Каталог решений - Вариант автоматизации складских операций

Разрешите представиться: Алексей, 34 года, неангажированный интеллектуал.

Порядка 15 лет реализую себя как 1с-программист, в основном в сфере торговли.

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

***

ВСТУПЛЕНИЕ

Пару лет назад на предприятии розничной торговли алкоголем возникла дискуссия на тему эффективности инвентаризации. 

Основные моменты:

• x2 mobilebase ds5 100% времени простаивают; (win, древней ревизии) 
• плохая оптимизация процесса; (на пару магазинов и склад уходило 3 долгих дня без торговли) 

Предложена идея создать самодостаточное решение и уместить его во всего лишь одну "обработку".

Основные задачи:

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

РЕАЛИЗАЦИЯ ИДЕИ

Схематически программный комплекс можно представить в следующем виде:

Периферия

• epf-обработка, которая находится в общем сетевом каталоге; (в неё же записываются все данные)
• клиенты с доступом к базе, запуск с помощью ярлыка; (/RunModeManagedApplication /execute)
• для ТСД выделена отдельная сетевая машина, подключение идет к ней по RDP; (на ней настроена 1С и ярлыки)

Основная программа

Структура

Складские задачи формализованы и вынесены в отдельный блок — 80% программы получилось абсолютно универсальным.

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

Таблицы бывают двух видов:

плановая: 

• объект; (основной срез учета, н-р номенклатура)
• аналитика; (дополнительный срез учета, н-р характеристика (может быть несколько))
• плановое количество; (сколько по плану, если нулевое — излишек)

фактическая: 

• период; (время ввода записи — широко используется в аналитике)
• пользователь; (кто ввел)
• объект; 
• аналитика; 
• фактическое количество; (сколько по факту, если меньше плана — недостача)

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

Как это работает

Далее описание из каких функциональных блоков состоит программа. ("И" — за этот участок отвечает интеграция)
Сразу отмечу, что не все режимы и формы обработки адаптированы для ТСД. Строго говоря, это только разделы по работе с заданиями. 

***

Программа встречает пользователя главным
меню,
которое состоит из трех пунктов:

• задания; (список активных заданий)
• настройки; (настройки программы) 
• выход; (завершает работу системы) 

В настройках только самое необходимое:

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

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

Форма ввода имеет минималистичный вид,
но обладает достаточным функционалом: 

• наименование задания и прогресс выполнения; 
• показатели работы текущего пользователя; (количество, время, темп)
• поле для ручного ввода; (особые сценарии, н-р добавление по артикулу)
• просмотр изображения текущей позиции (И); (двойной клик или enter)
• история ввода / отмена записи; (если есть доступ)
• возможность видеть только то, что осталось; (очень удобно в конце инвентаризации)

За работой потоков можно наблюдать в отдельном диалоге.
Там же небольшой функционал по их управлению..

Выполненные задания помещаются в архив. 
С этого момента они доступны администратору для анализа.

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

• периодичность; (группировка по годам, месяцам, неделям, дням, часам)
• тип задания; (если дело вышло за рамки инвентаризации)
• задание; 
• пользователь;

В дополнение к ним можно вывести несколько видов гистограмм.

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

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

Синхронизация потоков в задании осуществляется по следующему принципу:

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

Реализовано три варианта работы со сканером штрихкодов:

• режим эмуляции клавиатуры; (классика, старые win-тсд)
• подключаемое оборудование; (стандартная подсистема, native-компонента, стациональные ПК)
• передача кодов по сети через TCP; (интересный вариант, применяем на android-тсд)

ЗАКЛЮЧЕНИЕ

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

Спасибо за внимание!