"Микро-WMS": базовая WMS с упрощенной архитектурой, открытым кодом на PostgreSQL и клиентами на SimpleUI

Введение

Это максимально упрощенная, бесплатная полнофункциональная WMS с открытым кодом серверной части и конфигурации клиентов, где в качестве сервера БД используется PostgreSQL а взаимодействие с 1С и с клиентами(устройствами) осуществляется посредством REST интерфейса PostgREST (подробнее о PostgREST я писал тут : //infostart.ru/public/1217831/)
Т.е. это и готовая WMS и база для доработки под свои нужды.
В базе она умеет делать обычные для WMS операции:

• Приемка товара по распоряжению и «по факту»
• Размещение с использованием алгоритма размещения (естественно как рекомендация, по факту можно размещать по другом). Стратегия размещения в текущем примере учитывает объем, вес товаров и максимальную вместимость ячеек хранения по объему, весу, количеству
• Перемещение
• Отбор с использованием алгоритма отбора. А также с возможностью использования «фирменного» алгоритма планирования перемещений при отборе (см.  //infostart.ru/public/1081085/)
• Отгрузка (контроль отгрузки) по заказу
• Инвентаризация

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

При этом система обладает следующими достоинствами:

• 0 руб. за лицензии: PostgreSQL+PostgREST на линуксе. SimpleUI достаточно НЕ-Pro версии для всех процессов (с Pro-версией есть отличия в интерфейсе процессов)
• Не требовательна к железу
• Супербыстрая и масштабируемая: 2х-звенка SQL по дефолту значительно быстрее 3-х-звенной 1С. Проверено.
• Простота архитектуры +простота разработки клиентов на Simple UI = высокая скорость разработки и внедрения

Серверная часть вообще не имеет никакого визуального интерфейса для пользователя – все отчеты, печатные формы и т.д. формируются из нее на стороне 1С через REST,а для склада вся работа выполняется на мобильных устройствах на Simple UI. Вот такой черный ящик)) Впрочем все необходимое можно посмотреть и если что подредактировать pgAdmin-ом – там нормальный инструмент для визуального редактирования.

Для чего нужна?

Чтобы иметь простой и надежный инструмент для решения задач автоматизации склада. Но в отличии например от Simple UI, которая выросла из больших проектов, тут я использую противоположный подход: я делаю инструмент для будущих проектов и предлагаю присоединиться всем желающим. Да, обычно у нас происходит так – сначала делается проект под конкретного заказчика,потом под второго, третьего ну а потом бац-бац и тиражный продукт. Но я уже много лет занимаюсь WMS и серийными и написанными с нуля своими и в целом имею нужный опыт (правда не SQL а 1С). Просто когда делаешь архитектуру под конкретный проект заказчика над тобой висит целесообразность конкретным задачам а не универсальность архитектуры ну и сроки конечно же и бюджет. А тут можно спокойно поэкспериментировать и подобрать нужное решение. 

Кроме того я активно развиваю направление Simple UI в самостоятельном режиме работы не "с 1С" а "с PostgreSQL" в качестве бекенда, и мне нужно было убедиться что возможности самостоятельного режима доросли до «большого проекта», а это – отличная проверка. 

Почему в таком виде?

Это своего рода DIY(«сделай сам») продукт: набор функционала минимален специально, чтобы можно было быстро разобраться и доработать под себя. Например, часто приемка совмещена с размещением, а контроля отгрузки как такового нет – не беда, это можно быстро собрать из готовых блоков. Это противопоставляется концепции «коробочных» продуктов где настройки осуществляются условно «галочками» 
Большие и дорогие коробочные WMS которые предлагают настройку галками – штука хорошая, но есть нюансы. Дело в том что это продукты которые требуют серьезных знаний по методологии с одной стороны (попробуйте внедрить у себя без консультантов, ага) и отягощены большим объемом кода чтобы всю эту универсальность обеспечить. В случае 1Сных WMS –это десятки тысяч строк кода. Реальная ситуация – вам надо разобраться почему стратегия размещения работает не так как она должна работать, Вы читаете методические материалы, не помогает, лезете в отладчик – а там тонны кода. И все – день потерян, пока вы разберетесь и найдете ответ. А по сути если разобраться на конкретном складе на конкретных задачах работают алгоритмы размещения, отбора, подпитки каждая из которых в общем то несложная – ее код умещается на одном экране. 

Почему на SQL а не 1С?

