• Посилання скопійовано
Документ підготовлено в системі iplex

Про затвердження Уніфікованого формату транспортного повідомлення при інформаційній взаємодії платників податків, операторів і податкових органів в електронному вигляді телекомунікаційними каналами звязку з використанням електронного цифрового підпису

Державна податкова адміністрація України  | Наказ від 24.04.2009 № 213
Реквізити
  • Видавник: Державна податкова адміністрація України
  • Тип: Наказ
  • Дата: 24.04.2009
  • Номер: 213
  • Статус: Документ діє
  • Посилання скопійовано
Реквізити
  • Видавник: Державна податкова адміністрація України
  • Тип: Наказ
  • Дата: 24.04.2009
  • Номер: 213
  • Статус: Документ діє
Документ підготовлено в системі iplex
ДЕРЖАВНА ПОДАТКОВА АДМІНІСТРАЦІЯ УКРАЇНИ
Н А К А З
24.04.2009 N 213
Про затвердження Уніфікованого формату транспортного повідомлення при інформаційній взаємодії платників податків, операторів і податкових органів в електронному вигляді телекомунікаційними каналами зв'язку з використанням електронного цифрового підпису
На виконання розпорядження Кабінету Міністрів України від 06.02.2008 N 262-р "Про заходи щодо удосконалення системи адміністрування податку на додану вартість" та з метою подальшої уніфікації інформаційної взаємодії між платниками податків, операторами і податковими органами телекомунікаційними каналами зв'язку з використанням електронного цифрового підпису (далі - ЕЦП)
НАКАЗУЮ:
1. Затвердити Уніфікований формат транспортного повідомлення при інформаційній взаємодії платників податків, операторів і податкових органів в електронному вигляді телекомунікаційними каналами зв'язку з використанням електронного цифрового підпису (далі - Уніфікований формат транспортного повідомлення), що додається.
2. Наказ ДПА України від 22.07.2008 N 485 "Про затвердження Уніфікованого формату транспортного повідомлення при інформаційній взаємодії платників податків і податкових органів в електронному вигляді телекомунікаційними каналами зв'язку з використанням електронного цифрового підпису" вважати таким, що втратив чинність.
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.
4.2. Уніфіковане транспортне повідомлення для передачі документів до податкового органу за допомогою Оператора електронної звітності
Схему уніфікованого транспортного повідомлення представлено на рис. 2.
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<CR/LF>послідовність вигляду
<Тег>=<Значення>
Рядок 2<CR/LF>
...
Рядок n<CR/LF>
Теги, використовувані в транспортному заголовку документа:
НайменуванняЗначенняОбов'язковість
заповнення
FILENAMEІм'я файла у верхньому регістрі, що
відправляє (у кодуванні Win1251) та
закінчується символом CHR(13) +
CHR(10)
Так
SND_NAMEНайменування/ПІБ платника податків,
що подає звіт (у кодуванні Win1251)
та закінчується символом
CHR(13) + CHR(10)
Ні
SND_EMAILE-Mail відправника (у кодуванні
Win1251) та закінчується символом
CHR(13) + CHR(10)
Ні
RCV_NAMEНайменування одержувача (у кодуванні
Win1251) та закінчується символом
CHR(13) + CHR(10)
Ні
RCV_EMAILE-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<CR/LF>послідовність вигляду
<Тег>=<Значення>
Рядок 2<CR/LF>
...
Рядок n<CR/LF>
Теги, використовувані в транспортному заголовку ОЕЗ:
НайменуванняЗначенняОбов'язковість
заповнення
DOC_TYPEТип повідомлення: 1-Документ,
2-Квитанція, 3-Відповідь на
документ, 4-Карточка користувача,
10-результат виконання операції
передачі повідомлення, 100-запит
списку ID вхідної кореспонденції,
101-Запрос вхідного документа по ID
Так
REQ_DCTPТип запрошуваного повідомлення
(заповнюється для DOC TYPE=101),
див. "DOC TYPE="
Ні
FILENAMEІм'я файла, що міститься в
повідомленні (ID повідомлення)
Так
ANSWERIDID відповіді на документ (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=1
FILENAME=<Ім'я файла, що міститься в повідомленні
(ID повідомлення)>
EDRPOU=<ЄДРПОУ відправника>
DEPT=<Код філії відправника> (необов'язковий)
RCV_EDRPOU=<ЄДРПОУ одержувача>
RCV_DEPT=<Код філії одержувача> (необов'язковий)
SUBJECT=<Рядок опису документа>.
3. Блок даних, зашифрований на одержувача, містить контейнер документа.
Формат повідомлення "Квитанція"
Повідомлення передається від ОЕЗ платнику податків. Платник податків повинен підписати квитанцію і відправити її ОЕЗ для підтвердження доставки документа.
Структура:
1. Підпис ОЕЗ.
2. Транспортний заголовок ОЕЗ. У заголовку:
DOC_TYPE=2
FILENAME=<Ім'я файла, що міститься в повідомленні
(ID повідомлення)>
ANSWERID=<ID відповіді на документ (GUID)> (лише для
відповіді на документ)
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=2
FILENAME=< Ім'я файла, що міститься в повідомленні
(ID повідомлення)>
ANSWERID=<ID відповіді на документ (GUID)> (лише для
відповіді на документ)
EDRPOU=<ЄДРПОУ відправника>
DEPT=<Код філії відправника> (необов'язковий)
RCV_EDRPOU=<ЄДРПОУ одержувача>
RCV_DEPT=<Код філії одержувача> (необов'язковий)
SUBJECT=<Рядок опису документа>
3. Блок повідомлення "Квитанція", раніше відправлений одержувачу і "перешифрований" одержувачем на ОЕЗ:
3.1. Підпис відправника.
3.2. Позначка часу ОЕЗ.
3.3. Підпис ОЕЗ.
3.4. Текст квитанції.
Квитанція для повідомлень типу "Картка користувача" не містить поля транспортного заголовка "RCV_EDRPOU=" і "RCV_DEPT=".
Формат повідомлення "Відповідь на документ"
Повідомлення передається від ОЕЗ платнику податків. Повідомлення є відповіддю податкового органу на переданий документ. Наприклад, квитанція про призначення реєстраційного номера.
Структура:
1. Підпис ОЕЗ.
2. Транспортний заголовок ОЕЗ. У заголовку:
DOC_TYPE=3
FILENAME=< Ім'я файла, що міститься в повідомленні
(ID повідомлення)>
ANSWERID=<ID відповіді на документ (GUID)> (лише для
відповіді на документ)
EDRPOU=<ЄДРПОУ відправника>
DEPT=<Код філії відправника> (необов'язковий)
RCV_EDRPOU=<ЄДРПОУ одержувача>
RCV_DEPT=<Код філії одержувача> (необов'язковий)
SUBJECT=<Рядок опису документа>
ANSW_STT=<Рядок стану відповіді на документ:
0-оброблюється/1-завершено>.
3. Підписи оригінальної відповіді на документ.
4. Позначка часу ОЕЗ (яку накладено на незашифрований блок даних).
5. Блок, зашифрований на платника податків, містить контейнер документа.
Формат повідомлення "Картка користувача" (Реєстрація клієнта в системі)
Повідомлення відправляється платником податків на ОЕЗ для реєстрації користувача ОЕЗ. Обмін повідомленнями може виконуватися тільки між зареєстрованими на ОЕЗ користувачами.
Структура:
1. Підпис відправника.
2. Транспортний заголовок ОЕЗ. У заголовку:
DOC_TYPE=4
FILENAME=<Ім'я файла, що міститься в повідомленні
(ID повідомлення)> (GUID)
EDRPOU=<ЄДРПОУ відправника>
DEPT= <Код філії відправника> (необов'язковий).
3. Блок, зашифрований ключем ОЕЗ:
3.1. Блок даних картки.
3.2. Підписи клієнта (один або декілька), у т. ч. підпис підприємства (для юр. особи) або директора (для фіз. особи).
3.3. Блок XML з реквізитами користувача.
Структура і використовувані реквізити блоку XML:
<DECLAR xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="Z0100501.XSD">
...
<DECLARBODY>
<FIRM_EDRPOU>ЄДРПОУ/ІНН*</FIRM_EDRPOU>
<FIRM_DEPT>Філія</FIRM_DEPT>
<FIRM_NAME> Найменування організації*</FIRM_NAME>
<FIRM_OBLNUM> Код регіону*</FIRM_OBLNUM>
<FIRM_EMAILORG>E-mail контактний</FIRM_EMAILORG>
<FIRM_EMAILRCV>E-mail для
обміну повідомленнями</FIRM_EMAILRCV>
<FIRM_ALLEMAIL>1-Обмін повідомленнями завжди ведеться по
E-mail</FIRM_ALLEMAIL>
<FIRM_USESPECMAIL>1-Використовувати адресу E-mail на сервері
Оператора/0-Не использовать</FIRM_USESPECMAIL>
<FIRM_EMPPASS>Пароль адреси E-mail на сервері Оператора (якщо
не заповнено, пароль призначує Оператор)</firm_emppass>
<FIRM_ADR>Юридична адреса*</FIRM_ADR>
<FIRM_ADR_FIZ>Фактична адреса</FIRM_ADR_FIZ>
<FIRM_PHON> Контактний телефон*</FIRM_PHON>
<FIRM_MOBILE>Контактний мобільний телефон</FIRM_MOBILE>
<FIRM CONTPERS>Контактна особа</FIRM_CONTPERS>
...
</DECLARBODY>
...
</DECLAR>
---------------
* Обов'язковий реквізит.
Якщо не визначено реквізит "Фактична адреса", то як фактична адреса використовується реквізит "Юридична адреса".
Формат повідомлення "Команда"
Повідомлення відправляється платником податків на ОЕЗ для одержання інформації.
Структура:
1. Підпис відправника
2. Транспортний заголовок ОЕЗ. У заголовку:
DOC_TYPE=100 або 101
EDRPOU=<ЄДРПОУ відправника>
DEPT=<Код філії відправника> (необов'язковий)
REQ_DCTP=<Тип запрошуваного повідомлення> (для DOC_TYPE=101)
FILENAME= <Ім'я файла, що міститься в повідомленні
(ID повідомлення)> (для DOC_TYPE=101, або якщо повідомлення
передається по Email)
ANSWERID=<ID відповіді на документ (GUID)> (лише для
відповіді на документ).
Формат повідомлення "Результат виконання команди 100-запиту списку ID вхідної кореспонденції"
Повідомлення відправляється ОЕЗ платнику податків і містить запитуване повідомлення.
Структура:
1. Підпис ОЕЗ.
2. Транспортний заголовок ОЕЗ. У заголовку:
DOC_TYPE=100
EDRPOU=<ЄДРПОУ відправника>
DEPT=<Код філії відправника> (необов'язковий)
RESULT=<Код результату виконання операції>
RESADD=<Рядок з додатковою інформацією результату виконання
операції>.
3. Блок, зашифрований на одержувача:
Текстовий блок із списком рядків:
DOC_TYPE=<1 - Документ, 2 - Квитанція, 3 - Відповідь на
документ, 10 - Результат виконання операції передачі повідомлення>
FILENAME=,ANSWERID=>CR><LF>
ОЕЗ може відправляти повідомлення самостійно без запиту з боку платника податків, коли повідомлення має бути доставлене платнику податків.
Формат повідомлення "Результат виконання команди 101-запиту вхідного документа по ID"
Повідомлення відправляється ОЕЗ платнику податків і містить результат виконання команди 101.
Структура:
1. Підпис ОЕЗ.
2. Транспортний заголовок ОЕЗ. У заголовку:
DOC_TYPE=101
EDRPOU=<ЄДРПОУ відправника>
DEPT=<Код філії відправника> (необов'язковий)
RCV_EDRPOU=<ЄДРПОУ одержувача>
RCV_DEPT=<Код філії одержувача> (необов'язковий)
REQ_DCTP=<Тип запрошуваного повідомлення>
FILENAME=<Ім'я файла, що міститься в повідомленні
(ID повідомлення)>
ANSWERID=<ID відповіді на документ (GUID)> (лише для
відповіді на документ)
RESULT=<Код результату виконання операції>
RESADD=<Рядок з додатковою інформацією результату виконання
операції>.
3. Блок, зашифрований на одержувача, містить повідомлення "Документ" або "Квитанція" або "Результат виконання операції передачі повідомлення".
ОЕЗ може відправляти повідомлення самостійно без запиту з боку платника податків, коли повідомлення має бути доставлене платнику податків.
Формат повідомлення "Результат виконання операції передачі повідомлення"
Повідомлення відправляється ОЕЗ платнику податків і містить результат виконання команди операції передачі повідомлення.
Структура:
Транспортний заголовок ОЕЗ. У заголовку:
Реквізити, визначені для операції (тобто "клон" заголовка передаваного повідомлення)
RESULT=<Код результату виконання операції>
RESADD=<Рядок з додатковою інформацією результату виконання операції>.
Додаток 1
до Уніфікованого формату
транспортного повідомлення
при інформаційній взаємодії
платників податків,
операторів і податкових
органів в електронному
вигляді телекомунікаційними
каналами зв'язку
з використанням електронного
цифрового підпису
ПРИКЛАД
транспортного повідомлення, що містить документ податкової звітності ( vb213225-09 )
Додаток 2
до Уніфікованого формату
транспортного повідомлення
при інформаційній взаємодії
платників податків,
операторів і податкових
органів в електронному
вигляді телекомунікаційними
каналами зв'язку
з використанням електронного
цифрового підпису
ПРИКЛАД
файла документа податкової звітності
Ім'я файла:
26580000000126J020010610000134052008.XML
Зміст файла:
<?xml version="1.0" encoding="windows-1251"?>
<DECLAR xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="J0200106.XSD">
<DECLARHEAD>
<TIN>00000126</TTN>
<C_DOC>J02</C_DOC>
<C_DOC_SUB>001</C_DOC_SUB>
<C_DOC_VER>6</C_DOC_VER>
<C_DOC_TYPE>0</C_DOC_TYPE>
<C_DOC_CNT>134</C_DOC_CNT>
<C_REG>26</C_REG>
<C_RAJ>58</C_RAJ>
<PERIOD_MONTH>5</PERIOD_MONTH>
<PERIOD_TYPE>1</PERIOD_TYPE>
<PERIOD_YEAR>2008</PERIOD_YEAR>
<C_DOC_STAN>1</C_DOC_STAN>
<D_FILL>03042008</D_FILL>
<SOFTWARE/>
</DECLARHEAD>
<DECLARBODY>
<HZ>1</HZ>
<HZY>2008</HZY>
<HZM>05</HZM>
<HZYP xsi:nil="true"></HZYP>
<HTINJ>00000126</HTINJ>
<HDDGVSD xsi:nil="true"></HDDGVSD>
<HNDGVSD xsi:nil="true"></HINDGVSD>
<HNPDV>236476834278</HNPDV>
<HNSPDV>3266664-ГГ</HNSPDV>
<HLOC>12345, м. КИЇВ, Перемоги, б. 32</HLOC>
<HZIP>12345</HZIP>
<HTEL>678876</HTEL>
<HFAX xsi:nil="true"></HFAX>
<HEMAIL>deklarenko@podatok.kiev.ua<HEMAIL>
<HSTI>ДП_ У СОЛОМ&apos;ЯНСЬКОМУ Р-Н_ М. КИЄВА</HSTl>
<R10GA>150</R10GA>
<R10GB>30</R10GB>
<R21GA xsi:nil="true"></R21GA>
<R22GA xsi:nil="true"></R22GA>
<R30GA xsi:nil="true"></R30GA>
<R40GA xsi:nil="true"></R40GA>
<R50GA>150</R5OGA>
<R52GA>150</R52GA>
<R52GB xsi:nil="true"></R52GB>
<R60GA xsi:nil="true"></R60GA>
<R60GB>0</R60GB>
<R60GAD xsi:nil="true"></R60GAD>
<R70GA xsi:nil="true"></R70GA>
<R7OGB>0</R70GB>
<R82GB>0</R82GB>
<R83GA xsi:nil="true"></R83GA>
<R83GB>0</R83GB>
<R90GB>30</R90GB>
<R101GB>0</R101GB>
<R102GA xsi:nil="true"></R102GA>
<R110GA>0</R110GA>
<R121GB>0</R121GB>