100% в браузъра · файлът никога не напуска компютъра ви · безплатно, без регистрация

Блог · технически

Как се чете XSD грешка

XSD валидаторите съобщават проблемите с криптични кодове от вида cvc-complex-type.2.4.a. Зад всеки код обаче стои един прост въпрос: кой елемент, какъв проблем, къде. Ето как се разчита съобщението — с реалистични SAF-T примери.

19 август 2026 · 6 мин четене

Анатомия на едно съобщение

Типична 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 проблема — това е една настройка. Обратното също важи: две грешки с различни кодове върху различни елементи са два отделни проблема и се решават поотделно.

От съобщението до елемента: работен ред

  1. Извадете името на елемента от съобщението и махнете префикса: nsSAFT:TaxPointDateTaxPointDate.
  2. Намерете го в справочника — там пише какъв тип приема, задължителен ли е, каква е максималната дължина и на кои места в дървото се среща. Така разбирате какво точно е очаквала схемата.
  3. Отворете реда от съобщението в текстов редактор, който показва номера на редове (Notepad++ например), и сравнете реалното съдържание с очакваното.
  4. Търсете системната причина, не симптома. 400 еднакви грешки на различни редове са една грешка в настройката на експорта. Поправете я в счетоводния софтуер и регенерирайте файла — не редактирайте XML-а на ръка.

И едно предупреждение: XSD проверката е само първото сито. Файл, който минава схемата, пак може да бъде отхвърлен заради салда, суми или референции — тези проверки схемата не прави (логическите грешки в речника).

Или оставете превода на нас

Проверката на SAFTCheck показва всяка XSD грешка с ред, обяснение на български и съвет за поправка. Файлът не напуска компютъра ви.

Провери файла

Бележка: примерите са илюстративни, съставени по формата на стандартните cvc-* съобщения на XSD валидаторите (Xerces) и по официалната XSD схема на НАП — ограниченията на DefaultCurrencyCode и AccountID са от справочника на елементите.