За българския вариант на SAF-T

Става дума за SAF-T (Standard Audit File for Tax) 
или СТАНДАРТЕН ОДИТЕН ФАЙЛ ЗА ДАНЪЧНИ ЦЕЛИ 

Нормативната база свързана с това може да видите на сайта на НАП.

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

Потребителите, които се налага първи да внедрят БГ варианта на SAF-T трябва да очакват сериозни неприятности. Трябва да се въвеждат много допълнителни данни за съответствията между сметките и картотеките, които използват и тези, които се попълват според изискванията на НАП.  Има условие  да се включват детайлните редове за всички документи, като за всеки материален актив се задава съответствие с националната картотека КН8, която има над 15 хиляди записа.

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

Първата цел е да се създава коректен файл МЕСЕЧЕН ОТЧЕТ. Попълваме само секциите и таговете, които са задължителни.

Почти всички потребители на ПИТАГОР използват възможностите за корекции на данни преди текущия месец. По ЗС отчетния период е календарната година и това не е некоректно. Понеже във файла МЕСЕЧЕН ОТЧЕТ има данни за салдата в началото и в края на месеца ако не се използва възможността ЗАБРАНА ЗА ПРОМЕНИ до началото на текущия месец би трябвало всеки път освен файла за текущия месец да се подават и корекции за всички стари месеци.

За документите създавани с ПИТАГОР

Всеки, който прецени, че някой от документите, създавани с ПИТАГОР може да изглежда по добре има възможност да промени вида на документа като промени съответния макетен файл.

Документите се създават като се попълват HTML или RTF макети.
RTF макетите се използват предимно при документите свързани с персонала. Те се редактират лесно и всеки, който работи с MS OFFICE може да се справи.
HTML макетите дават почти неограничени възможности за реализиране на всякакви идеи на потребителите, но за промяната на съответния макет са  необходими познания по HTML и веб дизайн. Този, който прави промените трябва да се съобразявате с маркерите на полетата, в които се попълват данните.

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

ОТНОВО СУПТО

Първо ще припомни нормативната база за СУПТО, въпросната НАРЕДБА 18, регламентираща използването на фискални устройства в търговските обекти. 
Тази наредба е от 2006 г. и през 2018 г. се появи съществена промяна, сввързана с изискване към софтуера, който се използва в търговските обекти. Интересното е, че много голяма част от промените е свързана с продажбите, за които се издават фактури. НАП наложиха на разработчиците на софтуер сериозни ограничения, които най-общо целят да се правят невъзможни данъчни нарушения, свързани с всякакви продажби. Наредбата наложи на разработчиците тежка процедура на лицензиране на конкретните продукти. Иска се пълно описание на базата данни и изходния код на всеки продукт. Няма смисъл да се коментира, дали някой в НАП има капацитет да разбере нещо съществено от тези описания, но се появиха много основания за санкции при нарушения на тези изисквания.
Хиляди разработчици през периода между 2018 и 2020 г. бяха принудени да се занимават с това. След като влезе в сила много скоро стана ясно, че няма съществена полза от много от промените и изискванията, свързани със СУПТО отпаднаха.

В проекта за БЮДЖЕТ 2026  отново има задължение в търговските обекти да се използва само софтуер за управление на продажбите (СУПТО).
Целта на този пост е да обявим, че няма да правим опити да регистрираме версия на ПИТАГОР, която съответства на ограниченията на тази наредба и да обясним причините за това наше решение.

Основната причина е, че ограниченията, които налага наредбата СУПТО противоречат на важни възможности на ПИТАГОР. Ние считаме, че преди да се създаде окончателна версия на всеки официален документ той е в режим "чернова" и е нормално да се променя или да се анулира. След като документа е създаден има достатъчно възможности да се проследяват всички промени и всеки опит за злоупотреба с възможностите за променяне на документи лесно може да бъде открита.
Има и други причини. Въпросната наредба по принцип налага на разработчиците задължения, които са трудно изпълними. Разработчикът е длъжен да регистрира всяка нова версия. Длъжен е да дава техническо описание на безброй функции и да доказва, че в изходния код няма "дублиращи функционалности". Много е трудно да гарантираме на потребителите, че няма да имат проблеми свързани с наредбата при поддържане на такъв продукт.

