Двете съобщения от портала
Официалният FAQ на НАП (въпрос IV.2.4) разглежда точно този случай — подател получава две на пръв поглед еднакви грешки:
„Стойностите в елементи GL.28 CustomerID 104104104 и GL.29 SupplierID 104104104 в секция GeneralLedgerEntries не са попълнени съгласно изискванията или са подадени идентификатори за клиент/доставчик, който не фигурира в секция 2. MasterFiles, елемент MF.C.3/ MF.S.3.“
Портал за е-услуги на НАП · „Въпроси и отговори за SAF-T“, IV.2.4
„Стойностите в елементи GL.28 CustomerID 10BG104104104 и GL.29 SupplierID 10BG104104104 в секция GeneralLedgerEntries не са попълнени съгласно изискванията или са подадени идентификатори за клиент/доставчик, който не фигурира в секция 2. MasterFiles, елемент MF.C.3/ MF.S.3.“
Портал за е-услуги на НАП · „Въпроси и отговори за SAF-T“, IV.2.4
Съобщението е едно и също, но стойността вътре издава две различни грешки. Порталът показва подадения идентификатор — гледайте него.
Грешка 1: голият ЕИК, без код за тип
Първото съобщение се получава, защото — по думите на НАП — „подаденият идентификатор не е предхождан с код „10 - следван от ЕИК - където типът е 10, а ЕИК е уникалният идентификационен код за икономическите оператори, регистрирани в България“.
Тоест идентификаторът е съставен: първо кодът на типа, после самият номер. За българска фирма с ЕИК типът е 10:
ЕИК на контрагента: 104104104 Грешно (гол ЕИК): <nsSAFT:CustomerID>104104104</nsSAFT:CustomerID> Вярно (тип 10 + ЕИК): <nsSAFT:CustomerID>10104104104</nsSAFT:CustomerID>
Същото важи за SupplierID. Счетоводният софтуер обикновено пази чистото ЕИК — представката за тип трябва да се добави при експорта към SAF-T.
Грешка 2: излишният BG префикс
Второто съобщение (стойност 10BG104104104) е обратният случай: подателят е взел ДДС номера. По FAQ-а грешката е свързана с това, че „сте подали префикса за регистрация по ЗДДС „BG“ след кода за идентификаторът – в посочения тип не се посочва префикс на държава“.
ДДС номер по ЗДДС: BG104104104 Грешно (тип + ДДС №): <nsSAFT:SupplierID>10BG104104104</nsSAFT:SupplierID> Вярно (тип 10 + ЕИК): <nsSAFT:SupplierID>10104104104</nsSAFT:SupplierID>
Ако софтуерът ви пази контрагентите с ДДС номера, при експорта префиксът BG трябва да падне — при тип 10 се подава само ЕИК.
Практично правило преди подаване: извадете всички уникални стойности на CustomerID и SupplierID от файла и ги прегледайте на един екран. Стойност с букви вътре (BG…) или гол ЕИК без представка за тип е кандидат за отказ още на портала — по-лесно е да се види в списък, отколкото ред по ред.
Другата половина на съобщението: MasterFiles
Забележете какво още казва текстът на грешката: „…или са подадени идентификатори за клиент/доставчик, който не фигурира в секция 2. MasterFiles, елемент MF.C.3/ MF.S.3“. Идентификаторът не е само формат — той е и референция. Всеки CustomerID или SupplierID, използван в записите на GeneralLedgerEntries, трябва да съществува дословно като контрагент в MasterFiles:
<!-- MasterFiles: контрагентът е деклариран веднъж --> <nsSAFT:Customer> ... <nsSAFT:CustomerID>10104104104</nsSAFT:CustomerID> ... </nsSAFT:Customer> <!-- GeneralLedgerEntries: записът го реферира със СЪЩАТА стойност --> <nsSAFT:TransactionLine> ... <nsSAFT:CustomerID>10104104104</nsSAFT:CustomerID> ... </nsSAFT:TransactionLine>
Затова форматната грешка често се проявява двойно: ако в MasterFiles контрагентът е с 10104104104, а в записите стои голото 104104104, двете стойности не съвпадат и записът сочи към „несъществуващ“ контрагент. Класическият източник на разминаването — складовата и счетоводната програма с различни номенклатури — сме описали в речника на грешките.
CustomerID и SupplierID са просто текст до 35 знака — и 104104104, и 10BG104104104 са „валидни“ за схемата. Правилото „тип + номер, без префикс на държава“ се проверява чак от портала.Какво хваща валидаторът предварително
SAFTCheck прави кръстосана проверка на референциите: всеки CustomerID/SupplierID, реферирани в записите, се търси в MasterFiles. Несъвпадение — включително от разминал се формат между двете секции — се показва като несъвпадаща референция, преди файлът да стигне до портала. Проверката е в браузъра; файлът не се качва никъде.
Пуснете файла — валидаторът сверява всички референции срещу MasterFiles и показва кой идентификатор „виси“.
Източник: „Въпроси и отговори за SAF-T“, ЦУ на НАП, версия 2 — въпрос IV.2.4 (страница на обявата в nra.bg). Съобщенията за грешка са цитирани дословно; типовете и дължините на елементите — по XSD схемата (Приложение №1).