Міграція зі старої бази 1С до BAS: що переносити, що очищати й що звіряти

Спочатку зафіксуйте не назву програми, а точну точку переходу

Визначте модель переходу й глибину історії

Довідники: переносити ідентичність, а не накопичений безлад

Залишки: сума має збігтися разом з аналітикою

Взаєморозрахунки: борг без документа може втратити сенс

Зарплатні дані: розділіть старт розрахунку та архів історії

Основні засоби: облікова картка має відповідати реальному об’єкту

ПДВ: перевіряйте ланцюжок операції, а не тільки рахунки

Протокол міграції: документ, який відповідає на запитання «що саме зробили»

Контрольна оборотка: як довести, що перехід відбувся коректно

Репетиція переходу й перший робочий період

Коли потрібне окреме навчання команди

Підсумковий чек-лист

Перехід на BAS часто починають із простого запитання: «Чи можна перенести всю базу?». Для керівника це звучить як технічне завдання, але для бухгалтера справжнє питання інше: чи збережеться зміст обліку після того, як дані опиняться в новій структурі? Однакова сума на рахунку ще не означає однакову аналітику, а перенесений контрагент — не гарантія, що борг залишився прив’язаним до правильного договору, документа й валюти.

Тому міграція — не універсальна «конвертація одним кліком», а окремий обліковий проєкт. У ньому є власник рішення, зафіксований склад даних, правила перетворення, пробні завантаження, контрольна оборотно-сальдова відомість і письмове підтвердження результату. Чим старіша й сильніше доопрацьована база 1С, тим важливіше спочатку описати її фактичну логіку, а вже потім обирати інструмент перенесення.

Спочатку зафіксуйте не назву програми, а точну точку переходу

Формулювання «переходимо з 1С на BAS» для технічного завдання недостатньо. За однаковою звичною назвою можуть стояти різні конфігурації, редакції, релізи, платформи, розширення та роки локальних змін. До першого тестового вивантаження складіть паспорт міграції, у якому окремо зазначте:

• назву вихідної конфігурації 1С, її редакцію та повний номер релізу;
• версію платформи, режим роботи бази, СУБД, обсяг даних і кодування старих інтеграцій;
• назву цільової конфігурації BAS, редакцію й реліз, на якому виконуватимуть тестове та фінальне завантаження;
• версію BAF для серверів і робочих місць;
• усі розширення, зовнішні обробки, обміни, друковані форми, додаткові реквізити та нестандартні доробки;
• організації, підрозділи, склади, валюти, системи оподаткування й ділянки обліку, які входять у контур;
• дату зрізу, глибину історії, допустимий час простою та відповідальних за кожну контрольну ділянку.

Станом на 11 вересня 2026 року в інформаційній системі ІТС окремо публікуються оновлення BAF, прикладних конфігурацій, форм регламентованої звітності та сервісів. Наприклад, 2 вересня 2026 року було оприлюднено BAF 8.3.23.2301, але це не робить цей реліз автоматично правильною ціллю для будь-якого підприємства. Перед кожним пробним і фінальним перенесенням звіряйте сумісність та актуальні оновлення через ІТС BAS, а точні версії записуйте в протоколі. Так команда зможе відтворити результат і не сплутає помилку правил міграції з різницею релізів.

Визначте модель переходу й глибину історії

Перенесення «всього за всі роки» здається найбезпечнішим, але часто саме воно затягує проєкт і переносить у нову систему старі помилки. На практиці обирають одну з трьох моделей:

1. Початкові залишки на дату переходу. До BAS завантажують нормалізовані довідники, залишки та відкриті операції, а стару базу залишають доступною лише для перегляду історії.
2. Залишки плюс обмежений оперативний період. Окрім входу переносять документи поточного року або кількох місяців, щоб користувачі бачили звичний контекст і могли формувати потрібні розшифрування.
3. Повна документальна історія. Її обирають лише тоді, коли є обґрунтована потреба, достатній бюджет і підтверджено, що документи двох систем можна однозначно зіставити.

