Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Оглавление

• Вступление
• Ограничения при описании
• Термины и определения
• Параметры проекта
• Обновление конфигурации
• Бизнес цель проекта
• Выбор конфигурации системы
• Ключевой функционал ERP, который сложно внедрять на каждом проекте (по мнению автора)
• Ключевые архитектурные изменения
• Общий подход к управлению запасами
• Предварительные настройки системы
• Замена действий Заказа клиента
• Пример бизнес-процесса
  • Оформление Заказа клиента
  • Формирование отчета "Анализ заказа клиента"
  • Оформление Корректировки заказа клиента
  • Оформление Заказа на обеспечение
  • Формирование отчета "Анализ заказа на обеспечение"
  • Оформление Корректировки заказа на обеспечение
  • Рабочее место по обеспечению
  • Рабочее место по закупкам
  • Изменение подходов к расчету свободного остатка и индикация в отчетах
  • Оповещение перед установкой товаров в резерв
  • Установка товаров в резерв и оповещение об этом
  • Выполнение обмена резервами
  • Оформление Перемещения товаров
  • Взаимодействие с транспортным отделом
  • Оповещение перед снятием товаров с резерва
  • Отгрузка товаров клиенту
  • Изменение качества товара

Вступление

Все описанное в статье - это субъективное мнение автора исходя из опыта внедрений.

В декабре 2012 года я написал статью по внедрению крупного проекта (//infostart.ru/1c/articles/166856/). На тот момент это был мой первый опыт внедрения такого масштабного проекта в составе большой команды и хотелось поделиться этим опытом.

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

В 2021 году начали проект в дистрибьюторской компании. Имея большой опыт внедрения УПП, периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобно, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала). После завершения этого проекта появилось желание написать статью.

От желания до публикации прошел год :)

Ограничения при описании

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

Если будет интерес к каким-то отдельным механизмам, то отвечу в комментариях.

Термины и определения

• Склад потребности – склад, с которого планируется отгрузка товара клиенту;
• Склад резерва – склад, где физически находится товар;
• ЗнО – Документ «Заказ на обеспечение». Ключевой объект системы, который является разрезом обеспечения. Вся функциональность, связанная с обеспечением что была в документе «Заказ клиента» вынесена в него.
• Доступный остаток – остаток товара на складе, который не распределен ни одному заказу и его можно отгрузить «сейчас».
• Группа обеспечения - разрез в рамках, которого объединяются разные склады для решения задач обеспечения. Например, «Склады МСК», «Склады ЕКБ», «Склады ДВ» и т.д
• Настройка обеспечения – настройка, в которой для каждой группы обеспечения указывается в каком порядке и на каких группах обеспечения система должна автоматически выполнять поиск доступных складских остатков.
• Сигнальное событие – событие, которое требует участие специалиста отдела логистики, для определения варианта обеспечения потребности.
• Состояние обеспечения – состояние в системе обеспечения, по которому понятно какого товара достаточно, а какого нет.
  • Обеспечить – потребность необходимо закупить или произвести (полноценное производство или просто сборка товаров);
  • Обеспечен на складе – потребность сопоставилась с доступным остатком на складе;
  • Обеспечен к дате – потребность, сопоставленная с доступным ожидаемым поступлением (заказ поставщику, заказ на перемещение, производство, сборка);

Параметры проекта

• Срок проекта (Февраль 2021 по Июнь 2022)
  • Февраль по Апрель 2021 – обследование и моделирование;
  • Май 2021 по Март 2022 – проектирование, разработка, тестирование, тестовая миграция данных;
  • Апрель 2022 АД :), работа всех пользователей в новой системе;
  • Май 2022 стабилизация;
  • С Июнь 2022 поддержка и развитие системы.
• Команда проекта ИТ
  •  Руководитель проекта
  • Архитектор по финансам (взаиморасчеты, казначейство, упр. учет по методике Заказчика);
  • Архитектор по продажам, логистике;
  • Архитектор по закупам и транспорту;
  • Аналитики – 3 чел.;
  • Разработчики по функционалу – 4 чел.;
  • Разработчики по интеграциям и загрузке остатков – 4 чел.;
  • Ключевые бизнес-пользователи Заказчика – 20 чел.
• Переход в одну базу с нескольких систем, в которых работали от 10 до 15 лет.
  • Axapta – 1 база;
  • 1С самописная – 7 баз
  • 1С на базе УТ 10.3 – 1 база