Преди години успяхме да регистрираме вариант Н18 на ПП ПИТАГОР. Разработването на този продукт продължи близо година, като няколко месеца преди регистрирането се занимавахме предимно с това. Не беше изненада, че реалните приложения бяха много малко. Почти всички потребители намериха начин да се справят и без този продукт.
Натрупания опит и се убедихме, че беше грешка да се занимаваме с това. 

Считаме, че за голямата част от потребителите на ПИТАГОР е важно да не пилеем ресурси за създаване на продукт, който не е ясно дали ще има приложения. В момента основната ни цел е  да успеем да направим това, което сме обявили в поста ПРОМЕНИ СВЪРЗАНИ С ЕВРОТО и други промени, които ще са много по полезни за нашите потребители. 

ЗА КАСОВИТЕ НАЛИЧНОСТИ КЪМ 01.01.2026

Вероятно към 31.12.2025 г. ще има касови наличности в BGN по някои сметки - например 501 и 422.
Понеже след 01.01.2026 всички обороти по тези сметки ще са в EUR трябва салдата за тези сметки да се прехвърлят в нови сметки: 501BGN и 422BGN. Те ще са валутни с вид валута BGN и постоянен курс равен на (1 / 1.95583 ).

ПРОМЕНИ, СВЪРЗАНИ С ВЪВЕЖДАНЕ НА ЕВРОТО

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

ПЕРИОД, ВКЛЮЧВАЩ ДАННИ ПРЕДИ И СЛЕД 01.01.2026

Желателно е версията, с която се рабoти след 01.01.2026 да може да работи и с данни преди тази дата, като винаги, когато крайната дата за справките е преди  01.01.2026 валутата да е BGN, а в противен случай да е EUR. Ако периода за някоя справка включва документи за 2 години, тези, които са в BGN автоматично ще се преизчисляват в EUR.

След приключване на 2025 г. макар и по рядко ще се налага да се работи с данни за няколко години - напр. при справките, които използват данни за приключените години.

ПРОБЛЕМИ СЪС ЗАКРЪГЛЕНИЯ.

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

Пример:
Многоредова фактура за доставка. Ако формално превалутираме всички редове крайното салдо в EUR с голяма вероятност няма да е точно крайното салдо в BGN / 1.95583. Затова е добре на някой от детайлните редове да се записва корекцията.
Някой свръхнаблюдателен потребител може да открие, че в някой от детайлните редове има неточност: примерно 2 * 2 = 4.01. Но е важно, че при общия сбор няма да има аномалии.

Пример за проблемите със закръгленията с реални данни на конкретен потребител:

В случая се вижда какво се случва когато крайната дата за периода на справката е през 2026 г. стойностите до 2025 г. трябва да се преизчислят в евро. Въпреки, че това не е много голямо приложение и стойностите са преизчислени с голяма точност в сборния ред се вижда разлика от няколко стотинки. Може да се скрият такива разлики в някои случаи като се добавят коригиращи записи с дата 01.01.2026, но не знам дали е възможно да се избегнат във всички случаи

ПРОБЛЕМИ ПРИ ИЗЧИСЛЯВАНЕ НА САЛДАТА КЪМ 01.01.2026 г.

За всяка партиди, които са с крайно салдо # 0 с голяма вероятност при превалутирането ще има разлики от закръгления. За сметки, при които има много партиди превалутираното крайно салдо за сметката ще е различно от сбора на салдата за превалутираните партиди. Трябва да се измисли разумно решение за този проблем за да няма разлики между салдата на 31.12.2025 и 01.01.2026. Въпросните разлики ще се появяват за повечето сметки, за които има много партиди.

