Готовност: какво да извадим от системата

Готовността за SAF-T е способността организацията да произведе предвидимо, регулярно и защитимо подаване, което издържа на валидиране и контролни съпоставки. В практиката това не е "да имаме XML", а да имаме контролируем път от счетоводните регистри към структурирани данни, със стабилни ключове, нормализирани номенклатури, еднозначни мапинги и повторяеми проверки. Именно затова темата "какво да извадим от системата" е фундаментална: ако не извлечем правилния минимум на ниво ред, няма как да изведем връзките и няма как да построим одитната следа като данни.

От методологична гледна точка най-работещият подход е да мислим в два слоя. Първият слой е "минималният пакет", който осигурява структурните компоненти на месечния SAF-T и позволява базовите мостове за съгласуване. Вторият слой е "процесният модел", който превръща еднократното извличане в управляем цикъл: извличане, нормализиране, мапинг, проверки, файл, валидиране, подаване. Този модел е универсален и не зависи от ERP, а от дисциплината по данни и роли в организацията.

4.1. Минималният пакет: какво е "задължително да можем да извадим" и защо

Когато говорим за минимален пакет, не става дума за "всичко, което може да се изнесе". Става дума за тези извлеци, без които не можем да изградим структурния гръбнак на SAF-T и не можем да направим базовите контролни съпоставки "преди подаване". В книгата ви това е формулирано като минимален набор справки/извлеци и директно е свързано с това "къде отива" всяка справка в SAF-T структурата.

За да останем в портретен формат А4 и да избегнем широки таблици, минималният пакет е представен като карта "извлек→ къде отива", с два колони.

Таблица 4.1. Минимален пакет извлеци за SAF-T готовност: какво вадим и къде отива

Извлек/справка от системата Къде се използва в SAF-T и какъв проблем решава Сметкоплан MasterFiles → GeneralLedgerAccounts. Дава речника на AccountID и позволява журналът да бъде валиден като референции. Оборотна ведомост Контролни салда по сметки в рамките на GeneralLedgerAccounts (MasterFiles). Използва се като "контролен мост" към журнала и тоталите на периода. Журнал по редове (хронология на операции) GeneralLedgerEntries (транзакции и редове). Това е транзакционният слой, който прави възможни връзките документ↔осчетоводяване. ДДС дневници SourceDocuments → SalesInvoices и PurchaseInvoices (данъчните атрибути на документите). Използват се за съгласуване на данъчната логика и кодовете. Регистър фактури (продажби/покупки) SourceDocuments → SalesInvoices и PurchaseInvoices (документ + редове + данъци). Осигурява документния слой, който "обяснява" журнала. Плащания (регистър/хронология) SourceDocuments → Payments. Дава платежния слой и позволява затваряне на следата разчети↔плащания. Контрагенти MasterFiles → Customers и Suppliers (включително атрибути за идентификация/адреси). Осигурява речника на "кой", за да има референтна цялост.

Тази карта изглежда "счетоводно позната", но при SAF-T тя има по-строг смисъл. В обичайния месечен процес ние можем да приключим периода с коректни салда и да имаме фактури и плащания като документи, но да не разполагаме с чист журнал на ниво ред, с устойчиви ключове и с речници, които покриват 100% от участващите обекти. SAF-T прави този дефицит видим, защото документният слой и счетоводният слой трябва да се "срещнат" в данните, не в обясненията.

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

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

4.1.1. Сметкоплан: речникът на AccountID, без който журналът е "нечетим"

Сметкопланът в контекста на SAF-T не е "таблица с наименования". Той е речник на AccountID, който трябва да бъде устойчив във времето и еднозначен. Това е пряко свързано с принципа "една сметка = един устойчив код": ако в журнала се появи AccountID, който липсва или е "прекръстен" без мапинг спрямо MasterFiles, референтната цялост се нарушава и файлът става проблемен.

Таблица 4.2. Паспорт на извличане "Сметкоплан"

 

