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

Никто не думал, как можно уйти от корректировок?
Есть мысль при появлении изменений в заказе делать финт ушами - старый заказ закрыть, изменить номер и перенести в какой-то очень древний период, но остаются связанные документы - платежки, реализации и т.п. Боюсь, не взлетит. Есть какие-либо мысли по поводу?

Чем мешают корректировки?

Много чем. Например - написанные поверх механизмы используют номера строк ТЧ заказа покупателя - в РС хранятся всякого рода комментарии, чертежи, информация по резу.

У меня так реализовано. У менеджера в заказе есть кнопка "начать отгрузку". По ее нажатии стартует БП. Дальше заказ редактировать запрещено. Его можно только отменить из БП.

>Дальше заказ редактировать запрещено.

Полностью редактировать тоже нельзя. Желание клиента, тыкскыть, закон. БП как-то геморройно показалось. У меня скорость обработки заказа и отгрузки - один из главных приоритетов.

*полностью запретить редактировать нельзя

(4) заказ набирается на складе, а ты его корректируешь. Уверен, что это правильно?

Печально, но ваши написанные поверх механизмы видимо реализованы для документа, а не для регистров по заказам.
Просто и быстро переделать их под работу по данным регистров не получится 100%.

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

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

(7) Для движений регистров накопления их реализовать невозможно.
Про закрывать и делать новый - именно про это и вопрос: кто уже делал похожее, какие подводные камни?

(6) Клиент всегда предупреждается о задержках в отгрузке на неопределенный срок.

(9)А то что из за этого начинается путанница на складе и лишние транзакции не в счет?

(10) Из-за чего именно?

(7) +1.
Номера строк... это уже отдельная песня.
На регистрах возможен только учет, но не оформление :). Мои тоже хотят запретить в заказах порядок строк менять. Ну ну...
Отошли от Заказа. Сделали отдельный документ в котором и порядок строк менять нельзя и еще кое что, а на основании него вводится документ "Заказ покупателя".
Только вот с корректировками двойная работа. Нужно и первый документ корректировать, и корректировку заказа вводить.
В общем тоже интересно какие варианты получше можно придумать.

Использую - Изменение заказа - проще чем корретировка, но это в УПП, в УТ наверно только корректировка

ап. Еще мысли?

Как повлияет на производительность добавление еще одного измерения РН "Заказы покупателей" типа ХранилищеЗначения? Чтобы хранить там таблицы значений -  аналогичная колонка добавится в документа "заказ покупателя".

Это должно быть исключительной ситуацией и разруливаться уполномоченным человеком. Вплоть до возврата обратно по накладной "того чего не надо". На третий раз виновник будет думать лучше.
Если дать права делать с заказом чего хочешь наступит коллапс. Судя по постановке задачи песдетс уже подкрадывается.
Половина твоих проблем лежит в области административных действий и должны разруливаться руководством.

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

Вариант из УТ 11:

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

Документ разрешать перепроводить, но продумывать последствия.
ИЛИ кнопку, СФОРМИРОВАТЬ КОРРЕКТИРУЮЩИЕ ТРАНЗАКЦИИ.

сторнирование только в этом варианте мутно. думать надо.

(18) Не видел УТ11. Не совсем понял, измененные строки создаются копированием прямо в том же документе?
По описанию что-то напоминает "Изменение заказа" в УПП.

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

Заведите себе логиста )

Никаких действий непосредственно с первичным доком делать не следует

УП 2.0 (УТ 11) уже отошли от не следует.
Следует изучить практики, и принять верное решение.

(23) Я работал на адресном складе который сам же и писал.  Сборка началась, заявка полетела по частям по конвейеру. И тут умный менеджер - херак - меняет половину состава заявки. Да, я не удивлюсь если УПП такое поддерживает.

КЦ, сука, умный! ;-)
верьте ему...
.
у себя точно также делал очень похоже как у КЦ - заказы - только вводятся. любая корректировка - это новый корректировочный заказ. отмена заказа - это всегда документ специальный "отмена заказа". если заказ получил некий "железный" статус - все капец... его больше корректировать от балды нельзя... манагер его не скорректирует.. он уже ов власти другого подразделения...
.
а чтобы не было никакой путаницы: манагеры видят всегда срез только на сейчас - и ориентируются не по номерам заказов (посути это порядковый номер в журнале, он нам на! не нужен) - а по отдельному нумератору сделки в заказах...
.
как-то так...
.
не знаю как в снеговике - если корректировкиписать в самих движениях оригинального заказа сторнирую предыдущие и записывая текущие - то всегда есть риск при отмере проведения (внезапно случайно ну вот так случилось) - потерять всю историю развития заказа. - м.б. это и не критично бывает, а где-то критично...