Три різні речі, які плутають
Коли компанія каже «нам треба інтеграція з електронним документообігом», за цим стоять три різні задачі. Плутанина між ними — головна причина, чому проєкти в цій темі виходять дорожчими за очікування.
| Задача | Про що вона | Хто вирішує |
|---|---|---|
| Податкові накладні | Реєстрація ПН і РК в ЄРПН, розрахунок ліміту | Бухгалтерське ПЗ або спеціалізований сервіс |
| Первинка з контрагентами | Обмін актами, видатковими, договорами з підписом | Сервіс ЕДО |
| Внутрішній документообіг | Погодження заявок і договорів усередині компанії | Сама облікова система або окремий продукт |
Це три окремі контури. Business Central закриває третій власними засобами — узгодження документів, ліміти й маршрути погодження вбудовані. Перші два потребують зв’язки із зовнішніми сервісами, і саме тут виникають реальні рішення.
Чим саме обмінюються компанії
Перш ніж говорити про технічну частину, варто перерахувати, що фактично ходить між вами й контрагентами:
- Видаткова накладна й акт виконаних робіт — найбільший обсяг, саме заради них зазвичай і впроваджують ЕДО.
- Рахунок на оплату — часто ходить простою поштою, підпис не обов’язковий.
- Договір і додаткові угоди — рідше за обсягом, але критичні за наслідками.
- ТТН — для тих, хто возить товар власним транспортом або залучає перевізника.
- Акт звірки — регулярний, добре автоматизується.
Податкові накладні в цьому списку стоять окремо: вони йдуть не контрагенту, а в реєстр, і працюють за іншими правилами. Про них — у матеріалі про ПДВ і податкові накладні.
Як це зв’язується з обліковою системою
Механіка однакова незалежно від того, який сервіс ЕДО ви використовуєте, і зводиться до чотирьох кроків.
- Документ створюється в обліку. Видаткова формується з відвантаження, а не набирається руками в іншій програмі — інакше сенсу в інтеграції немає.
- Передається в сервіс ЕДО у погодженому форматі, підписується й вирушає контрагенту.
- Статус повертається в облік. Доставлено, підписано, відхилено. Це найважливіша частина: без зворотного статусу ви маєте два джерела правди й щоденну звірку.
- Вхідні документи приходять із сервісу й зіставляються з вашими замовленнями постачальникам.
Ключове рішення — саме третій крок. Багато компаній роблять інтеграцію в один бік: вивантажили документ і забули. Через місяць ніхто не знає, які накладні контрагенти підписали, а які висять. Двосторонній обмін статусами коштує дорожче, але саме він і є причиною робити інтеграцію.
Три рівні інтеграції за вартістю
| Рівень | Як працює | Кому підходить |
|---|---|---|
| Ручний | Вивантаження файлу з обліку, завантаження в кабінет сервісу | До 20–30 документів на місяць. Дешево і цілком робоче |
| Напівавтоматичний | Пакетне вивантаження за розкладом, статуси заносяться вручну | Перехідний варіант, коли обсяг виріс, а бюджету на повну інтеграцію ще немає |
| Повний обмін | Двосторонній обмін через API, статуси автоматично | Від кількох сотень документів на місяць |
Помилка, яку варто уникати, — одразу замовляти третій рівень «щоб було». Порахуйте свій реальний обсяг: якщо ви виставляєте тридцять накладних на місяць, ручний режим займає близько години, а повна інтеграція коштує як кілька місяців роботи бухгалтера.
Питання, які варто поставити до старту
Ці питання ставлять і сервісу ЕДО, і підряднику з впровадження. Розбіжність у відповідях — уже сигнал.
- Чи є в сервісу відкритий API й документація до нього, чи обмін тільки через кабінет?
- Хто розробляє й підтримує конектор — сервіс, підрядник чи це ваша розробка? І хто платить, коли сервіс змінить API?
- Що станеться зі зв’язкою при оновленні Business Central двічі на рік — конектор зроблено як розширення чи як зміну ядра?
- Як зіставляються контрагенти між системами: за ЄДРПОУ, за внутрішнім кодом, вручну?
- Що робити з документами, які контрагент відхилив? Це найчастіше не продуманий сценарій.
Останнє питання варте окремої уваги. Відхилений документ — це не помилка інтеграції, це нормальна ситуація, і в обліку має бути зрозуміло, що з ним робити далі.
Типові помилки
Контрагенти не зіставлені за єдиним ключем. Якщо в обліку «ТОВ Ромашка», а в сервісі «Ромашка, ТОВ», автоматичне зіставлення не спрацює. Зв’язувати треба за ЄДРПОУ, і це ще одна причина почистити довідник контрагентів до старту.
Документ формується двічі. Класика: бухгалтер створює видаткову в обліку, а потім заново набирає її в кабінеті ЕДО. Формально інтеграція є, фактично роботи побільшало.
Не продуманий сценарій виправлення. Помилку в підписаному документі виправляють коригуванням, а не переписуванням. Якщо цей маршрут не описаний, кожен випадок стає окремою пригодою.
Інтеграцію робили як зміну ядра. Тоді кожне оновлення Business Central ламає обмін. Робиться це розширенням — принцип той самий, що й для будь-яких доробок, розібраний у статті про доцільність кастомізації.
Часті запитання
Чи вміє Business Central працювати з українським ЕДО з коробки?
Ні, і жодна міжнародна система не вміє. Обмін із українськими сервісами електронного документообігу реалізується через конектор від партнера або окрему розробку. Це нормальна ситуація: український документообіг має свою специфіку, якої немає в базовому продукті.
Чи потрібна повна інтеграція, якщо документів небагато?
Зазвичай ні. До кількох десятків документів на місяць ручне вивантаження займає близько години й не потребує жодного бюджету. Порахуйте свій обсяг перед тим, як замовляти автоматизацію: часто вона окупається лише від кількох сотень документів.
Що станеться з інтеграцією під час оновлення Business Central?
Якщо конектор зроблено як розширення за стандартами Microsoft, оновлення він переживає. Якщо як зміна ядра — ламатиметься двічі на рік. Це питання варто поставити підряднику до початку робіт і зафіксувати відповідь письмово.
Чи можна вести податкові накладні прямо в Business Central?
Реєстрація ПН і РК в ЄРПН — окремий контур зі своїми вимогами. На практиці більшість компаній залишає його в спеціалізованому рішенні, а в обліковій системі веде первинку й розрахунки. Змішувати ці два контури в одному проєкті зазвичай не варто.
Як зіставляти контрагентів між системами?
За ЄДРПОУ — це єдиний надійний ключ. Зіставлення за назвою не працює через різнобій у написанні, а внутрішні коди у вас і в контрагента різні. Тому довідник має бути почищений до запуску обміну.