ВСЕ ЗАКОНОДАТЕЛЬСТВО УЗБЕКИСТАНА
Законодательство РУз / Отдельные отрасли экономики / Утратившие силу акты / Торговля. Общественное питание. Бытовое обслуживание /Технические требования к фискальному модулю, используемому в системе онлайн контрольно-кассовых машин, обеспечивающих передачу данных о расчетах в режиме реального времени (Приложение N 2 к Постановлению КМ РУз от 21.02.2019 г. N 150)
Полный текст документа доступен в платной версии. По вопросам звоните на короткий номер 1172
ПРИЛОЖЕНИЕ N 2
к Постановлению КМ РУз
от 21.02.2019 г. N 150
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
к фискальному модулю, используемому
в системе онлайн контрольно-кассовых машин,
обеспечивающих передачу данных о расчетах
в режиме реального времени
1. Фискальный модуль закупается в состоянии заводского выпуска, что означает отсутствие каких-либо идентифицирующих данных как внутренних, так и визуально доступных. В зависимости от соответствующих договоренностей устройство может содержать записанное производителем программное обеспечение или программное обеспечение будет устанавливаться при инициализации фискального модуля оператором фискальных данных (далее - ОФД).
2. Процесс производства фискального модуля подразумевает осуществление следующих действий с использованием соответствующей инфраструктуры:
а) запись специализированного программного обеспечения (апплета), осуществляющего операции по обработке и передаче фискальных данных;
б) присвоение уникального номера, генерацию открытого и закрытого ключей и передачу открытого ключа в носитель данных (во время пилотного проекта - в базу данных, в период полного проекта - в модуль безопасности НSM). Закрытый ключ хранится только на фискальном модуле;
в) нанесение визуальных данных - идентификационного номера модуля, соответствующего штрих-кода, логотипов и прочей необходимой визуальной информации.
3. Обработанный фискальный модуль имеет свой уникальный идентификатор, информация о котором хранится в системе ОФД и Государственном налоговом комитете Республики Узбекистан (далее - Комитет).
ФИСКАЛЬНОГО МОДУЛЯ
4. В качестве фискального модуля можно использовать устройства в форме смарт-карты или USB-ключа.
5. Фискальный модуль должен быть оснащен контроллером Infineon SLE77CLFX2400PM или совместимым с более новой версией. Более того, карта должна поддерживать T=0 и T=1 - протоколы коммуникации и криптографические алгоритмы ГОСТ 28147-89, UZDST1106-2009, UZDST1092-2009, 3DES, AES, RSA, SНA-1, SНA-224, SНA-256, ECC over GF(p) и Random number generation и функционалы шифрования.
На период реализации пилотного проекта предполагается использовать индустриальные стандарты Java Card 2.2.2 и Global Platform 2.1.1 или более новые версии.
ГЛАВА 3. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
ФИСКАЛЬНОГО МОДУЛЯ
6. Команды.
Программное обеспечение фискального модуля должно обеспечивать осуществление следующих команд:
Команда
|
Объяснение |
REQUEST CARD ACTIVATE |
Эта команда соответствует первому этапу активации фискального модуля и подразумевает генерацию криптограммы. Данная криптограмма должна передаваться в контрольно-кассовую машину (далее - ККМ), которая в свою очередь отправляет ее в информационную систему ОФД.
|
ACTIVATE CARD |
Второй этап активации фискального модуля подразумевает поступление в ККМ ответа от информационной системы ОФД и передачу его в апплет фискального модуля для использования в качестве одного из параметров команды ACTIVATE CARD. В результате осуществления этой команды сравниваются полученный от сервера и хранящийся на фискальном модуле ключи, в случае совпадения фискальный модуль получает активный статус.
|
DEACTIVATE CARD |
Данная команда используется при необходимости деактивации фискального модуля. Процесс деактивации имеет ряд ограничений, одним из которых является обязательная отсылка всех хранящихся в апплете и не отосланных в ОФД "Z-отчетов".
|
GET MODULE INFO |
Команда возвращает состояние всех переменных на момент осуществления запроса.
|
GET BATCН |
Команда возвращает содержание конкретного "Z-отчета".
|
REGISTER TRANSACTION |
Программное обеспечение аппарата ККМ берет суммарную цену. Данный параметр является настраиваемым и зависит от требований налогового законодательства. ККМ вызывает функцию REGISTER TRANSACTION в фискальном модуле и передает: тип транзакции, сумму и дату/время. В случае удачной регистрации транзакции фискальный модуль возвращает: свой (модуля) уникальный номер, уникальный нарастающий номер транзакции (номер растет при любой транзакции, вызывающей смену состояния фискального модуля), нарастающий номер данного типа транзакции, номер "Z-отчета", в котором проводится транзакция, другую дополнительную информацию и цифровую подпись. Необходима реализация возможности конфигурации списка и обязательности параметров в зависимости от формы хозяйствования налогоплательщика.
|
GEТ LAST TRANSACTION |
Команда возвращает данные последней зарегистрированной в информационной системе ОФД транзакции. Данная команда используется в случае отсутствия ответа об успешной регистрации транзакции, возникшем из-за технических причин.
|
CLOSE BATCН |
Команда, осуществляющая закрытие "Z-отчета" в апплете фискального модуля. Во время закрытия "Z-отчета" в фискальном модуле записывается информация о всех проведенных в соответствующий период транзакциях. Информация подтверждается цифровой подписью.
|
GET BATCН |
Команда, посылаемая ККМ в апплет фискального модуля для получения подписанных ключом данных "Z-отчета" для последующей отсылки в Комитет.
|
BATCН REGISTERED |
После отсылки в ОФД "Z-отчета" в ККМ возвращается сообщение о результате регистрации. Это сообщение в качестве параметра рассматриваемой команды передается из ККМ в апплет фискального модуля для проверки успешности регистрации "Z-отчета". Фискальный модуль осуществляет проверку валидности цифровой подписи, в результате которой фиксирует успешную передачу данных в центральный модуль безопасности, производит стирание этого отчета из своей памяти и сокращает счетчик непосланных отчетов.
|
7. Хранящаяся информация.
На протяжении всего периода использования (пока фискальный модуль сохраняет активный статус) в фискальном модуле должна сохраняться нижеследующая информация:
а) глобально в какой сумме и сколько транзакций проведено по каждому типу транзакции за весь период активности фискального модуля и соответствующие суммы по этим транзакциям;
б) сколько транзакций какого типа и на какую сумму проведено по каждому конкретному "Z-отчету";
в) ограниченное количество неотосланных "Z-отчетов". Этот параметр конфигурируется в зависимости от соответствующих требований.
Детальная информация о каждой транзакции должна храниться в фискальном модуле до получения подтверждения о приеме транзакции от ОФД.
8. Механизм нумерации транзакций.
В результате обработки транзакции в апплете фискального модуля должно осуществляться присваивание двух номеров транзакции:
а) постоянно растущий номер транзакции, не зависящий от ее типа;
б) постоянно растущий номер транзакции конкретного типа (дебетной, кредитной, дебетной безналичной, кредитной безналичной).
Механизм нумерации транзакций обеспечивает контроль всех транзакций на стороне Комитета. В случае изменения количества передаваемых в центральный модуль безопасности Комитета транзакций такие несанкционированные действия легко отследить при помощи механизма нумерации. На сервере хранятся пронумерованные транзакции, суммарное количество и сумма которых должны совпадать с данными "Z-отчета".
9. Ограничения по "Z-отчету".
Для каждого налогоплательщика ОФД устанавливает ограничение по максимальному количеству и общей сумме транзакций в одном "Z-отчете". По достижении максимального количества или общей суммы фискальный модуль должен отказывать в регистрации последующей транзакции, с требованием закрытия "Z-отчета" и отказом от дальнейшей работы. Однако закрытие "Z-отчета" не означает его незамедлительную отсылку в центральный модуль безопасности.
Количество неотосланных "Z-отчетов" также регулируется ОФД. По достижении максимального количества налогоплательщик обязан передать все скопившиеся отчеты в центральный модуль безопасности, а фискальный модуль должен перестать регистрировать и подписывать транзакции до передачи этих отчетов и закрытия дня.
10. Операционные требования к ПО.
Операционные требования, касающиеся количества транзакций в одном "Z-отчете", количества и периодичности отсылки "Z-отчетов" в ОФД, типы обрабатываемых транзакций и т.п. должны быть конфигурируемы и соответствовать требованиям Комитета.
11. Требования к системе безопасности.
Процесс производства фискального модуля требует разработки сопутствующей политики информационной безопасности, соответствующей требованиям не ниже предусмотренного утвержденным на территории Республики Узбекистан стандартом O`z DSt ISO/IEC 27001:2009.
ГЛАВА 4. ИНИЦИАЛИЗАЦИЯ ФИСКАЛЬНОГО МОДУЛЯ
12. Общее описание процесса инициализации фискального модуля.
Необходимым условием для выполнения инициализации фискального модуля является наличие установленного специализированного программного обеспечения - апплета, обеспечивающего выполнение соответствующих действий.
Процесс инициализации подразумевает:
а) генерацию ключей цифровой подписи и передачу отрытого ключа в CSM;
б) запись ключей сервера CSM для последующей идентификации поступивших ответов на запросы;
в) учет инициализированных фискальных модулей и обмен данными с персональным кабинетом налогоплательщика.
13. Требования к системе безопасности.
Обеспечение безопасности процесса инициализации фискального модуля должно быть осуществлено как с помощью применения соответствующих стандартных и утвержденных в Республике Узбекистан методов и средств защиты данных, так и с применением регламентированных средств физической защиты (камеры видеонаблюдения, ограничение физического доступа и т.п.).
Применение средств и действий по обеспечению безопасности необходимо для предотвращения:
а) утечки персональных ключей, что может сделать возможной фальсификацию программного обеспечения (апплета) фискального модуля;
б) потери информации об инициализации фискального модуля, которая может нарушить процесс активации фискального модуля.
Национальная база данных законодательства (www.lex.uz), 21 февраля 2019 г.