Чел съм надълбоко и нашироко за SAF-T и съм част от авангарда, който вече поема първите вълни на този проблем. Прегледал съм всички анализи, говорил съм и директно с одитори, включително от ИДЕС. И това, което постоянно откривам, не е просто незнание - а дълбока, системна слепота за мащаба на онова, което ни връхлита.

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

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

А дори там, където данните съществуват, идва вторият удар - мапирането. Говорим за 250 до 300 кода само за сметкоплана, които трябва да се съпоставят ръчно към една от общо 14-те номенклатури, които НАП изисква за SAF-T. А продуктовите номенклатури? Десетки, често стотици хиляди разнородни артикули, натрупани с години хаотично именуване, без никаква вътрешна логика за категоризация. Кой сяда да мапира ръчно стотици хиляди артикула? Никой няма капацитет за това - а без него SAF-T просто не може да излезе коректен.

А ето и частта, която наистина ме ужасява: хората, които би трябвало да разбират това - включително одитори - в огромната си част не го разбират. Става дума за ширеща се изчислителна неграмотност. Попитайте ги какво означава SAF-T на ниво модел на данните и ще получите празни погледи и плитки отговори. Те все още си представят, че става дума просто за по-голяма, по-лъскава справка. Не виждат смяната на парадигмата. И ако пазителите на финансовата истина не схващат проблема, как, за бога, се очаква бизнесът да се подготви?

 И като капак, в тази мъгла от неразбиране никнат вендори като гъби след дъжд. Току-що излюпени „решения“ никнат навсякъде, строени от хора, които нямат базово разбиране за счетоводна логика и които, смея да предположа, не са подавали декларация в НАП и пет пъти в живота си. Откъде точно знаят какво изобщо означава валидация? Тестовата среда на НАП е публична, да - но това не помага особено, защото всеки месец ни изненадва с нови грешки, нови проблеми, нова логика, която никой не е обявил. Работим по-голямата част ръчно, гоним движеща се мишена, докато тези вендори продават магически кутийки. Някакъв счетоводен софтуер вече покрива абсолютния минимум ред по ред и навързва общите суми, след което весело пакетира някакво „ERP решение“ и обявява, че всичко е наред. Това е повече от безумно. Напълно пренебрегва въпроса за междинния слой - онова измъчено пространство между изискването за SAF-T, ERP-то и реалната счетоводна логика - където всичко трябва да остане логически консистентно през множество точки с данни, нещо, което тези вендори очевидно никога не са решили. Те просто предполагат, че като вкараш инструмент, който работи ред по ред, кръстосаната логическа консистентност ще се получи от само себе си. Не се получава. Сложността се вдига до небеса, а невежеството, което стои зад това, е потресаващо.

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

Остава и НАП. От нас се изисква да изпратим безпрецедентен, колосален поток от гранулирани данни към институция, която никога не е трябвало да поглъща, валидира и осмисля нещо от този мащаб. Какво ще стане, когато потокът от данни се отприщи изцяло? Ще се удавят. Нямат надзорните системи, аналитичния капацитет, чисто преработвателната мощ да превърнат това цунами от данни в информирани действия. Ще бъдат парализирани,  ще останат блокирани, без да знаят откъде да започнат, докато бизнесът поема пълните разходи, рискове и вина. Това не е спекулация. Това е неизбежната физика на принудително изливане на данни върху неподготвен получател.

Няма да назовавам фирмата, в която работя, но е голяма - по-голяма от всеки популярен български счетоводен софтуер, който познавате, и работим с някои от тях за част от клиентите си, с огромно разочарование, трябва да добавя. Ние сме точно типът организация, от която бихте очаквали да има капацитет да се справи с това. И въпреки това все още не сме напълно готови. Правим го, и ще го правим, в по-голямата си част ръчно. Ако ние сме в това положение, какво остава за всички останали? Какво остава за бизнесите, които нямат ERP и им се казва, че трябва да си вземат, защото на хора, които дори не са решили кръстосаната логическа консистентност при себе си, им звучи просто? Те биват натикани в капан, маскиран като инструмент.

