При проведении реализации необходимо модфицировать Заказ покупателя (реквизиты, ТЧ). Это не есть хорошо

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

1) Тормоза
2) Транзакции
...

(0) Вывести в отдельный регистр сведений. В дальнейшем, информацию из этого РС вывести на форму документа "Заказ покупателя", если это нужно.

(0) Ну например: что делать при отмене проведения реализации? Размодифицировать Заказ покупателя? Тогда придётся где-то хранить его состояние до модификации.

(1) лучше в отдельную ТЧ
(2) про распроведение речь не идет. Действия только при проведении

(0) что должно происходить если потом эти реквизиты в ручную поправили в зад.

(3) нет как раз более правильно в регистр

(0) ошибка блокировки транзакции если заказ в это время открыт

(0)посмотри в типовой, как изменяется счет фактура при имзенении авансовых отчетов или реализаций и и.п.

1) (2) ++

Что делать с заказом при перепроведении РТиУ, что делать при изменении заказа после модификации РТиУ, что делать, если в РТиУ несколько заказов, или на один заказ несколько РТиУ.

2) Документ - это первичка, хозяйственный факт. Как то странно, что один один факт меняет какой то другой в прошлом. Нарушение логики и правил работы чревато огромным техническим долгом

3) С блокировками и транзакциями может случится большая веселость, особенно если что то валится внутри заказа и РТиУ не проводится со словами "В данной транзакции уже происходили ошибки"

4) Мой любимый аргумент - ".опой чую, что так делать плохо"

(0) >> Это не есть хорошо
Почему?
В бухе при проведении реализации изменяется счет-фактура. Никто не помер от этого.

(0) тормоза не сильные будут
плюс будут выскакивать ошибки при записи заказа например  заказ был в закрытом периоде а реализация прошла в открытом

(0)[Это не есть хорошо ]
это есть плохо,
это есть прямой путь к уничтожению Заказа как нужного документа

(9) никто не помер потому что счет-фактура на основании реализации, т.е. меняется потомок, а тут какбэ предок

у нас в базе есть документ Доставка, в нем учитывается стоимость и вес товара (в табличной части). документы реализации уже после проведения доставки могут меняться (после  подтверждения доставки это вообще нежелательно). я сделал регистр, где после проведения реализации устанавливается признак. пересчет в доставке происходит при ее открытии пользователем, либо раз в 20 минут фоновым заданием

(3) "про распроведение речь не идет. Действия только при проведении" - тогда вообще получается идиотизм:
1. Сделали заказ
2. Провели реализацию - заказ изменился.
3. Удалили/распровели реализацию, а заказ остался изменённым.

И вообще, непонятно, зачем реализация должна менять что-то в заказе?

(9) потому что в бухии сф это связанный(можно сказать придаточный) документ попробуйте ради прикола сделать так чтоб в сф был один набор номенклатуры а в реализации другой или просто создать сф без реализации . Связка заказ -реализация это набор обособленных документов (хотя реализация и вводится на основании заказа) но в заказе и реализации можно вести совершенно разную номенклатуру а так же можно создать реализацию ваще без заказа.

(13) т.е. у вас учёт никак с реальностью не связан?

(17) все реально. не понял вопроса. в доставке сохраняется старая (подтвержденная сумма реализации) и новая (после возможных изменений)

(0) Это не нужно. Если кому-то кажется, что это нужно - порекомендуй креститься.

P.S. Юзеры ленятся делать закрытие заказов?

(18) Ну смотри: допустим, подтверждения ещё нет. Вы отгрузили на 100 рублей. Сделали доставку на 100 рублей. Потом изменили реализацию на 200 рублей: ваша доставка тоже изменилась. Пришло подтверждение на 100 рублей, а по вашим данным получается, что вы якобы отгрузили на 200. Кто виноват?

+(20) И одна только сумма ещё полбеды. А если кому-то в голову придёт номенклатуру изменить, добавить/удалить позиции?

(20) меняется не стоимость самой доставки, а стоимость доставляемого товара или вес, соответственно меняется только распределение стоимости доставки по документам

(20) если они уже сделали доставку, то зачем менять реализацию??

(22) т.е. у вас товар в дороге может изменить вес или стоимость? Это как вообще?

(21) подтверждается (устанавливается галка и фамилия юзера) стоимость доставки, а не номенклатура внутри документов

(23) т.н. "вычерки", товар не доехал, документами корректировки реализаций у нас не пользуются

