Класс для API НСЦМ «Честный ЗНАК»

[Игорь Столяров]

Привет всем !

Класс для разрешительной проверки КМ (кодов маркировки) через API НСЦМ "Честный знак".
Поддержка целевой реализации в ПО ЛМ "Честный Знак" (обязательна с 01.09.2025 г.)
Полный боевой комплект с описанием интерфейса API и примерами.

Благодарность за помощь на старте проекта: FinsoftRZ и Alex412.
Любые замечания, исправления и дополнения - приветствуются !
------------------------------------------------------------------------------------------------------------
Ставь лайк, если уже понял, что ПО ЛМ ЧЗ нельзя обновить, а можно только переустановить !

[Игорь Столяров]

SQL создавался с великой целью, которая записана в его названии.
Т.е. полная изоляция клиента от того, что конкретно работает на сервере.
Составил запрос - получил резульат. Красота !

Можно сказать, что в общем ничего не получилось.
Нельзя взять какую-то систему и просто так переподключить с Microsoft SQL на Oracle и т.д.
А задать (и отладить !) запрос намного проще в том JSON, чем в огромном тексте с T-SQL.
С результатом запроса - тоже самое. Огромный текстовый массив без структуры - так себе решение.

C суверенной СУБД пошли по пути Non-SQL Баз Данных, где интерфейс обмена - это по сути REST запрос + JSON.
Мы же не заморачиваемся с тем какая конкретная СУБД работает на стороне ЕГАИС или Меркурия.
Ну посмотрим, что с этого получиться ...

А сам подход правильный. На реализацию суверенного T-SQL уйдёт много времени и получится язык 1С.
Т.е. смех и бесконечные мемы. А нужен ли он в технологии REST запросов ? Неть !

[finsoftrz]

Topspeed и btrieve тоже nosql базы данных. Разрабатывать намного проще, чем с sql или rest запросами. И код прост в понимании, и более компактен. Намного. NoSql это все то, что работает без использования языка sql.
Разумеется, все упирается в область применения.

[Игорь Столяров]

Разумеется, все упирается в область применения.

Создание в каждой торговой точке обновляемой БД кодов маркировки с компактным REST сервисом.
Такого точно ещё не было.

[Игорь Столяров]

Предположим, что в среднем хеш марки 10 Byte + 10 Byte сведения о её валидности.
Предположим, что в обороте сейчас 100 000 000 марок.
Тогда упрощённо общий размер БД марок: 20 * 100 000 000 / 1000 / 1000 = 2 GByte.
И это 23 товарных группы, а обычно используется не более 5. Получется 500 MByte.

Меньше CD диска. Один раз загружается и раз день выполняются репликации.
И всё не нужны никакие запросы через интернет - разрешительная проверка будет
выполняться в Локальном Модуле ЧЗ с суверенной БД "Енисей".

[finsoftrz]

Разумеется, все упирается в область применения.

Создание в каждой торговой точке обновляемой БД кодов маркировки с компактным REST сервисом.
Такого точно ещё не было.

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

[finsoftrz]

Предположим, что в среднем хеш марки 10 Byte + 10 Byte сведения о её валидности.
Предположим, что в обороте сейчас 100 000 000 марок.
Тогда упрощённо общий размер БД марок: 20 * 100 000 000 / 1000 / 1000 = 2 GByte.
И это 23 товарных группы, а обычно используется не более 5. Получется 500 MByte.

Меньше CD диска. Один раз загружается и раз день выполняются репликации.
И всё не нужны никакие запросы через интернет - разрешительная проверка будет
выполняться в Локальном Модуле ЧЗ с суверенной БД "Енисей".

Мне кажется, что марок в обороте сильно больше. У енисея висит информация про несколько миллионов касс, где они хотят эту систему разместить. Как ещё будет репликация работать, насколько база будет рости. Но самый большой вопрос, что вряд ли это все без обслуживания будет работать. А значит, дополнительные расходы.

[Игорь Столяров]

У енисея висит информация про несколько миллионов касс

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

ЛМ ЧЗ устанавливается на торговую точку в единственном экземпляре вне зависимости от
числа касс, каждый экземпляр ЛМ ЧЗ имеет свой уникальный идентификационный номер
(для каждого ИНН должен быть установлен отдельный экземпляр ЛМ ЧЗ)

Насколько я понимаю - это попытка номер три (после централизованного сервера и CDN площадок).
Задача ставится создать программый аналог ФН (фискального накопителя), который сильно тупит
и вообще не предназначен для обработки и хранения большого кол-ва КМ (кодов маркировки):

С 1 марта 2025 года при невозможности проверить продукцию в режиме онлайн – нужно
осуществить проверку в режиме офлайн

При отсутствии синхронизации ЛМ ЧЗ в течение 72 часов, утрачивается возможность
проверять продукцию через ЛМ ЧЗ (ППРФ 1944 п.18)

Мне кажется, что развитие системы КМ пошло по пути создания бесконечных костылей.
Вообще по хорошему учёт КМ и фискальный учёт на ККТ должны быть разделены.

И сейчас видимо нашла коса на камень. Коммерческие ОФД должны организовывать сбор и
обработку КМ в ИСМ для последующей передачи унитарному ЧЗ. Оно им надо бесплатно ?
Одно дело когда это были коробки с обувью и шубы и совсем другой объём, когда пошёл
оборот молочки, табака и пива. Это ведь не только сервера, но и тех. поддержка для разборок и т.д.

[PavelNK]

SQL создавался с великой целью, которая записана в его названии.
Т.е. полная изоляция клиента от того, что конкретно работает на сервере.
Составил запрос - получил резульат. Красота !