При приключване на годината в данните за началните салда трябва да се появят записи, които да коригират тези разлики. Освен това с дата 01.01.2026 г. ще се появят записи, които закриват тези разлики като се дебитира или кредитира някоя сметка.

Пример: Сметка доставчици с много крайни салда към 31.12

След превалутирането се вижда, че крайното салдо в лв.  / 1.95583 се различава от сумата на превалутираните партиди.

ВАЛУТНИ СМЕТКИ В EUR

След 01.01.2026 г. те вече би трябвало да се трансформират в сметки, които не са валутни.

Предлагаме от 2026 да се дефинират нови сметки, съответни на всяка валутна сметка в евро. Може да се появи възможност за автоматично прехвърляне на салдата към 01.01.2026 в новите сметки.

СМЕТКИ В BGN СЛЕД 31.12.2025

Сметки 501* и 422* ако имат салда след 31.12.2025 трябва да се трансформират във валутни.

ПРОМЕНИ, СВЪРЗАНИ СЪС ЗАПЛАТИТЕ

При приключване на м.12.2025 към всеки трудов договор ще се създаде доп. споразумение в сила от 01.01.2026 в което вече заплатата ще е в EUR. Вероятно ще се наложи да има забрана за въвеждане на отсъствия, за които периода включва дни от 2 години. 

ДОКУМЕНТИ ЗА ПОКУПКИ ОТ ДРУГИ ПРИЛОЖЕНИЯ

Когато има много фактури за покупки от някои доставчици една ефектна възможност на ПИТАГОР ще ви помогне да ги осчетоводите лесно.

Необходимо е данните за покупките да включват следните атрибути:

• ЕИК и ДДС НОМЕР на доставчика
• Номер, Дата и Дата на падеж на фактурата
• ЕИК и ДДС НОМЕР на получателя
• Вид валута и обща стойност за документа
• Име и наименование на артикула за всеки детайлен ред
• Количество, Стойност без ДДС Стойност вкл. ДДС за всеки детайлен ред.

За видовете артикули от всеки доставчик трябва да се зададат партидите, които се дебитират при осчетоводяване на конкретните детайлни редове от фактурите. Това изглежда досадно, но на практика става лесно. Ако има документи за минал период, които вече са осчетоводени програмата подсказва конкретните партиди на базата на тези данни.

Въвеждането на съответните партиди за артикулите е еднократно. След това всеки път, когато се импортират данни за конкретни артикули те ще се записват автоматично по зададените партиди.

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

Когато източника на документите използва също ПИТАГОР има възможности това да става достатъчно лесно.

ВАРИАНТ 1.
Данните на някои доставчици са достъпни в друга папка на същия компютър, на който са данните за конкретната фирма. В този случай може да използвате възможността ИМПОРТ ОТ ДРУГИ ПАПКИ от меню ДОКУМЕНТИ на счетоводния модул.

ВАРИАНТ 2.

Получили се по някакъв начин файлове с данните от друг доставчик. Той е използвал възможността СПОДЕЛЯНЕ НА  ФАКТУРИ ЗА ПРОДАЖБИ от модул ПРОДАЖБИ.

В този случай трябва да използвате възможността ИМПОРТ ОТ ДРУГИ ИЗТОЧНИЦИ от меню ДОКУМЕНТИ на счетоводния модул.

Дати на фактурите и Дати на падеж

Освен датата на счетоводната операция за всеки документ може да се въвежда и дата на първичния документ. 

За документите, които са свързани с фактури може да се въвежда и дата на падеж, която е различна от датата на документа. Тази дата е свързана със справките РАЗЧЕТИ С КОНТРАГЕНТИ и с възможностите ПЛАНИРАНЕ НА ПЛАЩАНИЯТА.