Немає UPO в KSeF: як завантажити офіційне підтвердження отримання?

Відсутність UPO після надсилання рахунка до KSeF сама по собі не є діагнозом. Спочатку перевірте статус рахунка або сесії, номер KSeF, референсний номер, контекст NIP і інструмент, через який документ було надіслано.

UPO можна завантажити лише для рахунка, успішно прийнятого KSeF, або для закритої й обробленої сесії, якщо було створено UPO сесії. Статус 100 або 150 означає, що потрібно далі моніторити те саме надсилання.

Якщо рахунок відхилено, він не отримає номера KSeF і UPO. Потрібно прочитати код помилки, виправити джерело проблеми і тільки потім повторно надіслати виправлений XML FA(3).

Найгірша реакція на відсутність UPO - автоматично повторити надсилання без перевірки статусу. Так можна створити дублікат або ускладнити пошук первинної операції.

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

Статус надсилання говорить більше, ніж повідомлення, що файл передано до системи. В API KSeF статус 100 означає прийняття рахунка до подальшої обробки, статус 150 означає, що обробка триває, а статус 200 означає успіх.

Лише успішний рахунок дає підставу переходити до номера KSeF і UPO. Статуси помилок вимагають діагностики. У такому випадку пошук UPO не має сенсу, доки не зрозуміло, чи документ взагалі прийнято.

Для ручного шляху почніть з правильного контексту платника. Увійдіть до Aplikacja Podatnika KSeF 2.0, виберіть правильний суб'єкт або NIP і знайдіть рахунок за власним номером, номером KSeF, датою або даними надсилання.

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

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

В інтеграції API спочатку отримують список сесій або статус конкретної сесії, потім рахунки в сесії або статус окремого рахунка. Лише після підтвердження прийняття документа переходять до endpoint UPO.

Документація CIRF описує два шляхи для UPO окремого рахунка: за референсним номером рахунка і за номером KSeF. Для UPO сесії є окремий endpoint з референсним номером UPO.

На практиці інтеграція повинна зберігати референс сесії, референс рахунка, номер KSeF, статус, дату прийняття і посилання або завантажений XML UPO. Без цих даних потім важко знайти підтвердження.

У щоденній роботі легко сплутати UPO рахунка з UPO сесії. UPO рахунка стосується одного документа. UPO сесії є збірним підтвердженням, яке з'являється після закриття й обробки сесії.

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

Номер KSeF ідентифікує рахунок, прийнятий системою, і повертається в UPO, але для endpoint завантаження в контексті сесії потрібен також контекст сесії. Сам номер KSeF без знання, де і як рахунок був надісланий, може бути недостатнім.

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

Якщо у вас є лише номер рахунка з поля P_2, почніть з пошуку документа в інструменті, через який він був надісланий. Лише потім зчитайте номер KSeF, номер сесії і шлях до UPO.

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

Спочатку оновіть статус рахунка. Якщо відповідь містить посилання на UPO, перевірте строк його дії. OpenAPI описує `upoDownloadUrl` як посилання, що генерується при запиті статусу, завантажується методом HTTP GET і закінчується через певний час.

Якщо посилання прострочене, згенеруйте його повторно через статус. Якщо працюєте через застосунок, перевірте правильний контекст NIP і чи цей застосунок підтримує UPO для цього рахунка. У KSeFGPT UPO доступне для рахунків, надісланих через цей застосунок.

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

Перевірте, чи статус не 100 або 150. Якщо статус показує помилку, отримайте деталі, включно з кодом, описом, details і можливими extensions. При коді 440 перевірте первинну сесію і первинний номер KSeF, бо це може бути дублікат.

Повну процедуру для помилок описано в посібнику Рахунок відхилено KSeF. Цей текст відповідає тільки на питання, чому UPO не видно і як встановити, чи підтвердження вже мало існувати.

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

Якщо рахунок надіслано через KSeFGPT, застосунок може показати його статус і зробити UPO доступним у тому самому процесі. Якщо документ було надіслано іншою системою, шукайте підтвердження в тому інструменті, Aplikacja Podatnika KSeF або через API.

Так бухгалтерія має одну процедуру: перевірити статус, прочитати номер KSeF, завантажити UPO після успіху або перейти до діагностики помилки. Це зменшує ризик повторного надсилання лише тому, що підтвердження не було видно на першому екрані.

Технічне FAQ Міністерства фінансів вказує, що немає обов'язку завантажувати й архівувати UPO KSeF. Попри це в операційній роботі варто зберігати UPO локально, бо це допомагає при аудиті, контролі статусів і питаннях контрагентів.

Найкращий комплект включає XML рахунка, номер KSeF, UPO, власний номер рахунка з P_2, дату прийняття, NIP продавця, контекст платника та інформацію, через який інструмент рахунок було надіслано.

Проста назва файлу може виглядати так: `NIP_prodavtsia-nomer_rakhunka-nomer_KSeF-upo.xml`. Важливіше за саму назву те, щоб команда завжди могла пов'язати UPO з конкретним рахунком, а не лише з пачкою або сесією.

Якщо UPO немає, не починайте з повторного надсилання. Спочатку перевірте статус того самого рахунка або сесії, номер KSeF, референсний номер, контекст NIP і джерело надсилання. Лише статус показує, чи потрібно чекати, згенерувати посилання повторно, шукати в іншому інструменті або виправляти помилку.

Якщо статус 200, завантажте UPO і збережіть його з номером KSeF та власним номером рахунка. Якщо статус 100 або 150, продовжуйте моніторинг. Якщо статус показує помилку, переходьте до діагностики відхилення замість створення нової версії документа.

Читайте далі: UPO в KSeF, Рахунок відхилено KSeF, Надсилання рахунків до KSeF та Скільки часу є на надсилання до KSeF.