Параметър Съдържание и практичен смисъл Какво извличаме Списък на сметките с устойчиви AccountID и основни атрибути (описание, тип, статус), така че да може да се дефинира MasterFiles/GeneralLedgerAccounts. Защо е критично Журналът (GeneralLedgerEntries) използва AccountID. Ако AccountID в журнала не съществуват в речника или са нестабилни, нарушаваме референтната цялост. Типичен дефект В системата има сметка "401A", но в речника е изнесена като "401-A" или липсва поради "прекръщаване" без правила. Това създава структурно несъответствие между слой "операции" и слой "номенклатури". Минимална вътрешна защита Процес за промяна на сметки и верификация на сметкоплана, така че всяка промяна да има мапинг към предходния код или ясно правило за непрекъснатост.

Тук е важно да се отбележи и един организационен детайл: сметкопланът е част от "master data". Масови промени в основните данни в хода на период (или след приключване) са високо рискови, защото променят идентичностите, върху които се крепят връзките документ–операция. В SAF-T това не е абстракция: ако променим ключовете, променяме начина, по който системата "разказва" историята на периода.

4.1.2. Оборотна ведомост: контролният мост към "истината на периода"

Оборотната ведомост е счетоводният инструмент, който дава бърза увереност, че периодът е "затворен" като салда и обороти. В SAF-T тя не се подава като отделен отчет, но служи като контролна рамка: контролни салда по сметки могат да се подадат в MasterFiles (GeneralLedgerAccounts), а вътрешно ОВ се използва за съпоставка срещу агрегата на журнала и срещу тоталите на документния слой.

Таблица 4.3. Паспорт на извличане "Оборотна ведомост"

Параметър Съдържание и практичен смисъл Какво извличаме Обороти и салда по сметки за периода (начални салда, обороти дебит/кредит, крайни салда), съгласно счетоводната политика на предприятието. Защо е критично ОВ е "счетоводният контролен тотал". Ако агрегатът на журнала не възстановява ОВ, проблемът е или в извличането, или в логиката на трансформацията. Къде "живее" в SAF-T Като контролни салда по сметки в рамките на MasterFiles/GeneralLedgerAccounts (контролен слой за сметки). Типичен дефект "ОВ е вярна", но журналът по редове, извлечен за SAF-T, е непълен (например липсват определени типове операции или има филтър по журнал), което прави невъзможно възстановяването на тоталите. Минимална вътрешна защита Съпоставка ОВ↔агрегат на журнал по сметки като част от контролния пакет преди подаване (това е основен мост в следващия раздел).

Оборотната ведомост е особено полезна и по още една причина: тя помага да се "закове" какво означава "истината на периода" при корекции. В SAF-T корекцията е нова версия на целия файл за периода, а редовна е последната приета версия; следователно организацията трябва да знае коя ОВ стои зад последната версия и как се е променила спрямо предходната, ако има промяна.

4.1.3. Журнал по редове: транзакционната хронология, без която няма "връзки"

Тук е най-голямата практическа разлика между "имаме счетоводство" и "имаме SAF-T готовност". Журналът за SAF-T не е просто списък от операции, а износ на транзакции и редове, така че да може да се проследи връзката между осчетоводяването и документния слой. В книгата този извлек е назован като "хронология на операции (General Ledger Journal)" и е пряко свързан със секцията GeneralLedgerEntries.

Таблица 4.4. Паспорт на извличане "Журнал по редове"

Параметър Съдържание и практичен смисъл Какво извличаме Транзакции и редове с идентификатор на транзакция, дати, сметки (AccountID), суми, описание и при възможност референции към документ/основание. Защо е критично Това е единственият слой, който позволява да се изгради одитна следа "как документът се превръща в счетоводен запис" като данни, а не като разказ. Къде "живее" в SAF-T GeneralLedgerEntries (транзакции и TransactionLine). Типичен дефект Нестабилни ключове (TransactionID), които се променят при повторен експорт; това прави невъзможно проследяване между версии и затруднява връзката към документи. Одитна следа при късно открита счетоводна грешка В SAF-T може да се вижда разлика между SystemEntryDate и GLPostingDate: кога е въведено и към кой период е отнесено. Това не е "дребен детайл", а механизъм да се управлява корекцията като видима следа в данните.

