Header - заглавната част на файла

Заглавната страница на файла - но не само

Header звучи като нещо формално и кратко - "заглавна информация". На практика е една от най-богатите на капани секции в целия SAF-T файл, точно защото съдържа данни, които рядко се актуализират в счетоводните програми (собственост на групата, действителни собственици, банкови сметки) - данни, които обикновено "просто стоят" някъде и никой не ги проверява редовно.

Header отвътре - картата на структурата

Преди да навлезем във всяко поле поотделно, ето картата на цялото Header - кои полета стоят direct под него, кои са прости стойности, кои водят към собствена подструктура и кои крият капан. Схемата долу показва и двете имена наведнъж - английското, каквото ще видите в самия файл или в съобщение за грешка, и практическото му значение на български.

TaxAccountingBasis и TaxEntity - какво всъщност декларират

Две от най-рано срещаните полета в Header звучат сходно на пръв поглед, но нямат нищо общо помежду си - и нито едно от двете не декларира вида на подаването (месечен / годишен / при поискване), въпреки че имената лесно карат да се предположи точно това.

• TaxAccountingBasis е задължително поле с точно четири валидни стойности - и описва типа на самото предприятие, не вида на файла:

Стойност	Значение
A	Обикновено търговско предприятие
P	Бюджетно предприятие
BANK	Банка
INSURANCE	Застраховател

За обикновена търговска фирма стойността е практически винаги A. Стойностите BANK и INSURANCE се свързват с особените правила за банкова и застрахователна тайна, разгледани в глава 9.

• TaxEntity е незадължително, свободен текст - идентификатор на конкретната фирма, подразделение или клон, който подава файла. Не е булева стойност "Individual" срещу "Group".

HeaderComment - истинското му предназначение

Тук идва истинската изненада: полето, което най-логично звучи като свободен коментар (”HeaderComment” - буквално "коментар в заглавната част"), е точно мястото, където живее вида на подаването - месечен, годишен или при поискване.

<nsSAFT:HeaderComment>M</nsSAFT:HeaderComment>

Официалната документация на схемата описва съдържанието му изрично като "месечен / Monthly, годишен / annual или 'при поискване' / on demand" - буквите M, A и D, същите, които вече познавате от глава 2.

Company - фирмените данни, отвъд самото име

Секцията Company (структурата зад него се казва CompanyHeaderStructure) носи повече от име и ЕИК - адрес(и), данъчен номер, телефон, имейл, банкова сметка. Диаграмата по- долу показва цялата ѝ структура и накъде води всяко от полетата ѝ.

Едно нещо си струва изрично да отбележим: адресните полета следват модел, който ще срещнете многократно из схемата - структуриран адрес (улица, град, пощенски код, държава по ISO 3166) вместо един свободен текстов ред. Ако вашата счетоводна програма пази адреса като едно поле "гр. София, ул. Х №5", преди подаване той трябва да бъде разбит на отделните съставни елементи, не преписан наготово в едно от тях.

Адрес, контакти, лице за контакт, данъчна регистрация - четирите тухлички

Четири малки структури се появяват многократно из схемата с почти same имена на полета: AddressStructure, ContactHeaderStructure, PersonNameStructure и TaxIDStructure. Диаграмата показва и четирите наведнъж, защото на практика рядко крият изненади - с едно важно изключение.

Банкови сметки - IBAN е правилото, не изключението

За банкова сметка с валиден IBAN подавате само IBANNumber - AccountNumber и SortCode не се дублират до него; схемата ги моделира като взаимно изключващи се пътеки (xs:choice), не като независими опционални полета.

<nsSAFT:BankAccount>
  <nsSAFT:IBANNumber>BG80BNBG96611020345678</nsSAFT:IBANNumber>
</nsSAFT:BankAccount>

Ownership (в Header) срещу Owners (в MasterFiles) - НЕ е едно и също

Това е капанът номер едно в цялата схема, защото имената звучат идентично на български.

• Ownership, вътре в Header, е задължителна структура и описва корпоративна собственост - дали фирмата е част от група, кой е крайният собственик, кой е действителният собственик (УБО) на дружеството.
• Owners, вътре в MasterFiles, е незадължителна структура и няма нищо общо с групи или УБО - тя описва собственост върху материални запаси (кой е собственик на конкретна партида стоки, когато не е самата фирма - например консигнация).

Действителните собственици - може да са повече от един

Полетата за действителния собственик (BeneficialOwnerNameCyrillicBG, BeneficialOwnerEGN и др.) не са ограничени до един собственик - схемата изрично позволява неограничен брой повторения на всяко от тях. Забележете обаче как точно се повтарят - не като групирани по собственик "пакети", а като успоредни списъци, подредени по позиция:

<nsSAFT:Ownership>
  <nsSAFT:IsPartOfGroup>4</nsSAFT:IsPartOfGroup>

  <nsSAFT:BeneficialOwnerNameCyrillicBG>Иван Иванов</nsSAFT:BeneficialOwnerNameCyrillicBG>
  <nsSAFT:BeneficialOwnerNameCyrillicBG>Мария Петрова</nsSAFT:BeneficialOwnerNameCyrillicBG>
  <nsSAFT:BeneficialOwnerEGN>7501010010</nsSAFT:BeneficialOwnerEGN>
  <nsSAFT:BeneficialOwnerEGN>8002020020</nsSAFT:BeneficialOwnerEGN>

  <nsSAFT:UltimateOwnerNameCyrillicBG>00</nsSAFT:UltimateOwnerNameCyrillicBG>
  <nsSAFT:UltimateOwnerUICBG>00</nsSAFT:UltimateOwnerUICBG>
  <nsSAFT:UltimateOwnerNameCyrillicForeign>Acme Holding ГмбХ</nsSAFT:UltimateOwnerNameCyrillicForeign>
  <nsSAFT:UltimateOwnerNameLatinForeign>Acme Holding GmbH</nsSAFT:UltimateOwnerNameLatinForeign>
  <nsSAFT:CountryForeign>DE</nsSAFT:CountryForeign>
