BAS + FlyDoc: як провести первинний документ від отримання до архіву без розриву в обліку
Практична схема електронного документообігу в BAS і FlyDoc: як розподілити відповідальність між менеджером і бухгалтером, пов’язати вхідний електронний документ з обліковим, налаштувати погодження, підписання та архів і не втратити контроль на переходах між етапами.. Що означає «без розриву». Актуальна версія: що перевірити перед налаштуванням. Маршрут документа: п’ять етапів і жодного повторного введення без контролю. Хто за що відповідає. Які налаштування потрібні до першого робочого документа. Пілотний запуск на одному сценарії. Типові помилки, через які інтеграція не дає результату. Контрольний список перед переходом у промислову експлуатацію. Практичний висновок
Актуальна версія: що перевірити перед налаштуванням
Маршрут документа: п’ять етапів і жодного повторного введення без контролю
Які налаштування потрібні до першого робочого документа
Пілотний запуск на одному сценарії
Типові помилки, через які інтеграція не дає результату
Контрольний список перед переходом у промислову експлуатацію
Постачальник уже надіслав акт або видаткову накладну в електронному вигляді, але всередині підприємства документ часто продовжує жити кількома паралельними життями. Менеджер перевіряє його в пошті чи месенджері, бухгалтер повторно вводить дані в BAS, керівник підписує окремий файл, а під час перевірки співробітники шукають фінальну версію в різних папках. Формально електронний документообіг є, проте розрив між первинкою та обліковою базою нікуди не зник.
Зв’язка BAS + FlyDoc дає змогу побудувати інакший процес: отриманий електронний документ проходить контрольований маршрут, пов’язується з об’єктом обліку, підписується уповноваженою особою та залишається доступним разом зі статусами обміну. Але сама інтеграція не замінює регламенту. Щоб система справді економила час, потрібно заздалегідь визначити, хто перевіряє господарський зміст, хто відповідає за облікові реквізити, у який момент дозволено підпис і що вважається завершеним пакетом для архіву.
Що означає «без розриву»
Безперервний ЕДО — це не просто відсутність паперу. Це ситуація, коли на всьому маршруті зберігається зв’язок між трьома сутностями:
- електронним оригіналом, отриманим від контрагента;
- рішеннями та коментарями відповідальних працівників;
- документом BAS, який відображає операцію в управлінському, бухгалтерському або податковому обліку.
Для кожного документа мають бути зрозумілі поточний статус, відповідальний, причина зупинки та наступна дія. Якщо файл уже підписано, але бухгалтер не бачить, на підставі якого облікового документа він опрацьований, це розрив. Якщо операцію проведено в BAS, а менеджер ще не підтвердив фактичне отримання товару чи послуги, це також розрив. Якщо в архіві лежить лише друкована копія без електронних підписів і службових повідомлень обміну, ланцюжок доказів неповний.
Актуальна версія: що перевірити перед налаштуванням
Станом на 11 вересня 2026 року на порталі ІТС BAS опубліковано реліз 2.1.43.1 «Business automation software for іntegrated enterprise management + FlyDoc». Важливо не плутати його з однойменним рішенням без позначки «+ FlyDoc», для якого версія 2.1.43.1 була опублікована днем раніше. Назва конфігурації, редакція, наявність інтегрованого модуля та номер релізу — це чотири окремі контрольні ознаки.
Номер 2.1.43.1 не слід автоматично переносити на BAS Бухгалтерію, BAS Управління торгівлею, BAS ERP чи галузеве рішення. Для кожної конфігурації мінімально сумісну версію потрібно перевіряти окремо в ІТС і зіставляти з фактичною версією робочої бази. Перед оновленням також варто переглянути опис релізу, відомі проблемні ситуації, вимоги до платформи та порядок резервного копіювання, а саме оновлення спочатку відпрацювати на копії бази.
Маршрут документа: п’ять етапів і жодного повторного введення без контролю
1. Отримання: документ потрапляє у правильний контур
На вході FlyDoc приймає первинний документ від контрагента. Перше завдання команди — не провести його якомога швидше, а правильно ідентифікувати. Система та відповідальний працівник мають визначити організацію-одержувача, контрагента, вид документа, договір, валюту, дату, номер і можливий зв’язок із замовленням або попередньою операцією.
Для вхідної черги корисно передбачити щонайменше чотири технічні стани: «новий», «потребує ідентифікації», «передано на перевірку» та «дублікат/помилковий адресат». Документ не повинен непомітно зникати із загального списку через те, що в довіднику по-різному записано назву контрагента або не знайдено договір. Такі випадки мають потрапляти в окрему чергу винятків із відповідальним і строком опрацювання.
2. Погодження змісту: зона відповідальності менеджера
Менеджер, замовник послуги, комірник або керівник підрозділу підтверджує не бухгалтерську форму, а реальність господарської події. Його запитання прості й предметні: чи поставлено саме той товар, чи виконано погоджений обсяг робіт, чи відповідають кількість і ціна замовленню, чи немає претензій до якості, до якого проєкту або центру витрат належить операція.
Результат перевірки має бути не усним повідомленням бухгалтеру, а зафіксованою дією: «погоджено», «відхилено» або «потрібне уточнення». Для відхилення потрібен коментар із конкретною причиною. Наприклад, «у документі 12 одиниць, фактично прийнято 10» значно корисніше, ніж «неправильно». Поки розбіжність не усунуто, документ не переходить до підписання.
3. Облікова перевірка: зона відповідальності бухгалтера
Бухгалтер перевіряє реквізити сторін, період, договір, суму, податкові параметри, номенклатуру, одиниці виміру та аналітику витрат. Важлива частина роботи — встановити однозначний зв’язок між електронним документом і документом BAS. Якщо за налаштованою схемою дані завантажуються автоматично, бухгалтер контролює зіставлення довідників і результат створення. Якщо певні поля заповнюються вручну, система має підсвічувати їх як контрольні, а не маскувати ручне втручання під повну автоматизацію.
На цьому етапі корисна перевірка за принципом «одна операція — один обліковий документ — один комплект електронної первинки». Винятки можливі, наприклад коли один акт потрібно розподілити між кількома підрозділами, але вони мають бути описані в регламенті. Інакше звіряння наприкінці місяця перетвориться на пошук причин, чому одна сума відображена двічі або залишилася лише в реєстрі ЕДО.
4. Підписання: тільки після двох змістовних перевірок
Накладення кваліфікованого електронного підпису — не технічна формальність і не спосіб «закрити червоне повідомлення». До підпису допускають документ, який пройшов господарське погодження та обліковий контроль. Перелік підписантів, послідовність підписів і право доступу до ключів потрібно визначати за видом документа, організацією та внутрішніми повноваженнями.
Ключі не варто передавати між працівниками або використовувати під обліковим записом іншої особи. У системі повинно бути видно, хто ініціював підписання, хто наклав підпис і коли контрагент завершив свою частину обміну. Якщо підписант відсутній, потрібен заздалегідь затверджений сценарій заміщення, а не імпровізований доступ до чужого ключа.
5. Відображення в обліку та архів: завершення процесу, а не дві різні історії
Момент проведення документа в BAS визначається обліковою політикою та конкретною господарською операцією. Не слід універсально прирівнювати отримання файла до визнання операції або чекати підпису там, де для оперативного контуру потрібне попереднє відображення. Правильне правило формулюється для кожного виду документа: коли створюється обліковий об’єкт, коли його можна провести, яка подія блокує закриття періоду та як опрацьовується подальше виправлення.
Після завершення обміну в архіві має залишатися не довільний PDF, а цілісний комплект: електронний оригінал, накладені підписи, службові повідомлення або квитанції, статус завершення та зв’язок із документом BAS. Пошук варто забезпечити щонайменше за контрагентом, датою, номером, видом документа, сумою та відповідальним. Окремо перевіряють резервне копіювання, відновлення та права доступу: архів, який ніхто не тестував на відновлення, не можна вважати надійним.
Хто за що відповідає
| Етап | Менеджер або власник операції | Бухгалтер |
|---|---|---|
| Отримання | Допомагає визначити замовлення, договір і підрозділ | Контролює правильну організацію, контрагента та вид первинки |
| Погодження | Підтверджує факт, обсяг, ціну, якість і призначення витрат | Перевіряє, чи достатньо даних для облікового опрацювання |
| Підпис | Погоджує в межах своїх повноважень | Контролює готовність реквізитів і маршрут до уповноваженого підписанта |
| Облік | Надає потрібну аналітику та пояснює відхилення | Створює або перевіряє документ BAS, проводить і контролює відображення |
| Архів | За потреби знаходить документ через пов’язану операцію | Контролює повноту електронного комплекту, строки доступності та звіряння |
Такий розподіл прибирає дві крайнощі. Менеджер не мусить знати бухгалтерські проведення, щоб підтвердити отриману послугу. Бухгалтер не повинен вгадувати, чи справді підрозділ прийняв результат робіт. Кожен відповідає за ту частину даних, яку може перевірити професійно.
Які налаштування потрібні до першого робочого документа
У типовій конфігурації частина зв’язків і схем обміну вже передбачена, але реальний процес підприємства майже завжди потребує уточнення правил. Не варто починати з програмування. Спочатку опишіть один маршрут на папері або в таблиці та позначте точки прийняття рішення.
- Складіть матрицю видів документів. Для акта, накладної, рахунку та коригування визначте відповідального менеджера, бухгалтера, підписанта і допустимі стани.
- Підготуйте довідники. Приберіть дублікати контрагентів і договорів, уніфікуйте номенклатуру та перевірте організації, підрозділи, центри витрат і користувачів.
- Налаштуйте зіставлення. Визначте, як електронний вид документа перетворюється на конкретний об’єкт BAS і які поля потребують ручної перевірки.
- Розмежуйте права. Отримання, погодження, редагування облікових даних, проведення та підписання не повинні автоматично належати кожному користувачеві.
- Передбачте винятки. Опишіть дублі, помилкового адресата, невідомого контрагента, розбіжність суми, відмову від підпису, анулювання та виправлення.
- Увімкніть контроль строків. Прострочені документи мають потрапляти до окремого звіту або сповіщення, а не губитися в загальному реєстрі.
Якщо типової логіки недостатньо, спершу сформулюйте вимогу мовою ролей, статусів і контрольних умов. Для команди, якій потрібно розібрати власний маршрут, корисним може бути індивідуальне навчання роботі з різними конфігураціями BAS: на практичному прикладі легше відокремити налаштування користувача від завдань, що справді потребують доопрацювання.
Пілотний запуск на одному сценарії
Найбезпечніше запускати ЕДО не одразу для всіх документів, а на одному частому й зрозумілому сценарії. Наприклад, виберіть акти послуг від п’яти постійних постачальників. Протягом пілоту проведіть кожен акт через повний маршрут і фіксуйте не лише помилки програми, а й організаційні затримки.
- FlyDoc отримує акт і визначає контрагента.
- Відповідальний менеджер звіряє послугу із замовленням та зазначає центр витрат.
- Бухгалтер перевіряє реквізити, суму й аналітику, після чого зв’язує акт із документом BAS.
- Уповноважена особа накладає підпис лише після обох погоджень.
- Бухгалтер контролює проведення, завершений статус обміну та повноту архівного комплекту.
Для оцінки пілоту достатньо кількох показників: середній час від отримання до першої реакції, тривалість погодження, частка документів із ручним виправленням зіставлення, кількість повернень контрагенту та число документів без зв’язку з BAS. Ці метрики показують вузьке місце краще, ніж загальне враження «стало швидше».
Типові помилки, через які інтеграція не дає результату
- Підписують до перевірки факту. Електронний підпис прискорює помилку так само добре, як правильний документ.
- Усі рішення залишають у чатах. Через місяць неможливо встановити, хто і що погодив.
- Прийом документа автоматично запускає проведення. Технічне отримання не підтверджує господарську операцію.
- Одна схема застосовується до всіх конфігурацій. Об’єкти, версії та доступні механізми в різних рішеннях BAS відрізняються.
- Не очищено довідники. Автоматичне завантаження створює дублікати або потребує постійного ручного вибору.
- Архівом вважають папку з PDF. Втрачається зв’язок з електронним оригіналом, підписами, квитанціями та обліковою операцією.
- Немає власника черги винятків. Документи з помилками накопичуються, хоча основний потік виглядає успішним.
Контрольний список перед переходом у промислову експлуатацію
- точно визначено конфігурацію, редакцію та сумісний реліз BAS + FlyDoc;
- оновлення перевірено на копії, а резервну копію можна відновити;
- для кожного виду первинки призначено менеджера, бухгалтера та підписанта;
- зафіксовано умови переходу між отриманням, погодженням, підписом, проведенням і архівом;
- електронний документ однозначно пов’язується з об’єктом BAS;
- налаштовано права користувачів і сценарій заміщення підписанта;
- розбіжності не видаляються, а потрапляють у контрольовану чергу;
- архів зберігає оригінал, підписи, службові повідомлення та зв’язок з обліком;
- пошук і відновлення архіву перевірено на тестовому наборі;
- після пілоту виміряно час проходження та частку ручних виправлень.
Практичний висновок
Найкращий результат BAS + FlyDoc дає не там, де намагаються автоматизувати кожен клік, а там, де прибирають повторне введення і залишають людині змістовний контроль. Менеджер підтверджує реальність та параметри операції, бухгалтер відповідає за облікову коректність і зв’язок із базою, підписант діє лише після погоджень, а архів зберігає повний електронний слід.
Почніть з одного виду документа, перевірте версію саме свого рішення, опишіть винятки та проведіть контрольний маршрут від вхідної черги до пошуку в архіві. Якщо на будь-якому етапі доводиться копіювати файл у пошту, повторно набирати вже наявні реквізити або усно з’ясовувати статус, процес ще має розрив. Саме ці місця й потрібно усунути до масштабування ЕДО на все підприємство.