Една особеност, която често спестява бъдещи проблеми, е да се реши рано какво означава "идентификатор на транзакция" във вашата система и дали е стабилен при повторяемо извличане. Ако TransactionID се генерира "в движение" при експорт, а не е вътрешен ключ на ERP, при корекции в рамките на срока и при повторно подаване ще получавате една и съща операция с различни ключове, което разрушава проследимостта. Това е типичен пример как чисто технологично решение (генериране на ключ при експорт) произвежда счетоводно-контролен риск.

4.1.4. ДДС дневници и регистър фактури: документният слой и данъчната логика като "кодове"

В минималния пакет поставяме едновременно ДДС дневниците и регистъра на фактурите, защото в практиката те се допълват. ДДС дневниците са "данъчният прочит" на документите, а регистърът фактури е "документният прочит" с номера, редове и детайли. В SAF-T и двете линии "отиват" в SourceDocuments (SalesInvoices и PurchaseInvoices), като данъчната логика трябва да се прояви чрез кодове по номенклатура, а не чрез свободни текстове.

Таблица 4.5. Паспорт на извличане "Регистър фактури"

Параметър Съдържание и практичен смисъл Какво извличаме Фактури продажби и покупки с уникален номер/дата/тип, контрагентен ключ, стойности, данъчна основа и данък, плюс редове (InvoiceLine) според възможностите на системата. Защо е критично SourceDocuments е "реалността на документа" като данни. Журналът може да даде суми, но документният слой дава основание, данъчна логика и редови детайл. Типични дефекти Дубли на документни референции в периода (номер/тип/дата), което изкривява тоталите и води до несъответствия; несъответствие между стойностите в документния слой и осчетоводяването. Минимална вътрешна защита Тест за уникалност на документите и мост "фактура↔GL" по стойност/дата, поне на извадка и на агрегат.

Таблица 4.6. Паспорт на извличане "ДДС дневници"

Параметър Съдържание и практичен смисъл Какво извличаме Продажби и покупки по ЗДДС в данъчната им структура: данъчна основа, данък, данъчен режим и кодове, които трябва да бъдат съпоставими и стабилни. Защо е критично Данъчната логика в SAF-T се чете чрез кодове (TaxType/TaxCode), не чрез текст. Ако дневникът работи с вътрешни текстове/описания, необходим е мапинг към номенклатура. Къде "живее" в SAF-T Данъчните атрибути се материализират в SalesInvoices/PurchaseInvoices (TaxInformation по редове) и се поддържат чрез MasterFiles/TaxTable. Типичен дефект В системата има "20% ДДС" като текст или вътрешен код без съпоставка към номенклатура; в резултат данните са несъпоставими и дават логически несъответствия при проверка.

Тук принципът "кодове, не имена" престава да е лозунг и става измерима работа: списъкът на използваните TaxCode стойности за периода трябва да бъде 100% съпоставим към кодовата номенклатура и да се поддържа като речник и мапинг таблица. В материалите от обученията това е представено като критерий за качество на данните и като минимален праг за контрол.

4.1.5. Плащания: от "банков ред" към проследима разчетна логика

Плащанията са част от минималния пакет не защото "без тях няма SAF-T", а защото без тях няма затваряне на разчетната история. В SAF-T плащанията се подават в SourceDocuments/Payments и те са естественият мост между разчетите и реалното уреждане. В книгата това е изведено като "хронология на плащанията (Payments register)" и е директно привързано към секцията Payments.

Таблица 4.7. Паспорт на извличане "Плащания"

