FREDO 01.03.203: що бухгалтеру перевірити після вересневого оновлення

Що підготувати до перевірки

Практичний тест на 10–15 хвилин

Які ще зміни версії 01.03.203 варто врахувати

Як діяти, якщо один з етапів не пройдено

Підсумковий чек-лист приймання оновлення

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

Станом на 11 вересня 2026 року в офіційному описі версії 01.03.203 зазначено три головні напрями змін: доопрацьовано роботу з токенами, виправлено перенесення поля «Стать» у Додатку 1 Об’єднаної звітності ПДФО та ЄСВ, а також оновлено форми й довідники. Актуальні повідомлення про релізи та їх повний склад слід звіряти через інформаційну систему ІТС BAS. Сам реліз не встановлює нових податкових ставок і не вводить у дію законопроєкти: це програмне оновлення з функціональними змінами та комплектом форм. Тому змінювати облікові параметри лише через номер версії не потрібно.

Що підготувати до перевірки

Найкраще тестувати не в останню годину подання звітності. Виділіть 10–15 хвилин, попередьте користувачів про коротку перевірку та заздалегідь визначте, хто фіксує результат. Якщо оновлення встановлює адміністратор, бухгалтер усе одно має пройти бізнес-сценарій сам: технічний запуск програми не підтверджує правильність даних у звіті.

До початку тесту підготуйте:

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

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

Практичний тест на 10–15 хвилин

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

0:00–2:00. Перевірте токен

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

У версії 01.03.203 доопрацьовано роботу з токенами, які обчислюють ідентифікатор ключа суб’єкта за алгоритмом ГОСТ 34.311 та містять секретні ключі, згенеровані за алгоритмом «Купина». Якщо в установі є такий носій, його треба включити до тесту обов’язково. Якщо використовуються кілька типів токенів, достатньо перевірити по одному робочому зразку кожного типу, а не робити висновок за одним пристроєм.

Зафіксуйте три результати: носій визначився, потрібний сертифікат знайдено, запит пароля з’являється штатно. Пароль у чек-лист не записують. Якщо токен не визначається, спочатку порівняйте поведінку на іншому USB-порту та під іншим дозволеним робочим профілем, перевірте драйвер і права доступу. Не перевстановлюйте навмання всю програму, доки не зрозуміло, на якому рівні зник пристрій.

2:00–3:30. Відкрийте базу під робочим користувачем

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

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

3:30–7:00. Сформуйте Д1 і перевірте поле «Стать»

Створіть або завантажте з облікової системи Додаток 1 до Об’єднаної звітності ПДФО та ЄСВ у формі, що відповідає типу платника: J0510111 або F0510111. Ключова перевірка цього релізу — не ручне введення, а саме автоматичне перенесення даних з облікової системи у FREDO.

Для кожного контрольного рядка пройдіть три рівні:

1. У BAS перевірте первинне значення реквізиту працівника, з якого формується поле «Стать».
2. Після завантаження відкрийте Д1 у FREDO й переконайтеся, що значення заповнилося автоматично у відповідному рядку.
3. Сформуйте попередній перегляд або друковану форму та звірте відображення у графі 06.

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

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

7:00–9:00. Запустіть контролі та підпишіть документ

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

Далі оберіть штатний комплект підписів і підпишіть документ токеном. Перевірте:

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

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

9:00–12:00. Відправте контрольований документ

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

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

12:00–15:00. Дочекайтеся квитанцій і закрийте тест

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

Відкрийте кожну квитанцію та звірте:

• ЄДРПОУ або інший ідентифікатор платника;
• назву форми й звітний період;
• дату та час приймання;
• результат контролю — прийнято, не прийнято або потрібне уточнення;
• причину відмови, якщо вона є;
• відповідність статусу у реєстрі змісту останньої квитанції.

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

Які ще зміни версії 01.03.203 варто врахувати

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

Звіти та податкові документи

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

Нові довідники

У загальних довідниках з’явився користувацький довідник «Рішення про включення до Реєстру неприбуткових організацій», підключений до полів форми J0101911. Для звітності до НБУ додано «Код виду рахунку» F144 та «Код ознаки використання користувачем засобів дистанційної комунікації» F072. Організаціям, яких це стосується, варто відкрити довідники, перевірити їх доступність для звичайного користувача та протестувати вибір значення у відповідній формі.

Нові та закриті форми

Для Державної казначейської служби додано річні форми FV43D153, FZV43153, FV43M153 і FZM43153. Їх початок дії — 1 листопада 2026 року. Це майбутня дата відносно дня виходу релізу, тому сама наявність форм у програмі не означає, що їх уже потрібно подавати.

Для планово-економічної та аналітичної звітності організацій, підпорядкованих Мінрозвитку, додано форми MTUPDT01, MTUPLV01, MTURLV01 і MTUOLV01 з різними початковими датами, періодичністю та строками. Водночас для низки пакетів звітності державних підприємств, Міністерства оборони та Укроборонпрому встановлено дату закриття 30 червня 2026 року; для частини з них останнім періодом подання є II квартал 2026 року. Перед створенням спеціалізованого звіту перевіряйте не лише код форми, а й орган, період, дату початку або закриття та склад пакета.

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

Як діяти, якщо один з етапів не пройдено

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

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

Підсумковий чек-лист приймання оновлення

1. У програмі відображається версія FREDO 01.03.203.
2. Робоча база відкривається під звичайним користувачем, доступні реєстри та історичні документи.
3. Апаратний токен визначається, потрібний сертифікат доступний, пароль запитується штатно.
4. J0510111 або F0510111 формується з облікової системи без технічної помилки.
5. Поле «Стать» заповнюється автоматично й правильно відображається у графі 06 друкованої форми Д1.
6. Вбудовані контролі виконані, причини попереджень зрозумілі.
7. Документ підписується правильним комплектом підписів, операція фіксується у протоколі.
8. Контрольований реальний документ відправлено один раз, час і початковий статус записано.
9. Квитанції отримані, відкриті та звірені з підприємством, формою, періодом і кінцевим статусом.
10. Перевірено релевантні нові довідники, дати дії форм і комплектність спеціалізованих пакетів.
11. Результат тесту та докази збережено без паролів і надлишкових персональних даних.

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