И ако сравните нашия SAF-T с този на други държави, ще видите, че нашият е далеч най-лошият. Изострен е до абсолютния максимум. Защо ни го причиняват? Ако целта е да ни дигитализират, ще ни дигитализират до изчезване.

Тази платформа се роди от петицията за SAF-T, но нека бъдем брутално честни: само подписите ще се провалят. Ако продължаваме както досега, инерцията тихо ще угасне някъде около 3 000 подписа - число, на което ти се изсмиват във всяка сериозна политическа дискусия. В нашата професия винаги сме смазани от срокове, с наведени глави, гасим пожари, без да вдигаме поглед, докато сградата вече гори. Особено на дати като 13-и и 14-и, когато напрежението връхлита, фрустрацията е задушаваща - но не можем да си позволим да останем вечно в тази реактивна схлупеност.

Ето моето предложение - и имам нужда от помощта на админите и на тази общност, за да го осъществим.

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

Пускаме тази анкета сред професионални групи, счетоводни общности, бизнес асоциации. Представяме я като неутрален инструмент за фактологично проучване - честно казано, кой би могъл да възрази срещу измерването на колективната готовност? Но в момента, в който агрегираните резултати излязат, вече няма връщане назад всички ще са видели истината. Всички ще видят, черно на бяло, пропастта между това, което се изисква, и това, което реално е възможно. Това споделено осъзнаване става невъзможно за игнориране и дава на тази платформа тежестта, от която се нуждае, за да бъде взета на сериозно.

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

Готов съм да помогна с изработването ѝ. Кой е с мен?

СТАНОВИЩЕ

на Българската асоциация на пощенските и фулфилмънт оператори в електронната търговия /БАПФОЕТ/

Относно: въвеждането на Стандартен одитен файл за данъчни цели (SAF-T), необходимостта от проверка и отстраняване на процедурния риск, свързан с липса на нотификация по Директива (ЕС) 2015/1535, и необходимостта от регулаторно опростяване на режимите за електронна търговия, онлайн услуги и малки предприятия.

I. Въведение

Българската асоциация на пощенските и фулфилмънт оператори в електронната търговия /БАПФОЕТ/ подкрепя целите за модернизация на данъчния контрол, дигитализация на отчетността и намаляване на сивия сектор. Въвеждането на SAF-T може да бъде полезен инструмент, ако бъде приложено с достатъчна правна сигурност, техническа предвидимост и реалистичен преходен период за бизнеса.

Същевременно последващият анализ на нормативната рамка показва, че темата не може да бъде разглеждана само като техническа подготовка на предприятията за подаване на XML файл. SAF-T засяга архитектурата на счетоводните, ERP, CRM, e-commerce, складовите и платежните системи. Поради това той има пряко отражение върху пазара на софтуерни услуги, международните облачни ERP системи, счетоводните къщи и малките предприятия.

В този контекст БАПФОЕТ счита, че преди започване на задължителното прилагане на режима е необходимо Министерството на финансите и НАП публично да изяснят дали проектите на националните разпоредби и техническите спецификации, свързани със SAF-T, са били нотифицирани по реда на Директива (ЕС) 2015/1535. Ако такава нотификация не е извършена, следва да бъдат предприети незабавни действия за отстраняване на процедурния риск и за гарантиране на правната сигурност за предприятията.

II. Нормативна и фактическа рамка

SAF-T е въведен в българското право чрез изменения в Данъчно-осигурителния процесуален кодекс, с които е създадена специална уредба за подаване на стандартен одитен файл за данъчни цели. На официалната страница на НАП са публикувани документи, свързани с формата и реда за подаване, включително XSD схема, структура, дефиниции, указания и примерни файлове.

От публичната информация следва, че от 1 януари 2026 г. първата група задължени лица ще започне да подава SAF-T в унифициран формат. НАП посочва, че около 460 дружества попадат в първия етап на задължението. В следващите години обхватът следва да се разширява към други категории предприятия.

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