Параметър Съдържание и практичен смисъл Какво извличаме Платежни записи (банка/каса) с дата, сума, валута, контрагент (ако е наличен), механизъм на плащане по номенклатура, и възможна референция към документ/основание. Защо е критично Без платежен слой разчетите са "отворени" като данни; при контрол се вижда счетоводната сума, но не се вижда затварянето на задължението/вземането. Къде "живее" в SAF-T SourceDocuments/Payments. Типичен дефект Плащания без връзка към контрагент и без документ/основание, което оставя платежните записи "изолирани" и затруднява съпоставките. В тематичните материали това е разгледано като нужда от обогатяване на плащанията и правила за връзки. Минимална вътрешна защита Форматни проверки (IBAN, ISO кодове) и вътрешна политика кога плащането трябва да носи референция към документ, ако системата позволява.

Една неутрална, но показателна ситуация е следната: в счетоводството задължението към доставчик е закрито чрез плащане, но платежният модул не съхранява връзка към фактурата и плащането остава просто "банков ред". В традиционна проверка това се обяснява с извлечение и разнос. В SAF-T подходът е различен: ако имаме възможност да поддържаме референции, те трябва да се използват; ако нямаме, трябва да има ясна политика как платежните записи се обогатяват или как се доказва връзката чрез други полета и мостове. Именно това е част от готовността и то стъпва върху процеса "извличане → нормализиране → мапинг → проверки".

4.1.6. Контрагенти: "едно лице = една карта" като техническо условие за валидируемост

Контрагентите са класическият пример за това как счетоводната практика "може да работи" вътрешно, но да бъде слаба като данни. В SAF-T контрагентът е речников обект в MasterFiles (Customers/Suppliers) и всяка фактура и всяко плащане го реферират чрез идентификатор. Ако има дубли или несъответствия, разчетите и връзките стават трудно интерпретируеми и рискът от несъответствия расте. Тематичните материали го формулират като принцип "едно лице = една карта" и дават типичен дефект: един и същ доставчик да бъде дублиран с различни SupplierID.

Таблица 4.8. Паспорт на извличане "Контрагенти"

Параметър Съдържание и практичен смисъл Какво извличаме Мастер данни за клиенти и доставчици: вътрешен идентификатор, име, данъчна регистрация (ЕИК/ДДС №), адреси, държава (ISO), и при нужда аналитична сметка/салда. Защо е критично Customers/Suppliers са "котвата" за документите и плащанията. Ако котвата е нестабилна (дубли/непълнота), документният и платежният слой не се връзват надеждно. Типичен дефект Един ЕИК има два SupplierID, защото доставчикът е въведен два пъти (на различни имена/адреси). Разчетите се "разцепват" и връзките документ–операция стават двусмислени. Минимална вътрешна защита Дедупликация по ЕИК/ДДС № + правила за имена/адреси и 100% покритие: всички контрагенти от фактури/плащания да присъстват в MasterFiles.

Тук готовността става управленска тема: ако няма собственик на мастер данните и правила за "сливане/разделяне", всяка корекция на данни (дори добронамерена) може да промени идентичностите и да произведе несъответствия между периоди и версии на файла. В тематичните материали това е отделено като сценарий "масови промени в основни данни" и е свързано с риск за връзките документ–операция.

4.2. Работен модел: извличане → нормализиране → мапинг → проверки → файл → валидиране → подаване

След като минималният пакет е ясен, остава въпросът "как точно се превръща в SAF-T". Тук най-важното е да не превръщаме темата в ИТ проект "генериране на XML", защото практическата причина за отхвърлянията почти винаги е по-дълбока: данните съществуват, но не са организирани като система от стабилни идентификатори, речници и връзки. Тази теза присъства като централен увод в универсалната карта за готовност и обяснява защо редът на стъпките е критичен: данни → връзки → проверки → версии.

Работният модел по-долу е представен като процесна карта в портретен формат. Той не е "контролен списък", а логика на трансформацията: какво е целта на всяка стъпка, какъв е минималният артефакт и какво означава "готово", за да преминем към следващата.

Таблица 4.9. Процесна карта на работния модел

Стъпка Същност, минимален резултат и счетоводен смисъл Извличане Изваждаме минималния пакет на ниво, на което са възможни връзки: речници (сметкоплан, контрагенти), транзакции и редове (журнал), документи и редове (фактури), плащания. Минималният резултат е суров набор извлеци, който е повторяем по период. Нормализиране Превръщаме данните в единни, устойчиви представяния: премахване на дублираните контрагенти (дедуп на контрагенти), стабилизиране на AccountID, унифициране на мерни единици, формати за дати/IBAN/ISO кодове. Резултатът е "златни записи" и правила за ключове. Мапинг Свързваме вътрешните кодове с външните номенклатури и с изискванията на схемата: TaxType/TaxCode, типове документи, методи на плащане, класификации (вкл. NC8 при приложимост). Резултатът е мапинг таблици + кратки политики. Проверки Строим контролни мостове и структурни проверки: уникалност на фактури, пълнота на мастер данни, съвпадение на документ↔GL по стойност/дата, форматни тестове (IBAN/ISO), тестове за използвани данъчни кодове. Резултатът е контролен пакет "преди подаване". Файл Генерираме SAF-T XML за периода като "пълна снимка" на слоевете според режима. Резултатът е файл, който носи информация за версията (кой/кога/защо). Валидиране Валидираме файла към XSD и към логически проверки; произвеждаме четим списък "грешка – поле – запис/ключ", който ускорява корекциите и обучението. Резултатът е стабилен цикъл за поправка, а не ръчно търсене. Подаване Подаваме по е-услуга, управляваме статуси (приет/отхвърлен) и спазваме режима на версии: корекцията е нов пълен файл, последният приет е редовен. Резултатът е предвидим месечен процес вместо поредица от кризисни повторения.

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

4.2.1. Извличането като инженеринг на "правилното ниво на детайлност"

В практиката извличането почти винаги е първата точка, на която се губи бъдещата проследимост. Причината е, че счетоводните системи позволяват много видове справки, но не всички са годни за SAF-T логиката "транзакции и редове". Затова минималният пакет трябва да бъде извеждан в режим, който запазва първичните ключове: вътрешни ID на контрагент, вътрешни кодове на сметки и документи, номера и типове на документи, и ако е възможно – връзки между документ и счетоводна операция. Това не е "лукс", а условие мостовете да бъдат построени без ръчно тълкуване.

4.2.2. Нормализиране: защо "почистването" не е козметика, а контрол на идентичности

Нормализирането често се подценява, защото изглежда като техническо изчистване. В SAF-T то е контрол на идентичности. Ако контрагентите имат дубли по ЕИК/ДДС №, ние имаме две истории за едно лице. Ако мерните единици са паралелни ("бр." и "pcs"), количествената история е шумна. Ако AccountID е нестабилен, операциите сочат към сметки, които "се сменят" като кодове. Тематичният лист за структурирани данни дава именно такива типични дефекти и ги свързва директно с нарушаване на референтната цялост.

В този смисъл нормализирането създава "златни записи" (golden records): за юридическо лице има една карта, за сметка има един код, за данъчен код има една дефиниция и една съпоставка. Това е моментът, в който организацията трябва да реши кой е източникът на истина за всяка номенклатура и кой е собственикът на промяната. Практическата пътна карта за готовност поставя именно това като ранна стъпка: инвентаризация на речници и източници, следвана от нормализация и дедупликация.

4.2.3. Мапинг: преводът между вътрешните кодове и официалните номенклатури

Мапингът е точката, в която счетоводството и данъчната функция трябва да говорят в кодове. Това е директно следствие от принципа "кодове, не имена" и от факта, че данъчните режими и елементи в SAF-T работят с номенклатури, а не със свободни описания. Когато вътрешната система е работила с текстови означения или локални кодове, мапингът не е "превод за красота", а логика за валидируемост. В оценъчните карти за качество на данните това се формулира като тест: списъкът на използваните данъчни кодове трябва да бъде 100% съответстващ на кодовия речник, подкрепен от мапинг таблица.