• Среднее количество одновременно работающих пользователей в одной базе ERP: 450.

Обновление конфигурации

Конфигурация обновляемая;

В июне 2023 года выполнили обновление с релиза 2.5.7.279 на 2.5.12.48 (почти 2 года не обновляли не было необходимости). Все затраты на подготовку обновления, тестирование, обновление рабочей базы и исправление ошибок после обновления составили 597 часов (1 человек 100% и 4 человека не 100% в течение 1,5 месяцев).

Бизнес цель проекта

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

Выбор конфигурации системы

В начале обследования Заказчиком рассматривались отдельные три базы ERP, УХ и Документооборот. По результатам обследования остановились на одной базе ERP. В начале обследования не было даже бета релиза 2.5.7, но понимание уже было, что к моменту начала разработки хотя бы бета версия уже будет. В результате не имея конфигурации, но представляя по презентациям с форума 1С приняли решение, что будем использовать 2.5.7, т.к. архитектура функционала по обеспечению подходила лучше. К концу обследования релиз 2.5.7 уже появился.

Ключевой функционал ERP, который сложно внедрять на каждом проекте (по мнению автора)

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

• Выполнение корректировок заказов в самих заказах; (тут принципиальный методический момент, в УПП как раз использовались отдельные документы). Есть история версий заказов, но, когда нужно собрать разные отчеты по корректировкам заказов, версиями уже не обойтись;
• Обеспечение внутри заказов. Это отдельная боль, она в 2.5.7 стала чуть лучше, за счет того, что «К обеспечению» не приводит к разбиванию строк документа, но с точки зрения наглядности данных и производительности решение все же не удачное.

Например, заказ клиента. На больших предприятиях сотрудники не занимаются массово ручной установкой действия "Резервировать на складе" это делает система автоматически. И тут начинаются проблемы. Заказ клиента мог быть на 50 строк, а после резервирования уже на 500 строк. В результате теряется наглядность, возникают ошибки округления.

К производительности отдельный большой вопрос. Например, есть ходовая позиция товара, которая встречается в 1000 заказов клиентов, товар пришел на склад и согласно бизнес-процессу нужно этот товар зарезервировать в 1000 заказах клиентов. Делается это автоматически и если использовать типовой функционал, то нужно обработать все 1000 заказов, где-то разбить строки и перепровести их. Команда разработки ERP не любит сравнение с УПП, но в УПП достаточно было ввести один документ «Резервирование товаров» и в таб. части перечислить все 1000 заказов. Разница очевидна, обработать и перепровести 1000 документов или 1. При этом если потребуется откатить операцию, то в случае УПП достаточно просто отменить проведение документа «Резервирование товаров», а в случае с ERP простого решения уже нет. Плюс удобство построения разных отчетов по снятию с резерва и установке товаров в резерв, по версиям это опять же сложный и длительный процесс. В общем мы пошли подходом, который был реализован в УПП и сделали отдельный документ «Резервирование товаров» интерфейсно копия с УПП.

• Обеспечение в рамках одного склада, а если складов несколько со своими МОЛ и еще территориально распределенными, то тут уже по методологии нужно использовать Заказы на перемещение. Но нормального инструмента по актуализации заказов на перемещение в конфигурации нет. Но даже если бы и был, то снова имеем огромный объем ссылок для актуализации, что очень нехорошо для производительности. А изменение потребности происходит постоянно (что-то добавить, что-то убрать). Можно, конечно, завести один ордерный склад и разные помещения, но для задач логистики помещений нет в ключевых регистрах, на которых строиться обеспечение. Да и использовать ордерные склады без необходимости дело сложное, у пользователей вводящих первичку объем работ увеличивается.

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

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

• Отсутствие в механизме обеспечения серий. Таким образом все что связано со сроками годности и датами производства в обеспечении не доступно; К этому пункту отдельные вопросы и не понятно, почему его сразу не реализовали, когда делали «новое» обеспечение. Пришлось реализовывать в рамках проекта.
• Отсутствие возможности включить использование ордерного склада только для схемы «Перемещение товаров». Есть схема работы со статусом перемещения, но, когда на складах разные МОЛ это не подходит. Ордерную схему для склада можно включить только отдельно для всех операций «Отгрузки» или «Приемки». Пришлось, сделать отдельную настройку для того, чтобы не включать ордерность при отгрузке и приемке, но, чтобы перемещения работали по ордерной схеме.