(23) Откуда я знаю зачем они это делают? Спрашивай у (13).

(26) "товар не доехал" - выпили по дороге? :)

в общем вы зря пытаетесь вникнуть в нашу ситуацию, у меня проблемы нет проблема у автора. я просто предложил способ решения, когда не надо мгновенно изменить данные

(28) возможно и это. а также на складе не положили, раздавили и т.д.

(0)Яйца курицу не учат. В данном случае Реализация - это яйцо.

(30) т.е. вы такие вещи никак в учете не отражаете, а просто правите первичку задним числом? Вот это я и имел ввиду в (17)

у одного заказа 2 реализации, интересно что получится :)

(32) да

Так делать нельзя. А как надо? Я пришел к такой схеме: документ Заказ - это шапка. Строки заказа - записи РС. Меняются независимо разными документами реализации и оплаты. Проблем почти нет. Статус есть у каждой записи РС и у Заказа в целом.

(34) А если счет-фактура с печатью уже уехала?

(36) а как у вас действуют в такой ситуации: привезли товар, не хватило коробки чего-либо. клиент забирает товар без документов? или клиент ставит свои подписи на документах и подписанные экземпляры возвращаются к нам

и с учетом это вообще в данном случае не связано

(37) и третий вариант машина обратно все загружает при обнаружении расхождений и привозит обратно на склад...

вопрос по организации учета неотфактурованных поставок и собственно отфактуровки?

(36) А если не уехала? Для этого существует временной интервал в течении которого документы могут быть отредактированны

Или статусы у документов, в частности статус документа доставки - "Машина уехала" и соответственно блокировка изменения документов

а если перепутают и ошибки исправлять?

(42) И что?

Опять таки куча механизмов, начиная от "ответственного сотрудника" который может вертать статус взад и заканчивая корректирующими документами, например "возврат с текущий доставки"

(43) да, и что? потом будут просить программиста убирать галку что машина уехала, менять и снова просить поставить эту галку...

(45) и?

(44) я представляю требуемый профессиональный уровень операторов, они запутаются в этих корректировках

(0) нелепый топик
ТС свинтил не указав главного что и как он меняет в Заказе

всё остальное чистый флюд

(47) Не знаю у меня заявка от покупателя после проведения нельзя никому редактировать. Корректировка - только через механизм ввода на основания. И ничего никто из менеджеров не путается

Реализации оператор может править только в течении дня, потом через механизм возвратов (при этом печатные формы учитывают возвраты) и ничего никто из операционистов не умер

(47) + на самом деле проблема у нас существует одна и она там, где бы никто не подумал - в оплате по документу. когда уменьшают сумму реализации, а она привязана в оплате ПКО, возникает предоплата по документу реализации, и в свою очередь возникает проблема у бухгалтерии со счетами 62.01-62.02
даже если будут использовать документ "корректировка реализации" вместо изменения реализации, эта проблема так и останется

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

(50) Ну так это проблема практически не имеет решения, так как есть выписки которые разносятся задним числом

стало заметно медленее - без создания документа 1 секунда, с создание 4 секунды

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

(15) логика такая. При проведении реализации могут возникнуть ошибки (большая дебеторка, нет товара на остатках, нет цен и т.д) или, при автоформировании, будут удаляться позиции, которых нет на остатке.
Т.е надо фиксировать почему клиенту не отгрузили, то что он хотел

(54) будет куча защит от дурака

(55) ну так и описываете все в регистре зачем в заказ писать,а потом и отчет проще наклипать будет сколько мы прибыли упустили из-за того этого.

по ТЗ надо писать именно в заказ. Поэтому и ищу аргменты против

ну самый противный это, если объект заказ кем то захвачен то невозможно будет провести реализацию. Если база sql  то возможна следующая картинка менеджер  открыл заказ сеть лагнула появился "демон" на рпхосте (просто висящая  блокировка которая сама отвалится через некоторое время) менеджер тем временем перезаходит в 1с и пробует провести реализацию получает все прелести блокировки транзакции до тех пор пока либо админ (программист) прибьет зависшую блокировку  либо она сама не пройдет по времени.

(0) А зачем изменять реквизиты и ТЧ?
Как понимаю, обычно у заказа меняется только статус на "Выполнено". Остальное зачем меняется?
А статусы лучше не в самом документе менять, а через РС, как тут советовали выше.

(58) А кто мешает писать в регистр, а в заказе просто отображать данные из регистра? Для заказчика это будет равноценно, а проблем будет на порядок меньше.