Статусы заказов покупателей для кладовщиков (и менеджеров)

Немножко про то решение, какое у меня в голове крутится:
Добавить в регистр накопления "Заказы покупателей" новый ресурс. Скажем, "КоличествоОбеспечено". И при загрузке данных с ТСД (при проведении документа "Множественный подбор заказов") делать корректировку (расход/приход) записей регистра с заполнением этого ресурса. При этом не очень хорошо понимаю, надо ли что-то менять в других регистраторах этого регистра накопления или и так все будет работать. И не понимаю, как быть в случаях, когда менеджер по продажам изменяет заказ покупателя задним числом. То же касается и варианта с новым регистром.

Как раз планирую доработку конфигурации выложить для УТ 10.3 для учета заказов (почти как в УТ 11.1). Все равно она уже с поддержки снята и обновлений не будет и можно выпускать свой cf или уже установчный.
Правда примитивные доработки планируются:
- новые перечисления по статусам заказов (Заказан, в работе, отгружен);
- добавляются статусы заказов в документы: Заказ покупателя и Реализация товаров и услуг;
Заказ считается закрытым если отгружен. Статус должен ставиться автоматически сам если полностью произошла отгрузка. Для этого нужен анализ при проведении документов реалазиации.
Преимущества только в отчетах и журналах где есть заказы и реализации: каждый статус у документа - строка со своим цветом. Только одни проблемы вылязят: и производительность падает и типовое нельзя затронуть.
А вот этот вариант у Вас, по моему уже лишний
Зачем отдельный документ делать? У заказа то есть ответственный? или не хотите плодить дерево документов по корректировке заказа?
А насчет
Тут Вы правы. Я его тоже взял за основу - если нет остатков по конкретному заказу в нем после проведения (перепроведения) реализации все ОК и можно изменить статус заказа. Я даже думаю потом проверить остатки еще раз: мало ли что в заказ программно могло прийти. Я про свойство "записывать" без проведения.
P.S. Да еще нужно учесть настройки учета: заказы могут быть в табличной части документа реализации, не только в шапке. У кого как.

Я решаю специфичную задачу. Конкретнее, оптимизирую бизнес-процессы на складе, сливая два процесса в один. Я и хотел изначально обойтись без новых документов и прочих модификаций типовой конфигурации, но не вышло из-за особенностей выбранного ПО для ТСД. Не умеет софт от Cleverence работать одновременно с несколькими документами, а надо! Вот и родился монстр под названием "Множественный подбор заказов". В 1с тоже можно было бы обойтись обычными заказами покупателей, да возникли сложности с загрузкой/выгрузкой заказов в ТСД и с отслеживанием выполнения заданий кладовщиками (не всегда кладовщик за смену успевает все заказы собрать на 100%). Все-таки проще их работу контролировать, когда информация о заданиях сохраняется.

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

Да и с регистром "Заказы покупателей" тоже есть идея не менять ничего в документах "Заказ покупателя", "Реализация товаров и услуг" и их корректировках, а отслеживать нужные изменения прямо в модуле регистра накопления. Не знаю еще, попадутся ли на этом пути подводные камни, но выглядит идея заманчиво.

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

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

Если для следующей смены - раз все не догрузили регистр не закрылся, есть остаток. от им и заниматься. Тут другие заморочки могут быть - например заказ может/ не может уехать не полностью укомплектованный )= работает ли правило 1 заказ =1отгрузка и т.д.

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

Какова структура реквизитов и процесс работы с документом МПЗ?
Что выгружается в ТСД и загружается обратно в МПЗ? Обзовем для простоты регистр Задания для склада.
по логике - мое предположение - в МПЗ изначально формируется задание конкретным кладовщикам (потсд-но например ) - список заказов на обработку.
Док провелся - в регистр попали документы - товары на обработку. В тсд ушли заказы товары. Кладовщик в тсд отмечает заказ и товар , который он набрал по данному заказу - фактически взял в точке а и положил на паллету Б в зоне подготовки к отгрузке. Далее в конце рабдня из тсд в МПЗ идет заказы товары, фактически набранные кладовщиком, МПЗ делает расход по регистру задания для склада. Логично что документа МПЗ скорее всего будет в рамках дня несколько - один на задание, второй на каждое тсд на исполнение задания (для сохранения хронологии). Таким образом фактически (физические) действия кладовщиков совпадают с программным отражением.
По поводу как - легко -)Если заказ есть в МПЗ и к нему не приступали - в регистре по нему есть остатки, если заказ есть в мпз и остатка по нему нет - заказ полностью набран.

Все, спасибо всем, сообразил, как надо сделать! :-)

Мне всегда было интересно, откуда у молодёжи антипатия к новым объектам... Ладно я во времена ассемблера боролся за каждый байт, но дети девяностых откуда про это знают??? Гены?
Эту задачу у крупных клиентов, один из которых со складом 24/7, я решал так.

Выше был задан правильный вопрос, что менеджер может изменить ТЧ заказа после передачи его в подбор. Это намёк на то, что надо иметь возможность просмотреть, что же конкретно передавалось в подбор. Кроме того, вспомним универсальное правило: если есть два события, у которых разные даты/время возникновения и разный инициатор, то это д.б. разные объекты ИБ. Отсюда правильный вывод: создаёт вводимый на основании заказа документ вроде "Задание на комплектацию". Этот документ вводится на основании заказа в момент принятия решения, что более этот заказ изменяться не будет и надо его комплектовать. Он включает в себя неотгруженную часть заказа. В нём фиксируется:
* ответственный - кто принял решение о начале комплектации;
* дата/время - когда было принято решение;
* желательная дата сборки - к какому сроку необходимо собрать;
* дополнительная колонка ТЧ "Количество (факт)" - для отражения, сколько товара реально нашли на складе и зашили в упаковку;
* флаги "подобрано", "проверено" и прочие, которые устанавливаются каждым складом/отделом_склада независимо (если их несколько);
* прочая информация, которая нужна кладовщикам;
На данный документ можно наложить условие, что он может вводиться по каждому заказу только в единственном числе.
Что, вся эта информация есть в оригинальном заказе покупателя? Зачем его корёжить? Чтобы иметь потом геморрой с обновлениями?
Конечно, этот документ проводится по отдельному регистру, ни в коем случае не трогая стандартный, т.к. из-за доп.измерений закрытый стандартным образом заказ может иметь незакрытые измерения и повисшие записи регистра. Уже сталкивался с таким хардкодом.
В результате проведения по отдельному регистру становится возможным создание отчётов по стандартному функционалу (УниверсальныйОтчет), которые освещают показатели учета:
* новые задания для печати листов на подбор или загрузки в ТСД;
* процесс подбора заданий и их завершённость;
* расхождения в ТЧ заказов и заданий на комплектацию - если менеджер внёс корректировки;
* расхождения в количестве по причине недостачи - чтобы провести локальную инвентаризацию.

Этот процесс работает у наших клиентов прекрасно и не вызывает проблем при обновлении.

PS: Забыл добавить! Конечно, необходимо использовать ордерную схему как минимум для отгрузок. В этому случае можно сделать заполнение ордера фактически найденным кладовщиками количеством.