• Функционал по учету товаров с различным качеством. На партнерской конференции по этой теме в свое время были большие обсуждения, но все они остались без внимания. Насколько хорошо этот функционал был реализован в УПП через отдельное измерение в товарных регистрах, настолько неудачно он реализован в ERP через заведение отдельной номенклатуры под каждое качество.

Мы в рамках проекта не стали реализовывать этот функционал в подходе как это было сделано в УПП, т.к. на существующей архитектуре это очень трудоемко, добавлять во все регистры обеспечения и товародвижения отдельное измерение «Качество».

Так как у нас вся номенклатура ведется по сериям мы вынесли этот разрез в серию. Реализовали отдельный интерфейс для назначения разных признаков неготовности (качеств) одной серии. В этом интерфейсе пользователь может от исходной серии на нужное количество автоматически создать новую серия со всеми параметрами как у исходной и с выбранными признаками неготовности. В результате формируется типовой документ «Пересортица товаров».

Признаки неготовности содержат признаки, которые отвечают за запрет отгрузки серии и ее автоматическом распределении  в запасах. 

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

Ключевые архитектурные изменения

• Разделение процессов резервирования и отгрузки товаров, без необходимости корректировать исходный заказ;
• Вынос функционала обеспечения из заказов;
• Изменение алгоритма распределения запасов (анализ складских остатков и ожидаемых поступлений на разных складах, в т.ч. в разрезе серий) и подхода по расчету свободных остатков на складах;
• Интеграция подсистемы доставки с обеспечением;
• Изменение подходов при работе с качеством (признаки неготовности);
• Отдельные рабочие места для закупок и логистики.

Общий подход к управлению запасами

При возникновении потребности система выполняет поиск доступных остатков на складах группы обеспечения «Склада потребности», дальше на складах по настройке обеспечения. Если по товару есть доступные остатки, подходящие по критериям (сроки годности, качество), то система автоматически сопоставляет такие товары (состояние обеспечения «Обеспечен на складе»). Если потребности обеспечены не все, то в таком же подходе анализируются доступные остатки в Заказах поставщикам, Заказах на перемещение, Заказах на обеспечение с видом «Сборка». Распределенным потребностям в заказах устанавливается состояние обеспечения «Обеспечен к дате».

Все что не удалось распределить получает состояние «Обеспечить».

Если по таким потребностям нет сигнальных событий (виды сигнальных событий описаны в разделе «Пример бизнес процесса»), тогда они автоматически попадают в «Рабочее место по закупкам». Если сигнальные события есть, то их отрабатывают специалисты отдела логистики (ЗнО делятся по специалистам отдела логистики автоматически), которые решают, все же нужно передать товар в закупку или предложить имеющийся товар, но с худшими характеристиками. Через сигнальные события реализован подход, что логистика должна реагировать только на отклонения от стандартного процесса.

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

В системе реализован алгоритм автоматического перераспределения запасов, даже если не будут происходить никакие изменения данных в системе. Это нужно для того, чтобы перераспределять товар, не отгруженный вовремя и по которому сопоставленные серии, больше не подходят по предъявленным требованиям к срокам годности, датам производства или качеству.

Предварительные настройки системы

В связи с тем, что мастер система для ведения НСИ отдельная и для упрощения работы с НСИ было принято решение отказаться от типового функционала схем обеспечения.

Ввели новой понятие «Группа обеспечения». Это разрез в рамках, которого объединяются разные склады. Например, «Склады МСК», «Склады ЕКБ», «Склады ДВ» и т.д.

Каждый склад может принадлежать только одной группе обеспечения. В склад добавили новый реквизит «Группа обеспечения».

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

Например, при возникновении потребности в товаре во Владивостоке, система сначала выполняет поиск доступных остатков на складах Владивостока, дальше на складах Новосибирска, затем Москвы, далее Екб и т.д.

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

Замена действий Заказа клиента

Пример бизнес-процесса

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

• Оформление Заказа клиента (Документ «Заказ клиента»).

Из заказа клиента убрано, все что связано с обеспечением. Заказ в данном случае является просто намерением Клиента что-то купить у компании по определенным ценам и в оговоренные сроки;

• Формирование отчета "Анализ заказа клиента"