Рішення приймають не за принципом «раптом знадобиться», а за переліком робочих і контрольних сценаріїв. Якщо давні документи потрібні лише для перевірок, дешевше й надійніше зберегти захищену копію старої бази, налаштувати доступ лише на читання та підготувати ключові звіти у відкритому форматі. Водночас строки зберігання первинних документів і регістрів визначаються чинними вимогами для конкретного підприємства; сама міграція не є підставою скорочувати їх.

Довідники: переносити ідентичність, а не накопичений безлад

Довідники створюють каркас майбутнього обліку. Якщо спочатку завантажити дублікати, а потім поверх них — залишки й документи, об’єднання елементів стане ризикованим: борги, партії або основні засоби можуть роз’їхатися між різними картками. Очищення треба виконувати до основного завантаження, але без втрати зв’язку з джерелом.

Що перевірити в основних довідниках

• Організації та банківські рахунки. Повні реєстраційні дані, податковий статус, валюта, чинність рахунків, відповідальні особи.
• Контрагенти й договори. Унікальні коди, назви, реквізити, ознаки покупця та постачальника, валюта, вид договору, правила взаєморозрахунків.
• Номенклатура. Одиниці виміру, коефіцієнти, ставки й види оподаткування, коди, характеристики, серії, партії та складські налаштування.
• Склади, каси, підрозділи та статті. Чинність елементів, відповідність організаційній структурі й аналітикам цільової конфігурації.
• Фізичні особи, працівники й посади. Відокремлення картки людини від трудових відносин, актуальність документів, відсутність дублювання та обґрунтований доступ до персональних даних.

Для кожного елемента зберігайте таблицю відповідності «ідентифікатор у джерелі — ідентифікатор у BAS». Дублікати не варто просто видаляти: спочатку визначте головну картку, перенаправте на неї зв’язки й зафіксуйте правило об’єднання. Неактивні елементи можна не завантажувати до робочих списків, якщо вони не беруть участі у відкритих залишках, гарантіях, розрахунках або обов’язковій історії.

Залишки: сума має збігтися разом з аналітикою

Початкові залишки переносять на погоджену дату після закриття періоду в старій базі. На час фінального перенесення операції або зупиняють, або ведуть у контрольованому «вікні», де кожен новий документ потрапляє до журналу дельти. Інакше бухгалтер звірятиме два рухомі набори даних.

Мінімальний контроль охоплює не лише підсумок за рахунком, а й усі значущі виміри:

• грошові кошти — за організацією, касою, банківським рахунком і валютою;
• запаси — у кількості та вартості, за складом, номенклатурою, характеристикою, серією або партією, якщо вони використовуються;
• незавершене виробництво й витрати — за підрозділами, статтями, замовленнями та іншими потрібними аналітиками;
• власний капітал, резерви й фінансовий результат — після погоджених регламентних операцій;
• податкові рахунки — з розшифруванням до об’єктів, які пояснюють суму.

Якщо цільова конфігурація має іншу модель аналітики, заздалегідь створіть правила перетворення. Наприклад, один субконто старої бази може розкладатися на договір, документ розрахунків і напрям діяльності в BAS. Таке правило потрібно тестувати на типових і нетипових випадках, а не виправляти вручну вже після завантаження.

Взаєморозрахунки: борг без документа може втратити сенс

Загальна дебіторська чи кредиторська заборгованість — лише верхній рівень перевірки. Для подальшого погашення, заліку авансів і валютної переоцінки BAS має отримати правильну структуру боргу. Звіряйте залишки за контрагентом, договором, документом розрахунків, валютою та строком виникнення.

Окремий список ризику варто скласти для:

• авансів і боргів, які в старій базі обліковувалися на різних рахунках або без документа розрахунків;
• від’ємних залишків і «перевернутих» дебету з кредитом;
• валютних договорів, курсових різниць і сум одночасно у валюті та гривні;
• внутрішньогрупових операцій, взаємозаліків і передач між організаціями;
• давньої заборгованості, щодо якої потрібне управлінське або юридичне рішення.

До тестового перенесення бажано провести звірки з ключовими контрагентами й закрити технічні копійки. Але «підчистити» реальний спірний борг лише заради красивої оборотки не можна: його слід перенести окремо, позначити в реєстрі проблем і призначити відповідального.

Зарплатні дані: розділіть старт розрахунку та архів історії

