Доброго.
Изменение заказа только корректировками.
Тут такая идея появилась у нашего руководства продажников.
Менеджер набивает заказ.
Потом начинается процедура его согласования.
Может поменяется количество, может поменяться набор позиций.
А идея такая, заказа набивается, переходит в некий статус принято.
А потом его менять можно только корректировками. Может кому такой механизм где попадался, мне бы глянут реализацию.

(0) ТиС. именно так, штатно.

1С:БП
Реализация товаров, услуг + Корректировка реализации.

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

(1) Это семерка же? еще живая?

(3)Я тоже как хочу. А то задрали меня вечные разборки.

(0) а что там глядеть то? При открытии формы смотришь - если под твои условия попадает документ (проведен в нужном статусе) - делаешь запрет на редактирование.

(4) а что с ней станет? Старый конь борозды не испортит

или перед записью вообще ))) - пользователь изменяет его, а записать не может )))

(6) Ну это заявка. А как показать все к нему корректировки?

(9) кому и зачем?

(9) в УТ10 была печатная форма заказа с учетом корректировок

(0) есть коммерческое предложение (то что вы хотите предложить), есть Заказ клиента (то что заказал из вашего предложения), есть реализация товаров и услуг (то что по факту вы реализовали). Все это еще под соусом статусов и причин отказа, что вам еще нужно то?)

(9) подчиненные документы для этого же придуманы?

(10) Оператору например. Открывает он заявку, а там половины уже нет.

(12) а вот по поводу корректировки реализации "Необходимость корректировок при отгрузке товаров может возникнуть как по нашей инициативе (нашли ошибку при оформлении документов отгрузки) или по инициативе клиента (при приемке товаров у клиента выявлены недостачи или излишки товаров)."

(12) Где такое есть?

(5) согласования, статусов и версионирования должно быть достаточно для этих целей

(12) так же есть еще версирование всего этого дела, всегда можете посмотреть, все версии документа и кто что правил.

(16) УТ11 велком

Приняли заказ, после обеда позвонил клиент и попросил добить пару позиций. Вечером товар стал на приход и мы ещё несколько позиций добавили в заказ и скинули общий счёт на оплату.
Мы же не коробками с 1с торгуем

а вот еще интересный момент "Заказ поставщику". В УТ11.4, КА2.4 для него нет корректировок и если заказ находится в закрытом периоде то его не поправить - двигает взаиморасчеты. И вот тут отдельный док-корректировка был бы очень кстати.

(5) ну так ты же вроде в 77 прогаешь тоже.
так что - какие проблемы? завинчиваешь гпйку (запрет изменения проведенных) - и херачат корректировочными.
чтобы остался с клиентом разговор в терминах сделки - заводишь в ЗаявкаПокупателя "номер сделки" (вариантов как реализовать - куча).

(12) мимо. нет сущности "что клиент хочет", а то "что заказал" - это то, что мы его удовлетворить можем из того что он "хочет"

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

(18) это тупо неудобно и годится только для шапочных реквизитов типа комментов, даты отгрузки итд. для "сравнения" тЧ - неудобно...
/
у меня примерно так (разность между "двумя заявками"  в данном случае "хотелка клиента - поставлено в резерв на отгрузку" https://content.screencast.com/users/Che66/folders/Capture/media/67da7c5b-80b4-43e5-b7ac-f66f3ff92451/LWR_Recording.png

(21) велкам в 77 ТиС - такое есть. активно мной юзалось в однйо непрсотой автоматизации.
.
и где такое что заказ поставщику двигает __взаиморасчеты_..? наверное это все-таки не взаиморасчеты, а немножко иначе называется/смысл?

(26)
>>и где такое что заказ поставщику двигает __взаиморасчеты_..? наверное это все-таки не взаиморасчеты, а немножко иначе называется/смысл?

ну это только у вас в ТИСах все фактическое а в новомодномейнстримных конфах еще есть и "плановые" ))

эххх ТИС... у мну была контора которая переписала ТИС под 8.1 практически один-в один и горя не знала 10лет...и тут к ней пришла КА2.4...гыыы

в ут 11 вообще корректировок нет, все изменения прямо в заказе

(27) плановые взаиморасчеты - ну так и надо говорить что плановые, а то насуют терминов хз пойми что. Как заказ - в тис если заказ - значит поставщикк, если заявка - значит покупателя. В ут/унф - без доп.уточнения хз повймешь про что речь про поставщика или покупателя

(29) в унф так же. При этом вроде как удобно, а с другой стороны костыли недодланные из всех мест торчат

(23) то что клиент хочет это и есть заказ клиента. Вам ни что не мешает, его хотелки, которых у вас нет на складе отметить отмененными позиции с нужной причиной. Так что не мимо.

(32) сейчас он хочет, а через час передумал.
Что делать?

Когда постоянный клиент это сплошь и рядом

