Номально получается. Уж сколько лет... главное бардак в очереди не устраивать. А логика простая: в очереди продуктива все неперенесенные прошли через тестовую, а значит, после копирования продуктива в тест должны быть повторно импортированы в тест. В случае, если в тесте несколько мандантов, ситуация усложняется, но не слишком...

то есть ты тащишь не разницу - а все полностью? с начала времен?

Поскольку если разницу тащить - то будет бардак полный. Поскольку все коммулятивные уже в проде:) Или бардак в очереди не устраивать ты имеешь в виду следующее - убрать из очереди все промежуточные - включенные в коммулятивный?

По крайней мере процесс, практически автоматичекий - сравнили импорты - разницу загнали в буфер - импортировали здесь не проходит совсем.

Все конечно и на разнице сработает - если коммулятивные запросы корректны и включают в себя только необходимую и достаточную информацию. Но я как-то не настолько доверяю разработчикам, чтобы подписываться как гарантирующая инстация под этим действом.

Согласен, если копирование делается копией системы, то геморроя с запросами существенно больше, чем при копировании манданта. В последнем случае несутся только настройки, а их смысла аккумулировать нет.

а зачем разбираться? и чего там разбираться?

1. куммулятивный - можно соотвествующим образом макрировать

2. переносите просто все запросы в дельте - какойто или какието будут кумулятивными, все остальные - обычные. Просто одно и тоже дважды(трижды) перенесется.

в чем проблема то?
в том смысле что если положим у нас нет общего запроса - или мы об этом не знаем - значит просто переносим те запросы, которых нехватает. Или я не прав?

ммм ну впринципе я готов оговориться, что скажем речь не идет о консультантских запросах из spro.

Скажем ограничим применение такой "техники" запросами сугубо для переноса отчетов и только отчетов. ( Тоесть программы, инклуды, объекты словаря, ФМ ).

я ж сказала, что не настолько доверяю разработчикам, чтобы быть гарантией таких переносов. То есть дельта - это будут только обычные запросы - куммулятивные в дельту не попадут в принципе.

В общем все опять сводится к вопросу о том, кто отвечает за конечный результат таких экспериментов.
Если базисник - то мне такая идея нифига не нравится.
Если разработчик - флаг ему в руки. Хотя в конечном случае, если все стало плохо, разбираться опять базису.
Получается - что я против в любом случае

Техника в кавычках - это правильно. Есть хорошая практика - давать запросам на разработку осмысленные имена и последовательно нумеровать каждый последующий по данной разработке. Например:
MM: Движение болтов по складу -1
MM: Движение болтов по складу -2 и т.д.
Тогда фильтры можно использовать, что существенно облегчает управление очередью импорта

Переносы отдали другому отделу, так что они там теперь варятся

Хоть что-то полезное для базисников сделали....

впринципе куммулятивный запрос такаяже дельта. Тогда спешал фо ю - мы скажем что это обычный запрос, и все. Как обычный. А если, "нам, разработчикам", будет надо - метнем только этот запрос. Мы то знаем что в нём лежит
(это скорее шутка)

Вот тут согласен на 100%.
Но тут ИМХО должен быть такой расклад:

Вариант1 - если млин базис хрен дает права на SE09 и на STMS до теста - то флаг вам в руки, дорогой BASIS. Сами и разбирайтесь, какой запрос и когда должен идти. Ну тогда и люли будет получать Базис если что.

Вариант2 - Базис говорит - ну чо типа АВАРеры, вы типа модные перцы, мега-брайны, бабла рубите тут немеряно, (даже иногда больше нас), ну короче специалисты, нет проблем - нате вам права. Но с реквестами (обычными или кумулятивными) разбирайтесь сами. 90%ов люлей - если что - будете получать вы.

На мой взгляд - разработческий - вариант2 более предпочтителен.

Базис, на мой взгляд, должен заниматься более "тонкой" работой. А чего там в запросе, а как бы так перенести какойто хитрый объект, ляля. Может таблицу на уровне СУБД сохранить (такое было в практике - мега спасибо одному базиснику, еслиб не он, люлей бы отхватили все полные руки) ну вобщем чтото такое, системное. Ну собственно - БАЗИС.

Запросы должен создавать разработчик и отвечать за них должен сугубо разработчик. (исключение - порядок переноса. если базис перенес не в том порядке - ну тут извините)



Готовы взять этот флаг в эти вот кожаные ручки



хахаха - "бедный, бедный Базис" (ничего личного)

Причем при втором варианте флаг будет вынут из кожаных ручек и поочередно вставлен в интересное отверстие обеим сторонам

Да полноте Вам, №1.

Вы так говорите, помоему, потому что, простите, имеете ввиду когото конкретного, изза которого вам чуть ... ну впрочем не важно.
(Ну право слово - не тянет на агрумент)

Во-первых, как уже, помоему неоднократно, говорилось ранее - это вопрос skills-ов конкретного человека. Ну если вы приняли АВАРера вот "толькочто выучившего Дельфи, Юникс, Виндовз, ВБ-ВБА, и вообще супер студента", одним словом стажера, за 500 долларов - ну это одно. Если вы принимаете - и отдаете себе отчет в этом - специалиста скажем со стажем 5 лет и за 3-4 тысячи долларов, ну это я думаю всеже другая разница, согласитесь?


Во-вторых - а отчего такой, ммм, ну не знаю, "шовинизм" чтоли - вы то сами боги чтоли? или не ошибаетесь? Или думаете что являетесь недосягаемой "высотой", и правдой в последней инстанции (это ни в коем случае не наезд). На самом деле речь идет о специалисте с классом равным вашему (а возможно и выше ) - который(ые) пришли заниматься делом, а не делать все возможное чтобы завалить систему.


Таким образом, по-моему, все коллизии можно свести к минимуму. (И "погонами" можно не хвастаться.)

Вы так не считаете?

2 Egal
Eсли Вы считаете, что чем опытней разработчик/функционал, то тем тщательней он рабтает - Вы, таки, не правы.
А если уж идти по Вашей логике до конца - то писать разработки, при определенном уровне опыта, можно сразу в продуктиве.
И насчет "бедного базиса" как-то нехорошо прозвучало. В любом случае, чтобы не наворотили разработчики, все дерьмо приходится разгребать базису. И относится это не только к R/3. Любой пользователь, прибивший у себя кучу документов, будет доставать админа, чтобы тот исправил его ошибки.