Потому что SQL быстро и надежно, легко масштабируется и бесплатно. Более подробно на эту тему я рассуждаю тут: //infostart.ru/public/1217831/
Но в качестве информации к размышлению, могу еще добавить следующее: для бизнеса имеет значение только общая цена проекта. Прям вот вся целиком – с необходимой инфраструктурой, лицензиями и т.д. Можно сказать что цена проекта – это пирог, и заказчику без разницы с кем вам приходится им делиться.

Описание функционала

Приемка и приемка по факту

Приемка по заказа начинается с выбора распоряжения. Как и в остальных процессах можно выбрать из общей ленты задач либо (для Pro-версии) из отдельного списка. ТМЦ приходят на адрес «К РАЗМЕЩЕНИЮ» - тот буфер на котором скапливаются товары, которые надо потом разместить в адресах. Отмечается план-факт. Можно выйти, потом продолжить. Как приемка закончена нажимаете на кнопку Завершить чтобы документ не светился в листе активных распоряжений.  Выглядит это так:

или так:

После приемки на пустом складе состояние остатков такое:

Размещение

Размещение это перемещение из зоны приемки в конкретные ячейки.
Как и во многих WMS учитывается любое состояние товара. Взял товар, но пока не донес до адресата – он будет числиться на пользователе, т.е. прямо на адресе=пользователь. Т.е. товар не зависает в пустоте пока он на складе - он всегда где то числится.
Можно выйти из процесса, а потом вернуться. «Корзина» будет отражать то что есть. Т.е. размещение состоит из 2х блоков операций «Взять» и «Положить». Сначала набираешь то что взять(это цикл), потом положить. Показывается что за тобой числится, что нужно разместить. 

на этапе взять - товар на кладовщике

после размещения - товар попадает на адреса:

Чтобы перейти от «Взять» к «Положить» - нужно нажать на соответствующую кнопку.
Размещение это в принципе обычное перемещение, но с одним отличием – работает режим рекомендации в какие ячейки размещать. Размещение учитывает вместимость ячеек и привязку товаров к ячейкам. Но вы можете размещать где считает нужным (не принимая во внимание алгоритм). Как и в любой WMS действия подтверждаются на все этапах. Также учитывается порядок обхода чтобы не метаться по складу аки броуновская молекула. Этот алгоритм (их может быть несколько для разного товара, зон) обычно сильно прописывается под себя. 

Отбор

Отбор — это перемещение из адресов хранения в зону отбора. Тут также используется рекомендательный алгоритм. Собственно алгоритмы — это то изза чего и внедряют WMS – то что позволяет оптимизировать работу. Их еще называют «стратегии». В конфе Simple UI по дефолту прописан метод get_picking – хранимая функция, в которой прописан алгоритм котрый по ID заказа выдает список адресов отбора в сортировке по simple_order – это простой порядок сортировки. Т.е. просто число (порядок) в каждом адресе по которому сортируется. При каждом отобранном товаре список пересчитывается. И в принципе можно отбирать не в том порядке который он рекомендует. 
Но, можно сделать гораздо более интересный вариант – сортировку списка по реальным дистанциям до ячеек относительно которых пользователь в данный момент находится. Т.е. он найдет ближайший маршрут. Для этого есть функция get_picking_alternative() пересортирует список по дистанциям от последней ячейки (текущее местоположение – последняя ячейка которую сканировали – т.е. так у которой вы стоите в момент сканирования). Для этого нужна карта расстояний в таблице wms_distances, а автоматизированный способ ее получения описан тут: //infostart.ru/public/1081085/

Вот такая получается функция с пересортировкой относительно текущей ячейки:

СREATE OR REPLACE FUNCTION api.get_picking_alternative(
	orderid character varying, lastaddress character varying)
    RETURNS TABLE(sku_id integer, sku character varying,address character varying, qty real) 
    LANGUAGE 'sql'

    COST 100
    VOLATILE 
    ROWS 1000
    
AS $BODY$
SELECT P.sku_id,P.sku,P.address,P.qty from api.get_picking(
	orderid
) as P left outer join api.wms_distances as D on P.address=D.address_dest and D.address_source=lastaddress order by D.distance

$BODY$;

Отгрузка

Отгрузка – это непосредственно отгрузка при списании с зоны отбора. В простом случае – пропикивание при погрузке в машину (не все может влезть в рейс).
Перемещение
Тут – это просто перемещение из одной ячейки в другую ячейку без задания. Например ручная подпитка/ уплотнение. Или что то еще.  Также состоит из 2х циклов «Взять» и «Положить» 

Инвентаризация

Просто процесс проверки фактического наличия по распоряжению. Результаты загрузятся в 1С.