</nsSAFT:Ownership>

Примерът по-горе показва и защо ultimate-owner полетата не остават празни дори когато крайният собственик е чуждестранно юридическо лице: UltimateOwnerNameCyrillicBG и UltimateOwnerUICBG (българските варианти) получават "00", защото не съществува българско наименование/ЕИК за чуждестранна компания - но CountryForeign получава реалната държава (DE), никога "00" (вижте следващия раздел защо).

IsPartOfGroup - едно поле, което отваря врата към други

Полето IsPartOfGroup (Ownership) приема пет стойности:

Код	Значение
1	Централа на местна група
2	Централа на мултинационална група
3	Част от местна група
4	Част от мултинационална група
5	Не е част от група

Стойностите 3 и 4 задължително отварят допълнителни полета - името, идентификатора и държавата на крайния собственик на групата. Не са опционални "допълнителни данни" - те стават мандаторни точно защото сте декларирали, че сте част от група.

Стойността "00" - не е грешка, а правило

Ако фирмата декларира IsPartOfGroup = 5 (не е част от група), очаквате логично полето за крайния собственик (UltimateOwnerUICBG) да остане празно.

Същото правило важи и за действителния собственик (УБО): ако той е чуждестранно физическо лице, полето за българското име на собственика (BeneficialOwnerNameCyrillicBG) не остава празно и не се опитвате да транслитерирате чуждото име на кирилица насила - попълва се "00", защото не съществува българско име за човек, който никога не е имал такова.

SelectionCriteria - или дати, или периоди, никога и двете

Полето, което декларира отчетния период на файла, може да се попълни по два алтернативни начина - чрез двойка конкретни дати (начало/край) или чрез двойка номинирани периоди (месец/година).

<nsSAFT:SelectionCriteria>
  <nsSAFT:PeriodStart>6</nsSAFT:PeriodStart>
  <nsSAFT:PeriodStartYear>2026</nsSAFT:PeriodStartYear>
  <nsSAFT:PeriodEnd>6</nsSAFT:PeriodEnd>
  <nsSAFT:PeriodEndYear>2026</nsSAFT:PeriodEndYear>
</nsSAFT:SelectionCriteria>

Правилото е или-или: попълвате едната двойка, не и двете едновременно "за по- сигурно". Дублирането не прави файла по-валиден - обърква кръстосаната проверка.

Свързани лица - връзка, която може да свърши

RelatedParty маркира контрагент като свързано лице (например дъщерно дружество, собственик на дял). Особеното тук е времевото измерение: ако връзката приключи през годината (например продажба на дела), не просто изтривате маркировката - попълвате RelatedPartyEndDate, датата на прекратяване. Файлът пази история на връзката, не само текущото ѝ състояние.

Name / NameLatin - повтарящ се модел

В няколко различни структури (фирмата подател, банкови сметки, контрагенти) ще срещнете двойка полета: Name (кирилица) и NameLatin (латиница). Моделът е взаимозаменяем резерв - схемата ги представя като избор един от двата (xs:choice), не като две независими задължителни полета. Веднъж щом разпознаете този модел тук, ще го срещате многократно и в другите секции на схемата.

Какво да запомните от тази глава

• TaxAccountingBasis декларира типа на предприятието (A/P/BANK/INSURANCE), не вида на подаването - лесен за объркване с вида файл, но напълно различно поле.
• TaxEntity е свободен текст за клон/подразделение, не булева "Individual/Group" стойност - задължението за подаване принадлежи на цялото юридическо лице, не на всеки клон поотделно.
• HeaderComment е мястото, където реално живее видът на подаването (M/A/D) - въпреки подвеждащото си име, не е свободен коментар.
• Ownership (Header, задължителна, за групи/УБО) и Owners (MasterFiles, незадължителна, за материални запаси) са различни структури, въпреки сходните имена.
• Действителните собственици могат да са повече от един - полетата се повтарят като успоредни списъци, свързани само по позиция, не по изричен идентификатор.
• IsPartOfGroup = 3 или 4 отваря допълнителни задължителни полета за крайния собственик; CountryForeign никога не приема "00", дори когато другите полета го правят.
• "00" е валидна, изрична стойност за "няма приложимо" - не заменяйте с празно поле.
• Банкова сметка с IBAN подава само IBANNumber; AccountNumber/SortCode/AccountName са за случаи без IBAN - и подавате всички платежни сметки на фирмата, не само основната.
• SelectionCriteria е или дати, или периоди - никога и двете.
• RelatedParty носи времево измерение - прекратена връзка получава крайна дата, не се просто маха.
• ContactHeaderStructure (Header) е задължителна; почти идентичната ContactInformationStructure (MasterFiles) не е - едни и същи имена на полета, различни правила според контекста.

Следващата глава е MasterFiles - основните данни на бизнеса: сметкоплан, клиенти, доставчици, продукти и активи.