Из заказа клиента есть возможность сформировать отчет «Анализ заказа клиента» в котором выводится вся необходимая информация для понимания обеспечения и отгрузки заказа. В отчете выводится информация по всем заказам на обеспечение, оформленным по заказу клиента.

• Оформление Корректировки заказа клиента

Если возникает потребность в каких-либо корректировках заказа клиента (уменьшить/увеличить количество товара, добавить/удалить товар, изменить цены), то эти действия выполняются через документ «Корректировка заказа клиента»;

• Оформление Заказа на обеспечение

На основании Заказа клиента оформляется «Заказ на обеспечение» это ключевой документ подсистемы обеспечения. В «Заказе на обеспечение» для заказа в целом или для каждой строки товара задается склад потребности. Это склад с которого планируется отгрузка Клиенту, товар и количество, дата отгрузки, когда товар нужно отгрузить Клиенту и требования к сроку годности на дату отгрузки (например, остаточный срок годности товара на дату отгрузки должен быть не меньше 70% или 160 дней). По результатам оформления этого документа, система выполняет поиск подходящего товара на складах, согласно настройкам системы. Для каждого склада потребности настраивается свой порядок обеспечения. Например, для склада потребности в Хабаровске поиск подходящего товара сначала выполняется во Владивостоке, затем в Екатеринбурге, далее в Москве и т.д.

• Формирование отчета "Анализ заказа на обеспечение"

Из заказа на обеспечение есть возможность сформировать отчет «Анализ заказа на обеспечение» в котором выводится вся необходимая информация для понимания обеспечения и отгрузки заказа. В отчете выводится информация только по выбранному заказу на обеспечение.

• Оформление Корректировки заказа на обеспечение

Для изменения параметров обеспечения используется документ «Корректировка заказа на обеспечение». С помощью него изменяются: дата отгрузки, количество и список товаров, требования к сроку годности, склад потребности (планировали отгрузку из Хабаровска, но сроки уже не позволяют и принято решение везти товар Клиенту напрямую из Екатеринбурга). В результате оформления этого документа происходит автоматический пересчет обеспечения.

• Рабочее место по обеспечению

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

Такие отклонения реализованы в системе при помощи сигнальных событий:

• Есть остатки на других складах – подходящий по предъявленным требованиям к срокам годности и датам производства товар есть на других складах компании, которые система обеспечения не анализирует автоматически (например, потребность в Москве, а товар есть в Хабаровске). В этом случае логистам нужно принять решение, передать его в закупку или привезти с других складов компании;
• Есть остатки с истекающим сроком годности – товар, НЕ подходящий по сроку годности или дате производства есть на складах, которые система обеспечения анализирует, но не сопоставляет автоматически;
• Есть остатки неготового товара – товар, НЕ подходящий по качеству есть на складах, которые система обеспечения анализирует, но не сопоставляет автоматически;
• Есть остатки на других складах (ИСГ или неготовый) – товар, не подходящий по сроку годности, дате производства или качеству есть на складах, которые система обеспечения НЕ анализирует автоматически;
• Опоздание отгрузки – в ЗнО есть товар, который не успевают отгрузить в срок;
• Опоздание закупки – в ЗнО есть товар, который не успевают закупить в срок, чтобы успеть отгрузить товар клиенту не позже согласованной с ним даты отгрузки;
• Есть свободные остатки в заказах поставщикам – товар, есть в заказе поставщику, который едет в свободный остаток, т.е. никакой ЗнО еще не распределен в такой заказ поставщику. Но система не смогла распределить потребность из-за различия в признаке обособления или закупаемый товар не подходит по предъявленным требованиям к сроку годности или дате производства, или товар должен приехать на склад, который система обеспечения не анализирует автоматически для ЗнО (например, потребность в Екатеринбурге, товар едет во Владивосток).

В рабочем месте по обеспечению реализованы различные фильтры, один из них — это оставить только ЗнО по которым есть не отработанные сигнальные события.

Количество, которое есть на остатках можно расшифровать и понять, что это за остаток.

По примеру, есть остаток товара, не подходящий по сроку годности или качеству на складе, который не входит в периметр автоматического сопоставления.

