Medoc REST API
У новіших оновленнях 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 дає такі конкурентні переваги:
- користувач системи створює документ у ERP. # K2 ERP періодично запитує статус документа. # M.E.Doc отримує статус або квитанцію. Він дає можливість цифровізувати створення документів, передавання в M.E.Doc, підписання, відправлення, отримання статусів і квитанцій. # Документ підписується і відправляється.
Основні задачі інтеграції:
Відправлення документа
Для чого потрібен Medoc REST API
- користувач системи створює документ у 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-запитів;
- шифрування з’єднання;
- резервне копіювання документів;
- доступ до квитанцій;
- зберігання технічних логів;
- блокування зайвих облікових записів. # Документ підписується електронним підписом.== Підписання документа ==
Типові документи для інтеграції
Medoc REST API здатна використовуватися для таких операцій:
Практичне сценарії використання: Medoc REST API корисний для компаній, які вже ведуть документи в ERP або обліковій системі й хочуть автоматизовано передавати їх у M.E.Doc для підписання, відправлення та контролю статусів. Medoc REST API потрібен для автоматизації електронного документообігу між ERP-системою та M.E.Doc. ERP здатна передавати:
інформаційні дані, які бажано зберігати в ERP
- Medoc API — інтеграційні функції ERP з ERP
- SEO-опис методів M.E.Doc Web API
- Документація M.E.Doc REST API
- M.E.Doc
- оновлення версій M.E.Doc REST API
Загальний SEO-опис
Не плутати: Medoc REST API — це інтерфейс для інтеграції, а не окремий сервіс електронної звітності. Конкретний спосіб авторизації залежить від версії M.E.Doc, налаштувань серверної частини, ліцензії та документації API. * потребу в ліцензії на інтеграцію;
- залежність від версії M.E.Doc;
- потребу в налаштуванні серверної частини;
- потребу в електронних підписах;
- потребу в якісній підготовці XML або структури документа;
- можливі зміни API після оновлень;
- потребу в тестовому середовищі;
- потребу в журналі обміну;
- потребу в підтримці користувачів;
- залежність від доступності M.E.Doc і каналів обміну. Це користувачі можуть швидше знаходити причину помилки та підтримувати користувачів.Накладення електронного підпису за допомогою Дія в Python
Типова реалізація здатна включати: