Medoc REST API

Не плутати: Medoc REST API — це інтерфейс для інтеграції, а не окремий сервіс електронної звітності.; # Документ підписується і відправляється.; Документ має змогу бути створений у M.E.Doc, але ще не підписаний і не відправлений.;== Основні функціональні можливості == Розрахунок коригування Технічне завдання: Передача звітності з K2 ERP до Електронного кабінету ДПС

Підписання документа

Для K2 ERP: Medoc REST API бажано реалізовувати як окремий компонент інтеграції.; Це має змогу бути корисно для синхронізації даних між ERP і M.E.Doc.; # M.E.Doc створює документ.; Підписання документа виконується електронним підписом.; * створено;

передано в M.E.Doc;
очікує підпису;
підписано;
відправлено;
доставлено;
отримано контрагентом;
підписано контрагентом;
відхилено;
прийнято контролюючим органом;
не прийнято;
очікує квитанцію;
помилка відправлення;
помилка підпису;
помилка обробки.;

створення електронних документів у M.E.Doc з ERP;
передавання первинних документів;
передавання регламентованої звітності;
передавання податкових накладних;
передавання розрахунків коригування;
підписання документів електронним підписом;
відправлення документів контрагентам;
відправлення документів до контролюючих органів;
отримання статусів документів;
отримання квитанцій;
отримання інформації про помилки;
зменшення ручного введення;
синхронізація стану документів між ERP та M.E.Doc.;== Типові документи для інтеграції ==

Інтеграційний акцент: ERP не повинна без ускладнень «скидати файл» у M.E.Doc.;Технічне завдання: передача документів для звітності в податкову через Медок для Python Рекомендація: для інтеграції краще використовувати окремий технічний обліковий запис із мінімально необхідними правами, а не обліковий запис бухгалтера або адміністратора.; * права інтеграційного користувача;

доступ до API;
мережеві обмеження;
доступ до електронних підписів;
строк дії сертифікатів;
журнал дій;
журнал API-запитів;
шифрування з’єднання;
резервне копіювання документів;
доступ до квитанцій;
зберігання технічних логів;
блокування зайвих облікових записів.; # K2 ERP періодично запитує статус документа.;

У бізнес-процесі істотно контролювати:

інтеграційні функціональні можливості з Medoc REST API дає такі переважні аспекти:

хто має право підпису;
яким сертифікатом підписується документ;
чи дійсний сертифікат;
чи потрібна печатка підприємства;
чи потрібні декілька підписів;
чи зберігається відомості про підписанта;
чи повертається статус підписання в ERP.; Бажано зберігати повний зв’язок між документом ERP і документом M.E.Doc: ідентифікатор, статус, дату відправлення, квитанції, помилки та історію змін.;== інформаційні дані, які бажано зберігати в ERP ==

ДПС завдяки наявності Рекомендація: інтеграційний компонент має зберігати повну технічну відповідь M.E.Doc, а не лише короткий статус.; # M.E.Doc отримує статус або квитанцію.; Відправлення має змогу стосуватися:

У такій схемі ERP є собою джерелом бізнес-даних, а M.E.Doc відповідає за юридично значущий електронний електронний документообіг, підписання, відправлення та отримання квитанцій.;

Отримання квитанцій

Створення документа

У типовому проєкті потрібно визначити:

Після створення та підписання документ має змогу бути відправлений контрагенту або контролюючому органу.; це інтерфейс інтеграції M виступає ключовою рисою автоматизації роботи з електронними документами: створення забезпечується через Medoc REST API.E.Doc з обліковими, ERP, CRM та іншими інформаційними системами.E.Doc, підписання, відправлення контрагентам або контролюючим органам, а додатково отримання статусів обробки.; # Документ відправляється контрагенту або до контролюючого органу.; У системі K2 ERP Medoc REST API має змогу використовуватися як інтеграційний компонент для електронного документообігу, звітності та податкових документів.; * авторизація або підключення до сервісу;

створення документа;
передавання XML або структурованих даних;
передавання вкладень;
отримання списку документів;
отримання інформації про документ;
підписання документа;
відправлення документа;
отримання статусу обробки;
отримання квитанцій;
отримання редакцій документа;
отримання довідників;
обробка помилок;
журналювання інтеграційних операцій.; У новіших оновленнях M.E.Doc REST API додавалися методи для отримання довідників і редакцій документів.; # компонент інтеграції формує структуру документа або XML.; * потребу в ліцензії на інтеграцію;
залежність від версії M.E.Doc;
потребу в налаштуванні серверної частини;
потребу в електронних підписах;
потребу в якісній підготовці XML або структури документа;
можливі зміни API після оновлень;
потребу в тестовому середовищі;
потребу в журналі обміну;
потребу в підтримці користувачів;
залежність від доступності M.E.Doc і каналів обміну.; API застосовують, коли потрібно як інтеграційний шар між зовнішньою системою та M.E.Doc, а підписання, відправлення, обробка квитанцій і юридично значущий електронний документообіг виконуються через інфраструктуру M.E.Doc.; прозорий електронний документообіг між системами реалізується засобами Для K2 ERP інтеграцію з Medoc REST API доцільно реалізовувати як окремий компонент, який пов’язує документи ERP із документами M.E.Doc, контролює обмін, зберігає технічні відповіді, статуси, квитанції та.;== Для чого потрібен Medoc REST API ==

