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

29 октября 2018

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

№ппНаименование программного продуктаСтоимость, ₽
1АРМ «АСФ: ТСД ЕГАИС» для одного FSRAR_ID (Лицензия для одного FSRAR_ID, включает лицензию на 1 терминал сбора данных и 1 АРМ десктоп-пользователя)80 000
Необязательные расходы:
2Дополнительная лицензия АРМ «АСФ: ТСД ЕГАИС»
для второго, третьего и далее FSRAR_ID (Лицензия для одного FSRAR_ID, включает лицензию на 1 терминал сбора данных и 1 АРМ десктоп-пользователя)
10 000
3Дополнительное рабочее место
(терминал сбора данных или АРМ десктоп-пользователя конфигурации) (Лицензируется запуск на каждом дополнительном терминале сбора данных (ТСД) и работа каждого дополнительного десктоп-пользователя с функционалом ПП. Предполагается наличие свободных лицензий 1С Предприятие (клиентских лицензий фирмы 1С)
5 000

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

№ппНаименование единицы оборудованияСтоимость, ₽
1ТСД Urovo i6200 (Urovo i6200 / MC6200S-SS2S5E000H / Android 5.1 / 2D Imager / Motorola SE4500 (soft decode) / Bluetooth / Wi-Fi / GSM / 2G / 3G / 4G (LTE) / GPS / NFC / 5.0MP (camera) / RAM 2 GB / ROM 16 GB / 4x-core 1,2 GHz / 4.0″ / 480×800 / 23 клавиши / 3800 mAh / 320 g / IP 65)35 000
Необязательные расходы:
2Проводной сканер штрих кодов (любой 2D сканер) (Если предполагается сканирование на стационарном рабочем месте, или сканер подключен к планшету в наличии)7 000
3Принтер ШК Godex G500 (Если предполагается осуществлять упаковку и маркировку групповой тары (производство, в т.ч. наборов, упаковка россыпи))18 000

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

№ппЭтапВремя, часовСтоимость, ₽
1Встраивание подсистемы АСФ: ТСД ЕГАИС в 1С8 (Указана усредненная стоимость внедрения. Финальная стоимость зависит от конфигурации, в которую встраивается ПП, степени доработки конфигурации, в которую встраивается подсистема АСФ:ТСД ЕГАИС, наличия уже существующего автоматизированного бизнес-процесса сканирования в рамках операций приемки, отбора (функционала который придется совмещать с новым функционалом как минимум до полного вымывания старой марки) и тому подобных факторов)817 600
2Обучение персонала (работе с ТСД и десктопной частью системы) (Расчет на удаленное обучение десктоп-пользователя и пользователя с ТСД (в ходе обучения может быть сколько угодно слушателей, предполагается, что речь идет о разовом обучении с последующей трансляцией знаний отсутствовавшим сотрудникам силами обученного персонала))48 800
3Настройка пользователей (настройки пользователей, которые будут работать с ТСД в КАТАП), назначение ролей на объекты встроенной подсистемы десктоп-пользователям (В расчет включена настройка двух пользователей)48 800
4Настройка ТСД (через RDP или посредством использования мобильного клиента)
Внимание! Настройка через мобильного клиента допустима только при использовании платформы 1С 8.3.12 (на этой платформе официально не работают продукты УТАП10, 1С ЛВЗ, 1С КАТАП 1 — то есть, для них организуется только терминальное подключение.
Внимание! Известные специалистам проблемы передачи сканированного кода с устройства (ТСД) в терминальную сессию решены утилитой собственной разработки компании «Алкосфера»)
48 800
Необязательные расходы:
5Подключение и настройка принтеров этикеток48 800
ИТОГО стоимость работ52 800

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

  • 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 сервер, позволяя решить проблемы трансляции длинных ШК в режиме эмуляции клавиатуры. Позволяет вести лог сканированных штрих-кодов, работать в фоновом режиме, выполнять автозапуск при загрузке операционной системы в фоновом режиме.

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

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

Почему наша система хороша в сравнении?Что это даетСистема, с которой сравнивалиКомментарий
Марки и упаковки хранятся в отдельных справочникахПозволяет экономить время записи в базу данных. Длина кода марки (новой) — 150 символов, 300 байт в UTF8, дерево индексов вам спасибо не скажет, когда будет обновлять индекс на 10 тысяч записей. Кроме того, справочник позволяет гибко прикрутить к нему дополнительные аналитики. Все это звучит довольно заумно, но когда речь пойдет о десятках и сотнях миллионов марок в базе, станет яснее — что именно имеется в виду.Коды марок и упаковок хранятся в виде строковых данных. При этом при копировании этих кодов в другие документы, их также приходится копировать. Нельзя прикрутить дополнительные аналитики напрямую.Мы гордимся нашим решением. Настолько, что мы в подсистеме ТСД ЕГАИС сделали конвертацию кодов марок и упаковок в «наши» справочники для случая, когда мы встраиваем ТСД ЕГАИС в конфигурацию сравниваемой системы.
Обрабатываемый документ можно разбить на несколько заданий на сканированиеЭто позволяет разбить одну большую накладную на несколько частей для параллельной обработки несколькими операторами и потом объединить результат.Все наоборот. Одну или несколько накладных можно собрать в одно «задание на сканирование». Грустно представлять себе человека, которому надо собрать задание в 10 тысяч марок.Вывод сделайте сами.
Мы работаем с данными онлайнЭто позволяет оперативно проверять марку или упаковку. И сделать это быстро, так как любое опосредованное соединение с базой добавляет задержки. Кроме того, это позволяет блокировать марку или код коробки и паллеты, что запрещает использовать её в сканировании другим работником и это — очень важно, особенно для крупных компаний с большим количеством персонала на складеПроверки в ходе работы отсутствуют. У решения есть 2 варианта — бесплатный RDP c прямым соединением и offline с опосредованным. В обоих вариантах никакой проверки нет, а, когда она появится, в офлайн режиме эта проверка станет болью в плане быстродействия.На многочисленных демо роликах систем конкурентов все они работают. Когда нужно на тестовой базе собрать тестовый заказ на тестовых марках в количестве 6 штук. Как только бутылок в заказе будет от 200, мы прогнозируем некоторые затруднения
Мы даже пишем свои приложения под Android для исключения искажения кода сканированной марки при соединении по RDPЭто жизненно необходимо, причем настолько, что непонятно, как жить без него — ведь код при пробросе в rdp сессию искажается, а далеко не каждый производитель ТСД разрабатывал в комплекте такую нейтрализующую проблему утилиту.Сложно сказать, чем вызвано отсутствие такого приложения. Формальный характер разработки RDP-версии? Передача проблемы ИТ-службе Заказчика? Отсутствие опыта реальных внедрений? Мы не знаем.Уважаемые участники рынка могут использовать наши наработки.

Итак, мы были готовы к ошибкам и доработкам, но смотрели на мир оптимистично, не планируя сроки таковых доработок более чем в объеме 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 недели бесплатных для клиента работ (мы не знали о проблеме заранее, но подписались что внедрим решение). А пользоваться теперь смогут все подобные клиенты. И снова пройдем к другой таблице сравнения, которую мы назовем «Я у мамы — программист»:

Почему наша система крута в сравнении?Что это даетСистема, с которой сравнивалиКомментарий
Мы правильно проектируем хранение марок.Мы храним состояния марок правильно, в независимом регистре, все данные хранятся в измерениях, чтобы не елозить потом по PID-ам keylook-up-ами. Измерения построены в правильном порядке для высокоселективных запросов, не допуская лишних некластерных индексов.Периодический регистр сведений, подчиненный регистратору — это ежам на смех. Это выльется в симпатичные проблемы производительности, как только накопится немного (с полгода) данных.«Мы храним состояния марок правильно» — а другие нет. А ещё мы моделируем поведение системы, наполняя её 5 млн. марок и собирая планы запросов. А наши конкуренты делают так? Мы не знаем.
Мы доверяем хранить иерархию упаковок типовым механизмамХвала фирме 1С за её конструкцию «В ИЕРАРХИИ». Это сэкономило нам сотни нефти.В сравниваемой системе был изобретен неплохой велосипед написания типового платформенного функционала.Иногда можно идти против правил, но это хорошо в ядерной физике, а не в программировании.
Генерируем правильные коды упаковок по стандартам РАРИзбежать ошибок пользователя уровня «а что, тут особый код нужен был, и как его вы прикажите вводить?»Никаких механизмов генерации штрих кодов упаковок нет.Ну просто нет. Живите с этим. Возможно, пока.
У нас есть формы интерфейса ТСД под режимы совместимости и общий код функционала в общих модулях.Можно запускать подсистему ТСД на конфигурациях в режиме совместимости 8.2 и 8.3 и модифицировать код для всех форм одновременно.А у сравниваемой системы — нет.Даже если будет реализована новая форма под новый режим совместимости, достаточно много времени уйдет либо на вынос кода в общие модули, либо на постоянные синхронизации кода.
Все формочки, кнопочки, надписи аккуратно отлажены руками и настраиваемым кодом.Мы серьезно. Всё тестировалось под разные ТСД (Urovo, Motorola, Honeywell) и разные разрешения экрана (640*480,800*600, 1000*600), разные RDP клиенты (Microsoft, Parallels, Tanas), и даже десктопы.Мы не пробовали запускать сравниваемую систему на разных ТСД, просто по причине лени отсутствия времени. Мы просто посмотрели и не увидели адаптационного кода под разные разрешения. Под десктопом все смотрится мелко.Скорее всего, при запуске на каком-нибудь разрешении, отличном от тестированного, интерфейс будет молить о быстрой смерти.

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

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

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

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

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

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

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

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

Почему наша система крута в сравнении?Что это даетСистема, с которой сравнивалиКомментарий
Мы сделали подсистему ТСД под Мобильный Клиент 1СМы планируем использовать его как основной режим работы с ТСД. Это позволяет местным программистам заказчика дорабатывать его своими силами программистов 1С, без привлечения Android-программистов.Нативное приложение под Android. Не знаем, чем продиктован такой выбор, ведь тут Мобильный клиент от 1С идеально напрашивался.Мы идем в ногу со временем, модно, стильно, молодежно. Посмотрите на скриншоты, они просто... красивы. А перейти на Мобильный клиент с нативного приложения будет тяжко — унификация кода, передача штрих кодов, аппаратных клавиш, вот это всё.
И она умеет издавать звуки. И это в 2018В случае завершения задания на сканирование, и, самое главное — ошибки, ТСД издаст звук — нежный в случае успеха и вещающий беду в случае ошибки.Нет.Ты не ты, когда таскал полчаса пыльные ящики водки, сканировал эти бутылки, и, когда победа была так близка, увидел ошибку на экране ТСД, молча выданную 15 минут назад.

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

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

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

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

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

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

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

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

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

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

Не нашли то, что искали?

Оставьте свой номер телефона, и мы бесплатно проконсультируем вас по возникшим вопросам.