Зарплата поєднує бухгалтерські підсумки, кадрові події, розрахункові показники та чутливі персональні дані. Тут особливо небезпечно переносити лише сальдо за рахунком розрахунків із працівниками. Для коректного продовження розрахунку можуть знадобитися:

• актуальні фізичні особи, працівники, кадрові позиції та чинні умови праці;
• нарахована, але не виплачена зарплата, депоновані суми, утримання й виконавчі документи;
• дані для розрахунку середнього заробітку, відпусток і лікарняних у потрібному періоді;
• залишки відпусток, резерви, взаєморозрахунки за податками та внесками;
• персональні податкові параметри й пільги з датами дії;
• кадрова історія, якщо вона реально використовується цільовим функціоналом і її можна однозначно відтворити.

Рішення про глибину зарплатної історії приймає розраховувач зарплати разом із кадровим фахівцем, а не лише розробник. Доступ до файлів вивантаження обмежують, тимчасові копії видаляють після приймання, а резервні копії зберігають у захищеному місці. Після завантаження виконайте паралельний розрахунок контрольного місяця й порівняйте нарахування, утримання, внески, виплату та проводки по кожному працівнику.

Основні засоби: облікова картка має відповідати реальному об’єкту

Для основного засобу недостатньо перенести первісну вартість і накопичену амортизацію. Потрібні інвентарний номер, дата введення в експлуатацію, стан, матеріально відповідальна особа, місце використання, рахунки обліку, підрозділ, метод і параметри амортизації, строк корисного використання, ліквідаційна вартість, модернізації та компоненти, якщо їх ведуть окремо.

Найкращий момент для міграції основних засобів — після інвентаризації. Фізичний об’єкт, інвентарна картка й бухгалтерська сума повинні утворювати один ланцюжок. Окремо розберіть повністю замортизовані, але діючі об’єкти; майно в ремонті, на консервації або в оренді; незавершені капітальні інвестиції; об’єкти з невірним місцем експлуатації. Контрольний розрахунок амортизації в BAS порівнюють не лише загальною сумою, а пооб’єктно.

ПДВ: перевіряйте ланцюжок операції, а не тільки рахунки

ПДВ — одна з ділянок, де механічне перенесення проводок найчастіше дає хибне відчуття рівності. У BAS важливий зв’язок між господарським документом, першою подією, авансом, податковим призначенням, податковою накладною або розрахунком коригування та станом їх опрацювання.

До карти перенесення включіть:

• податкові налаштування організацій і контрагентів із датами дії;
• види ставок і податкове призначення номенклатури та операцій;
• залишки за ПДВ-рахунками з документальною розшифровкою;
• незакриті аванси, очікуваний податковий кредит і податкові зобов’язання;
• зареєстровані, незареєстровані, заблоковані або відхилені податкові документи та коригування;
• операції зі змішаним чи спеціальним режимом використання, якщо вони є в обліку підприємства.

Чинні ставки, форми та правила заповнення не варто зашивати в одноразову обробку перенесення. Їх перевіряють на дату переходу, а цільову базу оновлюють до погодженого сумісного релізу. Після завантаження бухгалтер відтворює контрольні сценарії: закриття авансу, формування податкових документів, коригування, розподіл та звірку з регламентованими звітами.

Протокол міграції: документ, який відповідає на запитання «що саме зробили»

Протокол потрібен не для формальності. Без нього після кількох тестів неможливо впевнено сказати, яким правилом сформовано конкретний залишок і чому частину записів відкинуто. Для кожного запуску протокол має містити:

• дату й час, копії баз, точні релізи конфігурацій і BAF;
• версію обробки або сценарію міграції та контрольну суму пакета, якщо її використовує команда;
• перелік перенесених об’єктів, періодів і організацій;
• кількість прочитаних, створених, зіставлених, пропущених і помилкових записів;
• застосовані правила очищення, об’єднання й перетворення;
• помилки з посиланням на ідентифікатор джерела та рішення щодо кожної з них;
• підсумки контрольних звітів до та після завантаження;
• прізвища відповідальних і статус приймання кожної ділянки.

Ручні виправлення без протоколу треба мінімізувати. Якщо тест виявив системну проблему, краще змінити правило перетворення й повторити завантаження на чистій тестовій копії. Інакше фінальний запуск відрізнятиметься від перевіреного, а причину розбіжності доведеться відновлювати за пам’яттю.