III. Правен проблем: SAF-T като технически регламент по Директива (ЕС) 2015/1535

Директива (ЕС) 2015/1535 въвежда процедура за предоставяне на информация относно проектите на технически регламенти и правила относно услугите на информационното общество. Съгласно чл. 5, параграф 1 държавите членки предоставят на Европейската комисия проектите на технически регламенти преди тяхното приемане.

Според анализа на БАПФОЕТ изискванията за SAF-T имат белезите на технически регламент или най-малкото съдържат технически спецификации, които подлежат на проверка по Директива (ЕС) 2015/1535. Те определят задължителен машинночетим формат, XML/XSD структура, правила за валидиране, данъчни и бизнес номенклатури, ред за подаване и условия, при които файлът се приема или се счита за неподаден.

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

Особено важно е, че т.нар. фискално изключение по чл. 7, параграф 4 от Директива (ЕС) 2015/1535 не премахва задължението за нотификация по чл. 5. То освобождава единствено от прилагането на режима на изчакване по чл. 6 за определени фискални мерки. Следователно дори когато мярката има фискална цел, проектът следва да бъде съобщен на Европейската комисия, ако съдържа технически спецификации или правила за услуги.

IV. Значение на практиката на Съда на ЕС

Практиката на Съда на Европейския съюз потвърждава, че ненотифициран технически регламент не може да бъде противопоставян на частноправни субекти. Тази линия започва с делото CIA Security International (C-194/94) и е развита в последваща практика, включително Unilever Italia (C-443/98) и Sebat Ince (C-336/14).

Особено релевантно е решението по дело C-353/24, Europark Latvia and Skidata, в което Съдът приема, че национална норма, изискваща предоставяне на изходен код и изпълним код на регистриран софтуер във връзка с фискални технически изисквания, представлява технически регламент. Съдът подчертава, че такъв регламент може да бъде противопоставен на частноправни субекти само ако проектът е предварително съобщен на Европейската комисия по чл. 5, параграф 1 от Директива (ЕС) 2015/1535.

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

Този подход е особено важен за международни облачни ERP системи като Microsoft Dynamics 365 Business Central, SAP, Oracle NetSuite, Shopify, WooCommerce, Magento и други, при които националните технически изисквания влияят върху локализациите, разширенията, API интеграциите и пазара на софтуерни услуги.

V. Последици от липса на нотификация

Ако се потвърди, че проектите на разпоредбите и техническите спецификации за SAF-T не са били нотифицирани по реда на Директива (ЕС) 2015/1535, възникват няколко съществени правни последици.

Първо, възниква риск задължението за подаване на SAF-T в конкретния технически формат да не може да бъде противопоставяно на предприятията до отстраняване на нарушението. Това не означава отричане на целта на данъчния контрол, а поставя въпроса дали държавата е спазила задължителната процедура по правото на ЕС.

Второ, санкциите за не подаване, неподаден в срок или технически невалиден SAF-T файл биха били уязвими за съдебно оспорване, ако се основават на не нотифицирани технически изисквания.

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

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

Поради тези последици БАПФОЕТ счита, че въпросът следва да бъде разрешен преди режимът да започне да се прилага в санкционна и задължителна фаза.

VI. Специфично отражение върху малките предприятия, онлайн услугите и електронната търговия

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

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

При онлайн услугите проблемът е различен. Често няма физическа доставка, няма складово движение и няма наложен платеж, но има електронна заявка, електронно плащане, фактура и автоматизирано предоставяне на услуга. В тези случаи натрупването на SAF-T, Наредба № Н-18, режим за електронни магазини и СУПТО изисквания е непропорционално и трябва да бъде преразгледано.

БАПФОЕТ счита, че точно въвеждането на SAF-T следва да бъде използвано като повод за преминаване от контрол върху софтуера към контрол върху данните, тяхната проследимост, пълнота и качество.

VII. Наредба № Н-18, СУПТО и необходимостта от регулаторно опростяване

