Освен регулярно подаваните месечни и годишни SAF-T файлове, които разгледахме във
втората част на нашата поредица "Разбери SAF-Т", НАП ще може да изисква предоставянето на одитен файл "при поискване", който е обект на анализ в настоящата трета част. Срокът за предоставяне на такъв файл е
14 дни от получаване на искането от НАП, което налага отлична подготовка и бърза реакция. Въпреки, че за много от предприятията сроковете за влизане в сила на задължението са напред във времето (
от 2026 г. за големи предприятия до 2030 г. за микропредприятия), е особено важно да се предвиди от сега необходимостта от нов софтуер или актуализация на съществуващия, особено за предприятията, извършващи търговия със стоки, както и за счетоводителите, които ги обслужват, тъй като данните, изисквани в този сценарий, са специфични и изключително детайлни.
Кои секции и данни се подават основно в SAF-T файла „при поискване“?
Въз основа на
предложения проект на документация на НАП (XSD схема, Приложение 2 и Приложение 3), следните секции са ключови при подаване на SAF-T "при поискване":
1. MasterFiles / PhysicalStock (Наличности на стоково-материални запаси / Физически наличности)
Тази секция, макар и дефинирана като опционална (О) в общата структура, става задължителна за подаване в 14-дневен срок при изрично поискване от НАП. Тя изисква детайлна информация за всяка стокова наличност към конкретна дата (моментна снимка) или начални/крайни салда за период.
» WarehouseID (Задължително, Идентификатор на склада)
» ProductCode (Задължително, Код на продукта/материалния запас)
» ProductType (Задължително, Вид на продукта/материалния запас, от Nom_Inventory_Types)
» StockAccountCommodityCod
e (Задължително, Код от Комбинираната номенклатура NC8_TARIC)
» OwnerID (Задължително, ЕИК на собственика на стоката)
» UOMPhysicalStock (Задължително, Мерна единица на наличността)
» UOMToUOMBaseConversionFa
ctor (Задължително, Коефициент на преобразуване към основната мерна единица)
» UnitPrice (Задължително, Единична цена на стоката в наличност)
» OpeningStockQuantity (Задължително, Начално количество за периода)
» OpeningStockValue (Задължително, Начална стойност за периода)
» ClosingStockQuantity (Задължително, Крайно количество за периода)
» ClosingStockValue (Задължително, Крайна стойност за периода)
Други полета като LocationID (Локация в склада), StockAccountNo (Партиден/сериен номер), ProductStatus (Статус на продукта), StockCharacteristics (Характеристики на стоката) са незадължителни.
2. SourceDocuments / MovementOfGoods (Движение на стоки / Стокови потоци)
Тази секция също се подава при поискване от НАП в 14-дневен срок и отразява всички движения на СМЗ.
» На ниво MovementOfGoods (общо за всички движения):
» NumberOfMovementLines (Задължително, Общ брой редове от всички документи за движение)
» TotalQuantityReceived (Незадължително, Общо получено количество)
» TotalQuantityIssued (Незадължително, Общо издадено количество)
» На ниво StockMovement (Задължително, за всеки документ/операция по движение):
» MovementReference (Задължително, Уникален ID на документа за движение)
» MovementDate (Задължително, Дата на документа)
» MovementType (Задължително, Вид на движението от номенклатура Stock movement)
» DocumentReference (Задължително):
» DocumentType (Задължително, Вид на свързания документ)
» DocumentNumber (Задължително, Номер на свързания документ)
» Други полета като MovementPostingDate, MovementPostingTime, TaxPointDate, SourceID, SystemID, DocumentReference/DocumentLine са Незадължителни.
» На ниво StockMovementLine (Задължително, за всеки артикул в документа за движение):
» LineNumber (Задължително, Номер на реда)
» ProductCode (Задължително, Код на продукта)
» Quantity (Задължително, Количество)
» UnitOfMeasure (Задължително, Мерна единица от документа)
» UOMToUOMPhysicalStockCon
versionFactor (Задължително, Коефициент на преобразуване към мерната единица на физическия запас)
» MovementSubType (Задължително, Подвид на движението от номенклатура Stock movement)
» AccountID (Условно задължително, Счетоводна сметка, свързана с движението)
» TransactionID (Условно задължително, Връзка към счетоводна статия)
» Други полета като StockAccountNo, CustomerID, SupplierID, ShipTo, ShipFrom, BookValue, MovementComments, TaxInformation са Незадължителни или Условно задължителни.
3. SourceDocuments / AssetTransactions (Транзакции с активи)
Тази секция също се подава в 14-дневен срок при поискване от НАП и детайлизира операциите с дълготрайни активи.
» NumberOfAssetTransaction
s (Задължително, Брой транзакции с активи).
» На ниво AssetTransaction (Задължително, за всяка транзакция с актив):
» AssetTransactionID (Задължително, Уникален ID на транзакцията)
» AssetID (Задължително, ID на актива от MasterFiles/Assets)
» AssetTransactionType (Задължително, Код на типа транзакция от AssetMovementTypes)
» AssetTransactionDate (Задължително, Дата на транзакцията)
» TransactionID (Задължително, Връзка към счетоводна статия)
» AssetTransactionValuatio
ns (Задължително):
» AssetTransactionValuatio
n (Задължително, поне един запис):
» BookValueOnTransaction (Задължително, Балансова стойност след транзакцията)
» AssetTransactionAmount (Задължително, Стойност на самата транзакция)
» Други полета като Description, AssetSupplier, AssetTransactionValuatio
n/AssetValuationType, AssetTransactionValuatio
n/AcquisitionAndProductionCostsOnTransaction са незадължителни.
Предизвикателства при подготовката на данни "при поискване" – какво трябва да предвидят счетоводителите и бизнесът?
Информацията за PhysicalStock и MovementOfGoods е изключително детайлна, трябва да се поддържа в реално време и обикновено се поддържа в складовия софтуер на предприятието или в модул "Склад" на ERP системата, а не директно в счетоводната програма, използвана от много счетоводни кантори, особено когато става въпрос за изнесено счетоводство.
Много микро и малки предприятия използват базови складови програми или специфичен за дейността им софтуер (напр. за производство, включително чуждестранни системи), който може да не е предвиден за експорт на данни в толкова детайлен и структуриран вид, съвместим с изискванията на SAF-T и националните номенклатури (за типове движения, мерни единици и др.). Адаптацията на такива системи може да е технически сложна, скъпа или дори невъзможна. На практика, изискванията към тези секции предполагат наличието на развита ERP система, която да може да генерира тези данни автоматично и консистентно. Това обаче не отговаря на реалността за малките предприятия в България.
Ключов проблем възниква, ако продуктовите кодове (ProductCode) и описания в складовата система на клиента се различават от тези, използвани в счетоводния софтуер на кантората (където се отразяват фактурите за покупки/продажби и се дефинира MasterFiles/Products). SAF-T изисква единна продуктова номенклатура в целия файл. Това налага или поддържането на синхронизирани номенклатури между двете системи (при клиента и в кантората), или сложен процес на съотнасяне (mapping) преди генерирането на SAF-T, което е изключително трудоемко, податливо на грешки и практически невъзможно.
Друг потенциален казус с файла при поискване
НАП изисква "при поискване" едновременно:
- Данни за движение и наличности на стоки (SourceDocuments/MovementOfGoods и MasterFiles/PhysicalStock). Тази информация се намира в складовата програма в магазина на фирмата.
- Данни за транзакции с активи (SourceDocuments/AssetTransactions), които данни се водят в счетоводната програма в счетоводната кантора.
Въз основа на структурата и целите на SAF-T технически погледнато, SAF-T е замислен като
един файл за дадено предприятие и период.
Подаването на два напълно отделни файла, единият само със стокови данни, а другият само с данни за активи (и вероятно дублиращи се Header, MasterFiles и GeneralLedgerEntries, за да са валидни файловете),
не изглежда да е предвидено в стандартната схема. Това трябва да се уточни от НАП.
Заключение
Анализът на изискванията за секциите PhysicalStock (Наличности на СМЗ) и MovementOfGoods (Движение на стоки) разкрива една съществена импликация:
структурата и детайлността на тези данни са предвидени така, сякаш се очаква всяко предприятие (микро, малко или голямо), търгуващо със стоки и материали, да оперира със сложна, напълно интегрирана ERP система. Такива системи обикновено обединяват в единна база данни оперативната складова отчетност (с всички детайли за партиди, локации, специфични типове движения), счетоводния модул и модула за дълготрайни активи, позволявайки автоматичното генериране на консистентна и свързана информация. Реалността за преобладаващата част от микро и малките предприятия в България обаче е различна – те често използват отделни, по-опростени счетоводни програми (често при изнесено счетоводство) и базови складови или търговски софтуери, които не са интегрирани помежду си и не поддържат необходимото ниво на детайлизация и съвместимост с изискваните от SAF-T номенклатури и структури без значителни и скъпи доработки.