Анатомия на едно съобщение
Типична XSD грешка изглежда така:
file.xml:1542:38: cvc-complex-type.2.4.a: Invalid content was found
starting with element 'nsSAFT:TransactionDate'.
One of '{...:Period, ...:PeriodYear}' is expected.Четири части, винаги в този ред:
- Ред и колона (
1542:38) — къде във файла валидаторът се е спънал. Внимание: това е мястото, където проблемът е забелязан, не непременно където е причинен — при липсващ елемент валидаторът се спъва в следващия. - Код (
cvc-complex-type.2.4.a) — типът на нарушението. „cvc“ значи „component validation constraint“ — правило от схемата. - Елементът (
nsSAFT:TransactionDate) — за кой таг става дума. - Очакването (
One of '{...}' is expected) — какво схемата е искала да види на това място. Това е най-полезната част от съобщението.
cvc-complex-type.2.4.a — грешен ред или липсващ елемент
Най-честият код в SAF-T практиката. Значи: на тази позиция се появи елемент, който схемата не очаква. Причината е една от две — липсва задължителен елемент (и валидаторът среща следващия) или елементите са разместени, защото SAF-T изисква строга последователност.
cvc-complex-type.2.4.a: Invalid content was found starting with
element 'nsSAFT:TransactionDate'. One of '{...:PeriodYear}' is expected.Прочит: срещнат е TransactionDate, а се очаква PeriodYear. Тоест в транзакцията PeriodYear липсва или е след TransactionDate, вместо преди него. Поправя се в софтуера-източник — почти винаги една системна причина генерира десетки еднакви грешки (повече в речника).
cvc-complex-type.2.4.b — непълно съдържание
Огледалният случай: елементът е отворен и затворен, но вътре липсва задължително дете.
cvc-complex-type.2.4.b: The content of element 'nsSAFT:Invoice'
is not complete. One of '{...:InvoiceLine}' is expected.Прочит: има <nsSAFT:Invoice> без нито един <nsSAFT:InvoiceLine> — фактура без редове. Типично се случва, когато експортът изпуска редовете на празни или сторнирани документи (повече в речника).
cvc-datatype-valid — стойност в грешен формат
Стойността не отговаря на типа данни на елемента: дата, която не е дата, число, което не е число.
cvc-datatype-valid.1.2.1: '31.01.2026' is not a valid value for 'date'.Класиката: българският формат 31.01.2026 вместо изисквания ISO формат 2026-01-31, или сума с десетична запетая (1234,56) вместо точка (1234.56). Причината почти винаги е локализацията на експорта (повече в речника).
cvc-enumeration-valid — стойност извън списъка
Елементът приема само изброени стойности, а вашата не е сред тях.
cvc-enumeration-valid: Value 'BGN' is not facet-valid with respect
to enumeration '[EUR]'. It must be a value from the enumeration.Прочит: в DefaultCurrencyCode е подадено BGN, а схемата допуска само EUR. Квадратните скоби изброяват всички позволени стойности — при номенклатурните полета това е директно списъкът, с който трябва да се съобразите (повече в речника).
Сроден код е cvc-pattern-valid — стойността не пасва на шаблон (регулярен израз). Пример: AccountID е ограничен с шаблона [1-9][0-9]{2,4} — от 3 до 5 цифри, без водеща нула. Сметка 0501 ще предизвика точно тази грешка.
Защо грешките са стотици, а причината — една
XSD валидаторът не спира на първата грешка — той продължава и докладва всичко. Затова един файл с една-единствена системна грешка в експорта (например дати в грешен формат) връща стотици привидно различни съобщения: по едно за всяка фактура. Преди да изпаднете в паника от бройката, групирайте съобщенията по код и по име на елемент. Ако 380 от 400 грешки са cvc-datatype-valid върху nsSAFT:InvoiceDate, това не са 380 проблема — това е една настройка. Обратното също важи: две грешки с различни кодове върху различни елементи са два отделни проблема и се решават поотделно.
От съобщението до елемента: работен ред
- Извадете името на елемента от съобщението и махнете префикса:
nsSAFT:TaxPointDate→TaxPointDate. - Намерете го в справочника — там пише какъв тип приема, задължителен ли е, каква е максималната дължина и на кои места в дървото се среща. Така разбирате какво точно е очаквала схемата.
- Отворете реда от съобщението в текстов редактор, който показва номера на редове (Notepad++ например), и сравнете реалното съдържание с очакваното.
- Търсете системната причина, не симптома. 400 еднакви грешки на различни редове са една грешка в настройката на експорта. Поправете я в счетоводния софтуер и регенерирайте файла — не редактирайте XML-а на ръка.
И едно предупреждение: XSD проверката е само първото сито. Файл, който минава схемата, пак може да бъде отхвърлен заради салда, суми или референции — тези проверки схемата не прави (логическите грешки в речника).
Проверката на SAFTCheck показва всяка XSD грешка с ред, обяснение на български и съвет за поправка. Файлът не напуска компютъра ви.
Бележка: примерите са илюстративни, съставени по формата на стандартните cvc-* съобщения на XSD валидаторите (Xerces) и по официалната XSD схема на НАП — ограниченията на DefaultCurrencyCode и AccountID са от справочника на елементите.