При необходимости на расшифрованный остаток можно установить резерв на складе, где есть товар или в заказе поставщику.  При этом товар может находиться на складе, отличном от склада потребности Для этого нужно выделить строку с сигнальным событием и нажать кнопку «Резервирование». В открывшемся диалоге на закладке «Остатки на складах» устанавливается резерв в складских остатках. Там же можно увидеть на каком именно складе товар есть в свободном остатке. На закладке «Ожидаемые поступления» устанавливается резерв в заказах поставщику. Нужно ввести количество, которое требуется установить в резерв и нажать кнопку «Записать и закрыть». В результате автоматически формируется документ «Резервирование товаров» и товар устанавливается в резерв на складе. Или товар обосабливается и назначение прописывается в Заказ поставщику, таким образом выполняется резервирование в заказе поставщику.

Специалист отдела продаж видит в отчетах, что товар под его Заказ клиента или ЗнО находится в резерве и его можно перемещать, т.к. склад потребности и резерва отличаются.

Если перед тем, как установить в резерв нужно получить согласование от ответственного за ЗнО сотрудника отдела продаж, тогда в форме расшифровки указывается количество, которое нужно согласовать и нажимается кнопка «Сохранить и закрыть». Товары попадают на закладку «Согласование СГ» и с нее по одной кнопке создаются документы «Согласование сроков годности» и запускается процесс согласования документа внутри ERP.

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

• Рабочее место по закупкам

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

• Изменение подходов к расчету свободного остатка и индикация в отчетах

В типовом решении расчет свободного остатка выполняется в транзакции проведения документа. Т.е. сначала в рамках склада вычисляется свободный остаток, а уже затем вне транзакции выполняется распределение товаров между заказами. В нашем варианте, т.к. мы в общем случае не знаем на каком из складов окажется нужный нам товар, то пришлось изменить этот подход и рассчитывать свободный остаток вне транзакции в механизме распределения запасов между заказами. Так как такой подход приводит к тому, что при формировании отчетов свободный остаток может быть не актуальный, пока не выполнено распределение запасов, во все отчеты, где используется этот показатель выведена индикация (по факту 3 ключевых отчета, один типовой «Остатки и доступность» и два новых). Поэтому, когда пользователи формируют отчеты и видят эту индикацию, они ждут какое-то время и формируют отчеты снова. При одновременно работающих 450 пользователей, такие задержки не являются критичными (самое долгое распределение выполняется около 1 минуты, в основном такое распределение занимает секунды).

Для наглядности информации в отчете «Остатки и доступность» разделили колонку «В резерве» на несколько. В колонке «В резерве» осталось количество, физически зарезервированное на складе «Действие «Резервировать на складе»». Отдельно показаны резервы с состояниями «Обеспечен на складе» и «Обеспечен к дате». В колонке «Обеспечен на складе (возможно забрать)» отображается количество, которое можно отдать любому срочному заказу и при этом с учетом всех требований от клиента товар может быть закуплен в срок у поставщиков.

• Оповещение перед установкой товаров в резерв

Перед отгрузкой товаров Клиенту или необходимости перемещения товаров с центральных и консолидационных складов на региональные система автоматически формирует задачи ответственным за заказы клиентам с тем, что за 3 рабочих дня (настройка системы) до даты отгрузки Клиенту или со склада отправителя при перемещении товар будет подготовлен к отгрузке. В задачи попадает товар в состоянии «Обеспечен на складе». Критерий, что товар подготовлен к отгрузке и будет перемещаться между складами или его необходимо отгружать Клиенту является резервирование этих товаров на складах.

• Установка товаров в резерв и оповещение об этом

Если ответственный за Заказ клиента не перенес даты отгрузки по Заказу на обеспечение, то через Х рабочих дней (настройка в системе) после создания задач система автоматически устанавливает товар в резерв. Для этого используется документ «Резервирование товаров», в котором в таб. части «Товары» можно перечислить Заказы на обеспечение под которые товар нужно зарезервировать. Таким образом не требуется перепроводить и изменять Заказы клиентов для которых требуется установить товар в резерв. В нашем случае вместо изменения и перепроведения несколько сот заказов, в общем случае достаточно ввести один документ «Резервирование товаров» (по факту у нас резервирование выполняется 1 раз в час и документов получается несколько десятков, т.к. их формирование разделено по определенным принципам).

Кто работал с УПП узнает интерфейс документа, придумывать ничего не стали, а просто взяли и сделали как было в УПП.

При необходимости товар в резерв можно установить вручную, при этом если система обеспечения распределила товар для другого ЗнО (состояние «Обеспечен на складе») под другой ЗнО, то не выполняя никаких дополнительных действий, достаточно просто ввести документ «Резервирование товаров», а для товаров, которые отдали автоматически будет запущен пересчет обеспечения и ЗнО будет обеспечен по общим правилам, учитывая новую ситуацию с товаром.