Отличие функционала для Pro-версии и для бесплатной версии

Отличие одно: для процессов которые идут «по распоряжениям» в бесплатной версии работа начинается через ленту «Задачи». Т.е. процессы одинаковые но в качестве 1-го экрана «выбор распоряжения» - запуск через «Задачи», например так:

А в версии «PRO» также доступны отдельные списки для каждого процесса которые запускаются через меню процессов. Например так:

Как устроена WMS

Справочная информация. Интеграция с 1С и соответствие сущностей 1С и WMS

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

• Справочная информация (товары, штрихкоды и т.д.)
• Распоряжение

Загружаться может (по желанию):

• Факт по операциям (в виде например ордеров, либо просто «статусов»)
• Факт по инвентаризациям

В любой WMS все устроено проще чем в любой товароучётной системе в том плане что там нет того множества документов товародвижения которая есть в 1С. Собственно операций всего 2 – Приемка и Отгрузка. Отличаются только аналитика куда приходит и откуда списывается. Поэтому при интеграции всё многообразие документов 1С выгружается в два вида распоряжений – «на приемку» и «на отгрузку» (есть правда еще «на инвентаризацию» - это особый случай). Т.е. все поступления, перемещение на склад (с другого склада), возвраты, комплектации – это распоряжения на приемку. Опять же в 1С это могут быть «Заказы на…» а могут быть сами документы движения – бывают разные варианты. Может быть например распоряжение – Заказ клиента, может быть распоряжением уже оформленная «Реализация» и в качестве «факта» из WMS загрузится «Расходный ордер на товары». Все это реализуется на уровне обмена.
Вся Номенклатура+ Характеристики+ если есть Упаковки в этой WMS один справочник «Товары». Т.е. сочетание Номенклатура+Характеристика+Упаковка=SKU (stock keeping unit). И у нее есть конкретный штрихкод и артикул которые указывают именно на это сочетание. У этого сочетания есть вес и объем – параметры, необходимые д
Номенклатура может располагаться в конкретных ячейках (т.е. отведенные места на складе для каждой номенклатуры). Алгоритм размещения предлагает только эти адреса.

Устройство СУБД (серверная часть)

Команды на создание всех объектов СУБД находятся в файле поставки. Их нужно просто загрузить в Query tool и выполнить.

Таблицы, триггеры, представления

wms_addresses – адреса. У каждого адреса есть максимальная вместимость по объему, весу и количеству – для алгоритма размещения. Также есть простой порядок обхода – для варианта стратегии размещения или отбора (есть и другой вариант). Также у адреса есть штрихкод. Адреса можно загрузить из 1С (есть в обработке). Также клиент создает особые адреса – «К РАЗМЕЩЕНИЮ», «ОТБОР» и т.д. 
wms_goods – товары (включая понятие упаковки и характеристики). У товара есть вес, объем  - для расчета размещения. Также есть штрихкод. Это штрихкод конкретной упаковки. При желании можно завести отдельную таблицу ш/кодов и прописать в клиенте. Также для размещения в том варианте который есть нужно для каждого адреса прописать ячейки в котрых доступно размещение – wms_allowed_places
wms_operations – таблица в которую попадают все операции. Приход с «+», расход – с «-». Это «журнал операций» -кто, что, и для чего (поле to_operation-для разделения назначений). Так как он большой считать остатки по нему – неблагодарное дело. Поэтому существует таблица wms_totals – это всегда текущие остатки. Расчет происходит по триггеру в wms_operations. Вот такому:

BEGIN 
   LOCK TABLE api.wms_totals IN EXCLUSIVE MODE;

    IF tg_op = 'INSERT' THEN
        
		INSERT INTO api.wms_totals (sku_id,address_id, total)
VALUES
	(
		NEW.sku_id,
		NEW.address_id,
		NEW.qty
	) 
ON CONFLICT (sku_id,address_id) 
DO
		UPDATE
	  SET total = api.wms_totals.total+NEW.qty;
	
	RETURN NEW;
		
    ELSE
 
        RAISE EXCEPTION '% в wms_operations предполагаются только вставки', tg_op;
    END IF;
END;

wms_orders_captions и wms_orders – распоряжения из 1С и факт по ним. Факт попадает также по триггеру из wms_operations. К заказам привязываются операции, по ним происходит отбор, размещение. Распоряжения могут быть на люые оперции. Тут же – распоряжение на инвентаризацию. Это – «план-факт» для склада.
wms_distances – таблица расстояний для альтернативной маршрутизации по складу