Контрольна оборотка: як довести, що перехід відбувся коректно

Контрольна оборотно-сальдова відомість, або звична «контрольна оборотка», формується в обох системах на однакову дату, за однаковими організаціями та в однаковій валюті, за погодженими правилами порівняння. Спочатку звіряють баланс у цілому, потім рахунки, а далі — аналітику до первинного об’єкта.

У критерії приймання заздалегідь запишіть, де допускається різниця округлення, а де відхилення має бути нульовим. Кожну різницю класифікують: помилка вихідних даних, свідоме очищення, зміна методики обліку, технічна помилка або округлення. Формула «загалом майже зійшлося» для приймання непридатна.

Репетиція переходу й перший робочий період

Надійний план передбачає щонайменше два пробні завантаження. Перше показує невідомі формати й прогалини в правилах. Друге проводять після виправлень у повному обсязі та з хронометражем, щоб перевірити, чи вкладається команда у вікно зупинки. На фінальному запуску використовують ту саму версію правил, яку вже прийняли на репетиції.

1. Створіть резервні копії й перевірте можливість відновлення.
2. Закрийте погоджений період у джерелі та зафіксуйте дату й час зрізу.
3. Виконайте вивантаження, автоматичні перевірки й завантаження до BAS.
4. Сформуйте контрольну оборотку та деталізації по критичних ділянках.
5. Отримайте підписи відповідальних бухгалтерів, кадровика й керівника про приймання.
6. Відкрийте нову базу для роботи та ведіть журнал перших помилок без повернення до паралельного введення «про всяк випадок».

У перші дні перевіряйте не лише залишки, а й нові операції: оплату й погашення боргу, прихід та списання запасів, нарахування зарплати, амортизацію, закриття місяця й ПДВ-сценарії. Стару базу переводять у режим читання, але не знищують до завершення погодженого строку зберігання та стабілізації роботи.

Коли потрібне окреме навчання команди

Навіть технічно правильна база не дає результату, якщо користувач продовжує відтворювати в BAS звички старої конфігурації. Для нетипової ділянки корисно розібрати її на власних прикладах: довідники, документи, взаєморозрахунки, контрольні звіти та межі доробок. Саме такий практичний формат пропонує програма про індивідуальні конфігурації BAS; BAS Бухгалтерія на цій сторінці винесена в окремий курс, що теж варто врахувати під час вибору навчання.

Навчальний сценарій краще будувати за ролями. Комірнику потрібні партії, склади й інвентаризація; менеджеру — замовлення, резерви та взаєморозрахунки; бухгалтеру — проводки, закриття періоду й податковий контур; керівнику — звіти та критерії достовірності. До запуску кожен має виконати в тестовій базі свої п’ять-десять щоденних операцій і пояснити, яким звітом перевіряється результат.

Підсумковий чек-лист

• Зафіксовано точні вихідну й цільову конфігурації, релізи, BAF, розширення та всі доробки.
• Визначено дату зрізу, глибину історії й список даних, які свідомо не переносяться.
• Довідники очищено, а таблицю відповідності ідентифікаторів збережено.
• Залишки деталізовано до потрібної аналітики, а відкриті взаєморозрахунки — до документів.
• Зарплату перевірено контрольним розрахунком, основні засоби — пооб’єктно, ПДВ — за ланцюжком подій.
• Виконано щонайменше два пробні завантаження на копіях.
• Кожен запуск має протокол, реєстр помилок і відтворювану версію правил.
• Контрольна оборотка й деталізації підписані відповідальними за ділянки.
• Стару базу та резервні копії захищено, а доступ до персональних даних обмежено.
• Користувачі відпрацювали свої реальні операції до дати старту.

Успішна міграція не обов’язково переносить найбільше даних. Вона переносить саме ті дані, які потрібні для безперервної роботи й доказового обліку, очищає те, що заважало старій системі, та залишає зрозумілий слід перевірки. Якщо через місяць після запуску бухгалтер може пояснити кожну початкову суму, відкрити її аналітику й повторити контроль, перехід справді завершено — незалежно від того, скільки рядків було переміщено.