Има един особено полезен организационен принцип: мапинг таблиците трябва да се управляват като версии. Външните речници (например номенклатури и класификации) имат версии и актуализации; ако организацията няма процедура за обновяване и лог на промени, тя рискува да генерира файл с остаряла или несъгласувана кодова база. В тематичните материали това е изведено като отделен елемент на минималната дисциплина "преди подаване": външните речници се обновяват и има лог на актуализация.

4.2.4. Проверки: защо "контролният пакет" е част от готовността, а не отделна тема

Следващият раздел в навигацията ви е посветен изцяло на проверки и мостове, но в раздел 4 е важно да се каже едно предварително изречение: готовността не е налице, ако не можем да произведем контролен пакет, който да открива типичните дефекти преди подаване. Това е пряко следствие от процесната строгост: след приемане се извършват валидации и при несъответствия файлът се отхвърля; следователно предвидимостта на месечния процес зависи от това дали дефектите се хващат "вътре", а не "отвън".

Тематичните материали за качество на данните формулират точно такива базови проверки като критерии: уникалност на фактурите, консистентност документ - осчетоводяване, пълнота на контрагенти в MasterFiles, данъчни кодове като кодове по номенклатура, а не свободен текст, и форматни проверки за IBAN/ISO.

4.3. Разширение на минималния пакет: защо понякога "минималното" практически изисква още два-три извлека

В реални внедрявания често се вижда следната закономерност: за да работи минималният пакет като мостова система, се оказва полезно (а понякога и неизбежно) да се извадят още няколко извлека, които не са "в списъка", но намаляват риска от двусмисленост. В книгата ви тези допълващи извлеци са посочени като естествени компоненти на готовността: данъчни кодове и ставки (TaxTable), мерни единици и продукти (UOM + Products), фирмени банкови сметки, салдова ведомост по контрагенти, а при нужда – аналитичности.

Това разширение е важно да се разбере правилно: не се увеличава обемът на работа "за спорта", а се намалява обемът на бъдещите обяснения и корекции. Когато имаме отделен речник на данъчните кодове и отделен речник на мерните единици/продуктите, ние ограничаваме свободните текстове, стабилизираме ключовете и правим контролите по-автоматизируеми.

Таблица 4.10. Допълващи извлеци, които често правят минималния пакет "работещ"

Извличане/справка Защо често е необходимо на практика Данъчни кодове и ставки Ако вътрешната система има локални данъчни кодове, без отделен речник и мапинг рискът от "кодове като текстове" е висок. Мерни единици и продукти Дори при услуги, UOM дисциплината намалява шум; при запаси и движения е критична. Това е част от системността на номенклатурите. Салдова ведомост по контрагенти Помага да се докаже, че Customers/Suppliers в MasterFiles покриват реалните разчети и че няма "скрити" контрагенти извън документния слой. Фирмени банкови сметки и банкови извлечения Подпомагат Payments като структурирани записи и позволяват форматни проверки (IBAN) и обяснимост на платежните потоци.

Раздел 4 (Готовност: какво да извадим от системата) може да се обобщи с една проверима дефиниция: организацията е готова на минимално ниво, когато може да извлече сметкоплан, ОВ, журнал по редове, ДДС дневници, регистър фактури, плащания и контрагенти по повторяем начин за всеки период и когато може да ги прекара през процес "извличане → нормализиране → мапинг → проверки → файл → валидиране → подаване", така че да произведе предвидима последна приета версия за периода.

В този смисъл "готовността" не е еднократна задача. Тя е организационен актив: речници, правила за промяна, мапинг таблици, контролен пакет и версияция. Ако тези елементи липсват, подаването неизбежно се превръща в серия от повторения и корекции; ако са налични, SAF-T става месечен процес, който се управлява спокойно, защото дефектите се хващат преди подаване, а не след отхвърляне.