ЕРП. Нет запрета изменения данных документа ЗаказКлиента ?!?!
Юзеры спокойно заходят меняют и перепроводят
Не подскажите почему? К примеру в РеализацииТоваровУслуг есть проверка на "ДатаЗапретаИзменения" а в документе ЗаказеКлиента нет.

Развею Ваши фантазии.
Любые запреты реализуются программным кодом

Кстати, мы тут не вендор ЕРП.
Так что свою эмоциональность нам не выражайте

Ок

(0)

>>Не подскажите почему?
Потому что не нужно.

Что они у вас меняют и почему это плохо ?

Менеджер может и должен  менять свои Заказы клиента в той части, которая позволена ему бизнес-процессами компании.

>>К примеру в РеализацииТоваровУслуг есть проверка на "ДатаЗапретаИзменения"
Потому что изменение и перепроведение РТУ вызовет события по пересчёту ССТ и перезакрытию периодов. Дальше объяснять ?

А изменение Заказа клиента не приведет к перерасчету "расчетов по заказам"..?

(4)(5) Хороший вопрос, как раз таки изменение суммы ЗаказаКлиента, когда порядок расчетов "По заказам"?

(5) нет, все там будет хорошо.
(0) тема с редактированием заказа в ут11 уже поднималась, поиск по форуму рулит

(7) Разве все будет хорошо? Регистр распределения точно не будет сходится с товарными остатками. А распределение много где используется.

(0) Сделайте сами, глянул у себя - тут сделали раздел "Заказы".

(0) Я читал такое объяснение: жизненный цикл заказа иногда может длиться годами, поэтому его нельзя включать в обычную проверку даты запрета.

(10) +1
Вот мы создали заказ клиенту и уже три месяца с ним согласовываем цены. Или заказ, который отгружается в течении длительного срока несколькими итерациями и мы хотим какие-то неотгруженные еще позиции закрыть.

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

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

(0)
заказ это плановое действие.
не имеет отношения к регламентированному учету,
остаткам товаров.

Зачем его закрывать?

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