БАПФОЕТ поддържа позицията, че SAF-T не следва да се наслагва върху съществуващите режими без анализ на дублирането. След като НАП ще получава структурирани счетоводни, фактурни, платежни и бизнес данни, следва да се прецени кои съществуващи задължения могат да бъдат опростени или отменени.

Наредба № Н-18 е създадена в друга технологична среда, при която фокусът е върху фискални устройства, локални софтуери за управление на продажби и предварителен контрол върху процеса на продажба. Днешната електронна търговия работи чрез облачни ERP, CRM, e-commerce платформи, API интеграции, платежни доставчици, open banking и автоматизирани фулфилмънт процеси.

Затова БАПФОЕТ предлага МФ и НАП да възприемат принципа „едни данни — едно подаване“. Когато данни за продажбата, фактурата, плащането и счетоводното записване се предоставят чрез SAF-T, електронна фактура, ДДС дневник или проследимо банково/електронно плащане, те не следва да се изискват повторно чрез друг подзаконов режим без доказана контролна необходимост.

Особено важно е СУПТО режимът да бъде преразгледан спрямо международните облачни ERP, CRM и e-commerce системи. Българската регулация не трябва да затруднява внедряването на съвременни системи чрез прекомерно локални технически изисквания, които не са съгласувани с правилата на вътрешния пазар на ЕС.

VIII. Искания и предложения на БАПФОЕТ

С оглед изложеното БАПФОЕТ предлага Министерството на финансите и НАП да предприемат следните действия:

IX. Предложен подход към МФ и НАП

БАПФОЕТ не предлага отказ от SAF-T и не оспорва необходимостта от модернизация на данъчния контрол. Напротив, асоциацията счита, че SAF-T може да бъде полезен инструмент, ако се въведе по правно издържан, пропорционален и технологично реалистичен начин.

Проблемът е, че при липса на яснота относно нотификацията по Директива (ЕС) 2015/1535 реформата рискува да започне с правен дефект, който може да доведе до съдебни спорове, невъзможност за санкциониране, оспорване на доказателства в ревизионни производства и претенции срещу държавата.

Затова препоръчваме МФ и НАП да разглеждат нотификацията не като формалност, а като инструмент за прозрачност, предвидимост и защита на единния пазар. Това е особено важно при изисквания, които засягат международни облачни ERP системи и софтуерни решения, използвани от малки и средни предприятия.

X. Заключение

БАПФОЕТ подкрепя въвеждането на модерни механизми за електронен обмен на данни между бизнеса и приходната администрация. Същевременно асоциацията счита, че SAF-T не може да бъде въведен ефективно и устойчиво, ако съществуват съмнения относно спазването на задължителната европейска процедура за нотификация на технически регламенти.

Ето защо настояваме Министерството на финансите и НАП да извършат публична проверка на нотификационния статус на SAF-T, да предприемат необходимите действия за отстраняване на процедурния риск и да не прилагат санкционен подход, докато правната рамка не бъде изцяло изяснена.

В същото време въвеждането на SAF-T трябва да бъде използвано като възможност за реално намаляване на документалната и организационната тежест върху малките предприятия, онлайн услугите, електронната търговия и фулфилмънт сектора чрез преглед на Наредба № Н-18, СУПТО и дублиращите режими.

Крайната цел следва да бъде не повече формални задължения, а по-добър риск-базиран контрол, основан на качествени данни, правна сигурност и принципа „едни данни — едно подаване“.

Приложение: използвани източници и материали

1. Директива (ЕС) 2015/1535 на Европейския парламент и на Съвета от 9 септември 2015 г. относно процедурата за предоставяне на информация в сферата на техническите регламенти и правилата относно услугите на информационното общество.

2. Официална страница на НАП: „Системата за счетоводно отчитане SAF-T в България“, включително заповед, XSD схема, структура, дефиниции и примерни XML файлове.

3. Решение на Съда на ЕС по дело C-353/24, Europark Latvia and Skidata, относно технически регламент, софтуерен изходен код и задължение за предварителна нотификация.