(33) ну вот смотрите, каждый час клиент звонит и просит поменять один товар на другой. Зачем вам портянка из 10 вариаций, которых он каждый час менял? Да это есть в версиях документа, но где вы это учитывать будете? В спросе? Вот пример сферического коня в вакууме: блондинка звонит и каждые 5 мин "передумывает" то ли красную ей сумочку то ли "синюю". Через несколько часов все же решает остановиться на красной, но придя за ней в магазин и увидев там чуть другого фасона зеленую, покупает ее. Вопрос, а нахрена вам 20 вариантов корректировок с разными цветами сумки? Где вы это используете?

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

(36) такое же ощущение складывается.

(36) главное программиста озадачить)

(0)(11) в ут10.3 есть такое из коробки. Заказ покупателя и к нему хоть миллион корректировок. В заказе покупателя есть возможность распечатать заказ с учетом всех корректировок.

(32) тады приблизительно норм.

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

(35) проблема в одновременной правки заказа и реализации.
У тебя есть заказ на красную сумку, оперзал выписывает документы на склад на красную сумку как в заказе, менеджер зашел и поменял красную на синюю, кто виноват что клиенту пришла зеленая?

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

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

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

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

(0) в БиТ: Строительстве точно такая схема реализована с заказами поставщику...

(46) тогда по идее статусов достаточно.

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

(49) >немного вариантов: изменение количества, замена одной позиции на другую, ну и удаление или добавление позиций.
а какие еще теоретически могут быть варианты???? :-)
(48) статусы в текущей ветке УТ/КА/ЕРП сделаны через жопппу - из расчета, что контора покупает вагон холодильников, делает по 100 пересогласований в день, назначает скидки ("скидка покупателю за первый заказ 3% но не более 400 рублей, но если покупатель из козлодрищенска, то можно, но не более чем на полтора холодильника...)...

(50) да запросто, смена с ИП Пупкин на ИП Васюткин

(49) ну так если статусы есть то что мешает прописать запрет изменения документам с "посмертным" статусом.

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

(53) я с торговлей сто лет не работал но группы компаний помню еще с древнейших времен. когда клиент один а юплиц у него десяток. и эти часто подменяли и отгрузки и оплаты - сегодня через "Рога+" везем, завтра через "Копыта+" оплатим.

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

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

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

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

Во у меня бигбос родил.
Значится так, если заказ уходит на сборку его переводит в режим только для чтения.
Если кто-то что-то забыл и надо его откатить. То откатываем все связные доки, заказу делаем статус аннулирован и все заново.
Будет походу весело.

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

(59) ну адекватный босс )

(55) это да. в WMS это решается, но гемора все-равно выше крыши. Поэтому обычно ставят "время отсечки", после которого изменение заказа на отгрузку не принимается.

(59) отменяйте заказ и делайте новый. Будет вам история по "анулированным")

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

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

(59) в (60) примерно правильно описано...

(65) смотря как реализовать и какой склад. К примеру, отменили заказ, его товар хранится во временной ячейке, пока не переместят в старую/или оптимальную. Если же в течение дня отменили заказ, а потом сказали собрать новый, то на сборке будет указана временная ячейка, откуда и возьмется товар для заказа. Остатки временной ячейки разберутся в конце дня по складу.

(65) а вообще лучше запрещать редактировать заказ после согласования и оплаты и работать по предоплате)

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

(69) ага, но все равно допиливается весь этот функционал под текущий склад и бизнес-процессы.

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

(70) ну, само оно, никак не сделается... ;-)

(71) зависит от упаковки. Наблюдал "mateur video" когда разгружали примерно пол-фуры, вытаскивали паллету, обмотанную стрейч-пленкой в 100500 слоев, разпаллечивали  и добавляли товар. Потому, что термологгеры, и термобарьеры. И если "наш" товар окажется "перед" термомобарьером, а не "за", или будет незапаллечен - уже будут вопросы по его терморежиму, он же отдельно от логгера... а значит, мы имеем право его не принять, а оно не надо ни поставщику, ни перевозчику, ни нам...
В общем, ситуации бывают сильно разные, и где-то леХко, а где-то авотхрен.
(64) ээээ, "система витязь"????
(67) да, "во временной ячейке". кто-то его должен туда положить. для того, чтобы положить товар (ладно если пять кило, а если тонна?) туда, его нужно взять откуда-то и переместить на какое-то расстояние. А комплектовщики обычно "на сделке", и собирают за смену 3-4 тонны... вот если ему сказать, что его 2 часа работы надо куда-то "откатить"? он ведь может и накатить!

(73) Система "Витязь" - сделал я, а вы - еб..есь!

(73) сделанную работу откатить нельзя. жизнь невозможно первернать назад. и это хорошо. только так и удается "лечить" всяких манагеров.

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

(76) +100