Если товар находится в резерве под один ЗнО, а его нужно передать другому ЗнО, тогда в одном документе «Резервирование товаров» сразу можно снять товар с резерва с одного ЗнО и установить в резерв под другое ЗнО (эту операцию по запросу продаж выполняют специалисты отдела логистики).

• Выполнение обмена резервами

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

• Оформление Перемещения товаров

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

• Если товары требуется перемещать между складами, то специалисты отдела логистики через рабочее место по обеспечению набирают в «Товары к отгрузке» товар, который нужно перемещать и по нажатию одной кнопки автоматически формируют планы перемещения (промежуточные документы, которые оформляют разные логисты). В рабочем месте есть возможность установить фильтр и увидеть все ЗнО, которые необходимо перемещать.

Дальше указывается, что и в каком количестве нужно перемещать.

Указывая значение в колонке «Отгрузить» и нажимая «Сохранить» информация попадает в «Товары к отгрузке». Таким образом логист набирает из разных ЗнО то, что уже необходимо перемещать. И дальше по нажатию одной кнопки автоматически по заложенному алгоритму в систему формирует планы перемещений.

• Дальше, когда все сотрудники отдела логистики сформировали планы перемещений, один специалист от логистики по всем планам перемещения создает задания складу на отгрузку. Задание складу на отгрузку реализовано в виде отдельного документа «Распоряжение на отгрузку» с видом «Перемещение». По факту этот документ заменят функционал заказа на перемещение и всегда формирует движения с вариантом отгрузки «Отгрузить» и строго под потребности ЗнО. Не стали дорабатывать документ «Заказ на перемещение», а оставили его в типовом функционале и используем для перемещения товаров, находящихся в свободном остатке (не под ЗнО). Единственно, что убрали из заказа на перемещение возможность работы с «Действием» и всегда формируем его с действием «Отгрузить».

Создание заданий складу из планов перемещения реализовано в виде одной кнопки «Создать распоряжения» в которую заложен алгоритм консолидации планов перемещения в распоряжения на отгрузку.

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

• Взаимодействие с транспортным отделом

При проведении распоряжения на отгрузку с видом «Перемещение» автоматически создается документ «Груз». Это основной документ взаимодействия всех служб с транспортным отделом. В нем заложены алгоритмы расчета прибытия груза, прохождения контрольных точек маршрута в зависимости от плановых нормативов, заложенных в маршруты и версии маршрутов. При движении груза в случае изменения плановой даты прибытия информация обновляется в системе обеспечения и перераспределение запасов выполняется уже с уточенной информацией о дате прибытия.

• Оповещение о снятии товаров с резерва

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

• Отгрузка товаров клиенту

У ответственного за Заказ клиента есть три варианта.

• Первый перенести дату отгрузки и тогда товар не будет снят с резерва. Для переноса даты отгрузки необходимо оформить «Корректировку заказа на обеспечение». Переносить дату отгрузки по товарам, которые находится в резерве можно только с предварительного согласования. В зависимости от срока, на который переносится дата отгрузки предусмотрен разный уровень согласований. Это сделано, чтобы товар не находился длительное время в резерве, т.к. такой товар не участвует в автоматическом распределении запасов;
• Второй, ничего не делать и тогда товар будет снят с резерва, а Заказ на обеспечение аннулирован. О чем пользователь получит соответствующую задачу-ознакомление;

• Третий, это отгрузить товар клиенту. Для этого оформляется документ «Распоряжение на отгрузку Клиенту», который выполняет действие «Отгрузить» аналогичное типовому действию в документе «Заказ клиента».

Из распоряжения на отгрузку по одной кнопке реализован механизм автоматического создания реализаций и перепродаж между юр. лицами.

Таким образом в системе разнесены процессы обеспечения (документы «Заказ на обеспечение» и «Корректировка заказа на обеспечение»), резервирования и снятия товаров с резерва (документ «Резервирование товаров»), и подготовка к отгрузке (документ «Распоряжение на отгрузку Клиенту»).

• Изменение качества товара

Изменение признаков неготовности выполняется в форме списка справочника "Номенклатура". Если по серии после поступления товара на склад, нет других документов товародвижения, то признак неготовности можно назначить напрямую в серии.

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