4. Практика на Съда на ЕС по дела CIA Security International (C-194/94), Unilever Italia (C-443/98), Sebat Ince (C-336/14) и свързаната практика относно не противопоставимост на ненотифицирани технически регламенти.

5. Правен анализ относно липса на нотификация по Директива (ЕС) 2015/1535 за измененията в ДОПК и ЗДДС от 2025 г., предоставен на БАПФОЕТ.

6. Правен анализ относно последиците от ненотифицирането на режима SAF-T за предприятията, администрацията и санкционните производства, предоставен на БАПФОЕТ.

7. Публикации и разяснения на НАП, МФ и международни данъчни консултантски организации относно по етапното въвеждане на SAF-T в България.

Здравейте, колеги,

Предвид големия интерес към последната ми публикация, искам да споделя нещо, с което се сблъсквам ежедневно в работата си.

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

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

Това е огромна грешка. Ето и най-яркият червен флаг, който ще ви покаже, че доставчикът ви още не е започнал работа, но иска да ви държи спокойни и "в течение": ако сте говорили с вашия вендор и те ви обещават, че ще са готови след 3 - 4 месеца, това не е време за генериране на тестове и настройки за съвместимост. Това е времето, което те си отделят, преди изобщо да започнат каквато и да е работа по създаването на програмата. Те едва сега започват да разработват и все още не са се задълбочили какво точно представлява SAF-T. Точно това означава този срок, никаква реална работа все още не е свършена.

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

Знам това, защото част от тях ни плащат, за да им направим интеграции. Позволяват ни да влезем в техните програми, за да намерим документите и да подравним потоците от данни. И впечатленията ми са ужасяващи.

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

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

Разбирането, че SAF-T ще бъде "функция с едно кликване", "модул" във вашия софтуер, или най-лошото, което съм чувал, обикновен конвертор на файлове (като конвертиране от Word в txt или PDF), е просто абсурдно.

SAF-T е цяла програма. И по-лошо, той е средство за огромните международни корпорации като SAP, Ernst & Young, KPMG, Deloitte, PwC, NetSuite и Oracle да погълнат местните доставчици. Защото тези местни фирми просто няма да могат да се адаптират и конкурират. Това трябва да е ясно като бял ден.

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

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

Защо мислите, че казвам всичко това, въпреки че работя за тях? Първо, защото те едва ли ще прочетат какво пиша тук, още повече че преките ми ръководители общуват на друг език. Второ, защото това ще има огромни бизнес и икономически последствия, които ще засегнат цялата ни професия. Не е преувеличение да кажа, че това е трансформация, каквато се случва веднъж на десетилетие, а ние просто не я приемаме достатъчно сериозно.

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

Ако все пак като професионалисти искаме да запазим настоящите си средства, сегашния си софтуер, колкото и сложен и лабиринтообразен да е, за да не се предаваме на големите международни корпорации, за да запазим контрола си на пазара и да се адаптираме по естествен начин, то тогава ни е необходим компромис между тях. Както казах в коментар към предишната си публикация, все повече стигам до убеждението, че решението е мост, междинен софтуер (middleware), който да работи с българските локални счетоводни програми. Това е решението, което виждам, но за да се случи, доставчиците (вендорите), а ако те не искат поради своето сляпо упорство, то поне хората, които ги използват, трябва да си сътрудничат, за да унифицират различните си формати на въвеждане на данни. Разбира се, това е само спечелване на време и преодоляване на текущите вълни, за да се даде на сектора и на местния пазар нужното време за адаптация.

Моля, споделете и вашите наблюдения....

Колеги, седмица 7-ми ден под напрежение със САФ-Т, а усещането е, че всеки ден излиза нова "тайна" версия на схемата. 

Имам конкретен казус и искам мнение: При генериране на XML-а за продажби, системата ми връща грешка за несъответствие в ДДС-то с 0.01 лв. (една стотинка!). В счетоводната програма всичко е изравнено, но НАП-портала я връща.