!!! ВНИМАНИЕ !!! ВАЖНО !!! Данный пост - техническое сравнение системы Честный Знак и типовых реализаций API от других ИТ-игроков ("усредненное" типовое API). Любая задача, не противоречащая объективным законам, может быть решена. Сущность данного поста объяснить почему на интеграцию с обычным API вы легко найдёте исполнителя за недорого, а при попытке создать решение с ЧЗ или будете посланы, или Вам выкатят астрономическую сумму. Дополнительные интеграции с ЧЗ на текущий момент для бизнеса крайне нужны (в посте будет разъяснено почему), но получить их почти нереально.
Сразу - политического контекста вроде "зачем" и "почему" тут не будет. Ввели маркировку и ввели. Пост чисто технический, про то, как создать эталонную систему уровня "Через Жопу". Согласно Распоряжение Правительства Российской Федерации от 03.04.2019 № 620-р оператором системы без конкурса назначено ООО "Оператор-ЦРПТ" — дочерняя компания ООО «Центра развития перспективных технологий» (50 % ЦРПТ принадлежит структуре ООО «Юэсэм технологии», подконтрольному Алишеру Усманову и его партнёрам, еще по 25 % - АО "ГК «Концерн Автоматика», входящему в состав госкорпорации «Ростех», и ООО «Элвис-плюс групп», принадлежащему Александру Галицкому). Назначение было осуществлено с подписанием соглашения о ГЧП. В вопросах ИТ Усманов, это прежде всего Майл.ру, а Галицкий - ряд международных ИТ-проектов. К чему эта ремарка? В собственниках ЧЗ достаточно крутые игроки не только рынка ИТ в России, но и достаточно весомые на мировом уровне. И эти игроки умудрились сделать всё настолько отвратительно, что если завтра всплывёт новость, что ЧЗ делали студенты 2- 3 курса под наставничеством пенсионера, то я в этом сомневаться не буду ни секунды. Теперь почему так по пунктам, с элементами повествования. Вас обязали обмениваться информацией с ЧЗ, для этого Вам нужно сформировать данные для отправки в систему, прежде всего Вы столкнётесь с:
1. Документация. Документация расположена здесь Возьмём сперва описание схем информационного обмена Интересующихся могут скачать документ. Вкратце - до 38 страницы норм, 39 - 51 в принципе почти норм, 52 - 69 - сойдёт, 70 - 333 - полный пиздец. Объясняю почему - обычно для любого продукта есть 2 набора документации - внутренний и внешний. Так вот описание схем, это приличный внутренний документ, который "для своих" и который наружу обычно не выставляется. В юзерспейс выкатывают совершенно другую документацию в совершенно другом формате. Для примера можно взять любые доки почти от любого софта / сервиса (они по структуре одинаковые) и сравнить. Де-факто уже давно стало стандартом описание в формате "структура - разъяснение - пример". Если разработчик не прошел суровую школу чтения инженерной документации где до 80% нужно додумать самому, то читать это будет больно. Описание кодов - Для каждой группы товаров свой код, причём не только DM (о нём ниже), но и другие. И каждый код работает только в своей подсистеме. При этом на самом сайте ЧЗ написано, что система изначально проектировалась для отслеживания ВСЕХ товаров, поэтому вполне легко можно было выйти на единый стандарт. Далее здесь и здесь - API... В котором мы видим, что данные можно передавать в XML/JSON/CSV... Стоп... JSON/CSV, а где в описании схем инфообмена указаны JSON/CSV? При более глубоком изучении документов оказывается, что ЧЗ, это не ЧЗ, а уже сразу с документации "Коллекция Франкенштейнов" т.к. есть ТРИ версии API, и ДВА стиля составления документации (почитайте документы). Нашли свой и...
2. Версионность схем. Версии схем описанных подсистем 72, 78, 37... При этом явно будут добавлять новые схемы. Вот Вы серьезно? Специализированные магазины, которые торгуют только 1-й категории товаров в реальности как бы нет, то есть и на стороне ЧЗ и на стороне торговли уже сегодня нужно создавать 2 - 3 решения для продажи. Делать в 1,5 - 2 раза больше работы, и нести в 3 - 4 раза больше затрат. На-хе-ра? До ЧЗ с таким я в ИТ-сфере не сталкивался никогда, потому что есть много причин почему так делать нельзя. Прежде всего потому что и по здравому смыслу и по всем концепциям унификация всегда наиболее оптимальный вариант. Аллегория тут может быть такая, что на автомобиль установлены ступицы под разные типы болтов и левое переднее колесо на любые 3 оставшихся места Вы не поставите, потому что число болтов и их расстояние до оси разное. И встретив такое авто у любого человека мнение может быть только одно... Хорошо, нашли "свою" документацию, версионировались, разобрались что и как будет передаваться, перевели документацию на человеческий и...
3. Код DataMatrix. Чтобы знать какие данные отправлять их нужно прежде всего считать. Поскольку ЧЗ "забыли" прописать стандарт нанесения кода, то мы имеем логичную ситуацию... Кто как хочет, тот так и др... Наносит коды маркировки. В результате чего мы имеем огромный геморрой из-за дебилов-дизайнеров, которые подобрали слабо контрастные цвета, опять же дебилов-дизайнеров, которые "прячут" код делая его настолько мелким, что по некоторым товарам работают только довольно дорогие сканеры (остальные их тупо не видят) и то не долго т.к. из-за микроповреждений стекла вполне рабочие сканеры достаточно быстро начинают ошибаться, дебилы-разработчики, которые не смогли правильно сделать подогнать визуальный код под цифровой формат из-за чего дебилы-инженеры умудряются "дописывать" данные (подробнее в пункте про ФФД 1.2) делая код не читаемым, дебилы-технологи, которые не могут подобрать нормальную краску, живущую достаточно долго, чтобы спокойно реализоваться. В результате имеем товар, но из-за разных дебилов до 2 % партии товара может пойти в утилизацию из-за невозможности этот товар продать. Хрен с ним, отсканировали, передаем...
4. Основной формат во всех схемах XML (причём в МДЛП он единственный). Система ЧЗ для загрузки сведений использует формат XML. XML — язык разметки, по факту более строгая версия HTML. Его разрабатывали для представления документов и текстов, где доля разнотипных символьных данных велика, а доля разметки мала. Избыточность разметки XML предназначена для решения ситуаций, когда данные не вписываются в традиционную модель документа. В 2013 году W3C признал XML неэффективным и создал рабочую группу для переработки стандарта. Хуже всего формат проявляет себя в работе с простой структурой данных и небольшим объёмом символьных данных (поля данных). А обмен данными с ЧЗ это именно передача простой структуры с небольшим объёмом символьных данных т.е. выбрана технология, которая W3C (да и любым квалифицированным программистом) признана как наихудшая для этих целей. В целом генерировать XML не сложно, но он имеет значительное количество лишних данных и тратит намного больше ресурсов как отправителя, так и получателя на обработку. Можно привести аллегорию, что пересылаются не вордовские документы, а сканы документов. В подобных системах уже давно стали стандартом JSON/YAML, которые обрабатываются гораздо проще и быстрее. Хорошо, данные сформировали и никуда не отправили, потому что...
5. ГОСТ-шифрование. В чём проблема? Поскольку этот тип шифрования нахрен никому не нужен, то найти программистов и библиотек для решений... Особенно если Ваша товароучётная система более-менее современная и на современном языке программирования, то это вообще адская боль. Точнее не боль, а всего лишь необходимость писать свой криптопровайдер или создавать туннели ГОСТ-шифрования на UNIX, что опять же не уровень среднего разработчика. На этом этапе мы понимаем, что по факту делаем систему монополией для нескольких игроков, потому что ни одна адекватная контора интеграционное решение писать в полном объёме не будет. Потому что дорого и вообще нахер не нужно. Тут могут возразить, что у КриптоПРО вроде как есть библиотеки для ГОСТ-шифрования. Есть, даже работают. Документация здесь - https://docs.cryptopro.ru/cades/ легко и удобно (нет) поддерживаются все популярные языки программирования (нет). Хорошо, решили этот вопрос и...
6. Подключение не публичное. Чтобы подключить собственное решение к ЧЗ нужно пройти квест. Хрен с ним, прошли, отправили данные и...
7. Нет возможности проверки данных до продажи. Мы принимаем 100 единиц товара, отправляем данные и получаем квитанцию, что всё отлично, продаём и... Получаем штраф. Потому что проверка кодов показывает, что в ЧЗ на идентификатор МД записалось только 90. Где оставшиеся 10 - один ЧЗ знает. Может быть. Хорошо, завтра уже все 100 у нас. Послезавтра может быть 75. Потому что. А через месяц оказывается, что Вы торгуете незаконно. Потому что в ФИАС Вашему адресу поменяли код и Вам выдали новый идентификатор места деятельности. Без Вашего уведомления. Следовательно товар на новом ИМД, а Вы продаете со старого. И инструментов проверки и контроля нет. Вообще. И это - основная боль любого бизнеса связанного с маркировкой, потому что по факту ЧЗ - черный ящик, который при практически идеальной работе может выкидывать в нарушения до 35 % оборота товаров по разным причинам. А может и не выкидывать. И вообще у ЧЗ есть прекрасная традиция, с непостоянной, но периодичностью делать...
8. Длительное подтверждение и Низкий уровень доступности сервиса. Система, которая за регламентирована и обложена штрафами настолько, что обязана работать с доступностью 99,9999 % довольно часто любит "радовать" всех участников тем, что выкидывает ошибки доступа. При этом логистика и бизнес-процессы естественно приостанавливаются или вообще останавливаются. Скорость передачи товара относительно "до маркировки" может упасть до 3 - 4 раз. Чтобы труп маркировки (а по другому я его объективно не назову) подавал хоть какие-то признаки жизни с октября стал обязательным формат фискальных документов 1.2 (ФФД 1.2.) и...
9. ФФД 1.2. Сущность заключается в том, что при добавлении товара в чек ККМ проводится проверка на 2-х серверах кода маркировки. Если Вы:
- работаете в крупном городе;
- на торговой точке у Вас провайдером Ростелеком (не реклама, опыт);
- классные админы, которые грамотно настроили ККМ;
- вы отсеяли поставщиков с дебилами-инженерами, которые дописывают что-то в маркировку;
- у вас "вымылся" весь товар с тестовыми кодами маркировки.
то в целом Вам будет пофиг. Если нет, то ККМ может "задуматься" надолго (до 10-20 секунд на единицу товара), херачить ошибки или вообще товар может стать не продаваемым из-за несоответствия формата кода (снова привет дебилам-инженерам). Догадаться, что если Вы делали эксперименты с кодами, то строгую верификацию нужно делать не ранее истечения срока годности тестовых партий - слишком сложно. И наконец пройдя весь этот путь приходит понимание, что ЧЗ страдает...
A. Не приспособленность к реальности. Честно - устал писать, поэтому менее значимые косяки пропустил. Система маркировки, по своей архитектуре, исходит из постулата, что абсолютно все участники имеют высококвалифицированные кадры, отшлифованные до идеала бизнес-процессы, соблюдают их абсолютно идеально, что сама система ЧЗ работает идеально... По факту всё гораздо ближе к прямой противоположности. Бизнес заставили и продолжают заставлять тратить огромные деньги на видимость жизнеспособности смердящего трупа. И делать красивые отчеты.
Подводя итог я сперва ещё раз напомню, что не касаюсь вопроса нужна или не нужна маркировка, просто её нужно делать не как справочник идиотизма, а хоть немного жизнеспособной. И традиционно "предлагай":
1. Единый стандарт документации, в качестве образца можно взять шаблон любого крупного продукта. Документация Майкрософт, Яндекса, Постгреса и т.д. и т.п.
2. SDK для разработчиков как минимум ТОП-10 языков программирования.
3. Единый стандарт маркировки и единая система обработки данных. Грубо говоря код формата []код товарной группы[]EAN-13[]серийный номер[]криптоподпись[].
4. Как минимум альтернативный вариант работы "на чтение" по стандартному SSL/Токенам. Потому что из-за "ветров перемен" данные в любой товароучётной системе по факту показывают погоду, а адекватных механизмов автоматизированной сверки нет.
5. Использование CSV/JSON как основного формата передачи данных.
6. Технический стандарт кода маркировки. Тип подложки по фону и материалу, краска (цвет и свойства), точные размеры (не менее Х мм).
7. Отмена ключей приложений.
8. Обеспечение 100 % доступности.
9. Система подтверждения списания по частичному коду маркировки. Грубо говоря инструмент в котором можно при частичном повреждении кода запросить его полностью и продать.
P.S. В ходе телефонного опроса, проводимого ЧЗ среди участников оборота примерно год назад, всё это (и не только это) было высказано. Но тут появляется главная проблема современного менеджмента - тотальное нежелание признавать и исправлять свои ошибки.