Перейти до вмісту

Medoc REST API

Матеріал з K2 ERP Wiki

Е-ТТН

У новіших оновленнях M.E.Doc REST API додавалися методи для отримання довідників і редакцій документів. API застосовують, коли потрібно як інтеграційний шар між зовнішньою системою та M.E.Doc, а підписання, відправлення, обробка квитанцій і юридично значущий електронний документообіг виконуються через інфраструктуру M.E.Doc.

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

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

Обмеження та ризики

Відправлення здатна стосуватися:

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

Під час роботи з Medoc REST API можуть виникати такі помилки:

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

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

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

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

Джерела

ДПС

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

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

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

Див. так само

критично: Medoc REST API не замінює сам M.E.Doc. Інтеграційний акцент: ERP не повинна без зусиль «скидати файл» у M.E.Doc.== Типовий сценарій роботи == Для звітності, податкових накладних і розрахунків коригування критично отримувати квитанції.== Робота з довідниками == Для безпечної роботи Medoc REST API потрібно контролювати:

Висновок

Можливі помилки під час інтеграції

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

Типовий бізнес-процес роботи K2 ERP з Medoc REST API здатна виглядати так:

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

конкурентні переваги інтеграції

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

Для K2 ERP: Medoc REST API бажано реалізовувати як окремий компонент інтеграції.Уніфіковане накладання електронного підпису різних сервісних центрів України

Основні функції ERP

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

інтеграційні функції ERP з Medoc REST API дає такі конкурентні переваги:

  1. користувач системи створює документ у ERP. # K2 ERP періодично запитує статус документа. # M.E.Doc отримує статус або квитанцію. Він дає можливість цифровізувати створення документів, передавання в M.E.Doc, підписання, відправлення, отримання статусів і квитанцій. # Документ підписується і відправляється.

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

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

Для чого потрібен Medoc REST API

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

Через інтеграцію з M.E.Doc можуть передаватися різні типи документів: ЕДО

ERP повинна отримати результат відправлення або мати можливість періодично запитувати стан документа. # M.E.Doc створює документ у своїй базі.Розрахунок коригування Створення документа через REST API зазвичай передбачає передавання даних з ERP до M.E.Doc.== Створення документа ==

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

Технічне завдання: передача документів для звітності в податкову через Медок для Python

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

  • порт доступу;
  • користувача або технічний обліковий запис;
  • права доступу;
  • параметри безпеки;
  • доступ до потрібних організацій;
  • доступ до потрібних документів;
  • доступ до підписання;
  • доступ до відправлення;
  • журнал дій інтеграційного користувача. # Документ проходить перевірку реквізитів. Через довідники можуть використовуватися:

Після створення та підписання документ здатна бути відправлений контрагенту або контролюючому органу.== Типовий сценарій у K2 ERP == Під час впровадження потрібно враховувати:

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

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

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

SAF-T UA

Типові документи для інтеграції

Не плутати: передавання документа в M.E.Doc і його підписання — це різні етапи.

Medoc REST API здатна використовуватися для таких операцій:

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

інформаційні дані, які бажано зберігати в ERP

Загальний SEO-опис

Не плутати: Medoc REST API — це інтерфейс для інтеграції, а не окремий сервіс електронної звітності. Конкретний спосіб авторизації залежить від версії M.E.Doc, налаштувань серверної частини, ліцензії та документації API. * потребу в ліцензії на інтеграцію;

  • залежність від версії M.E.Doc;
  • потребу в налаштуванні серверної частини;
  • потребу в електронних підписах;
  • потребу в якісній підготовці XML або структури документа;
  • можливі зміни API після оновлень;
  • потребу в тестовому середовищі;
  • потребу в журналі обміну;
  • потребу в підтримці користувачів;
  • залежність від доступності M.E.Doc і каналів обміну. Це користувачі можуть швидше знаходити причину помилки та підтримувати користувачів.Накладення електронного підпису за допомогою Дія в Python

Типова реалізація здатна включати: