Генетични дефекти на масовия БГ софтуер — Защо SAF-T ще бъде апокалипсис
Преди повече от 20 години един израелски архитект на ERP системи каза нещо, което днес звучи като пророчество: *"Многото аналитични признаци ще направят системата ви чуплива, неуправляема и непродаваема. По света такова нещо не се прави."*
Днес, през 2026 г., когато НАП бавно, но сигурно затяга примката със **SAF-T (Standard Audit File for Tax)**, българският софтуерен пазар е пред колапс. Не защото нямаме програмисти, а защото сме заложници на **„Навиците на Баба Яга"**.
https://github.com/katehonz/saf-t-bg/tree/main
---
## 0.1. Коя е „Баба Яга" в счетоводството?
Това не е конкретен човек. Това е **манталитетът** на „лелката консултант", която вярва, че софтуерът е цифрова тетрадка с безкрайни полета. Тя иска „Аналитичност 1" за името на шофьора, „Аналитичност 2" за номера на ремаркето и „Аналитичност 20" за това дали шефът е бил в добро настроение, когато е подписал фактурата.
**Генетичният дефект:** Масовият български счетоводен софтуер е проектиран като `flat table` (плоска таблица) с 20-30 текстови полета (`varchar`), наречени „Аналитичности". Те нямат релация, нямат валидация, нямат логика. Всеки от тези „свободни признаци" е просто текстово поле, в което може да се напише абсолютно всичко — от ЕИК номер до рецепта за баница.
Този архитектурен подход беше роден в началото на 2000-те, когато софтуерните компании слушаха не инженери, а „лелки консултанти". Резултатът е софтуер, който е **генетично неспособен** да произведе структуриран изход.
## 0.2. „Гъвкавостта на входа" — Мантрата на Баба Яга
Българските счетоводители са свикнали софтуерът да е „пластичен". Те казват на разработчика: *„Искам да мога да пиша каквото си поискам в това поле!"*. Програмистът, за да му е мирна главата, слага един `varchar(max)` или 20 свободни аналитични признака.
**Резултат:** В базата данни влиза „информационна помия". Един път там е име на шофьор, втори път е „спешно за утре", трети път е празно пространство или невалиден символ.
Тази „гъвкавост" се продаваше като предимство. Рекламите казваха: *„Нашият софтуер е напълно конфигурируем!"*. В действителност това означаваше: *„Нашият софтуер няма никаква вътрешна логика."*
## 0.3. „Смърт на изхода" — Когато SAF-T почука на вратата
Когато държавата (НАП) каже: *„Сега ни дай тази помия, но я подреди в XML по стандарт на ОИСР"*, настъпва **клинична смърт** за системата.
- **Липса на мапване:** Не можеш да автоматизираш изхода, защото нямаш логика на входа. Как ще преведеш „Аналитичност 7" към структурирания XML таг `<AnalysisID>`?
- **Валидационен ад:** XML схемата (XSD) очаква структура, а ти й подаваш „свободно съчинение". Всяко гърмене на валидатора за „латинска буква" или „невалиден формат" е директно следствие от това, че си позволил на входа да влиза всичко.
**Аксиомата е проста:**
> Гъвкавостта на входа е смъртната присъда на изхода.
SAF-T не е просто отчет. Това е **релационен извлечен модел**. Той изисква от изхода да излезе математически точна картина на бизнеса. Ако на входа си позволил „гъвкавост" (демек хаос), на изхода получаваш **невалиден файл**. А невалидният файл в очите на НАП е равен на **глоба**.
## 0.4. Юридически хватки срещу технически изисквания
В момента масовката от софтуерни компании пращат хора на платени семинари. Там юристи и номенклатурчици от НАП обясняват глобите.
**Проблемът:** Юристът не може да ти обясни как да мапнеш хаоса от „Аналитичност 7" към структурирания XML таг `<AnalysisID>`. Когато софтуерът ти е строен върху пясък, никаква „юридическа консултация" не може да го направи стабилен.
**SAF-T е технически стандарт, а не философско есе.**
SAF-T изисква строга йерархия: **MasterFiles** (основни данни) и **GeneralLedgerEntries** (записи в главната книга).
- **В нормалния свят:** Използва се минималистичен подход — Контрагенти, Артикули, ДМА. Всичко е свързано с уникални ключове (ID).
- **В света на Баба Яга:** Подават се нулеви файлове, защото при реални данни системата „гърми". Валидаторът на НАП отхвърля файлове заради една латинска буква, защото софтуерът не сравнява ЕИК, а прави примитивно сравнение на текст.
## 0.5. Отсрочката — „Потьомкинско село"
Това, че в момента само няколкостотин фирми на големите международни ERP системи подават данни (и то често нулеви), е само димна завеса. Отсрочката е дадена, за да може „масовката" да разбере как да превърне каруцата си в космически кораб.
**Спойлер:** Няма да успеят с „кръпки". Не можеш да закърпиш архитектурен дефект с ъпдейт. Не можеш да добавиш релационна цялост в система, която е проектирана без нея. Не можеш да строиш XML йерархия върху плоска таблица.
## 0.6. Предупреждение към собствениците на фирми
> *„Когато купувате или разработвате софтуер, не търсете такъв, който ви позволява да правите всичко. Търсете такъв, който ви принуждава да правите нещата правилно. Защото **гъвкавостта на входа**, с която са свикнали вашите счетоводители днес, ще бъде **смъртната присъда** на вашата фирма утре, когато софтуерът на НАП откаже да приеме дигиталния ви хаос."*
## 0.7. Заключение: Време е за ампутация
Единственият начин да оцелеете в ерата на SAF-T е **минимализмът**:
1. Изхвърлете 20-те аналитичности. Заменете ги с релационни връзки.
2. Спрете да слушате юристи за технически проблеми.
3. Изисквайте от софтуера си валидация на входа, а не „свобода".
4. Подредете мастър данните си **сега**, преди да дойде крайният срок.
SAF-T не е заплаха, а **огледало**. И това, което виждаме в него, е **20-годишно закъснение** в архитектурното мислене на масовия български счетоводен софтуер.
Следващите глави на тази книга ще ви покажат как изглежда **правилният подход** — с код, с примери и без илюзии.