Для понимания масштаба предприятия приведу некоторые усредненные цифры.
Площадь склада (включая зоны приемки/отгрузки) ~ 3000 кв.м.
- Ярусов на складе 3-4
- Зоны приемки 3 шт.
- Зоны отгрузки 3 шт.
- Количество ячеек на складе 700 шт.
- Средне недельная приемка/отгрузка на склад ~ 110 т.
- Средне недельные внутренние перемещения склада ~ 50 т.
- Среднее количество заказов в неделю ~1000 заказов.
- Количество SKU - 900 позиций
Итак, поехали, первая задача - учет по партиям. Это то, что мы сделали сразу и сделали правильно. Первое, что приходит в голову, это включить использование серий, что мы и решили делать. Это хорошо, но в одной накладной, как правило, приходит несколько партий производителя по одной номенклатуре. Маркировать каждую коробочку или использовать ШК поставщика мы отказались по простой причине, что это занимает огромное количество времени на приемке, пересбор паллеты займет раза в три - четыре больше времени на эту процедуру. Приняли простое решение - одна номенклатура по одной накладной это, собственно, одна партия. Дату производства решили взять как самую старую дату из существующих в этой партии. Таким образом, одна паллета - одна маркировка, и не надо ничего пересобирать. Идею внедрили сразу, и она была работоспособной, хотя мы это решение используем почти на всех проектах. Стандартный механизм формирования серий и печати этикеток выкинули сразу и доработали приходный ордер. Стандартный механизм требовал огромного количества тычков мышки, которые нам показались бесполезными. Мы все завязали на одну кнопку «Сгенерировать партии», которая после ввода ордера на основании заказа заполняет все, что необходимо, и сразу печатает этикетку.
Печать этикетки - отдельная тема. Мы сделали свою этикетку, где формировали qr код, внутри которого УИД партии, единицы измерения, номенклатуры, количество и еще один уникальный УИД для каждой этикетки, чтобы различать повторные сканирования. Количество из этикетки использовали только при размещении, во всех остальных случаях требовался ввод.
Следующий этап - размещение на складе. 1С предлагает сама определять местоположение на складе, но тут у предприятия возникали сложности с определением этого правила, которые постоянно менялись. Решение было следующим: мы на этикетке печатали плановое размещение, а дальше на усмотрение старшего смены определялось размещение номенклатуры на складе. Как показало время, решение было хорошим, и после обучения регламенту размещения все заработало с приемлемым качеством.
Само размещение фиксировалось с помощью ТСД и разработанного под эти цели мобильного приложения на 1С. На стороне ТСД формировался аналог документа «Отбор и размещение», который по HTTP отправлялся в 1С:КА2, формируя документ размещения на складе.
Вот таким образом почти штатно оформили приход на склад.
Отгрузка – самое больное.
Итак, оформляется заказ покупателя с указанием зоны доставки. Группируем по зонам доставки и оформляем саму доставку, передаем ее на склад.
Моя большая ошибка, что я изначально планировал использовать штатные функции под отгрузку. Которые от склада требуют высокой точности учета и слаженности работы.
Есть у нас задание на доставку, которое превращается в расходные ордера. По расходным ордерам формируем отборы и отправляем их на ТСД. Сам склад поделен на зоны, кладовщик выбирает зону, на которой он работает и видит список товаров, который необходимо принести в зону отгрузки. Вроде все складно звучит.
Первая проблема, с которой столкнулись, это организационная, не все отборы добросовестно сканировались кладовщиками.
Второе, возникала ситуация, когда товар есть в заказе, а остатка на складе не хватает, и нужно уменьшить ордер и заказ.
Третье, используются аналоги номенклатуры и вместо заказного.
Четвертое, отгрузить могут чуть больше/меньше по факту, чем заказано. С весовым товаром 1С умеет работать, а вот со штучным нет.
Пятое, в момент отбора товара грузчик может ошибиться с количеством, и на этапе загрузки товара в машину и проверки расходного ордера это выявится.
Переломить организацию бизнес-процессов получилось частично, да и многие из них имели здравый смысл. НО, в типовом использовании ордерной схемы от 1С:КА это приводило к невозможности оформить отгрузку. И весь процесс вставал «колом» и постоянно требовал ручной корректировки документов. При работе склада 24/7 нужно реализовать схему максимально просто и доступно для рабочего персонала. Сам запуск отгрузки проходил достаточно болезненно, но по итогу мы получили достаточно хорошее решение.
Что было сделано.
Отказались от документа отбор в зону отгрузки. На ТСД передавали регистр сведений, содержащий задание на отгрузку. Все, что сканировал склад, оформлялось перемещением в специальную ячейку. В типовом варианте отбор сразу списывает в зону отгрузки, в которой нет остатка, и любое отклонение приводит к большому «кнопконажимательству». В нашем варианте при отборе товара он перемещался в специальную ячейку, а при завершении проверки расходного ордера он (ордер) списывал из этой ячейки товар. Если в ячейке отгрузки оставался остаток (положительный или отрицательный), то это были некие отклонения, которые анализировались в период инвентаризации. Рассмотрим, например, ситуацию: на склад пришла коробка 1000 шт. товара. Мы перемещаем с основного склада в зону отгрузки эти 1000 штук. В момент проверки оказывается, что там не 1000, а 980 шт. Соответственно в ордер попадает 980. А 20 штук зависают в зоне отгрузки. Самое важное, что на основном складе это отклонение в 20 штук не будет висеть, мы его «изолировали» в специально отведенной ячейке.
В корне переработана обработка проверки количества и сам расходный ордер. Это позволило делать замену номенклатуры, корректировать по факту количество товара или отказываться от товара при его отсутствии и невозможности заменить на аналог. БАРДАК, скажете Вы, но как обыграть ситуацию, когда последний остаток товара на складе оказывается непригодным под отгрузку. А он висит в заказе. Все, приехали, заказ есть, остаток есть, а отгрузить не можем. А теперь представим, что это третья смена. Что делать? Нужен механизм, который позволит либо сделать замену номенклатуры на аналог, либо не грузить ее вообще. Относительно штатных функций ордерного адресного склада в 1С:КА2, могу сказать, что задумка отличная, но вот реализация хромает и в реальной жизни сложно применима. Либо требует от склада высокой степени организации. Но высокая степень организации не всегда возможна. Во всяком случае, на начальном этапе. Мы руководствовались следующим принципом, что сначала даем складу максимум свободы и потихоньку "закручиваем болты" в их свободе действий. Это принесло некоторые успехи, но проблемы с заменами номенклатуры и корректировкой количества, была особенность конкретного бизнеса, к которой необходимо было приспособиться.
По факту реализовали механизм, который при проведении отбора правит все регистры таким образом, что все отклонения система «прожевывала» без ошибок. А ошибок подобный подход давал огромное количество, так как система постоянно анализирует закрытие заказов при работе подсистемы доставки и формировании расходных ордеров.
Также сделали функцию вывода на телевизор листа сборки. Когда открывается форма проверки заказа, то список товара дублируется на экран телевизора. По ходу проверки список уменьшается. Экран телевизора видят грузчики, которые участвуют в погрузке товара, тем самым не ждут команды от бригадира.
По итогу у нас получилось неплохое решение, и реализовали требуемую схему учета. У нас получилось отличное мобильное приложение для работы склада. Организовали отбор по всем правилам хорошего тона. Приложение сортирует отбор товара под отгрузку. От самого дальнего угла склада в сторону зоны погрузки. Предлагает к отбору только ячейки первого яруса (если самая старая партия расположена на разных ярусах), позволяет работать в зоне отсутствия связи, позволяет оформить списание аналогов при необходимости, получать остатки практически в режиме реального времени.
И еще одно мобильное приложение, для проведения инвентаризации, которое позволяло по нашим QR кодам этикеток, которые мы придумали, собирать информацию о товарах на складе и заполнять документ пересчета. Почему отдельное? Ну для того, чтобы можно было ставить его на телефоны грузчиков и использовать не только ТСД, так как в период инвентаризации требуется повышенное количество оборудования.
Подведу некий итог по своему проекту:
Что понравилось в типовом решении и дорабатывалось достаточно мало:
- Приемка на склад
- Заказы покупателя
- Подсистема взаиморасчетов (типовая полностью)
- Документы закупки и ее корректировки (типовая полностью)
- Работа с оборудованием: весы, сканеры (типовая полностью)
- Выпуск продукции
Что не понравилось, и очень сильно переписали:
- Подсистема доставки (поймали множество ошибок и подсистема не очень гибкая, чтобы подстроить под свои бизнес-процессы. Пришлось вносить много правок.)
- Расходный ордер (множество изменений связанных с аналогами и корректировками)
- Проверка заказа в расходном ордере (переписали полностью, проще было написать свою с нуля)
- Отбор товара в зону отгрузки (вообще все переделали, хотя изначально планировали почти типовое).
- Реализация товаров (много изменений в основном связано с индивидуальными бизнес-требованиями предприятия, также следствие переписки расходных ордеров).