Хранимые процедуры

Хранимые процедуры в PostgreSQL можно писать на нескольких языках – SQL, plpgsql, C  и встроенном. Есть даже отладка! 
Отдельно стоит выделить процедуру get_tasks(“user”) – это обязательная процедура для получения ленты задач для пользователя. Т.е. Simple UI к ней обращается, а что там внутри – какие задачи – вы уже сами определяете.
Get_picking(order_id) – процедура «отбора». Исходные данные – id заказа. По строкам заказа подираются ячейки в которых лежит товар. Если не хватило – это косяк, она сообщит.
Как альтернативу можно использовать Get_picking_alternative(orderid,lastaddress) – функция маршрутизации относительно текущего положения
Get_placement_orders(user_id) – процедура подбора размещения. Размещение пытается разместить все товары, лежащие в «К РАЗМЕЩЕНИЮ» по правилам: а именно – в ячейки, предназначенные для товара, но с учетом веса, объема и максимального количества.
Прочие процедуры, присутствующие в файле – это для экранов отображения на клиенте, просто сервисные процедуры, для отображения например на экране план-факта. Это можно сделать и не через хранимые процедуры, но так удобнее.

Клиентская часть

Все что работает на клиентах находится в конфигурации Simple UI "Микро-WMS" которая присутствует в демо-базе. По сути - это единственный интерфейс системы не считая отчетов. Все управление - с клиентских устройств. Не буду подробно останавливаться на SimpleUI в данном посте так как об этом написано уже много. Скажу лишь что Simple UI - это конструктор мобильных фронтов, единственная задача которого - максимально упростить процесс разработки. Так, на разработку например процесса, "Отгрузка" у меня ушел где то чуть меньше часа вместе с тестированием, дизайном и т.д. Клиент Simple UI работает в нескольких режимах взаимодействия с сервером. В данном случае это - "самостоятельный режим". Т.е. конфа запускается независимо, с сервером (СУБД PostgreSQL) взаимодействует через REST интерфейс синхронным способом, отправляя HTTP запросы. Логика работы распределена между клиентом и сервером. В основном на сервере. Код в итоге получается крайне лаконичный, работать очень легко. 

Вот так например выглядит один из экранов в конструкторе:

Установка для пользования и для доработки

Серверную часть можно развернуть где угодно – у себя на компьютере, на VPS, на винде на линукс. Также по запросу могу предоставить сервер для тестирования на своем облаке.

Для того чтобы развернуть систему у себя нужно :

1)    Поставить PostrgreSQL и PostgREST как описано в этой статье http://postgrest.org/en/v6.0/tutorials/tut0.html  (а также еще тут немного : //infostart.ru/public/1217831/)
2)    Если делать по инструкции то  в Постгре будет схема api. У меня все SQL-команды прописаны для этой схемы. Нужно выполнить SQL команды которые прилагаются в файле SQLМикроWMS.txt в pgAdmin либо другим средсвом администрирования. Файл находится в архиве в комплекте поставки на основной странице Simple UI: //infostart.ru/public/1153616/
На этом этапе собственно сама БД готова и готова принимать команды.
3)    Скачать Simple UI из Google Play либо apk (нужна последняя версия!), зайти в Магазин приложений и скачать «Микро WMS»:

4)    Забить имя пользователя Postgres в настройки и Url REST сервера из п.1.
Теперь готовы и клиенты. Но нужно еще первоначальное заполнение. Для этого нужна интеграция.
5)    Обработку для интеграции с 1С находится там же – в комплекте поставки, в архиве. Нужно заменить АдресБекенда - на свой!

Все. Можно пользоваться!

Если нужно что то менять в СУБД: подключаемся pgAdmin-ом и меняем)

Если нужно менять в клиенте: в демо базе присутствует конфигурация «Микро-WMS» -это и есть конфигурация клиентской части. Нужно заменить Адрес бекенда в 1С на свой IP.

Если нужно просто попробовать:

Если НЕ нужно разворачивать у себя, а хочется просто попробовать, то это можно сделать прямо в моем облаке - тот адрес который по умолчанию прописан в настройках приложения и в обработке интеграции. Оно правда слабоватое (1 проц+HDD+512ОЗУ), но для теста пойдет. Скоро будет другое. Просто закидываете свои товары обработкой (не меняя адрес), адреса, какие то распоряжения и все - можно пробовать на устройствах и смотреть как работает

Просьба: Публиковать изменения для своих клиентов либо напрямую, либо (если через «магазин приложений») - через свою базу!