Егаис 3. Помарочный учет алкоголя в 1С. Цена и сроки автоматизации

В этой статье команда «Алкосферы» расскажет читателям:

• Почему внедрением процессов помарочного учёта заниматься надо было ещё вчера сейчас, несмотря на то, что новая марка появится 1 января 2019;
• Сколько стоит внедрение помарочного учёта, и как быстро мы можем его вам организовать;
• Историю создания нашего решения АСФ: ТСД ЕГАИС. Почему наш продукт и услуги стоят своих денег;
• Заключение, обещания и напутствия.

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

Почему автоматизацию помарочного учёта надо проводить сейчас?

Всё просто, все мы — люди, и хотим спокойно спать и не нервничать. Такое, знаете, нормальное желание — не работать круглосуточно в авральном режиме.

А ведь именно так было в мае-июне, когда к нам обратилось слишком большое количество алкогольных оптовиков и производителей. Казалось бы, это не проблема, большой спрос должен регулироваться увеличением предложения?

Причина проста и сложна одновременно:

• С 2018 года в Российской Федерации внедряется организационно сложная система прослеживаемости маркированного алкоголя, с учётом каждой марки на каждой бутылке в каждой операции купли-продажи. Этого раньше никто не делал! И неоткуда скопировать наработки по программному обеспечению и отработанные бизнес-процессы ведения этой деятельности.
• То есть, сам процесс только проектируется, и в основе точки отсчета — лишь регламентные требования ФС РАР. А сама деятельность людей на складе и в офисе применительно к задаче помарочного учёта только начинает «прорисовываться» в головах и на бумаге ответственными сотрудниками и собственниками алкогольных компаний.

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

В итоге, можно однозначно говорить, что даже несмотря на солидный опыт (мы спроектировали основную логику ТСД ЕГАИС ещё в 2016 году), на рынке пока нет универсального решения для помарочного учёта. То есть, нет подходящего на 100% именно для вас, профильный читатель.

Однако, есть максимально проработанное и вариативное решение. А его разработчик, компания «Алкосфера», готова на многое:

• Вставлять в типовую версию продукта (на базе настраиваемых опций) требуемый только вам функционал.
• Предоставлять скидки на доработки, если функционал действительно важен и универсально отвечает потребностям всех участников рынка. А то и вовсе сделать их бесплатно.
• Обеспечивать совместимость/встраивание продукта в различные (в том числе и устаревающие, но повсеместно используемые) конфигурации учётных систем на платформе 1С.

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

На данный момент помарочный учёт в ЕГАИС 3 находится в «отложенном» состоянии.

И все снова расслабились, как в пятницу вечером. А мы так и вовсе даже — нашли время на написание статьи — клиенты сетуют на неучастие Алкосферы в светских раутах. Дескать, занятость проектами оправданием не является.

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

А что это означает? Да вероятнее всего, все тот же уход с рынка. Кто-то ведь сможет отгружать товар, пока вы будете ругаться на складе и искать виноватых сотрудников.

Предлагаем вам провести автоматизацию помарочного учёта:

• в комфорте,
• недорого,
• недолго, в идеальном усреднении до 7 рабочих дней,
• с учётом ваших особенностей и взглядов на то, что должна уметь программа,
• можно даже удаленно (доказано практикой),
• можно с отсрочкой платежа,
• и даже в часовом поясе до +9 часов к Мск. У нас длинные руки и ясный взор в любое время суток.

Обращайтесь, мы рады вам.

Сколько стоит внедрение помарочного учёта

Общаясь с новыми клиентами, мы обратили внимание на упоминание странных коммерческих предложений (далее — КП) с миллионными суммами в графе ИТОГО. Также есть много неясностей со сроками и даже исполнителями внедрения, а КП выглядят как ребусы, вызывающие больше вопросов, чем ответов.

Самым диковинным для нас оказалось КП, где клиенту предлагалось все делать самостоятельно (включая программирование предлагаемой ему системы на её внутреннем языке). А интегратор осуществлял консультативные функции и за результат ответственности не нес.

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

В качестве публикации неких средних ориентиров, смасштабировать (или наоборот, уменьшить) которые на свои мощности и дополнительные «хотелки» может каждый, приведем расчет КП по простому проекту. Исходные данные примерно такие: в организации 10-20 пользователей, система УТАП 10/11, на складе будет 1 сотрудник с ТСД.

Расчет стоимости внедрения помарочного учёта в ЕГАИС 3.0 с использованием ПП «АСФ:ТСД ЕГАИС»

Стоимость программного обеспечения, ₽:

Стоимость оборудования, ₽:

Стоимость работ по внедрению, ₽:

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

• 80 000 ₽ + 7 000 ₽ + 52 800 ₽ = 139 800 ₽ (вариант стационарного рабочего места для сверки и отбора, подойдет для небольшой компании);
• 80 000 ₽ + 35 000 ₽ + 52 800 ₽ = 167 800 ₽ (вариант мобильного рабочего места для сверки и отбора, небольшая компания с одним ТСД).

В большинстве случаев у вас есть и компьютер, и 2D сканер под стационарное место, у многих есть терминалы сбора данных и принтеры этикеток. В этом случае оборудование можно не учитывать, и стоимость внедрения ещё ниже.

Если захочется почитать более вдумчиво или уже даже позвонить нам: вот тут всё есть. Видео, руководство пользователя (!), внедрения, цены.

Два года разработки подсистемы ТСД ЕГАИС. История в деталях

Предпосылки

Когда все начиналось, подсистема ТСД не казалась нам чем-то сложным. Мы написали целостную систему. И, несмотря на то, что клиенты использовали её в 2016 году, в основном, «под постановку на баланс», работали все операции (сверка поступлений, инвентаризация, отбор при отгрузках)

Именно отсутствие помарочного учёта и делало невостребованным качественный учёт — можно было принимать на баланс все, что хочешь и отгружать любой пересорт, лишь соблюдай соответствие остатков в разрезе справок Б в учётной системе и в ЕГАИС.

С появлением первых новостей о поштучном учёте в октябре 2017 года мы, взяв уже готовые наработки, планировали уложиться в три месяца, к январю 2018. Ясное дело — для того чтобы потом рекламироваться и делать внедрения, все оставшееся до июля время, снискать успех и достаток.

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

Концептуально, мы сразу решили делать подсистему ТСД ЕГАИС универсальным образом встраиваемой в типовые и отраслевые конфигурации 1С (и, конечно, в нашу собственную разработку). Причина такой архитектуры — опыт реальных внедрений относительно средних и крупных оптовиков. Он дал нам железобетонное понимание: для эффективной автоматизации процессов помарочного учёта маркированного товара на складе, система, работающая на ТСД (терминале сбора данных) в руке работника или стационарных постах должна:

• Иметь онлайн доступ ко всем данным основной учётной системы;
• Иметь доступ к коду и модулям основной учётной системы;
• Иметь (желательно) доступ к данным ЕГАИС и его сервисам;
• Иметь устойчивость к постоянному развитию функционала;
• ...и вытекающую отсюда не затратную и универсальную доступность к доработке и разработке;
• Разработчик не должен добавлять объекты и логику дополнительного функционала в три разных места и на разных языках: в основную систему, в обработку интеграции, и в отдельную систему на ТСД.

Для достижения автоматизации процесса полного цикла, качественной защиты от дурака, доступности к мониторингу — такая подсистема должна просто являться частью основной системы. Любой ИТ-директор подтвердит, что лишний узел = лишние трудозатраты на саппорт и риски.

Да, некоторые системы выносить в отдельные не только вредно, но и полезно (большой объем изолированных, не нужных в основной учётной системе данных и операций) — например системы WMS. Но помарочный учёт? Он в любом случае уже присутствует в основной учётной системе, туда из ЕГАИС придут марки, там будут храниться и в итоге списываться. Подсистема для мобильного терминала никак не нагрузит основную БД, наоборот — не создаст нового узла со своим хранилищем и обработками обменов, за которым надо постоянно присматривать и ловить глюки, устранять рассинхрон данных (вероятнее всего новому сотруднику). Некоторые традиционные системы с развитием платформы 1С и появлением мобильного клиента просто изживают себя, как минимум в секторе до 50 пользователей — например, различные «мобильные торговли».

Отдельной задачей сразу стояло написание (разработка) отдельного приложения для устранения известной техническим специалистам проблемы передачи штрих кодов в сеанс RDP (неточная передача с ТСД в удаленный сеанс). Причина:

• Наша подсистема должна была работать на ТСД не только в режиме мобильного приложения 1С (используя возможности платформы 1С8.3.12), когда rdp-соединения не требуется;
• Но и должна отвечать потребностям старых учётных систем (КАТАП1, ЛВЗ, УПП 1.3, УТАП10, УТ10), которые официально на новой платформе не работают, и для них остается лишь rdp-соединение.

Реализация — первый релиз

Поначалу эта инвестиционная разработка шла почти по плану, и к середине февраля 2018 мы уже имели частично готовое решение. ТСД ЕГАИС могла выполнять сверку входящих марок от поставщика по коробам, сборку марок на отгрузку по коробам, задания на переупаковку марок в короба. Подсистема работала на базе нашей конфигурации «Алкосфера» (решение на базе УТ11 с подсистемами ИЕГАИС и ТСД ЕГАИС) и пользовалось всеми её благами помарочного учёта, среди которых отдельно хотелось бы выделить:

• хранения марок и упаковок в справочниках,
• обособленный помарочный (по-марочный) учёт на универсальном документе «Движение марок».

На основании данных справочников и документа создавались документы «Задание на сканирования» с разбиением товарного состава по 3 различным стратегиям (которые можно легко модифицировать под требования заказчика), таким как:

• «по строкам документа»,
• «по товарному составу»,
• «по работникам склада».

Вот у нас есть поступление на 10 тысяч бутылок, и нам надо его всего отсканировать. Потому что нет уверенности в качестве данных поставщика. Мы можем дать это поступление 1 человеку, и он будет сканировать его до заката, пока остальные отдыхают, а можем разбить по строкам (или по количеству пропорционально 10 работников).

Сам интерфейс ТСД запускался тогда под Тонким клиентом, через RDP соединение, работа производилась online, в процессе сканирования уже проводились различные проверки:

• соответствие сканированного штрих кода ожидаемому (требуется PDF417, отсканировали DataMatrix),
• проверка уже сканированной марки/ упаковки,
• принадлежности марки к заданной номенклатуре.

Отдельно было написано приложение ScanCode Transport под Android, под передачу сканкодов, и размещено в Google Play (пока в режиме закрытого бета-тестирования):

Утилита отслеживает события от сканера штрих кодов и отправляет отсканированный штрих код по сети на TCP сервер, позволяя решить проблемы трансляции длинных ШК в режиме эмуляции клавиатуры. Позволяет вести лог сканированных штрих-кодов, работать в фоновом режиме, выполнять автозапуск при загрузке операционной системы в фоновом режиме.

Мы делаем гибкую, умную и настраиваемую систему (и инвестиций на разработку не жалели).

Далее по тексту мы будем выделять важные акценты в отдельные таблички, где подчеркнем их в сравнении с решением не нашего производства, но попавшего к нам в руки в ознакомительных целях.

Итак, мы были готовы к ошибкам и доработкам, но смотрели на мир оптимистично, не планируя сроки таковых доработок более чем в объеме 40 человеко-дней.

Реализация — развитие релиза

Однако, все существенно изменилось в январе 2018 года, когда наш самый крупный клиент (у которого уже 2 года использовалась наша подсистема Интерфейс ЕГАИС), обратился с просьбой организовать ему в срок до 1 марта 2018 года помарочные ТТН (отгрузки) для региональной сети магазинов «Командор». Грозящих штрафами или разрывом контрактов при отсутствии марок: времена были неспокойными, все ждали новые марки и строгий помарочный учёт алкоголя в ЕГАИС 3 с 1 июля 2018.

Наш заказчик сообщил, что он не готов ставить на баланс марки абстрактно, чтобы при поступлении заказа выборочно сканировать их под отгрузку этой конкретной сети.

Мы предложили добавить режим «сканирования под заказ», при котором:

• Стартовой точкой автоматизированного бизнес процесса становится поступление заказа от сети;
• На основании которого создается «задание на постановку»;
• По результатам выполнения которого создается «Акт постановки марок на баланс организации» по справкам Б;
• А затем, когда на основании «заказа» будут введены «Реализация» и «ТТН ЕГАИС», данные отсканированные марки будут автоматически загружены в ТТН, во избежание повторного сканирования.

