В конце 2021 года принимал участие в подготовке к переводу организации, занимающейся оптовой торговлей, с модифицированной 1С:УПП на типовую функциональность 1С:ERP 2.5.7.
Одной из задач был корректный автоматический перенос статуса обеспечения товаров по заказам клиентов между базами. Коротко расскажу, чем пользовались пользователи в 1С:УПП для управления обеспечения товарами заказов клиентов (упоминаю только значимые для моих целей объекты):
А) Документ "Заказ покупателя", при проведении формируется запись в РН "Заказы покупателей" (остаточный), контроль неактуальных заказов не осуществляется;
Б) При необходимости закрепления товаров на основании "Заказа покупателя" формируется документ "Резервирование товаров", при его проведении формируется запись в РН "Товары в резерве на складах" (остаточный);
В) При необходимости оформления заказа поставщику на основании "Заказа покупателю" формируется "Заказ поставщику", при его проведении формируется движения в РН "Размещения заказов" (остаточный).
В ходе контрольно-следовательных мероприятий выяснилось, что состояние заказов клиентов никто не актуализирует. То есть, в РН "Заказы покупателей" висят актуальные и неактуальные заказы. При этом опираться на остатки по РН "Товары в резерве на складах", "Размещение заказов покупателей" тоже не совсем корректно, потому что по некоторым актуальным заказам не было записей по этим регистрам, так как они планировались к обеспечению собственным производством и достоверность данных в этих регистрах также была не 100%.
*в ходе решения задачи возникла мысль дополнительно сориентироваться на остатки взаиморасчетов, но так как это также не давало 100% результата, то заморачиваться уже не стал.
Классифицировал варианты статусов обеспечения позиций (в том числе части позиций) внутри одного актуального заказа:
- отгружены;
- сформирован заказ поставщику;
- сформирован резерв;
- не резервированы.
Типовой перенос переносит заказы полностью. Так как, основной инструмент менеджеров в 1С:ERP для управления обеспечением товаров находится внутри "Заказа клиента", то поинтересовались у "1С" по наличию инструментов для решения подобной задачи. 1С сказал просто: "просто перенесите только актуальные заказы с актуальными строками - ненужное оставьте в УПП". Менеджеры сказали: "ребята, если заказ хоть частично актуален нужно перенести все строки".
Решение проблемы с актуальностью
Так как менеджеры сказали, что свой список актуальных заказов они помнят условно, то договорились с ними о том, что мы предоставим им отчет в котором по нашему мнению будут собраны актуальные заказы (с 01.07.2021). Они на него посмотрят и вычеркнут ненужное и добавят нужное.
Сделали отчет "Данные для резервирования в ERP" со следующими данными:
- заказ покупателя, дата заказа, ответственный, номенклатура, единица измерения, процент/скидки наценки, количество заказа (данные взяты из ТЧ "Товары"/"Услуги" заказов клиентов, по которым есть остатки в РН "Заказы покупателей"*)
*было сильное подозрение, что данные РН могут отличаться от данных заказов
- остаток к отгрузке (данные из РН "Заказы покупателей");
- отгружено (разница между полями "количество заказа" и "остаток к отгрузке");
- количество резерв (данные из РН "Товары в резерве на складах");
- количество заказано (данные из РН "Размещение заказов покупателей");
- количество не распределено (рассчитывалось как разница между полями "остаток к отгрузке", "количество резерв", "количество заказано".
Для отчета был создан макет, в котором были выделены две области: подтвержденные номера и исключаемые номера. Собственно, отчет заранее отсекал заказы с исключаемыми номерами и при определении значения поля "Признак подтверждения" использовал данные из области макета "Подтвержденные номера".
Чего следует опасаться: гипотетически в рамках одного счета может быть на одно позицию использоваться разные скидки\наценки или единицы измерения (нет никаких технических ограничений). В этом случае, данные из РН "Товары в резерве на складах", "Размещение заказов покупателей" задвоятся.
Для вывода отчета использовался СКД, а формирование данных было вынесено внутрь модуля (можно все перевести в СКД).
Менеджеры отсмотрев историю определили список (письмо менеджерам с просьбой писал коммерческий директор - это важно!: в котором было сказано, что резервы по неподтвержденным заказам перенесены не будут), подлежащий выгрузке, мы откорректировали макет и фактически подготовили информацию для корректировки заказов в 1С:ERP.
*понятно, что после перехода менеджеры подходили еще, но так как это они проигнорировали распоряжение своего руководства - это скорее были просьбы, чем недовольство.
Перенос данных
Типовой механизм просто переносит заказы. Мы перенесли заказы за весь 2021 год (и поставили в непроведено), в строках указали обеспечение "Резервировать".
В отчете "Данные для резервирования ERP" добавили функцию отбора подтвержденных, по номеру, по списку номеров и выгрузки в файл XML данных по отобранным заказам (понятно, что если отбор не стоит, то выгружается все).
Перед выгрузкой итоговая таблица полученная отчетом переформировывалась. Фактически, каждая строка отчета разбивалась на несколько строк по видам обеспечения. Алгоритм определения обеспечения (взято прямо из кода):
//РАЗБОР КОЛИЧЕСТВА ОТГРУЖЕНО
//действие - ОТМЕНЕНО (в количестве равном значению поля отгружено), склад действия - из склада заказа клиента
//РАЗБОР КОЛИЧЕСТВА В РЕЗЕРВЕ
//действие - РЕЗЕРВИРОВАТЬ только для подтвержденных заказов, резервируемое количество вычисляется по формуле:
//?(Ожидаемая отгрузка - (Количество в резерве + количество заказано) < 0, МАКС(0, Ожидаемая отгрузка - количество заказано)) - приоритет у заказов
//из списка резервов находим по заказу и номенклатуре нужные резервы и до исчерпания расчетного резерва формируются строки ТЗ - склад действия из подобранных строк
//действие - К ОБЕСПЕЧЕНИЮ только для НЕ подтвержденных заказов, обеспечиваемое количество вычисляется по формуле:
//?(Ожидаемая отгрузка - (Количество в резерве + количество заказано) < 0, МАКС(0, Ожидаемая отгрузка - количество заказано)) - приоритет у заказов
//из списка резервов находим по заказу и номенклатуре нужные резервы и до исчерпания расчетного резерва формируются строки ТЗ - склад действия из подобранных строк
//РАЗБОР КОЛИЧЕСТВА ЗАКАЗАНО
//действие - К ОБЕСПЕЧЕНИЮ ОБОСОБЛЕННО, количество рассчитывается по формуле:
//мин(ожидаемая отгрузка, количество заказано)
//РАЗБОР НЕ РАСПРЕДЕЛЕННОГО КОЛИЧЕСТВА
//действие - К ОБЕСПЕЧЕНИЮ, только для подтвержденных заказов, количество равно оставшейся сумме
//действие - НЕ ОБЕСПЕЧИВАТЬ, только для неподтвержденных заказов, количество равно оставшейся сумме
Фактически, в xml выгружались следующие данные: GUID заказа, GUID номенклатуры, GUID склада (расположение резерва могло отличаться от склада заказа клиента), процент скидки/наценки, количество, определенный (вышеуказанным алгоритмом) тип обеспечения.
Структура файла:
<?xml version="1.0" encoding="UTF-8"?>
<Корневой>
<ЗаказКлиента GUIDЗаказПокупателя="313f5b23-51ba-11ec-9407-801844f2439d">
<ОписываемаяСтрока>
<ПризнакПодтверждения>Да</ПризнакПодтверждения>
<GUIDНоменклатура>9a3e5e4d-4b8c-11df-8a4e-4aac79b8fa0d</GUIDНоменклатура>
<GUIDРазмещение>3d1c86ee-0309-11de-89d4-001e8c647770</GUIDРазмещение>
<ПроцентСкидкиНаценки/>
<Количество>2,5</Количество>
<Действие>Отменено</Действие>
</ОписываемаяСтрока>
<ОписываемаяСтрока>
<ПризнакПодтверждения>Да</ПризнакПодтверждения>
<GUIDНоменклатура>cfe72ceb-b612-11e2-b2a4-ac162d7189ff</GUIDНоменклатура>
<GUIDРазмещение>3d1c86ee-0309-11de-89d4-001e8c647770</GUIDРазмещение>
<ПроцентСкидкиНаценки/>
<Количество>6,75</Количество>
<Действие>Отменено</Действие>
</ОписываемаяСтрока>
<ОписываемаяСтрока>
<ПризнакПодтверждения>Да</ПризнакПодтверждения>
<GUIDНоменклатура>cfe72ceb-b612-11e2-b2a4-ac162d7189ff</GUIDНоменклатура>
<GUIDРазмещение>3d1c86ee-0309-11de-89d4-001e8c647770</GUIDРазмещение>
<ПроцентСкидкиНаценки/>
<Количество>13,5</Количество>
<Действие>КОбеспечениюОбособленно</Действие>
</ОписываемаяСтрока>
</ЗаказКлиента>
</Корневой>
На стороне ERP была создана обработка, которая читала данные выгрузки (пользуясь тем, что типовая выгрузка сохраняет GUID'ы) и преобразовывала загруженные заказы клиентов по следующему алгоритму:
- собираются текущие данные ТЧ "Товары" документов "Заказ клиента" (группировка по номенклатуре, упаковке, виду цены, цене, проценту ручной скидки, даты отгрузки; суммирование полей количество, сумма, сумма ручной скидки, сумма НДС, сумма с НДС);
- для каждой полученной строки ищутся строки полученные из УПП (по полям заказ, номенклатура, процент скидки/наценки);
- исходя из полученных записей формируются новые строки ТЧ "Товары" "Заказов клиентов" (с правильным обеспечением).
*важно! если требуется вариант обеспечения "Резервировать", но товара на складе нет устанавливается вариант обеспечения "К обеспечению"
Важно, что если в перенесенном заказе в ERP количество больше, чем приехало из УПП (вдруг!), то лишнее количество установится в отменено.
Кроме того, в обработке есть возможность сверить состояния обеспечения заказа по файлу и по данным ERP (простой вывод табличного документа через построитель).
P. S. При необходимости могу помочь с аналогичным переходом.
P. P. S. Отчет сам по себе также может существовать.
Вступайте в нашу телеграмм-группу Инфостарт
