я говорил за сам метод слияния и больной, но все же альтернативы LSMW )))

я наоборот создавал и расширял объекты логистики на основании предложенного и описанного подхода

@ Sedlo Едва ли кто-то в здравом уме будет удалять из продуктива коды, которые использовались в документах, по меньшей мере - до архивации этих документов Что касается системы разработки - имхо, всегда лучше создать свою схему ZTAXRU, тогда и проблем потенциальных будет меньше, и стандартные коды "выпиливать" будет не нужно.

@ Justudent Рад, что вам понравилось Меня эта схема когда-то тоже очень повеселила, и много времени сэкономила

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

1) К счастью, нет.
2) Да, от здравого ума. Я не вижу ни одной причины, по которой нужно обязательно использовать / изменять стандартную процедуру, а не копировать ее в свою и модифицировать под себя. Со сбытовыми прайсинговыми процедурами, к примеру, именно так и работают, почему этот отросток прайсинга должен быть исключением?

По хорошему, вы правы. Но, лично видел, как в коде прописывали 'TAXRU' (вместо того, чтобы определять его по настройкам). Вы возразите, что нужно программы разрабатывать правильно, но жизнь она такая, зачем лишний раз создавать возможность ошибки и создавать схему ZTAXRU?
С прайсинговыми схемами сравнение некорректное, так как на проектах схем в SD создается несколько для разных торговых документов и для разных ситуаций (лично делал несколько по объективным причинам и сейчас на проектах вижу несколько схем), а в налогах схема всегда одна и привязана к стране.
Сам люблю копировать стандартные настройки в Z*, но не в данном случае...

Plank, я с вашим аргументом согласен, но ведь риски есть и с другой стороны - нет 100% гарантий, что в новых разработках российской локализации не появится недокументированных сюрпризов со ссылкой на TAXRU. Используя ZTAXRU, мы избегаем риск того, что при тестировании упустим такой сюрприз.

Я совершенно не спорю, что вариант с использованием TAXRU рабочий и корректный. Пожалуй, если мне бы нужно было сделать подобную настройку сейчас, я бы пошел именно по этому пути, так как по совокупности факторов он с моей точки зрения немного лучше. В 2007, когда началась дискуссия в этой ветке, я по ряду причин считал, что ZTAXRU немного предпочтительнее. По большому счету, никакой разницы между этими вариантами при корректной процедуре контроля изменений в продуктивной системе нет