Данный режим был доработан нами, отлажен на рабочем процессе заказчика и, в дальнейшем, оказался очень полезным при сдаче/прёмке проекта автоматизации помарочного учёта в системе клиента. Мы просто ставим на баланс и проводим полные циклы документооборота прямо в продуктивном контуре, а потом все операции откатываем назад! Это позволяет быстро настроить ТСД на складе, обучить персонал и дать как общее, так и прикладное (практическое) представление о работе подсистемы ТСД. Также этот режим был доработан, чтобы точкой отсчета мог быть документ «Реализация», для тех клиентов, которые не используют документ «Заказ клиента» в своем учёте.

Интересным (и прорывным в части нового функционала системы ТСД ЕГАИС) клиентом оказался импортер-акцизный склад/агреггатор в Латвии, который оклеивает марками продукцию, отправляемую в РФ.

Основным требованием данного заказчика была возможность поточного сканирования а) кодов наклеиваемых на бутылки марок и б) соответствующих им кодов коробок и паллет. С последующей выгрузкой данных о связках этих кодов в форматах (их уже сейчас разработано несколько), требуемых клиентами Заказчика из РФ.

Дополнительными требованиями клиентов из РФ, разумеется, стали особые печатные формы этикеток групповой тары. По всей видимости, от этих «российских» прихотей иностранным поставщикам не удастся избавиться, и некоторые клиенты будут требовать «свою» этикетку. Также как это было и пока продолжается с «особыми» печатными формами унифицированных, по сути, документов типа Торг-12 или Счет-фактура.

А ещё, в рамках этого внедрения был добавлен режим групповой обработки кодов, поступающих от сканера с большой частотой, что в конечном итоге позволило обрабатывать коробку из 12 бутылок примерно за 2 секунды (на самом деле, это не предел — всё упирается в возможности человеко-аппаратного комплекса «мотальщик-отрезчик-поточный сканер»).

Подробности внедрения были ранее описаны в соответствующей статье. Здесь мы акцентируем внимание на продолжающееся расширение типового функционала системы ТСД ЕГАИС в условии её реальных внедрений.

Что было дальше?

Одним из клиентов стал импортер, который обеспокоился отсутствием информации от разработчика об автоматизации именно складских процессов помарочного учёта. И просил встроить наш ТСД ЕГАИС в их работающую учётную систему на базе «1С8: Управление торговлей алкогольной продукцией» (версия 11.3).

Мы стали проектировать интеграцию. Первым столкновением с суровой реальностью стал механизм хранения марок и упаковок — вернее, его отсутствие. Во всех местах хранения были просто строки для ввода марок, состояния марок хранились в лютом периодическом (!) регистре сведений, подчинённым регистратору (!) по позиции, причем все данные находятся в ресурсах (минуя кластерный индекс).

Знающие люди быстро поймут, в какую тыкву сей регистр превратится через полгода использования.

Далее мы прошли суровое испытание освоения кода построения местной иерархии упаковок. Эту иерархию архитекторы почему-то сделали свою, на регистре сведений, не решившись довериться иерархическому справочнику от фирмы 1С. Однако программисты в итоге осилили только 5 уровней вложенности, жестко зафиксировав их в многостраничных запросах.

Но все когда-то заканчивается... Мы подумали, разобрались и решили впилить в конфигурацию УТАП нашу версию хранения марки и упаковки (в виде отдельных справочников). А по результатам обработки заданий на сканирование — выполнять конвертацию, вытаскивая данные из наших справочников и сохраняя их в строковых реквизитах основной конфигурации УТАП.

В целом, это сработало, но так как решение мы делали универсальное, понадобилось достаточно много времени, чтобы поправить ошибки и ветки кода по ветвлению вызовов. Параллельно, был впилен наш механизм генерации кодов упаковок и паллет по правилам ФС РАР, так как и этого механизма мы не нашли, а работать клиенту было надо. Система заработала на тестовом УТМ, рабочая база клиента была обновлена, были сформированы сканирования под заказ, поправлены ошибки и клиент отравлен в свободное плавание.

Ещё дальше

