GeneralLedgerEntries - счетоводните записи

Три нива, не едно

GeneralLedgerEntries е самото счетоводство - но структурирано на три вложени нива: Journal (дневник) съдържа Transactions (счетоводни операции), а всяка операция съдържа TransactionLines (счетоводни редове - дебит/кредит записите). Повечето капани в тази секция идват от объркване на кое ниво трябва да живее коя информация.

CustomerID и SupplierID на две нива едновременно

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

Дебит и кредит - взаимно изключващи се, не двойка

Всеки ред е или дебитен, или кредитен - никога и двете. Ако редът е дебитен, CreditAmount отсъства напълно от реда - не се пише "0.00". Схемата ги моделира като истински xs:choice - същият принцип, който видяхме за началните салда в MasterFiles (глава 4), се повтаря тук на ниво отделен ред.

Сумите не са голи числа - AmountStructure

DebitAmount, CreditAmount, TaxAmount и останалите парични полета в GLE не са прости десетични числа - всяко от тях е цял контейнер, AmountStructure.

AccountID срещу TaxpayerAccountID - кой код е чий

Ред от транзакцията може да носи и двете полета едновременно, и това е нормално - те описват различни неща:

• AccountID - кодът по номенклатурата на НАП (сметкопланa, съпоставен при мапирането - виж глава 7).
• TaxpayerAccountID - вашият вътрешен номер на сметката, както е в собствената ви счетоводна програма, преди мапиране.

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

Идентификаторите тук следват същите префиксни правила

Полетата CustomerID/SupplierID в GLE следват абсолютно същата префиксна система, разгледана подробно в глава 7 (10=ЕИК, 11=VIES ДДС номер, 13=ЕГН и т.н.), включително изискването за валиден код на държавата при чуждестранни контрагенти. Ако използвате софтуер, който проверява или коригира тези кодове автоматично (какъвто е случаят с Magi), проверката важи еднакво тук и в MasterFiles - но ако не сте сигурни дали инструментът ви прави това, проверете идентификаторите ръчно и тук, не само в MasterFiles.

Корекция на грешка от миналия период - две различни дати

Ако откриете грешка от предходен период и я коригирате сега, записът носи две отделни дати, не една:

• SystemEntryDate - днешната дата, когато реално въвеждате корекцията в системата.
• GLPostingDate - датата от периода, за който се отнася грешката (миналия месец, не днешния).

<nsSAFT:Period>12</nsSAFT:Period>
<nsSAFT:PeriodYear>2025</nsSAFT:PeriodYear>
<nsSAFT:TransactionDate>2026-02-15</nsSAFT:TransactionDate>
<nsSAFT:SystemEntryDate>2026-02-20</nsSAFT:SystemEntryDate>
<nsSAFT:GLPostingDate>2025-12-31</nsSAFT:GLPostingDate>

Забележете, че Period/PeriodYear следват GLPostingDate (декември 2025), не датата, на която реално въвеждате записа.

TaxInformation - данъчният код на всеки ред

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

Как да проверите себе си преди подаване

• Всеки ред има CustomerID/SupplierID на транзакционно И редово ниво - и правилната комбинация от трите сценария (само клиент / само доставчик / никой от двата).
• Всеки ред е или дебитен, или кредитен - никога и двете, никога "0.00" за отсъстващото.
• Всяка парична стойност е пълен AmountStructure; за отчетната валута CurrencyAmount съвпада точно с Amount.
• Всеки ред носи TaxInformation - с реален код за 600/700 или с кодовете за неприложимост "000"/"000000" за всичко останало, никога липсващ елемент.
• Корекция от минал период разграничава SystemEntryDate (днес) от GLPostingDate (периода на грешката), а Period/PeriodYear следват GLPostingDate.

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

• Journal → Transaction → TransactionLine - три нива, всяко със собствени изисквания.
• CustomerID/SupplierID се подават на ниво транзакция И на ниво ред, не само на едното.
• Три различни сценария за контрагент: само клиент, само доставчик, или никой - последният получава идентификатора на подаващата фирма и на двете полета, не "0" и не празно.
• DebitAmount и CreditAmount са взаимно изключващи се на ниво ред (xs:choice) - отсъстващото поле не се пише с "0.00".
• Паричните полета са пълни AmountStructure контейнери (Amount + CurrencyCode + CurrencyAmount + ExchangeRate), не голи числа; за отчетната валута CurrencyAmount трябва да съвпада точно с Amount.
• AccountID (номенклатура на НАП) и TaxpayerAccountID (вътрешен код) са различни полета с различно предназначение, не дублиране.
• TaxInformation присъства на всеки ред без изключение - реален код 600/700 или кодове за неприложимост "000"/"000000", никога липсващ елемент.
• Корекция на грешка от минал период носи SystemEntryDate (днес) отделно от GLPostingDate (периода на грешката) - а Period/PeriodYear следват GLPostingDate.

Следващата глава е SourceDocuments - фактурите, плащанията и движението на стоки зад счетоводните записи.