Призначення
Система SWinED (Single Window of Electronic Documents) призначена для здійснення обміну розрахунками коригування кількісних і вартісних показників до податкових накладних в електронному вигляді між контрагентами (далі – Документи). Система транспортує Документи, завірені ЕЦП, в зашифрованому вигляді.
Для криптографічних перетворень використовуються сертифіковані засоби ЕЦП, що відповідають законодавству України. Такі засоби наразі використовуються для підписання і шифрування електронних документів, що подаються до ДФСУ.
Функції системи
- Транспортування електронного Документа від відправника до одержувача;
- Підтвердження доставки електронного Документу до одержувача.
Архітектура системи
До складу системи входять:
- Сервер обміну документами
WEB-сервіс працює під управлінням Microsoft Internet Information Services і здійснює обмін з клієнтами.
- Клієнти
Сервіс Windows, що здійснює обмін із сервером обміну документами.
Сервер обміну документами має свій сертифікат, яким шифруються Документи, що передаються.
Протокол обміну
Обмін здійснюється за протоколом SOAP.
Протокол SOAP забезпечує обмін інформацією з сервером незалежно від платформи клієнта.
Адреса сервера: http://109.237.89.107/SWinEd_Doc/SwinEd.asmx
Детальний опис протоколу наведений у прикладі та додатках.
Вимоги до засобів криптографічного захисту
Всі вузли, що входять до складу системи, посвідчують Документи, що передаються, електронним цифровим підписом. Тому на кожному вузлу має бути встановлений сертифікат і секретний ключ.
Задачі
Всі документи в системі розділяються по задачам. Задача характеризується кодом – натуральним числом або 0.
Поняття задачі використовується для групування документів за функціональним призначенням.
Для обміну розрахунками коригування кількісних і вартісних показників до податкових накладних використовується код задачі 0.
Підрозділи
Документи в системі адресуються комбінацією ЄДРПОУ/ДРФО і підрозділу. Таким чином, підтримується організації з відокремленими підрозділами. Кожен підрозділ приймає тільки адресовані йому Документи. Крім того, система підтримує обмін Документами між підрозділами.
Передача Документів
- Всі Документи, що передаються до Серверу обміну документами, мають бути підписаними ЕЦП відправника.
Ідентифікатори Документів не можуть дублюватись.
- Документи, що передаються до Серверу обміну документами, мають бути зашифровані на сертифікат Серверу обміну документами.
- Одержувачу Документи передаються зашифрованими на сертифікат одержувача.
- Одержувачу Документи передаються з ЕЦП відправника, що накладена під час надсилання.
- Формат транспортного повідомлення відповідає вимогам уніфікованого формату транспортного повідомлення при інформаційній взаємодії платників податків ДФС.
- Використовуються формати “UA1” (UA1_SIGN – підписаний блок, UA1_CRYPT – зашифрований блок).
Примітка: такі саме формати створюються в програмному забезпеченні для подання електронної звітності до ДФСУ та інших державних органів.
- Ідентифікатор Документа – це ім’я файлу Документа «Розрахунок коригування», згідно з форматом імені файлу, затвердженим наказом МДЗУ від 29.11.2013 № 729.
Порядок обміну
- Відправник отримує сертифікат Серверу обміну документами викликом GetCertificate.
- Відправник передає Документи до Серверу обміну документами викликом Post.
- Одержувач перевіряє наявність Документів на Сервері обміну документами викликом Check (або List).
- Одержувач отримує Документи викликом Receive (або Load).
- Одержувач підписує квитанції на доставку Документів.
- Одержувач позначає Документи як прийняті викликом Mark. У виклик Mark передаються підписані квитанції на доставку Документів.
Для використання в багатопоточних програмах використовуються виклики List (отримання списку ідентифікаторів вхідних Документів) і Load (завантаження Документів за списком).
Функції і структури обміну
Приклад обміну Документами
Розглянемо обмін електронними Документами на прикладі тестової клієнтської програми «Тест обміну документами»
Відправка
- Вибір файлу для відправки
В нашому прикладі подальші дії виконуються програмою автоматично, згідно налаштувань в файлі конфігурації.
- Вибір одержувача – одержувач ідентифікується за кодом ЄДРПОУ/ДРФО. В прикладі код ЄДРПОУ/ДРФО одержувача задається в файлі конфігурації.
- Підписання відправником – шлях до сертифікатів, ключів, а також паролі вказані у файлі конфігурації програми.
- У випадку відправки контрагенту розрахунку коригування кількісних і вартісних показників до податкових накладних з від’ємною сумою ПДВ для подальшої його реєстрації в єдиному реєстрі податкових накладних контрагентом – покупцем, Документ в обробку приймається вже підписаним. В цьому випадку клієнт накладає ЕЦП поверх існуючого підпису.
- Шифрування – Документ шифрується на сертифікат серверу обміну документами. Сертифікат попередньо отримується з сервера.
- Відправка – Документ відправляється на сервер обміну документами по прямому з’єднанню (по протоколу SOAP). Файл опису WEB-служби може бути завантажений з сервера обміну документами.
Застосовується метод Post (Передати документи).
Отримання
- Клієнт отримує список Документів сервера.
Застосовується метод List (Отримати список вхідних Документів).
- Виконується завантаження Документів за списком.
З кожним Документом завантажується технологічна квитанція. В подальшому квитанція підписується і повертається на сервер. Квитанція призначена для підтвердження одержання Документа.
Застосовується метод Load (Отримати вхідну кореспонденцію за списком Документів)
- Одержані Документи розшифровуються.
- Знімаються підписи Документів
- Документ зберігається в каталозі, вказаному користувачем в діалоговому вікні.
- Розшифровуються технологічні квитанції.
- Квитанції підписуються.
- Квитанції шифруються на сертифікат Серверу обміну документами.
- Виконується відправка на сервер технологічних квитанцій для підтвердження одержання Документів.
Застосовується метод Mark (Позначити Документи як оброблені).
Перевірка доставки
- Клієнт отримує підтвердження доставки Документу одержувачу.
Перевірка виконується по списку ідентифікаторів файлів.
Застосовується метод CheckAcquired (Отримати підтвердження отримання Документів одержувачем).
Примітки
- Для побудови прикладу використовується середовище Microsoft Visual Studio
- Перед запуском прикладу необхідно зареєструвати COM -сервер криптографічних перетворень. Для цього перейти в папку “Example\UniCrypt” і виконати в командному рядку команду
UniCryptC.exe / R
- Перед запуском прикладу необхідно у файлі «Example.exe.config» указати:
- шлях до клієнтських сертифікатів і ключів;
- адресу сервера Поштамту.
Додаток 1
Функції обміну
- Передати документи до Серверу обміну документами
ProcessResult Post( string senderEDRPOU, int senderDept,
DocumentType docsType, DocumentInData[] docs, out int errorDocIdx );
senderEDRPOU – код ЄДРПОУ відправника;
senderDept – код підрозділу відправника;
docsType – тип документів, що передаються;
docs – документи, що передаються;
errorDocIdx – індекс помилкового документа в масиві docs.
- Отримати документи з Серверу обміну документами
ProcessResult Receive( string recipientEDRPOU, int recipientDept,bool procAllDepts, string caName, byte[] cert, out bool restPreset, out DocumentOutData[] docs );
recipientEDRPOU – код ЄДРПОУ одержувача;
recipientDept – код підрозділу одержувача;
procAllDepts – ознака обробки всіх підрозділів;
caName – Ім’я АЦСК, крипто бібліотека якого використовується для підписання і зашифрування документів для передачі одержувачу;
cert – сертифікат одержувача для зашифрування;
restPresent– ознака присутності вхідних документів окрім переданих;
docs – документи, що приймаються.
- Отримати список вхідних документів з Серверу обміну документами
ProcessResult List( string recipientEDRPOU, int recipientDept,bool procAllDepts, out DocumentId[] list );
recipientEDRPOU – код ЄДРПОУ одержувача;
recipientDept – код підрозділу одержувача;
procAllDepts – ознака обробки всіх підрозділів;
list – перелік ідентифікаторів документів, що приймаються.
- Отримати документи з Серверу обміну документами за списком
ProcessResult Load( string recipientEDRPOU, DocumentId[] list,string caName, byte[] cert, out bool restPresent, out DocumentOutData[] docs );
recipientEDRPOU – код ЄДРПОУ одержувача;
list – перелік ідентифікаторів документів, що приймаються;
caName – Ім’я АЦСК, крипто бібліотека якого використовується для підписання і зашифрування документів для передачі одержувачу;
cert – сертифікат одержувача для зашифрування;
restPresent– ознака присутності вхідних документів окрім переданих;
docs – документи, що приймаються.
- Позначити документи на Сервері обміну документами як прийняті
ProcessResult Mark( ProcessedDocument[] docs, out int errorDocIdx );
docs – підписані квитанції про прийом документів;
errorDocIdx – індекс помилкового документа в масиві docs.
- Перевірити наявність вхідної кореспонденції
ProcessResult Check( string recipientEDRPOU, int recipientDept,bool procAllDepts, out int qtDocs );
recipientEDRPOU – код ЄДРПОУ одержувача;
recipientDept – код підрозділу одержувача;
procAllDepts – ознака обробки всіх підрозділів;
qtDocs – кількість вхідних документів.
- Отримати підтвердження отримання документів одержувачем
ProcessResult CheckAcquired( string senderEDRPOU,
DocumentIdAcq[] list, out bool[] acquired );
senderEDRPOU – код ЄДРПОУ відправника;
list – перелік ідентифікаторів документів, що перевіряються;
acquired – перелік результатів перевірки документів із list.
- Отримати сертифікат Серверу обміну документами
ProcessResult GetCertificate( string caName,out Certificate[] certs);
caName – Ім’я АЦСК (null – передаються сертифікати всіх підключених АЦСК);
certs – сертифікати.
Додаток 2
Структури обміну
public enum DocumentType { /// <summary> /// Оригінальний документ /// </summary> Original = 0, /// <summary> /// Документ-відповідь /// </summary> Response = 1 } /// <summary> /// Документ, що приймається /// </summary> [Serializable] public class DocumentInData { public string EDRPOU; public int dept; public string docId; public byte[] document; public string originalDocId; public int task; } /// <summary> /// Документ, що передається /// </summary> [Serializable] public class DocumentOutData { public DateTime deliver; public int docCd; public string docId; public DocumentType docType; public byte[] document; public DateTime income; public string originalDocId; public int recipientDept; public string recipientEDRPOU; public int senderDept; public string senderEDRPOU; public int task; public byte[] ticket; } /// <summary> /// Оброблений документ /// </summary> [Serializable] public class ProcessedDocument { public int docCd; public string docId; public DocumentType docType; public byte[] ticket; } /// <summary> /// Ідентифікатор документа /// </summary> [Serializable] public class DocumentId { public int docCd; public DocumentType docType; }
/// <summary>
/// Ідентифікатор документа для перевірки підтвердження отримання
/// </summary>
[Serializable]
public class DocumentIdAcq {
public string docId;
public DocumentType docType;
public string originalDocId;
}
/// <summary> /// АЦСК та сертифікат /// </summary> [Serializable] public class Certificate { public string caName; public byte[] cert; }
Додаток 3
Коди помилок
public enum ProcessResult { /// <summary> /// OK /// </summary> SWINED_OK = 0, /// <summary> /// Сервіс тимчасово недоступний /// </summary> SWINED_TEMPORARY_UNAVAILABLE = 1, /// <summary> /// Некоректний код ЄДРПОУ (перевищує максимальну довжину) /// </summary> SWINED_EDRPOU_INVALID = 2, /// <summary> /// Відсутні дані для обробки /// </summary> SWINED_EMPTY_DATA = 3, /// <summary> /// Помилка перевірки підпису /// </summary> SWINED_CRYPT_ERROR_UNSIGN = 4, /// <summary> /// Помилка розшифрування /// </summary> SWINED_CRYPT_ERROR_DECRYPT = 5, /// <summary> /// Внутрішня помилка обробки повідомлення /// </summary> SWINED_CRYPT_ERROR_INTERNAL = 6, /// <summary> /// Відсутні підписи документу /// </summary> SWINED_SIGN_ABSENT = 7, /// <summary> /// ЄДРПОУ із підпису не співпадає з переданим /// </summary> SWINED_SIGN_EDRPOU_MISCOMPARE = 8, /// <summary> /// Перевірка документу – Некоректний код ЄДРПОУ (перевищує максимальну довжину) /// </summary> SWINED_DOC_EDRPOU_INVALID = 9, /// <summary> /// Перевірка документу – Некоректний ідентифікатор документа /// </summary> SWINED_DOC_ID_INVALID = 10, /// <summary> /// Перевірка документу – Пустий зміст документу /// </summary> SWINED_DOC_EMPTY = 11, /// <summary> /// Документ з таким ідентифікатором вже зареєстровано /// </summary> SWINED_DOC_ALREADY_REGISTERED = 12, /// <summary> /// Некоректний ідентифікатор оригінального документа /// </summary> SWINED_ORIG_DOC_ID_INVALID = 13, /// <summary> /// Оригінальний документ не існує /// </summary> SWINED_ORIG_DOC_ABSENT = 14, /// <summary> /// Некоректний тип документа /// </summary> SWINED_DOC_TYPE_INVALID = 15, /// <summary> /// Перевірка документу – Документ занадто великий /// </summary> SWINED_DOC_TOO_BIG = 16, /// <summary> /// Некоректна послідовність підписів квитанції /// </summary> SWINED_TICKET_INVALID_SIGNS_SEQUENCE = 17, /// <summary> /// Некоректний зміст квитанції /// </summary> SWINED_TICKET_INVALID_CONTENT = 18, /// <summary> /// Документ, що квитується, не існує /// </summary> SWINED_TICKET_DOC_ABSENT = 19, /// <summary> /// Криптографічна бібліотека із зазначеним іменем не існує /// </summary> SWINED_CRYPTOLIB_ABSENT = 20, /// <summary> /// Некоректний сертифікат /// </summary> SWINED_CERTIFICATE_INVALID = 21, }
