язык интерфейса

Технические требования к фискальному модулю, используемому в системе онлайн контрольно-кассовых машин, обеспечивающих передачу данных о расчетах в режиме реального времени (Приложение N 2 к Постановлению КМ РУз от 21.02.2019 г. N 150)

Технические требования к фискальному модулю, используемому в системе онлайн контрольно-кассовых машин, обеспечивающих передачу данных о расчетах в режиме реального времени (Приложение N 2 к Постановлению КМ РУз от 21.02.2019 г. N 150)

Полный текст документа доступен в платной версии. По вопросам звоните на короткий номер 1172

ПРИЛОЖЕНИЕ N 2

к Постановлению КМ РУз

от 21.02.2019 г. N 150



ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

к фискальному модулю, используемому

в системе онлайн контрольно-кассовых машин,

обеспечивающих передачу данных о расчетах

в режиме реального времени


ГЛАВА 1. ОБЩИЕ ПОНЯТИЯ


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


2. Процесс производства фискального модуля подразумевает осуществление следующих действий с использованием соответствующей инфраструктуры:

а) запись специализированного программного обеспечения (апплета), осуществляющего операции по обработке и передаче фискальных данных;

б) присвоение уникального номера, генерацию открытого и закрытого ключей и передачу открытого ключа в носитель данных (во время пилотного проекта - в базу данных, в период полного проекта - в модуль безопасности НSM). Закрытый ключ хранится только на фискальном модуле;

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


3. Обработанный фискальный модуль имеет свой уникальный идентификатор, информация о котором хранится в системе ОФД и Государственном налоговом комитете Республики Узбекистан (далее - Комитет).



ГЛАВА 2. ФИЗИЧЕСКИЕ ПАРАМЕТРЫ

ФИСКАЛЬНОГО МОДУЛЯ


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 г.