ДЕРЖАВНА ПОДАТКОВА АДМІНІСТРАЦІЯ УКРАЇНИ
Н А К А З
24.04.2009 N 213
Про затвердження Уніфікованого форматутранспортного повідомлення
при інформаційній взаємодії платників податків,
операторів і податкових органів
в електронному вигляді
телекомунікаційними каналами зв'язку
з використанням електронного цифрового підпису
На виконання розпорядження Кабінету Міністрів України
від 06.02.2008 N 262-р ( 262-2008-р ) "Про заходи щодо
удосконалення системи адміністрування податку на додану вартість"
та з метою подальшої уніфікації інформаційної взаємодії між
платниками податків, операторами і податковими органами
телекомунікаційними каналами зв'язку з використанням електронного
цифрового підпису (далі - ЕЦП) Н А К А З У Ю:
1. Затвердити Уніфікований формат транспортного повідомлення
при інформаційній взаємодії платників податків, операторів і
податкових органів в електронному вигляді телекомунікаційними
каналами зв'язку з використанням електронного цифрового підпису
(далі - Уніфікований формат транспортного повідомлення), що
додається.
2. Наказ ДПА України від 22.07.2008 N 485
( v0485225-08, va485225-08 ) "Про затвердження Уніфікованого
формату транспортного повідомлення при інформаційній взаємодії
платників податків і податкових органів в електронному вигляді
телекомунікаційними каналами зв'язку з використанням електронного
цифрового підпису" вважати таким, що втратив чинність.
3. Директору Департаменту інформаційно-аналітичного
забезпечення процесів оподаткування Шевченку С.С. забезпечити
дотримання вимог Уніфікованого формату транспортного повідомлення
при введенні в промислову експлуатацію програмного забезпечення з
використанням електронного цифрового підпису.
4. Директору Департаменту масово-роз'яснювальної роботи та
звернень громадян Косарчуку В.П. оприлюднити Уніфікований формат
транспортного повідомлення.
5. Контроль за виконанням наказу покласти на заступника
Голови Регурецького В.В.
Голова С.В.Буряк
ЗАТВЕРДЖЕНОНаказ ДПА України
24.04.2009 N 213
УНІФІКОВАНИЙ ФОРМАТтранспортного повідомлення
при інформаційній взаємодії платників податків,
операторів і податкових органів
в електронному вигляді телекомунікаційними
каналами зв'язку з використанням електронного
цифрового підпису
Уніфікований формат транспортного повідомлення для обміну
інформацією між платниками податків, операторами і податковими
органами в електронному вигляді телекомунікаційними каналами
зв'язку з використанням електронного цифрового підпису (далі -
Уніфікований формат транспортного повідомлення) застосовується для
організації обміну електронними документами між платниками
податків і податковими органами телекомунікаційними каналами
зв'язку з використанням електронного цифрового підпису
(далі - ЕЦП). Обмін електронними документами здійснюється за
допомогою транспортного повідомлення (далі - ТП) із прикріпленим
до нього транспортним контейнером, що містить зашифровані дані
(електронні звіти, квитанції тощо).
1. Шляхи обміну інформацією
Обмін інформацією між платниками податків і податковими
органами в електронному вигляді може проводитися двома шляхами: електронний документ передається безпосередньо до податкового
органу; електронний документ передається до податкового органу за
допомогою Оператора електронної звітності.
2. Оператор електронної звітності
Оператор електронної звітності (далі - ОЕЗ) являє собою
комплекс, який складається з апаратного забезпечення, програмного
забезпечення та нормативних документів і призначений для
забезпечення транспортування документів між платниками податків
і податковими органами в електронному вигляді телекомунікаційними
каналами зв'язку, з використанням електронного цифрового підпису.
3. Вимоги до криптографічного захисту інформації
Усі криптографічні перетворення виконуються засобами систем
криптографічного захисту інформації (СКЗІ). Застосовувані СКЗІ
повинні відповідати таким вимогам: реалізовувати процедури формування й перевірки ЕЦП відповідно
до вітчизняного стандарту ДСТУ 4145-2002; реалізовувати процедури відкритого розподілу ключів
відповідно до вітчизняного стандарту ДСТУ ISO IEC 15946-3:2006; реалізовувати процедури симетричного шифрування відповідно
до ГОСТ 28147-89; бути сертифікованими відповідно до законодавства України. Функції бібліотек криптографічних перетворень, що надаються
центрами сертифікації ключів для інтеграції у систему приймання та
обробки податкової звітності, повинні відповідати специфікаціям
криптографічних перетворень викладених у додатку 3.
4. Уніфікований формат транспортного повідомлення
Уніфікований формат транспортного повідомлення підтримує всі
діючі типи електронних документів інформаційної взаємодії,
обумовлених порядком подання податкової звітності відповідно до
чинного законодавства України та інших нормативних актів Державної
податкової адміністрації України.
4.1. Уніфіковане транспортне повідомлення для передачі
документів безпосередньо до податкового органу Схему уніфікованого транспортного повідомлення представлено
на рис 1 ( va213225-09 ).
4.2. Уніфіковане транспортне повідомлення для передачі
документів до податкового органу за допомогою Оператора
електронної звітності Схему уніфікованого транспортного повідомлення представлено
на рис. 2 ( va213225-09 ).
5. Вимоги до структури транспортного повідомлення,що передається телекомунікаційними каналами зв'язку
Транспортне повідомлення являє собою файл у форматі
електронної пошти (МІМЕ), оформлений за стандартом RFC-1521. Файл, який вміщує транспортний контейнер, входить у
транспортне повідомлення як файл-вкладення ("Content-Disposition:
attachment"). Ім'я файла-вкладення зазначено в полі "filename".
Розмір файла транспортного контейнера не може бути нульовим. Транспортне повідомлення може мати тільки одного одержувача. Одне транспортне повідомлення, передане телекомунікаційними
каналами зв'язку, повинно містити тільки один вкладений у нього
транспортний контейнер. Розмір транспортного повідомлення,
переданого телекомунікаційними каналами зв'язку, не повинен
перевищувати 10 Мбайт. У випадку прийняття до обробки
транспортного повідомлення Оператором електронної звітності та
прийомним комплексом податкового органу, контейнер з тим самим
ім'ям не може бути переданий тим самим відправником вдруге. Ідентифікаційний код платника податків за ЄДРПОУ або
індивідуальний податковий номер фізичної особи далі за текстом -
ЄДРПОУ. Заголовок транспортного повідомлення повинен містити такі
обов'язкові поля: "From:" - поле, що містить ім'я відправника у кодуванні
"Quoted Printable/Windows 1251" або "Base64/Windows 1251" й
електронну адресу відправника, поміщену у кутові дужки <>; "Reply-To:" - поле, що містить ім'я відправника в кодуванні
"Quoted Printable/Windows 1251" або "Base64/Windows 1251" й
електронну адресу відправника, поміщену у кутові дужки <>; "To:" - поле, що містить ім'я одержувача в кодуванні "Quoted
Printable/Windows 1251" або "Base64/Windows 1251" й електронну
адресу одержувача, поміщену у кутові дужки <>; "Message-ID:" - поле, що містить унікальний, у межах
організації відправника, ідентифікатор повідомлення довільного
формату з довжиною, що не перевищує 40 символів; "Content-Transfer-Encoding:" - поле, що містить механізм
кодування тіла повідомлення. Припустимі значення: "Quoted
Printable/Windows 1251", "Base64". Приєднаному файлу вкладення повинні відповідати поля: "Content-Type:", що містить ключове слово
"application/octet-stream" і параметр "name=". Параметр "name"
повинен містити ім'я файла вкладення. Ім'я файла повинно
кодуватися в Quoted Printable/Windows 1251 або Base64/Windows
1251. "Content-Disposition:", що містить ключове слово "attachment"
і параметр "filename". Ім'я файла повинно кодуватися в Quoted
Printable/Windows 1251 або Base64/Windows 1251. "Content-Length:", що містить довжину вкладення. "Subject:" - зміст поля представлений у кодуванні "Quoted
Printable/Windows 1251" або "Base64/Windows 1251", визначається
типом документа та ім'ям приєднаного транспортного контейнера. Приклад транспортного повідомлення, що містить документ
податкової звітності (розрахунку), наведено у додатку 1. Приклад файла документа податкової звітності наведено у
додатку 2.
6. Вимоги до структури транспортного контейнерадля передачі документів безпосередньо
до податкового органу
6.1. Узагальнений формат транспортного контейнера для
передачі документів безпосередньо до податкового органу Заголовок транспортного контейнера Реквізити шифрування даних Зашифровані дані
6.2. Перелік блоків даних транспортного контейнера для
передачі документів безпосередньо до податкового органу Зашифрований блок даних
Формат зашифрованого блоку даних:
------------------------------------------------------------------ | Елемент | Значення | |--------------------------+-------------------------------------| |Сигнатура |"XXX_ CRYPT", | | |де XXX - код Центру сертифікації | | |електронних ключів: | | |"A", "B", "C", ... - символьний | | |ідентифікатор, привласнений АЦСК* | |--------------------------+-------------------------------------| |0-символ | | |--------------------------+-------------------------------------| |4 байти |розмір зашифрованого документа | |--------------------------+-------------------------------------| |Зашифрований документ | | ------------------------------------------------------------------
--------------- * Символьний ідентифікатор, привласнений АЦСК, називається за
порядком літер латинського алфавіту відповідно до черговості
проходження акредитації в Україні. Тобто, першому акредитованому
ЦСК в Україні буде привласнено символ "A", другому за часом
акредитації - символ "B", третьому - "C", далі за латинським
алфавітом.
Підпис
Формат підпису:
------------------------------------------------------------------ | Елемент | Значення | |--------------------------+-------------------------------------| |Сигнатура |"XXX_SIGN", | | |де XXX - код Центру сертифікації | | |електронних ключів: | | |"A", "B", "C", ... - символьний | | |ідентифікатор, привласнений АЦСК* | |--------------------------+-------------------------------------| |0-символ | | |--------------------------+-------------------------------------| |4 байти |розмір буфера підпису та підписаних | | |даних | |--------------------------+-------------------------------------| |Буфер підпису та | | |підписаних даних | | ------------------------------------------------------------------
--------------- * Символьний ідентифікатор, привласнений АЦСК, називається за
порядком літер латинського алфавіту відповідно до черговості
проходження ними акредитації в Україні. Тобто, першому
акредитованому ЦСК в Україні буде привласнено символ "A", другому
за часом акредитації - символ "B", третьому - "C", далі за
латинським алфавітом.
Позначка часу Позначка часу отримується з АЦСК за протоколом TSP
(Timestamp Protocol).
Формат позначки часу:
------------------------------------------------------------------ | Елемент | Значення | |--------------------------+-------------------------------------| |Сигнатура |"XXX_STAMP", | | |де XXX - код Центру сертифікації | | |електронних ключів: | | |"A", "B", "C", ... - символьний | | |ідентифікатор, привласнений АЦСК* | |--------------------------+-------------------------------------| |0-символ | | |--------------------------+-------------------------------------| |4 байти |розмір хешу оригінального документа | |--------------------------+-------------------------------------| |хеш оригінального | | |документа | | |--------------------------+-------------------------------------| |4 байти |розмір буфера позначки часу | |--------------------------+-------------------------------------| |Буфер позначки часу | | |--------------------------+-------------------------------------| |4 байти |розмір даних, на які накладено | | |позначку часу | |--------------------------+-------------------------------------| |Блок даних, на які | | |накладено позначку часу | | ------------------------------------------------------------------
--------------- * Символьний ідентифікатор, привласнений АЦСК, називається за
порядком літер латинського алфавіту відповідно до черговості
проходження акредитації в Україні. Тобто, першому акредитованому
ЦСК в Україні буде привласнено символ "A", другому за часом
акредитації - символ "B", третьому - "C", далі за латинським
алфавітом.
Заголовок транспортного контейнера Транспортний заголовок документа містить інформацію про
передаваний документ.
Формат транспортного заголовка документа:
------------------------------------------------------------------ | Елемент | Значення | |--------------------------+-------------------------------------| |Сигнатура |"TRANSPORTABLE" | |--------------------------+-------------------------------------| |0-символ | | |--------------------------+-------------------------------------| |4-байтовий розмір |без врахування довжини сигнатури і | |транспортного заголовка |0-символа | |--------------------------+-------------------------------------| |CR/LF |символи повернення каретки (0D) і | | |переводу рядка (0A) | |--------------------------+-------------------------------------| |Рядок 1 |послідовність вигляду | | |= | |--------------------------+-------------------------------------| |Рядок 2 | | |--------------------------+-------------------------------------| |... | | |--------------------------+-------------------------------------| |Рядок n | | ------------------------------------------------------------------
Теги, використовувані в транспортному заголовку документа:
------------------------------------------------------------------ |Найменування| Значення |Обов'язковість| | | | заповнення | |------------+------------------------------------+--------------| |FILENAME |Ім'я файла у верхньому регістрі, що | Так | | |відправляє (у кодуванні Win1251) та | | | |закінчується символом CHR(13) + | | | |CHR(10) | | |------------+------------------------------------+--------------| |SND_NAME |Найменування/ПІБ платника податків, | Ні | | |що подає звіт (у кодуванні Win1251) | | | |та закінчується символом | | | |CHR(13) + CHR(10) | | |------------+------------------------------------+--------------| |SND_EMAIL |E-Mail відправника (у кодуванні | Ні | | |Win1251) та закінчується символом | | | |CHR(13) + CHR(10) | | |------------+------------------------------------+--------------| |RCV_NAME |Найменування одержувача (у кодуванні| Ні | | |Win1251) та закінчується символом | | | |CHR(13) + CHR(10) | | |------------+------------------------------------+--------------| |RCV_EMAIL |E-Mail одержувача (у кодуванні | Так | | |Win1251) та закінчується символом | | | |CHR(13) + CHR(10) | | |------------+------------------------------------+--------------| |PRG_TYPE |Назва програмного забезпечення для | Так | | |накладання та перевірки ЕЦП | | | |відправника довжиною не більше | | | |десяти символів (у кодуванні | | | |Win1251) та закінчується символом | | | |CHR(13) + CHR(10) | | |------------+------------------------------------+--------------| |PRG_VER |Версія програмного забезпечення для | Ні | | |накладання та перевірки ЕЦП | | | |відправника довжиною не більше | | | |десяти символів (у кодуванні | | | |Win1251) та закінчується символом | | | |CHR(13) + CHR(10) | | |------------+------------------------------------+--------------| |SND_DATE |Дата і час відправки в форматі | Так | | |YYYYMMDDHHNNSS без розподільників та| | | |закінчується символом | | | |CHR(13) + CHR(10) | | |------------+------------------------------------+--------------| |CERTYPE |Символьний ідентифікатор, | Так | | |привласнений АЦСК (XXX) та | | | |закінчується символом | | | |CHR(13) + CHR(10) | | |------------+------------------------------------+--------------| |CRC32_SIGN |Контрольна сума згідно з алгоритмом | Так | | |CRC32 зашифрованого блоку даних та | | | |закінчується символом | | | |CHR(13) + CHR(10) | | |------------+------------------------------------+--------------| |CRC32_FILE |Контрольна сума згідно з алгоритмом | Так | | |CRC32 підписаного блоку даних та | | | |закінчується символом | | | |CHR(43) + CHR(10) | | |------------+------------------------------------+--------------| |SUBJECT |тип документа податкової звітності | Так | | |(у кодуванні Win1251) та | | | |закінчується символом | | | |CHR(13) + CHR(10) | | |------------+------------------------------------+--------------| |GET_STAMP |Ознака необхідності передачі у | Ні | | |відповідь позначки часу | | |------------+------------------------------------+--------------| |RESULT |Результат прийому повідомлення | Ні | | |(0 - успішно, 1 - помилка, | | | |2 - попередження) | | ------------------------------------------------------------------
6.3. Формати повідомлень, які надсилаються в транспортному
контейнері для передачі документів безпосередньо до податкового
органу Формат повідомлення "Документ" Повідомлення передається від платника податків до податкового
органу. Структура: 1. Підпис відправника. 2. Транспортний заголовок документа. 3. Блок даних, зашифрований на одержувача, містить підписи
платника податків і блок з документом у форматі XML. Увага! Підписи платника повинні накладатися у такому порядку: 1. Підписана секція (XXX_SIGN) - підписана ключем головного
бухгалтера (за умови наявності посади на підприємстві). 2. Підписана секція (XXX_SIGN) - підписана ключем директора
(керівника) підприємства. 3. Підписана секція (XXX_SIGN) - підписана ключем цифрової
печатки підприємства (за умови її наявності). 4. Підписана секція (XXX_SIGN) - підписана ключем цифрової
печатки філіалу підприємства (за умови наявності філіалу на
підприємстві). 5. Блок з документом у форматі XML. Формат повідомлення "Документ з позначкою часу" Повідомлення передається від податкового органу до платника
податків. Повідомлення є відповіддю податкового органу на запит
документа. Структура: 1. Транспортний заголовок документа. 2. Блок даних, зашифрований на одержувача: 2.1. Підпис податкового органу. 2.2. Позначка часу на момент отримання документа від платника
податків. 2.3. Підписи платника податків. 2.4. Блок з документом у форматі XML. Формат повідомлення "Відповідь на документ" Повідомлення передається від податкового органу до платника
податків. Повідомлення є відповіддю податкового органу на переданий
документ. Наприклад, квитанція про призначення реєстраційного номера. Структура: 1. Підпис податкового органу. 2. Транспортний заголовок документа. 3. Блок, зашифрований на платника податків, містить підписи і
текст відповіді податкового органу. Формат повідомлення "Відповідь на документ з позначкою часу"
Повідомлення передається від податкового органу до платника
податків. Повідомлення є відповіддю податкового органу на переданий
документ, якщо транспортний заголовок документа містить тег "
GET_STAMP=1". Наприклад, квитанція про призначення реєстраційного номера. Структура: 1. Позначка часу. 2. Підпис податкового органу. 3. Транспортний заголовок документа. 4. Блок, зашифрований на платника податків, містить підписи і
текст відповіді податкового органу.
7. Вимоги до структуритранспортного контейнера ОЕЗ
7.1. Узагальнений формат транспортного контейнера ОЕЗ Формат повідомлення для відправки на ОЕЗ: Підпис відправника Транспортний заголовок ОЕЗ Транспортний контейнер документа або Блок даних, підготовлений для ОЕЗ або Зашифрований блок даних, підготовлений для ОЕЗ Формат повідомлення від ОЕЗ: Підпис ОЕЗ Транспортний заголовок ОЕЗ Транспортний контейнер документа або Блок даних, підготовлений ОЕЗ або Зашифрований блок даних, підготовлений ОЕЗ
7.2. Перелік блоків даних контейнера ОЕЗ Зашифрований блок даних
Формат зашифрованого блоку даних:
------------------------------------------------------------------ | Елемент | Значення | |--------------------------+-------------------------------------| |Сигнатура |"XXX_CRYPT", | | |де XXX - код Центру сертифікації | | |електронних ключів: | | |"A", "B", "C", ... - символьний | | |ідентифікатор, привласнений АЦСК* | |--------------------------+-------------------------------------| |4 байти |розмір зашифрованого блока даних | |--------------------------+-------------------------------------| |Зашифрований блок даних | | ------------------------------------------------------------------
--------------- * Символьний ідентифікатор, привласнений АЦСК, називається за
порядком літер латинського алфавіту відповідно до черговості
проходження акредитації в Україні. Тобто, першому акредитованому
ЦСК в Україні буде привласнено символ "A", другому за часом
акредитації - символ "B", третьому - "C", далі за латинським
алфавітом.
Підпис
Формат підпису:
------------------------------------------------------------------ | Елемент | Значення | |--------------------------+-------------------------------------| |Сигнатура |"XXX_SIGN", | | |де XXX - код Центру сертифікації | | |електронних ключів: | | |"A", "B", "C", ... - символьний | | |ідентифікатор, привласнений АЦСК* | |--------------------------+-------------------------------------| |0-символ | | |--------------------------+-------------------------------------| |4 байти |розмір буфера підпису та підписаних | | |даних | |--------------------------+-------------------------------------| |Буфер підпису та | | |підписаних даних | | ------------------------------------------------------------------
--------------- * Символьний ідентифікатор, привласнений АЦСК, називається за
порядком літер латинського алфавіту відповідно до черговості
проходження акредитації в Україні. Тобто, першому акредитованому
ЦСК в Україні буде привласнено символ "A", другому за часом
акредитації - символ "B", третьому - "C", далі за латинським
алфавітом.
Позначка часу Позначка часу отримується з АЦСК за протоколом TSP
(Timestamp Protocol).
Формат позначки часу:
------------------------------------------------------------------ | Елемент | Значення | |--------------------------+-------------------------------------| |Сигнатура |"XXX_STAMP", | | |де XXX - код Центру сертифікації | | |електронних ключів: | | |"A", "B", "C", ... - символьний | | |ідентифікатор, привласнений АЦСК* | |--------------------------+-------------------------------------| |0-символ | | |--------------------------+-------------------------------------| |32 байти |хеш оригінального документа | |--------------------------+-------------------------------------| |4 байти |розмір буфера позначки часу | |--------------------------+-------------------------------------| |Буфер позначки часу | | |--------------------------+-------------------------------------| |4 байти |розмір даних, на які накладено | | |позначку часу | |--------------------------+-------------------------------------| |Блок даних, на які | | |накладено позначку часу | | ------------------------------------------------------------------
--------------- * Символьний ідентифікатор, привласнений АЦСК, називається за
порядком літер латинського алфавіту відповідно до черговості
проходження акредитації в Україні. Тобто, першому акредитованому
ЦСК в Україні буде привласнено символ "A", другому за часом
акредитації - символ "B", третьому - "C", далі за латинським
алфавітом.
Транспортний заголовок ОЕЗ Транспортний заголовок Оператора містить інформацію про
передаваний блок даних.
Формат транспортного заголовка Оператора:
------------------------------------------------------------------ | Елемент | Значення | |--------------------------+-------------------------------------| |Сигнатура |"ZPOSTTRANSPORTABLE" | |--------------------------+-------------------------------------| |0-символ | | |--------------------------+-------------------------------------| |4-байтовий розмір |без врахування довжини сигнатури і | |транспортного заголовка |0-символа | |--------------------------+-------------------------------------| |CR/LF |символи повернення каретки (0D) і | | |переводу рядка (0A) | |--------------------------+-------------------------------------| |Рядок 1 |послідовність вигляду | | |= | |--------------------------+-------------------------------------| |Рядок 2 | | |--------------------------+-------------------------------------| |... | | |--------------------------+-------------------------------------| |Рядок n | | ------------------------------------------------------------------
Теги, використовувані в транспортному заголовку ОЕЗ:
------------------------------------------------------------------ |Найменування| Значення |Обов'язковість| | | | заповнення | |------------+------------------------------------+--------------| |DOC_TYPE |Тип повідомлення: 1-Документ, | Так | | |2-Квитанція, 3-Відповідь на | | | |документ, 4-Карточка користувача, | | | |10-результат виконання операції | | | |передачі повідомлення, 100-запит | | | |списку ID вхідної кореспонденції, | | | |101-Запрос вхідного документа по ID | | |------------+------------------------------------+--------------| |REQ_DCTP |Тип запрошуваного повідомлення | Ні | | |(заповнюється для DOC TYPE=101), | | | |див. "DOC TYPE=" | | |------------+------------------------------------+--------------| |FILENAME |Ім'я файла, що міститься в | Так | | |повідомленні (ID повідомлення) | | |------------+------------------------------------+--------------| |ANSWERID |ID відповіді на документ (GUID) | Ні | | |(Документ визначається полем | | | |FILENAME) | | |------------+------------------------------------+--------------| |EDRPOU |ЄДРПОУ відправника | Так | |------------+------------------------------------+--------------| |DEPT |Код філії відправника | Ні | |------------+------------------------------------+--------------| |RCV_EDRPOU |ЄДРПОУ одержувача | Так | |------------+------------------------------------+--------------| |RCV_DEPT |Код філії одержувача | Ні | |------------+------------------------------------+--------------| |SUBJECT |Рядок опису документа | Ні | | |(довільний текстовий рядок) | | |------------+------------------------------------+--------------| |ANSW_STT |Статус відповіді на документ: | Ні | | |0-оброблюється/1-завершено | | |------------+------------------------------------+--------------| |RESULT |Код результату виконання операції | Ні | |------------+------------------------------------+--------------| |RESADD |Рядок з додатковою інформацією про | Ні | | |результат виконання операції | | ------------------------------------------------------------------
Ідентифікатором (ID) повідомлення є комбінація полів
"FILENAME=" і "ANSWERID=". Для повідомлень типу "Картка користувача" в полі "FILENAME="
знаходиться GUID. Для повідомлень типу "Картка користувача" в таблиці ZPMSG
поле IDRCP дорівнює нулю. Тип повідомлення 10 призначений для одержання результату
обробки сервером повідомлень типу 1-4.
7.3. Формати повідомлень, які передаються в транспортному
контейнері ОЕЗ Формат повідомлення "Документ" Повідомлення передається від платника податків до ОЕЗ.
Основний вид повідомлення. Призначений для передачі документів у
податковий орган. Структура: 1. Підпис відправника. 2. Транспортний заголовок ОЕЗ. У заголовку: DOC_TYPE=1FILENAME=(ID повідомлення)> FILENAME=(ID повідомлення)> EDRPOU= DEPT= (необов'язковий) RCV_EDRPOU= RCV_DEPT= (необов'язковий) SUBJECT=. 3. Блок даних, зашифрований на одержувача, містить контейнер
документа. Формат повідомлення "Квитанція" Повідомлення передається від ОЕЗ платнику податків. Платник
податків повинен підписати квитанцію і відправити її ОЕЗ для
підтвердження доставки документа. Структура: 1. Підпис ОЕЗ. 2. Транспортний заголовок ОЕЗ. У заголовку: DOC_TYPE=2FILENAME=(ID повідомлення)> ANSWERID= (лише для
відповіді на документ) FILENAME=(ID повідомлення)> ANSWERID= (лише для
відповіді на документ) EDRPOU= DEPT= (необов'язковий) RCV_EDRPOU= RCV_DEPT= (необов'язковий) SUBJECT= 3. Блок, зашифрований на одержувача. 3.1. Транспортний заголовок документа (з єдиним тегом
"ENCODING=WIN"). 3.2. Позначка часу ОЕЗ. 3.3. Підпис ОЕЗ. 3.4. Текст квитанції. Квитанція для повідомлень типу "Картка користувача" не
містить поля транспортного заголовка "RCV_EDRPOU=" і "RCV_DEPT=". Формат повідомлення "Підтверджена квитанція" Підписана платником податків квитанція, яка передається ОЕЗ
для підтвердження доставки документа. Структура: 1. Підпис відправника. 2. Транспортний заголовок ОЕЗ. У заголовку: DOC_TYPE=2FILENAME=< Ім'я файла, що міститься в повідомленні
(ID повідомлення)> ANSWERID= (лише для
відповіді на документ) FILENAME=< Ім'я файла, що міститься в повідомленні
(ID повідомлення)> ANSWERID= (лише для
відповіді на документ) EDRPOU= DEPT= (необов'язковий) RCV_EDRPOU= RCV_DEPT= (необов'язковий) SUBJECT= 3. Блок повідомлення "Квитанція", раніше відправлений
одержувачу і "перешифрований" одержувачем на ОЕЗ: 3.1. Підпис відправника. 3.2. Позначка часу ОЕЗ. 3.3. Підпис ОЕЗ. 3.4. Текст квитанції. Квитанція для повідомлень типу "Картка користувача" не
містить поля транспортного заголовка "RCV_EDRPOU=" і "RCV_DEPT=". Формат повідомлення "Відповідь на документ" Повідомлення передається від ОЕЗ платнику податків.
Повідомлення є відповіддю податкового органу на переданий
документ. Наприклад, квитанція про призначення реєстраційного
номера. Структура: 1. Підпис ОЕЗ. 2. Транспортний заголовок ОЕЗ. У заголовку: DOC_TYPE=3FILENAME=< Ім'я файла, що міститься в повідомленні
(ID повідомлення)> ANSWERID= (лише для
відповіді на документ) FILENAME=< Ім'я файла, що міститься в повідомленні
(ID повідомлення)> ANSWERID= (лише для
відповіді на документ) EDRPOU= DEPT= (необов'язковий) RCV_EDRPOU= RCV_DEPT= (необов'язковий) SUBJECT= ANSW_STT= 0-оброблюється/1-завершено>. 3. Підписи оригінальної відповіді на документ. 4. Позначка часу ОЕЗ (яку накладено на незашифрований блок
даних). 5. Блок, зашифрований на платника податків, містить контейнер
документа. Формат повідомлення "Картка користувача" (Реєстрація клієнта
в системі) Повідомлення відправляється платником податків на ОЕЗ для
реєстрації користувача ОЕЗ. Обмін повідомленнями може виконуватися
тільки між зареєстрованими на ОЕЗ користувачами. Структура: 1. Підпис відправника. 2. Транспортний заголовок ОЕЗ. У заголовку: DOC_TYPE=4FILENAME=(ID повідомлення)> (GUID) FILENAME=(ID повідомлення)> (GUID) EDRPOU= DEPT= (необов'язковий). 3. Блок, зашифрований ключем ОЕЗ: 3.1. Блок даних картки. 3.2. Підписи клієнта (один або декілька), у т. ч. підпис
підприємства (для юр. особи) або директора (для фіз. особи). 3.3. Блок XML з реквізитами користувача. Структура і використовувані реквізити блоку XML:xsi:noNamespaceSchemaLocation="Z0100501.XSD"> ... ЄДРПОУ/ІНН* Філія Найменування організації* Код регіону* E-mail контактний E-mail для обміну повідомленнями
1-Обмін повідомленнями завжди ведеться по
E-mail 1-Використовувати адресу E-mail на сервері
Оператора/0-Не использовать Пароль адреси E-mail на сервері Оператора (якщо
не заповнено, пароль призначує Оператор) 1-Обмін повідомленнями завжди ведеться по
E-mail 1-Використовувати адресу E-mail на сервері
Оператора/0-Не использовать Пароль адреси E-mail на сервері Оператора (якщо
не заповнено, пароль призначує Оператор) Юридична адреса* Фактична адреса Контактний телефон*Контактний мобільний телефон Контактний мобільний телефон Контактна особа ...
...
--------------- * Обов'язковий реквізит. Якщо не визначено реквізит "Фактична адреса", то як фактична
адреса використовується реквізит "Юридична адреса". Формат повідомлення "Команда" Повідомлення відправляється платником податків на ОЕЗ для
одержання інформації. Структура: 1. Підпис відправника 2. Транспортний заголовок ОЕЗ. У заголовку: DOC_TYPE=100 або 101 EDRPOU= DEPT= (необов'язковий)REQ_DCTP= (для DOC_TYPE=101) FILENAME= (ID повідомлення)> (для DOC_TYPE=101, або якщо повідомлення
передається по Email) ANSWERID= (лише для
відповіді на документ). REQ_DCTP= (для DOC_TYPE=101) FILENAME= (ID повідомлення)> (для DOC_TYPE=101, або якщо повідомлення
передається по Email) ANSWERID= (лише для
відповіді на документ). Формат повідомлення "Результат виконання команди 100-запиту
списку ID вхідної кореспонденції" Повідомлення відправляється ОЕЗ платнику податків і містить
запитуване повідомлення. Структура: 1. Підпис ОЕЗ. 2. Транспортний заголовок ОЕЗ. У заголовку: DOC_TYPE=100 EDRPOU= DEPT= (необов'язковий) RESULT=RESADD=операції>. RESADD=операції>. 3. Блок, зашифрований на одержувача: Текстовий блок із списком рядків:
DOC_TYPE=документ, 10 - Результат виконання операції передачі повідомлення>
FILENAME=,ANSWERID=>CR> DOC_TYPE=документ, 10 - Результат виконання операції передачі повідомлення>
FILENAME=,ANSWERID=>CR> ОЕЗ може відправляти повідомлення самостійно без запиту з
боку платника податків, коли повідомлення має бути доставлене
платнику податків. Формат повідомлення "Результат виконання команди 101-запиту
вхідного документа по ID" Повідомлення відправляється ОЕЗ платнику податків і містить
результат виконання команди 101. Структура: 1. Підпис ОЕЗ. 2. Транспортний заголовок ОЕЗ. У заголовку: DOC_TYPE=101 EDRPOU= DEPT= (необов'язковий) RCV_EDRPOU= RCV_DEPT= (необов'язковий) REQ_DCTP=FILENAME=(ID повідомлення)> ANSWERID= (лише для
відповіді на документ) FILENAME=(ID повідомлення)> ANSWERID= (лише для
відповіді на документ) RESULT=RESADD=операції>. RESADD=операції>. 3. Блок, зашифрований на одержувача, містить повідомлення
"Документ" або "Квитанція" або "Результат виконання операції
передачі повідомлення". ОЕЗ може відправляти повідомлення самостійно без запиту з
боку платника податків, коли повідомлення має бути доставлене
платнику податків. Формат повідомлення "Результат виконання операції передачі
повідомлення" Повідомлення відправляється ОЕЗ платнику податків і містить
результат виконання команди операції передачі повідомлення. Структура: Транспортний заголовок ОЕЗ. У заголовку: Реквізити, визначені для операції (тобто "клон" заголовка
передаваного повідомлення) RESULT=RESADD=операції>.
RESADD=операції>.
Додаток 1до Уніфікованого формату
транспортного повідомлення
при інформаційній взаємодії
платників податків,
операторів і податкових
органів в електронному
вигляді телекомунікаційними
каналами зв'язку
з використанням електронного
транспортного повідомлення,
що містить документ податкової звітності
( vb213225-09 )
Додаток 2до Уніфікованого формату
транспортного повідомлення
при інформаційній взаємодії
платників податків,
операторів і податкових
органів в електронному
вигляді телекомунікаційними
каналами зв'язку
з використанням електронного
файла документа податкової звітності
Ім'я файла: 26580000000126J020010610000134052008.XML Зміст файла:xsi:noNamespaceSchemaLocation="J0200106.XSD"> xsi:noNamespaceSchemaLocation="J0200106.XSD"> 00000126 J02 001 6 0 134 26 58 5 1 2008 1 03042008 1 2008 05
00000126 236476834278 3266664-ГГ 12345, м. КИЇВ, Перемоги, б. 32 12345 678876 deklarenko@podatok.kiev.ua ДП_ У СОЛОМ'ЯНСЬКОМУ Р-Н_ М. КИЄВА 150 30 150 150 0 0 0 0 30 0 0 0 0 0 0 0 0 30 0 30 0 0 0 0 0 30 03042008 Петров Петро Петрович Ваніліна Олена Петрівна
Додаток 3до Уніфікованого формату
транспортного повідомлення
при інформаційній взаємодії
платників податків,
операторів і податкових
органів в електронному
вигляді телекомунікаційними
каналами зв'язку
з використанням електронного
цифрового підпису
СПЕЦИФІКАЦІЯкриптографічних функцій
1. Вступ
В документі надається опис уніфікованої бібліотеки функцій,
призначених для криптографічних перетворень інформації. Бібліотека
призначена для застосування при розробці програмного забезпечення
в будь-якому середовищі розробки (Microsoft Visual C++,
Visual Basic, C#, CodeGear RAD Studio тощо).
2. Загальні вимоги 1. Робота в середовищі Microsoft Windows 98/2000/XP/Vista. 2. Багатопоточність. 3. Бібліотека повинна поставлятися для платформ х86 та х64. 4. Передача параметрів за угодою __ stdcall. 5. Пам'ять під блоки з результатом роботи функцій виділяється
визиваючою стороною.
3. Поставка бібліотеки Бібліотека поставляється у вигляді DLL. Ім'я DLL:
Crypt_XXX.DLL, де XXX - ім'я постачальника бібліотеки. Доступ до функцій DLL виконується функцією GetProcAddress.
4. Склад бібліотеки 1. Функція накладання підпису int __stdcall MakeSign (const void* pkbuf, int pklen, const
char* pwd, const void* hashbuf, void* signbuf, int* signlen);
------------------------------------------------------------------ | Параметр | Опис | |--------------------------+-------------------------------------| |const void* pkbuf |Буфер з секретним ключем | |--------------------------+-------------------------------------| |int pklen |Розмір буфера з секретним ключем | |--------------------------+-------------------------------------| |const char* pwd |Пароль секретного ключа, повинен | | |закінчуватись символом '\0' | |--------------------------+-------------------------------------| |const void* hashbuf |Буфер з хешем документу, | | |розмір 32 байта | |--------------------------+-------------------------------------| |void* signbuf |Буфер для підпису, якщо | | |NULL - в signlen повертається розмір | |--------------------------+-------------------------------------| |int* signlen |Розмір підпису в буфері | ------------------------------------------------------------------
Функція повертає 0, коли успішно виконано, або код помилки.
2. Функція перевірки підпису int __stdcall VerifySign (const void* certbuf, int certlen,
const void* hashbuf, const void* signbuf, int signlen);
------------------------------------------------------------------ | Параметр | Опис | |--------------------------+-------------------------------------| |const void* certbuf |Буфер з сертифікатом | |--------------------------+-------------------------------------| |int certlen |Розмір буфера з сертифікатом | |--------------------------+-------------------------------------| |const void* hashbuf |Буфер з хешем документу, | | |розмір 32 байта | |--------------------------+-------------------------------------| |const void* signbuf |Буфер з підписом | |--------------------------+-------------------------------------| |int signlen |Розмір буфера з підписом | ------------------------------------------------------------------
Функція повертає 0, якщо підпис вірний, або код помилки.
3. Функція перевірки сертифікату int __stdcall VerifyCert (const void* certbuf, int certlen,
const void* rootcbuf, int rootclen);
------------------------------------------------------------------ | Параметр | Опис | |--------------------------+-------------------------------------| |const void* certbuf |Буфер з сертифікатом | |--------------------------+-------------------------------------| |int certlen |Розмір буфера з сертифікатом | |--------------------------+-------------------------------------| |const void* rootcbuf |Буфер з кореневим сертифікатом | |--------------------------+-------------------------------------| |int rootclen |Розмір буфера з кореневим | | |сертифікатом | ------------------------------------------------------------------
Функція повертає 0, коли сертифікат відповідає кореневому,
або код помилки.
4. Функція шифрування блоку даних int __stdcall Encrypt (const void* certbuf, int certlen, const
void* docbuf, int doclen, void* outbuf, int* outlen);
------------------------------------------------------------------- | Параметр | Опис | |--------------------------+--------------------------------------| |const void* certbuf |Буфер з сертифікатом | |--------------------------+--------------------------------------| |int certlen |Розмір буфера з сертифікатом | |--------------------------+--------------------------------------| |const void* pkbuf |Буфер з секретним ключем | |--------------------------+--------------------------------------| |int pklen |Довжина буфера з секретним ключем | |--------------------------+--------------------------------------| |const char* pwd |Пароль секретного ключа, повинен | | |закінчуватись символом '\0' | |--------------------------+--------------------------------------| |const void* docbuf |Буфер з документом | |--------------------------+--------------------------------------| |int doclen |Розмір буферу з документом | |--------------------------+--------------------------------------| |void* outbuf |Вихідний буфер, якщо NULL - в outlen | | |повертається розмір | |--------------------------+--------------------------------------| |int* outlen |Розмір вихідного буферу | -------------------------------------------------------------------
Функція повертає 0, коли успішно зашифровано, або код
помилки.
5. Функція розшифрування блоку даних int __stdcall Decrypt (const void* pkbuf, int pklen, const
char* pwd, const void* docbuf, int doclen, void* outbuf, int*
outlen);
------------------------------------------------------------------ | Параметр | Опис | |--------------------------+-------------------------------------| |const void* pkbuf |Буфер з секретним ключем | |--------------------------+-------------------------------------| |int pklen |Довжина буфера з секретним ключем | |--------------------------+-------------------------------------| |const char* pwd |Пароль секретного ключа, повинен | | |закінчуватись символом '\0' | |--------------------------+-------------------------------------| |const void* certbuf |Буфер з сертифікатом | |--------------------------+-------------------------------------| |int certlen |Розмір буфера з сертифікатом | |--------------------------+-------------------------------------| |const void* docbuf |Буфер з документом | |--------------------------+-------------------------------------| |int docsize |Розмір буферу з документом | |--------------------------+-------------------------------------| |void* outbuf |Вихідний буфер, якщо NULL - в outlen | | |повертається розмір | |--------------------------+-------------------------------------| |Int* outlen |Розмір вихідного буферу | ------------------------------------------------------------------
Функція повертає 0, коли успішно виконано, або код помилки.
6. Функція звірки сертифікату з секретним ключем int __stdcall VerifyCertPKMatch (const void* certbuf, int
certlen, const void* pkbuf, int pklen);
------------------------------------------------------------------ | Параметр | Опис | |--------------------------+-------------------------------------| |const void* certbuf |Буфер з сертифікатом | |--------------------------+-------------------------------------| |int certlen |Розмір буфера з сертифікатом | |--------------------------+-------------------------------------| |const void* pkbuf |Буфер з секретним ключем | |--------------------------+-------------------------------------| |int pklen |Розмір буфера з секретним ключем | |--------------------------+-------------------------------------| |const char* pwd |Пароль секретного ключа, повинен | | |закінчуватись символом '\0' | ------------------------------------------------------------------
Функція повертає 0, коли сертифікат та секретний ключ
являються відповідними, або код помилки.
7. Функція отримання інформації з сертифікату int __stdcall GetCertlnfo (const void* certbuf, int certlen,
UACertlnfo* info);
------------------------------------------------------------------ | Параметр | Опис | |--------------------------+-------------------------------------| |const void* certbuf |Буфер з сертифікатом | |--------------------------+-------------------------------------| |int certlen |Довжина буфера з сертифікатом | |--------------------------+-------------------------------------| |UACertlnfo* info |Структура з інформацією з сертифікату| | |(приведена нижче) | ------------------------------------------------------------------
Функція повертає 0, коли успішно виконано, або код помилки. Структура UACertlnfo
------------------------------------------------------------------ | Поле | Опис | |--------------------------+-------------------------------------| |char Serial[64] |Серійний номер сертифікату | |--------------------------+-------------------------------------| |char EDRPOU[11] |ЄДРПОУ установи | |--------------------------+-------------------------------------| |char DRFO[11] |ДРФО особи | |--------------------------+-------------------------------------| |char Name[64] |ПІБ особи або найменування установи | |--------------------------+-------------------------------------| |char Email [64] |E-mail | |--------------------------+-------------------------------------| |char Title[64] |Посада | |--------------------------+-------------------------------------| |char PostalCode[7] |Поштовий індекс | |--------------------------+-------------------------------------| |char Obl[64] |Область | |--------------------------+-------------------------------------| |char Rayon[64] |Район | |--------------------------+-------------------------------------| |char Adres[64] |Адреса | |--------------------------+-------------------------------------| |char Tel[64] |Телефон | |--------------------------+-------------------------------------| |time_t DtBeg |Дата початку дії сертифікату | |--------------------------+-------------------------------------| |time_t DtEnd |Дата закінчення дії сертифікату | ------------------------------------------------------------------
Вирівнювання членів структури - 1 байт. Розмір кожного строкового поля містить завершуючий 0-символ.
8. Коди помилок
------------------------------------------------------------------ |#define CRYPT_OK |0 |/|Успішно | |-----------------------------+--+--+----------------------------| |#define CRYPT_BUFFER EMPTY |1 |/|Буфер порожній | |-----------------------------+--+--+----------------------------| |#define CRYPT_DLL_NOT_LOADED |2 |/|DLL не ініціалізовано | |-----------------------------+--+--+----------------------------| |#define CRYPT_BAD_CERT |3 |/|Помилка отримання інформації| | | | |з сертифікату | |-----------------------------+--+--+----------------------------| |#define |4 |/|Даний сертифікат не може | |CRYPT_CERT_NOT_ALLOWED | | |використовуватися для | | | | |виконання операції | |-----------------------------+--+--+----------------------------| |#define CRYPT_SK_NOT_MATCH |5 |/|Не збігається пара | | | | |сертифікат - секретний ключ | |-----------------------------+--+--+----------------------------| |#define CRYPT_SK_CORRUPT |7 |/|Некоректний формат | | | | |секретного ключа | |-----------------------------+--+--+----------------------------| |#define CRYPT_BAD_PASSWORD |8 |/|Помилка підпису/шифрування, | | | | |можливо вказано невірний | | | | |пароль | |-----------------------------+--+--+----------------------------| |#define CRYPT_BAD_SIGN |11|/|Невірний підпис | |-----------------------------+--+--+----------------------------| |#define CRYPT_INTERNAL_ERR |12|/|Внутрішня помилка перевірки | | | | |підпису | |-----------------------------+--+--+----------------------------| |#tdefine CRYPT_BAD_CRC |13|/|Помилка перевірки | | | | |цілісності: буфер пошкоджено| |-----------------------------+--+--+----------------------------| |#define CRYPT_NOT_SUPPORTED |14|/|Функція не підтримується | ------------------------------------------------------------------
-
скопійовано
-
-
