ЗА разликите в данъчна балансова стойност между Данъчен амортизационен план и Справката за данъчни амортизации по категории.
В Данъчния амортизационен план са включени всички активи, а в справката за данъчни амортизации по категории, само тези които имат данъчни амортизации през годината, затова е нормално да има разлика в данъчната балансова стойност между двете справки.
Какво ще се случи при годишното приключване?
За всяка сметка се изчислява превалутираното салдо към 01.01.2026г. Ако общият сбор за сметката се различава от превалутирания общ сбор към 31.12.2025 г. в началните салда се записва корекция за тази разлика за да се "скрие" тази аномалия. Освен това с дата 01.01.2026 в служебна папка "_EUR" се появява запис с обратен знак за тази разлика. Общата стойност за всички подобни записи се вижда в сметка, която се избира при приключването.
По принцип през 2026 г. за всички документи, освен за валутните фактури стойностите са в EUR. За плащания в лв. може да се избира специална сметка /напр. 4221/ която не е валутна. Стойностите по нея ще идват в EUR и за всяка дата би трябвало да се прехвърлят в съответна валутна сметка в лв. - напр. 501BGN.
Става дума за по един запис за всяка дата, за която има такива плащания. Това ще е само до края на м. 01.2026 и няма смисъл да се използва някаква специална възможност за превалутиране на такива плащания.
Става дума за SAF-T (Standard Audit File for Tax)
или СТАНДАРТЕН ОДИТЕН ФАЙЛ ЗА ДАНЪЧНИ ЦЕЛИ
Нормативната база свързана с това може да видите на сайта на НАП.
Идеята е чрез данни, които се споделят с НАП да се предоставя информация, която може да се използва при данъчни проверки. По принцип има смисъл от това и има примери как това се прави в други европейски държави.
Потребителите, които се налага първи да внедрят БГ варианта на SAF-T трябва да очакват сериозни неприятности. Трябва да се въвеждат много допълнителни данни за съответствията между сметките и картотеките, които използват и тези, които се попълват според изискванията на НАП. Има условие да се включват детайлните редове за всички документи, като за всеки материален актив се задава съответствие с националната картотека КН8, която има над 15 хиляди записа.
Трудна задача имат разработчиците. Файла SAF-T съдържа много секции с огромно количество тагове и в някои случаи са необходими много усилия за да се разбере какво точно трябва да е съдържанието на някои тагове. Основната ни цел е създадения файл да се валидира с XSD файла на НАП. Има вероятност освен формалното валидиране за съответствие със схемата да има допълнителни контроли за съдържанието, но до момента не виждаме възможност за тестване на сайта на НАП.
Първата цел е да се създава коректен файл МЕСЕЧЕН ОТЧЕТ. Попълваме само секциите и таговете, които са задължителни.
Почти всички потребители на ПИТАГОР използват възможностите за корекции на данни преди текущия месец. По ЗС отчетния период е календарната година и това не е некоректно. Понеже във файла МЕСЕЧЕН ОТЧЕТ има данни за салдата в началото и в края на месеца ако не се използва възможността ЗАБРАНА ЗА ПРОМЕНИ до началото на текущия месец би трябвало всеки път освен файла за текущия месец да се подават и корекции за всички стари месеци.
Всеки, който прецени, че някой от документите, създавани с ПИТАГОР може да изглежда по добре има възможност да промени вида им като промени съответен макетен файл.
Документите се създават като се попълват HTML или RTF макети.Програмата се разпространява с макети, които можете да се използват за създаване на нови варианти.
Първо ще припомни нормативната база за СУПТО, въпросната НАРЕДБА 18, регламентираща използването на фискални устройства в търговските обекти.
Тази наредба е от 2006 г. и през 2018 г. се появи съществена промяна, сввързана с изискване към софтуера, който се използва в търговските обекти. Интересното е, че много голяма част от промените е свързана с продажбите, за които се издават фактури. НАП наложиха на разработчиците на софтуер сериозни ограничения, които най-общо целят да се правят невъзможни данъчни нарушения, свързани с всякакви продажби. Наредбата наложи на разработчиците тежка процедура на лицензиране на конкретните продукти. Иска се пълно описание на базата данни и изходния код на всеки продукт. Няма смисъл да се коментира, дали някой в НАП има капацитет да разбере нещо съществено от тези описания, но се появиха много основания за санкции при нарушения на тези изисквания.
Хиляди разработчици през периода между 2018 и 2020 г. бяха принудени да се занимават с това. След като влезе в сила много скоро стана ясно, че няма съществена полза от много от промените и изискванията, свързани със СУПТО отпаднаха.
В проекта за БЮДЖЕТ 2026 отново има задължение в търговските обекти да се използва само софтуер за управление на продажбите (СУПТО).
Целта на този пост е да обявим, че няма да правим опити да регистрираме версия на ПИТАГОР, която съответства на ограниченията на тази наредба и да обясним причините за това наше решение.
Основната причина е, че ограниченията, които налага наредбата СУПТО противоречат на важни възможности на ПИТАГОР. Ние считаме, че преди да се създаде окончателна версия на всеки официален документ той е в режим "чернова" и е нормално да се променя или да се анулира. След като документа е създаден има достатъчно възможности да се проследяват всички промени и всеки опит за злоупотреба с възможностите за променяне на документи лесно може да бъде открита.
Има и други причини. Въпросната наредба по принцип налага на разработчиците задължения, които са трудно изпълними. Разработчикът е длъжен да регистрира всяка нова версия. Длъжен е да дава техническо описание на безброй функции и да доказва, че в изходния код няма "дублиращи функционалности". Много е трудно да гарантираме на потребителите, че няма да имат проблеми свързани с наредбата при поддържане на такъв продукт.
Преди години успяхме да регистрираме вариант Н18 на ПП ПИТАГОР. Разработването на този продукт продължи близо година, като няколко месеца преди регистрирането се занимавахме предимно с това. Не беше изненада, че реалните приложения бяха много малко. Почти всички потребители намериха начин да се справят и без този продукт.
Натрупания опит и се убедихме, че беше грешка да се занимаваме с това.
Считаме, че за голямата част от потребителите на ПИТАГОР е важно да не пилеем ресурси за създаване на продукт, който не е ясно дали ще има приложения. В момента основната ни цел е да успеем да направим това, което сме обявили в поста ПРОМЕНИ СВЪРЗАНИ С ЕВРОТО и други промени, които ще са много по полезни за нашите потребители.
Вероятно към 31.12.2025 г. ще има касови наличности в BGN по някои сметки - например 501 и 422.
Понеже след 01.01.2026 всички обороти по тези сметки ще са в EUR трябва салдата за тези сметки да се прехвърлят в нови сметки: 501BGN и 422BGN. Те ще са валутни с вид валута BGN и постоянен курс равен на (1 / 1.95583 ).
