Нечестный знак
В этом месяце меня два раза разбудили в 5 утра. Людям из родного сибирского часового пояса требовалась срочная помощь программиста. Потому что государство в непростой текущей обстановке не нашло ничего лучше, кроме как продолжить развитие маркировки и как всегда не без нареканий. В этой заметке попробую без лишних технических терминов порассуждать о разработке крупных информационных систем. Вдруг это кому-нибудь покажется интересным...
Итак на просторах нашей Родины действуют две глобальные государственные системы товароучета с маркировкой: ЕГАИС (для алкогольной продукции) и Честный знак (для табачной, текстильной, обувной, молочной и некоторых других видов). Почему не одна - очень хороший вопрос. Но нет худа без добра, их можно сравнить.
- Код акцизной марки состоит из цифр и больших английских букв.
- Длина кода фиксирована.
- Код не содержит разделителей.
- Коды передаются через систему целиком (без обрезания).
- Если в электронном документе указаны коды упаковок, то коды акцизных марок товаров находящихся в упаковке указываются тоже.
- При передаче данных, электронный документ сначала поступает в систему, проходит проверку и если все хорошо, направляется получателю.
- Код маркировки состоит из цифр, больших и маленьких английских букв и нескольких знаков препинания. Такая регистрозависимость приводит к проблемам при настройке сканера, чувствительной к нажатию CapsLock.
- Длина кода не регламентирована и может быть разной у разных видов продукции. Почему так?
- В коде могут быть указаны скобки в качестве символов разделителей, при этом скобки также могут быть и обычными символами. Спросил об этом в техподдержке, они удивились моему удивлению.
- В коде могут быть специальные символы разделители <GS>. Большинство программ эти символы игнорируют, не умеют их передавать, для решения проблемы передачи, например в кассу, код маркировки дополнительно шифруется. Зачем это надо?
- Через систему коды передаются в усеченном виде без криптохвоста, а сканер сканирует марку с хвостом. Вероятно, чтобы труднее было сверить :-)
- Если в электронном документе указаны коды упаковок, то коды маркировки товаров находящихся в упаковке не указываются. Неужели для экономии размера файла, ведь современные каналы связи такие медленные :-)
- Введены понятия потребительской упаковки с заданным количеством товара и транспортной упаковки с произвольным количеством. Чтобы жизнь медом не казалась :-)
- При передаче данных документ сразу поступает получателю и только после подтверждения (подписания) попадает в систему где проходит проверку и может быть отвергнут. При этом получатель считает, что все хорошо, а на самом деле это не так.
Пара слов о процессе приемки. Приемщик должен проверить соответствие фактического товара заявленному в бумажном или электронном документе. Если какой-то товар учитывается индивидуально и это реализовано в виде специального штрихкодирования, то приемщик должен с помощью автоматизации сравнить отсканированные коды с кодами в электронном документе. А теперь еще раз взглянем на отличия двух систем. Ну совершенно же очевидно, что как будто нарочно у Честного знака все зачем-то усложнено. И по каждому пункту возможны ситуации потенциальных ошибок. А у ЕГАИС наоборот все просто, логично, а значит, надежно. Мы технари любим посмеиваться над странностями естественных языков и ошибками переводов. Но как можно было так неудачно спроектировать формат кодов. Ведь в технических системах, как и в обычном общении, самое главное - это взаимопонимание. А тут такое наворотили. Наверняка у разработчиков Честного знака есть все современные методики: Scrum, DevOps и т.д. и т.п. И что-то мне подсказывает, что им даже не стыдно.
Так что же произошло в этом грустном осеннем месяце, почему меня будили в столь ранний час... Дело в том, что в электронных документах стала приходить молочная продукция. Казалось бы, все несуразности формата кодов маркировки учтены, все работает, просто добавился еще один вид. Все должно быть по аналогии. Но нет предела совершенству. Допустим пришло три коробки какого-то товара. В документе должны быть перечислены коды нанесенные на каждую из них на заводе, а система гарантирует, что внутри именно то что нужно, достаточно пикнуть сканером коробку и быть уверенным, что пересорта нет. Но в случае молочки в документе неожиданно на все три коробки указывается всего один код и последние символы этого кода - это общее количество товара. Вот это поворот! Значит, код этот сгенерирован не на заводе, а поставщиком, то есть ломается сама идея маркировки, система ничего не гарантирует. Товары индивидуального учета можно подтвердить только по количеству. Пересорты возможны, а значит, обязательно будут. А отдуваться за это будет розница, потому что потребитель жалуется в соответствующие инстанции именно на розницу. Можно было бы отсканировать каждую пачку мороженого или творога из каждой коробки но это нереально, хотя бы по гигиеническим соображениям. Кроме того, непонятно где взять заявленные марки пачек для сверки. Вот такая творится профанация. И виноваты в этом не политики, они просто хотели порядка и побороть контрафакт, и не менеджеры всех уровней, которые по цепочке доложили друг другу, что все заработало. Они просто не знают о тонкостях. Виноваты разработчики, которые придумали ужасную схему. Поганой метлой нужно гнать этих разработчиков и объединять обе системы в одну на базе более продуманной архитектуры ЕГАИС.
Вот почему из последних, явно слабеющих, сил я пытаюсь говорить о недопустимости излишнего усложнения. Дорогие начинающие программисты, запомните одну вещь, то какие вы используете технологии и методики неважно совсем, вернее это важно только для вас. Главное, чтобы заложенные в ваш проект архитектурные решения были простыми, логичными, а значит, надежными. Чтобы вашими разработками было удобно пользоваться. А если допущена ошибка (лишняя сложность), ее обязательно нужно исправить в следующей версии.