Практическа готовност - от мапиране до подаване

От теория към първия реален файл

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

Тествайте, преди да подадете истински

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

Основните причини, зад които стоят повечето грешки

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

"Зеленото отметче" не е финалната проверка

Споменахме го в глава 7, но си струва да го повторим тук, защото е най-подценяваната подробност в цялата подготовка - това са две отделни проверки, не една, и минаването на едната не казва нищо за другата. Диаграмата ги показва една до друга.

Практически това значи: не спирайте на "зелено е, значи е готово". Прегледайте и кръстосаните препратки, преди да подадете.

Кратък списък за проверка преди подаване

• Мапирани ли са всички кодове (сметкоплан, данъчни кодове, мерни единици, видове документи) към официалните номенклатури на НАП - не оставени във вътрешния формат на счетоводната програма (глава 8)?
• Съществува ли всеки CustomerID/SupplierID, използван в GeneralLedgerEntries и SourceDocuments, реално в MasterFiles - и изписан по идентичен начин навсякъде (глава 7)?
• Съответства ли името на файла точно на изисквания формат за вида подаване (месечен, годишен, при поискване - глава 2)?
• Има ли текстови полета, потенциално по-дълги от допустимата граница за типа им (глава 8), които трябва да прегледате ръчно, преди да разчитате на автоматично отрязване?
• Проверили ли сте специфичните за вашия клиент случаи - група/УБО (глава 3), активи с две оценки (глава 4), международни плащания или сектор с особени облекчения (глава 9)?
• Взаимно изключващите се двойки полета (начални салда, дебит/кредит, Delivery/ MovementReference/DeliveryPeriod - глави 4-6) попълнени ли са всяка само с едната си страна, не и с двете?
• Първото генериране на файла минало ли е през тестовата среда на НАП, преди реално подаване?

Ролята на софтуера ви в цялата тази работа

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

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

Какво да запомните от тази глава

• Първото генериране на файл минава през тестовата среда на НАП, не директно в продукция.
• Практически всички съобщения за грешка спадат към шепа повтарящи се причини - вижте таблицата по-горе и наръчника с грешки за обяснение на прост език. Ако софтуерът ви показва "информационна" бележка вместо грешка, това е неговата собствена корекция, не съобщение от НАП.
• XSD валидацията ("зеленото отметче") и кръстосаните проверки между секции са две отделни проверки - и двете трябва да минат.
• Кратък чеклист преди подаване пести повече време от опита да гадаете грешките в движение.

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