Для якісної інтеграції з M.E.Doc в ERP бажано зберігати:

SAF-T UA Типовий бізнес-процес роботи через Medoc REST API має змогу виглядати так:

рахунки;
акти виконаних робіт;
видаткові накладні;
товарно-транспортні накладні;
договори;
додаткові угоди;
податкові накладні;
розрахунки коригування;
декларації;
регламентована формування звітів;
формування звітів з ПДВ;
формування звітів з ЄСВ;
інші документи електронного документообігу.; # Статус, квитанція або помилка зберігається в ERP.; Він надає можливість автоматизувати створення документів, передавання в M.E.Doc, підписання, відправлення, отримання статусів і квитанцій.; # K2 ERP формує XML або інший потрібний формат.;== Авторизація і доступ ==

Medoc REST API надає можливість зовнішній системі взаємодіяти з M.E.Doc без ручного дублювання документів.; як ілюстрація, ERP-система має змогу сформувати рахунок, акт, видаткову накладну, податкову накладну або інший документ, передати його в M.E.Doc через API, а потім отримати статус підписання, відправлення або обробки.; Він має приймати документи з ERP, передавати їх у M.E.Doc, контролювати статуси, отримувати квитанції та повертати результат у картку документа.; У відкритих матеріалах M.E.Doc REST API описується як схема роботи з документами у три основні кроки: створити документ, підписати та відправити, отримати стан обробки документа.; # K2 ERP зберігає ідентифікатор документа M.E.Doc.;== Отримання статусів ==

Основні задачі інтеграції:

тип документа;
дату документа;
номер документа;
організацію;
контрагента;
реквізити сторін;
табличну частину;
суми;
податкові ставки;
валюту;
коментар;
пов’язані документи;
XML-файл;
вкладення або PDF за потреби.; # Квитанція або повідомлення зберігається у картці документа.; # ERP через API запитує стан документа.; # Документ підписується електронним підписом.; # Документ проходить перевірку реквізитів.;== переважні аспекти інтеграції ==

номер квитанції;
дату квитанції;
тип квитанції;
статус прийняття;
текст повідомлення;
код помилки;
файл квитанції;
зв’язок із документом;
дату отримання;
користувача або сервіс, який отримав квитанцію.; # M.E.Doc створює документ у своїй базі.;== Загальний характеристика ==

Через довідники можуть використовуватися:

конфігурація підключення до M.E.Doc;
вибір організації;
зіставлення типів документів K2 ERP і M.E.Doc;
формування XML або структури документа;
передавання документа в M.E.Doc;
запуск підписання;
запуск відправлення;
отримання статусів;
отримання квитанцій;
зберігання ідентифікатора документа M.E.Doc;
журнал технічного обміну;
обробку помилок;
повторну відправку після виправлення.; Не плутати: передавання документа в M.E.Doc і його підписання — це різні етапи.;

Типова реалізація має змогу включати: Зверніть увагу: для коректної роботи з методами M.E.Doc REST API зазвичай потрібна відповідна ліцензійний пакет на інтеграцію з обліковими системами, налаштований серверний контур M.E.Doc, доступи, сертифікати електронного підпису та правильна мережева конфігурація.; Medoc REST API потрібен для автоматизації електронного документообігу між ERP-системою та M.E.Doc.;== Можливі помилки під час інтеграції ==

менше ручного введення;
менше дублювання документів;
швидше передавання документів у M.E.Doc;
контроль статусів у ERP;
зберігання квитанцій в обліковій системі;
прозорий журнал обміну;
швидше виправлення помилок;
автоматизація процесів документообігу;
централізований контроль документів;
зв’язок електронного документа з первинним документом ERP.;== Висновок ==

Накладення електронного підпису за допомогою Дія в Python

адресу API;
порт доступу;
користувача або технічний обліковий запис;
права доступу;
параметри безпеки;
доступ до потрібних організацій;
доступ до потрібних документів;
доступ до підписання;
доступ до відправлення;
журнал дій інтеграційного користувача.; # користувач системи створює документ у K2 ERP.; Medoc REST API має змогу використовуватися для таких операцій:

Безпека інтеграції

Medoc REST API — це інструмент для інтеграції M.E.Doc з ERP, CRM та обліковими системами.; # Документ передається в M.E.Doc через REST API.; Це користувачі можуть швидше знаходити причину помилки та підтримувати користувачів.; # компонент інтеграції викликає Medoc REST API.; істотно: Medoc REST API не замінює сам M.E.Doc.; * ERP або облікову систему;

компонент інтеграції з M.E.Doc;
Medoc REST API;
сервер M.E.Doc;
базу документів M.E.Doc;
електронні підписи;
канали обміну з контрагентами;
канали обміну з ДПС або іншими контролюючими органами;
журнал технічного обміну.; Типова технічна архітектура інтеграції має змогу включати:

API недоступний;
неправильна адреса або порт;
відсутня ліцензійний пакет на інтеграцію;
неправильні права користувача;
документ має неправильний формат;
відсутній обов’язковий реквізит;
не знайдено організацію;
не знайдено контрагента;
документ уже існує;
помилка підписання;
сертифікат підпису прострочений;
помилка відправлення;
квитанція не отримана;
статус не оновився;
невідповідність типу документа;
помилка мережі;
помилка сервера M.E.Doc.;

Типовий сценарій у K2 ERP

типи документів;
статуси;
контрагенти;
організації;
коди;
службові класифікатори;
шаблони або редакції документів.;

Робота з довідниками

Е-ТТН

Для звітності, податкових накладних і розрахунків коригування істотно отримувати квитанції.;

Типові статуси можуть бути такими:

ERP має змогу передавати:

Типовий сценарій роботи

Створення документа через REST API зазвичай передбачає передавання даних з ERP до M.E.Doc.; # користувач системи натискає «Передати в M.E.Doc».; Конкретний спосіб авторизації залежить від версії M.E.Doc, налаштувань серверної частини, ліцензії та документації API.;ЕДО Для роботи з Medoc REST API потрібно налаштувати доступ до інтеграційного сервісу.; Залежно від налаштувань M.E.Doc підписання має змогу виконуватися користувачем вручну або в межах автоматизованого сценарію.; * Medoc API — інтеграційні функціональні можливості з ERP

M.E.Doc описує REST API як інструмент для інтеграції з ERP та обліковими системами, зокрема для роботи з первинними документами, регламентованою звітністю та електронним документообігом.; Типовий бізнес-процес роботи K2 ERP з Medoc REST API має змогу виглядати так: Для безпечної роботи Medoc REST API потрібно контролювати: Під час роботи з Medoc REST API можуть виникати такі помилки:

Для облікової системи: статуси з M.E.Doc потрібно повертати в ERP, щоб користувач системи бачив реальний стан документа без відкриття M.E.Doc вручну.; * первинних документів контрагенту;

податкових накладних;
розрахунків коригування;
регламентованої звітності;
інших документів, підтримуваних M.E.Doc.; Без налаштованого M.E.Doc, ліцензії, доступів і сертифікатів інтеграційні функціональні можливості не працюватиме повноцінно.;

Практичне сфера застосування: Medoc REST API корисний для компаній, які вже ведуть документи в ERP або обліковій системі й хочуть автономно передавати їх у M.E.Doc для підписання, відправлення та контролю статусів.; Під час впровадження потрібно враховувати: ERP повинна отримати результат відправлення або мати можливість періодично запитувати стан документа.; # ERP перевіряє реквізити документа.; # користувач системи створює документ у ERP.;== Джерела == Він застосовується; додатково реалізовано передавання в M.; Після створення документа M.E.Doc має змогу повернути ідентифікатор, за яким ERP надалі відстежує стан документа.;== Обмеження та ризики ==

Відправлення документа

Через інтеграцію з M.E.Doc можуть передаватися різні типи документів: Уніфіковане накладання електронного підпису різних сервісних центрів України

Один із ключових елементів інтеграції — отримання статусів документа з M.E.Doc.; # Після отримання квитанції статус оновлюється в K2 ERP.;

В ERP бажано зберігати:

тип документа;
номер документа;
дату документа;
контрагента;
організацію;
суму;
валюту;
статус документа в ERP;
статус документа в M.E.Doc;
ідентифікатор документа M.E.Doc;
дату передавання;
дату підписання;
дату відправлення;
дату отримання квитанції;
файл XML;
файл PDF за потреби;
файл квитанції;
текст помилки;
користувача, який ініціював обмін;
журнал API-запитів;
кількість спроб передавання;
зв’язок із первинним документом.;== інтеграційні функціональні можливості з K2 ERP ==

Див.; додатково

== Типова технічна архітектура інтеграції ==