Хочу поделиться некоторыми любопытными с моей точки зрения кейсами настройки УТ11.4 как системы управления складом.

Автоматизируем ячеистый склад, сотрудников склада > 100. Сам бизнес – интернет-магазин, без специализации.

Почему выбрали УТ11 для автоматизации склада – описывать не хочу, т.к. мне лично эта тема очень надоела. Хочу рассказать про производственную часть, т.к. рассказать есть чего, а вот материалов по этой теме (УТ в части управления складом) в сети я почти не нашел. С другой стороны, детальная проработка процесса управления складом в УТ11 показала полную работоспособность этого решения.

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

Первый нюанс нашего проекта – по возможности, использовать типовую УТ, т.е. изменения в конфигурацию не вносим, а если вносим, то должна быть очень серьезная аргументация. И если все-таки вносим изменения – то делаем все максимально автономно, включаем затронутые и новые модули в отдельные подсистемы для более легкого обновления конфигурации. Соответственно, по возможности, все изменения выносим в расширение конфигурации. Что собственно и вполне получилось.

Второй нюанс, это довольно таки глубокая интеграция с основной КИС (это УТ10), когда обмены проходят не только на входе и выходе складского процесса, но и в процессе размещения и отгрузки товара. Таково требование бизнеса, да и времени наверное.

Рисунок 1. Схема взаимодействия систем

К примеру, принятый товар (тот что пересчитали в зоне приемки) мы продавать пока что не можем, а вот размещенный на полках – уже можем (при условии формирования ПТУ в КИС). Соответственно информация о постепенно размещаемом товаре должна оперативно поступать в КИС.

Другой пример. Клиент отменил заказ или часть заказа уже после начала процесса отбора товара. Комплектация заказа уже прошла или идет. Но вот до момента упаковки – должна быть возможность скорректировать заказ. Поэтому в момент упаковки необходимо еще раз запросить КИС об актуальном составе заказа и окончательно заблокировать его от корректировки.

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

Рисунок 2 Измененные и добавленные в расширении объекты

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

Итак начнем с процесса приемки

Приемка товаров

Старт приемки.

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

Так как процесс начинается по факту приезда машины поставщика в зону приемки, приходный ордер (и Заказ поставщику) в УТ11 появляется именно в момент начала приемки товара, когда кладовщик выбирает нужный Заказ поставщику из списка заказов.

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

Рисунок 3 Форма ТСД для выбора заказа поставщику для приемки

На форме расширения типовой формы «Рабочее место работника склада» увеличены кнопки, отключена необходимость ввода серий, добавлена кнопка план-факт, которая сверяет план по Заказу поставщику и отсканированный факт.

Также реализован режим «Поточного сканирования», когда сканирование не вызывается кнопкой «Сканировать», а продолжается после предыдущего сканирования до тех пор, пока пользователь не нажмет «ESC» или факт не станет соответствовать плану. Ну в подписи при сканировании добавлен Артикул и ожидаемое количество.

Рисунок 4. Форма приемки товара

Дополнительно добавлена функция привязки новых ШК к товару – при отсутствии ШК товара из списка Заказа поставщику вызывается специальный диалог привязки нового ШК к товару

Обработка серийных номеров

Типовая УТ требует внесения серийных номеров в момент приемки товаров. Что не есть хорошо, т.к. задерживает процесс приемки товаров. По идее, драгоценные зоны приемки нужно побыстрее освобождать, пересчитать товар и отпустить экспедитора.

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

Этот процесс был доработан в УТ11 следующим образом:

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

• если внесены данные по всем товарам, для которых ведется учет серийных номеров, приходный ордер становится доступным для размещения. Специальное регламентное задание формирует документы «Размещение». Процедура формирования документов – типовая, логика размещения по ячейкам не менялась, но вызывается с измененными и дополнительными параметрами

Приемка «заказных» товаров

Отмечу, что тут доработка не потребовалась, заказной товар (тот который закупается под конкретный заказ клиента, а в Заказе поставщику есть "Назначение" со ссылкой на Заказ клиента) поступает в отдельную область и ячейки. Единственный момент, что добавлена функция печати этикетки на заказной товар в момент приемки

Отклонения при приемке

При приемке товара, бывают отклонения, привезли не тот товар, не довезли. УТ11 по изначальной логике позволяет принимать все. По требованиям заказчика реализована такая логика:

• если товара нет в Заказе или больше по количеству–товар не принимается (отправляется назад)
• если товар недопоставлен, приходный ордер формируется в статусе «Требуется обработка», а в КИС формируется документ «Корректировка заказа», который требует обработки менеджера. Как только менеджер подтверждает корректировку и состав заказа поставщику (с учетом корректировки) совпадает с приходным ордером, в УТ11 приходный ордер получает статус «Принято» и процесс складской обработки продолжается дальше.

Процессы отгрузки и прочие — в следующих частях…