Можно сказать, что в общем ничего не получилось.
Нельзя взять какую-то систему и просто так переподключить с Microsoft SQL на Oracle и т.д.
А задать (и отладить !) запрос намного проще в том JSON, чем в огромном тексте с T-SQL.
С результатом запроса - тоже самое. Огромный текстовый массив без структуры - так себе решение.

C суверенной СУБД пошли по пути Non-SQL Баз Данных, где интерфейс обмена - это по сути REST запрос + JSON.
Мы же не заморачиваемся с тем какая конкретная СУБД работает на стороне ЕГАИС или Меркурия.
Ну посмотрим, что с этого получиться ...

А сам подход правильный. На реализацию суверенного T-SQL уйдёт много времени и получится язык 1С.
Т.е. смех и бесконечные мемы. А нужен ли он в технологии REST запросов ? Неть !

Феноменально!
Весь мир, не одно десятилетие юзает SQL и не знает о том, что SQL - это полное дерьмо, что у тех кто это все придумывал и делал ничего не получилось. Что панацея - это какой-то Non-SQL. Игорь, я думаю, что лучше не писать, тем более в такой категоричной форме, о том в чем Вы, мягко говоря, не очень хорошо разбираетесь.

[PavelNK]

Можно написать запросы так, что их будет хавать, может быть не любая, но почти любая СУБД. И легко переключать с MSSQL на Oracle или на PostgreSQL и наоборот. Кстати о птичках, действительно в каких-то проектах лучше использовать NoSQL, но таких проектов гораздо меньше, примерно на порядок, чем SQL. Более того, современные СУБД SQL весьма хорошо справляются с большинством задач, которые решают NoSQL.

[Игорь Столяров]

И легко переключать с MSSQL на Oracle или на PostgreSQL и наоборот.

Ну это не так. Точнее не совсем так.
Аналогично можно написать программу, в которой можно переключать БД, например, с TopSpeed на Btrieve MKDE или DBF.
Но тогда придётся обходится базовыми совместимыми типами данных. Это не плохо, но существенное ограничение.
В SQL хуже - там придётся забыть ещё и про расширенный функционал запросов, да и базовый часто отличается ...

Но академическое приложение уровня "Hello world !" можно сделать совместимым с разными типами SQL серверов.

[finsoftrz]

Я всегда пользовался базовыми типами данных, ещё со времен клариона для доса. И вроде особо не страдаю. Речь, видимо, сводится конкретно к decimal и pdecimal.
Зато когда у одного клиента база стала сильно распухать в связи с ростом торговой сети, получилось легко решить эту проблему, просто прописав в шаблонах в нужном месте prop:driver='btrieve'. Приложение практически осталось без изменений (точнее, по мелочам была пара правок в системном разделе). И сейчас одно и тоже приложение без пересборок работает и с tps, и с btrieve. Просто в каталог с файлами базы данных подкладывается пустой файлик btrieve.cfg. Размер базы на btrieve сейчас порядка 60 гб, не считая логов. Хорошо помню все разговоры, зачем пишете под tps, вот вырастет размер базы, все придётся заново переписывать под sql, лучше сразу, чтобы потом не мучиться. Оказались не правы те ребята.

[Игорь Столяров]

Речь, видимо, сводится конкретно к decimal и pdecimal.

В TPS есть ещё BLOB. Он достаточно удобен для сохранения данных неизвестного размера.
Но идея в том, что совместимость всё равно требует выполнения определённых условий ...

[PavelNK]

Я всегда пользовался базовыми типами данных, ещё со времен клариона для доса. И вроде особо не страдаю. Речь, видимо, сводится конкретно к decimal и pdecimal.
Зато когда у одного клиента база стала сильно распухать в связи с ростом торговой сети, получилось легко решить эту проблему, просто прописав в шаблонах в нужном месте prop:driver='btrieve'. Приложение практически осталось без изменений (точнее, по мелочам была пара правок в системном разделе). И сейчас одно и тоже приложение без пересборок работает и с tps, и с btrieve. Просто в каталог с файлами базы данных подкладывается пустой файлик btrieve.cfg. Размер базы на btrieve сейчас порядка 60 гб, не считая логов. Хорошо помню все разговоры, зачем пишете под tps, вот вырастет размер базы, все придётся заново переписывать под sql, лучше сразу, чтобы потом не мучиться. Оказались не правы те ребята.

Чтобы понимать насколько правы или не правы те или иные ребята нужно поработать достаточно плотно с разными БД, я работал и с Clarion и с Btrieve и с SQL, разными SQL. Работа с разными SQL отличается, разные инструменты, разные алгоритмы, но в целом, работать с SQL, на мой взгляд, на порядок удобнее, комфортнее, чем с файловыми БД. Но, как говорят, на вкус, да на цвет, товарища нет.

[PavelNK]

И легко переключать с MSSQL на Oracle или на PostgreSQL и наоборот.

Ну это не так. Точнее не совсем так.

Аналогично можно написать программу, в которой можно переключать БД, например, с TopSpeed на Btrieve MKDE или DBF.
Но тогда придётся обходится базовыми совместимыми типами данных. Это не плохо, но существенное ограничение.
В SQL хуже - там придётся забыть ещё и про расширенный функционал запросов, да и базовый часто отличается ...

Но академическое приложение уровня "Hello world !" можно сделать совместимым с разными типами SQL серверов.

Базовый отличается не сильно, но даже базовый гораздо удобнее, комфортнее, функциональнее, чем SET-GET-PUT, смею Вас заверить.
Но хозяин-барин, хочет шьет - хочет порет)))

[PavelNK]

Если бы файловые БД были лучше, то все вернулись бы на них, но ситуация обратная