Следующим этапом было внедрение ТСД ЕГАИС в решение «1С8:Ликероводочный и Винный Завод». Блок помарочного учёта в нем был, конечно, тот же, с которым мы уже столкнулись ранее. Однако! Конфигурация ЛВЗ клиента работала хоть и на платформе 8.3, но в режиме совместимости с версией 8.2.13, что привносило свое «веселье» в виде совершенно других размеров элементов формы интерфейса нашей подсистемы ТСД ЕГАИС. Это привело к тому, что у нас появилась отдельная форма под режим 8.2, а весь код переместился в общие модули, оставив после себя в формах только вызовы процедур общих модулей.

Всего-то 1,5 недели бесплатных для клиента работ (мы не знали о проблеме заранее, но подписались что внедрим решение). А пользоваться теперь смогут все подобные клиенты. И снова пройдем к другой таблице сравнения, которую мы назовем «Я у мамы — программист»:

Нужно больше инноваций

Начиная второй виток разработки подсистемы ТСД ЕГАИС, мы в своих непонятных нормальным людям программистских мечтах думали: «Ах, как было бы хорошо, если бы фирма „1С“ (да продлит Господь её дни) выпустила аналог Тонкого клиента под Android, этакое мобильное приложение в режиме online».

И вот, 27 октября 2017 года фирма «1С» преподносит подарок. Прямо все то, о чем мы мечтали, но не решались спросить — анонс «Мобильного клиента». А вот тут уже пахнет стратегией... и мы четко определили для себя абсолютную ненужность движений разработки в сторону отдельных нативных приложений.

Мечты превратились в ожидания тестовой версии, которая была получена в феврале 2018.

Сразу же были начаты изыскания, собирания ошибок и тестирования. По результатам, мы получили рабочую версию подсистемы ТСД ЕГАИС и для Мобильного клиента, но с особенностями. Пришлось создать отдельную форму интерфейса сканирования, и отдельные формы под справочники. Кроме того, в рамках утилиты ScanCode Transport был реализован механизм передачи сканированных штрих-кодов и нажатых аппаратных клавиш в Мобильный Клиент (которого нет в стандартной реализации МК):

В целом, ТСД ЕГАИС под Мобильный клиент получился милым и симпатичным. Ну, посмотрите, какой он классный:

Использование мобильного клиента позволяет пользователю системы легко и непринужденно дорабатывать нашу ТСД ЕГАИС силами обычных программистов 1С (штатных и не очень), без привлечения программистов Android, открытым понятным кодом с предсказуемым поведением.

Это зафиксируем в таблице «В завтрашний день не все могут смотреть. Вернее смотреть могут не только лишь все, мало кто может это делать»:

Заключение, обещания, анонсы!

В статью многое не вошло, большие статьи никто не читает, и даже сюда доберутся не все. Но для искушенного читателя: у нас в подсистеме есть ещё много чего, жизненно необходимого:

• выборочная проверка с разными настраиваемыми стратегиями,
• паллетирование (4 варианта, включая непрерывное паллетирование в режиме бутылка-коробка-коробки-паллета, с возможностью произвольной остановки упаковки паллеты для нецелых паллет),
• переупаковка,
• контроль вскрытия,
• загрузка марок и упаковок из внешних систем через Web-сервис,
• запрос данных марки через Web-сервис.

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

Мы разрабатываем и будем и дальше его пилить, не покладая рук — унифицированное решение, доступное всем, не жадничая в функционале.

Уже сейчас в состав подсистемы включаются такие жизненно важные вещи как:

• Совмещение работы склада (закупки, отгрузки) с товаром, который оклеен старой и новой марками (вы не думали, что будут сложности? а вы подумайте, подумайте...);
• Категоризация справок Б (будут справки Б со старыми марками, поставленными на 3 регистр, просто старые справки Б без марок, и новые марки) и их обработка и учёт при работе на складе на ТСД

Хотелось, чтобы и ваша организация своевременно пришла к нам со своими идеями, потребностями и деньгами.

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

Рынок систем автоматизации процессов работы с маркированными товарами только зарождается. На очереди табак, не исключена маркировка пива. И мы уверены, что наша гибкая, вариативная, почти все умеющая «из коробки» система займет в нем свою нишу.