Happy Baby. Автоматизация процессов на складе: от сбора заказов до отгрузки клиентам

На старте к проекту подключились специалисты от клиента – Ирина Вагнер, бухгалтер, и Александр Трофимов, системный администратор.
Выделили верхний и нижний уровни процессов всей компании, чтобы наглядно показать место процессов склада во всей системе. Для наглядности и простоты восприятия использовали нотацию BPMN.
На схеме показали последовательность шагов и этапов, сколько людей задействовано на каждом этапе, а также отразили места, где могут возникать задержки. Так что сразу стало понятно, какие процессы можно упростить и улучшить.
Чтобы наглядно показать, какие документы должны создавать люди, а какие – создаваться автоматически при выполнении определённых условий, мы выделили автоматику 1C:УНФ в отдельную функцию.
Количество процессов нижнего уровня часто говорит о сложности и вариативности деятельности компании. И как следствие, предполагаемой сложности автоматизации: чем более вариативна деятельность, тем сложнее построить автоматизированную систему. К примеру, у этого проекта у нас получилось восемь нижнеуровневых процессов отгрузки, отличающихся друг от друга.

В рамках этого проекта основной задачей для нас стала автоматизация поштучного контроля отгрузок.
Для решения задачи нужен был терминал сбора данных (ТСД). Мы выбрали терминал на операционной системе Android, так как на ней лучше всего работает мобильная платформа «1С». Изучили лучший опыт автоматизации склада и остановились на следующих этапах, которые нужно отслеживать:
1) есть заказ, которой нужно собрать. Заказ состоит из нескольких товаров и часто его собирают несколько кладовщиков;
2) товар нашли и сняли с полки;
3)товар упаковали вместе с другими товарами из заказа;
4)коробку с полностью собранным заказом поставили на паллету;
5)погрузили в машину и машина уехала.
Каждый такой этап сопровождается сканированием и формированием учётных сущностей.

Уже на первом этапе стало очевидным несоответствие между базовыми возможностями 1С и необходимостью нескольких кладовщиков редактировать один и тот же заказ.
Нам нужно было обеспечить одновременно монопольный доступ к заказу и его параллельное редактирование несколькими кладовщиками.
Вот, что мы сделали: когда каждый новый кладовщик открывает документ заказа, который нужно собрать, 1С:УНФ автоматически создает новый документ, по сути копию документа заказа, где он видит список товаров, которые должны быть собраны.
Далее кладовщик сканирует QR код заказа и в ТСД появляется список товаров из заказа. Если кладовщик сканирует нужный товар, ТСД помечает его зеленым и товар добавляется, а если сканируется товар, которого нет в заказе или который был добавлен другим кладовщиком ранее, ТСД издает неприятный звук и выдает сообщение на красном поле. Товар не добавляется. По результатам сканирования данные передаются в документ заказа.

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

Кладовщик ставит коробки на поддон и сканирует QR-код каждой. На принтере печатается упаковочный лист с информацией о товаре.
При сканировании коробок система проверяет их принадлежность к собираемому заказу. Если проверка не прошла, кладовщик получает предупреждающий звуковой сигнал и сообщение об ошибке.
Когда все коробки распределены по местам, заказ перемещается в зону отгрузки и ждёт подачи машины.
Загрузка машины происходит быстро, отсканировать нужно только упаковочные листы (по количеству палет). После сканирования система автоматически формирует расходный ордер, и заказ считается отгруженным.

Happy Baby нужно было сделать инвентаризацию быстро и без ошибок: отсканировать каждую единицу и успеть за новогодние праздники.
Восемь дней на инвентаризацию склада из более 500 000 SKU — задача не из простых.
Особенно, когда на товарах указано два штрихкода.
Что? Два разных штрихкода на одной упаковке? Зачем? А вот зачем. Возьмем, например, соску-пустышку. Она может быть 3-х разных размеров в восьми цветовых решениях. Это 24 товара, которые могут быть упакованы в одну промо-упаковку для поставки в магазин максимально широкого ассортимента.
Чтобы видеть всё разнообразие таких товаров в базе и не плодить номенклатуру можно использовать характеристики товара. Каждое индивидуальное сочетание характеристик — отдельная SKU с отдельным штрихкодом, но при этом у всего этого одна товарная карточка. Всё прекрасно, но лишь до того момента, как начинается работа с разными сетями. Для одних сетей нужно, чтобы каждая из 24 пустышек была отдельным товаром с отдельным штрихкодом, а для других – наоборот, важно, чтобы все они имели один общий штрихкод, независимо от цвета и размера. Поэтому на упаковке и клеятся два штрихкода — общий для данного товара и частный для определенного сочетания характеристик.
Как же инвентаризировать такие товары? Ведь на складе в момент инвентаризации неизвестно, для какой сети закупался данный товар и как он занесён в систему.
Для автоматизации нужна определенность: принимаем решение учитывать все товары по характеристикам, а для отдельных сетей превращать их в «общие» автоматически в момент отгрузки. То есть, кладовщик сканирует всегда отдельные штрихкода характеристик. Но для отгрузок в сеть, которой нужен общий штрихкод, система автоматически делает документ «Производство», переводя отдельные штрихкоды в общие. Сканируешь всегда отдельный штрихкод, а в документ попадает или отдельный, или общий в зависимости от покупателя – идеально!

Функционал инвентаризации есть во многих учётных конфигурациях 1С. Проблемы начинаются тогда, когда объём склада не позволяет посчитать его за один день или схема расположения товаров сложна.
Обычный документ инвентаризации состоит из таблицы, в которой указана номенклатура и её количество по данным 1С. Требуется посчитать реальный остаток и внести его в таблицу.
Часто бывает, что товар лежит в нескольких местах на складе или нет свободной площади, чтобы переместить уже посчитанный товар. Наиболее часто встречается проблема пересортицы, когда неизвестно, с каким товаром перепутан пересорт.
Решение было такое.
Освободили документ инвентаризации от табличной части и сделали проверку таким же механизмом, как при отгрузке. Все кладовщики идут и просто сканируют всё, что видят. Всё автоматически собирается в единый документ и сопоставляется с учётными остатками.

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