SourceDocuments - изходните документи
Изходните документи - фактури, плащания, движения на стоки и данъчни активи.
Документите зад числата
Ако GeneralLedgerEntries (глава 5) е счетоводният запис на операцията, SourceDocuments е първичният документ зад нея - фактурата, платежното нареждане, стоковата разписка. Четирите подсекции тук са SalesInvoices, PurchaseInvoices, Payments, MovementOfGoods и AssetTransactions.
InvoiceStructure - една структура, споделена от продажби и покупки
SalesInvoices и PurchaseInvoices не са две различни структури, дефинирани отделно -
и двете се изграждат от една и съща InvoiceStructure, само с обратна посока на
контрагента (клиент срещу доставчик). Веднъж разбрана структурата на едната страна,
знаете и другата.
SupplierInfo - защо липсва, не е грешка
Фактура за продажба е по дефиниция свързана с клиент, не с доставчик. Затова в нея
елементът SupplierInfo отсъства напълно - схемата ги моделира като истински
xs:choice между CustomerInfo и SupplierInfo, не като двойка независими
опционални полета. Не се попълва с нули, не се повтарят данните на подаващата фирма
"по подразбиране". Ако видите фактура за продажба без SupplierInfo, това не е пропуск
за поправяне - това е правилното състояние.
Delivery - незадължителен контейнер с три взаимно изключващи се опции
На ниво ред от фактурата, Delivery е незадължителен контейнер за информация за
доставката - но щом решите да го включите, схемата налага истински xs:choice вътре
в него между три възможности: MovementReference (препратка към конкретен документ за
движение на стоки, вече отчетен другаде), DeliveryDate (единична конкретна дата на
доставка) или DeliveryPeriod (период чрез FromDate/ToDate, когато доставката е
разсрочена или периодична). Правилото - попълвате само едно от трите, не комбинация
"за по-точно описание" - е познато вече от Header (SelectionCriteria, глава 3) и
MasterFiles (салда, глава 4).
Delivery не е една от трите опции - тя ги съдържа
Лесно се бърка редът тук: Delivery не е третата алтернатива редом с
MovementReference и DeliveryPeriod - тя е външният контейнер, а истинският избор
между трите конкретни начина (включително DeliveryDate, лесен за пропускане) става
вътре в нея.
ShipTo / ShipFrom - адресът на доставка не винаги е адресът на контрагента
Отделно от самия контрагент (клиент/доставчик с неговия регистриран адрес), фактурата
може да носи ShipTo/ShipFrom - конкретния адрес, откъдето/накъдето реално е тръгнала
стоката. Двата адреса съвпадат в повечето случаи (стоката отива направо в седалището на
клиента), но не винаги - например доставка директно до складова база, различна от
адреса по регистрация. Не попълвайте автоматично адреса на контрагента тук "за да е
попълнено" - ако имате реалния адрес на доставка, той е това, което полето очаква.
Продукти, купени за собствена консумация - ProductCode = "0"
Купувате канцеларски материали, които осчетоводявате директно като разход, не като
материален запас за препродажба. На реда на тази покупна фактура ProductCode не
изисква измислен вътрешен код за "текущ разход" - подава се изрично "0", защото
разходът просто не влиза в продуктовата номенклатура на файла. Същият принцип на изрична
нулева стойност за "не е приложимо", който видяхме многократно в предишните глави.
Митнически декларации - когато фактурата не е фактура
При внос отчитате митническа декларация (ЕАД), не обичайна фактура от доставчик.
Детайл, лесен за пропускане
AccountID на ниво фактура (в случая - декларация) и AccountID на ниво ред
може да се различават - митническата сметка на цялата декларация не е задължително
същата като ДДС сметката, използвана на конкретен ред. Не е грешка да видите различни
стойности тук - двете нива описват различни неща.
Обратно начисляване на ДДС - появява се на две места
Обратното начисляване (VAT reverse charge - типично при вътреобщностни доставки или определени услуги) не се отчита само веднъж.
Едно и също число, две подсекции
Една и съща операция се отразява и в SalesInvoices, и в PurchaseInvoices - веднъж като "продажба" (начисляване на ДДС към себе си) и веднъж като "покупка" (право на данъчен кредит). Ако виждате едно и също число два пъти в различни подсекции на файл с обратно начисляване, това дублиране е очаквано, не грешка при подготовката.
Payments - три вложени нива, аналогични на GLE
Payments следва подобна на GeneralLedgerEntries вложена логика: всяко плащане носи
PaymentLine записи (кои конкретни фактури покрива плащането, задължителни, по един за
всяка), PaymentSettlement (разплащателни детайли - начин на плащане, банкова сметка,
опционална) и PaymentDocumentTotals (обобщените суми на целия платежен документ,
опционална).
PaymentLine носи собствени CustomerID/SupplierID
Точно както при TransactionLine в GLE (глава 5), всеки PaymentLine носи свои
собствени CustomerID/SupplierID - винаги присъстват, независимо дали плащането
като цяло е обвързано с един контрагент.
MovementOfGoods - StockMovement и неговите редове
MovementOfGoods следва същия модел "документ → редове": StockMovement описва самото
движение (референция, дата, тип), а StockMovementLine - конкретното количество и
осчетоводена стойност в него.
AssetTransactions - придобиване, изписване, преоценка
AssetTransactions носи AssetTransactionValuations - оценките на актива към момента
на транзакцията (придобиване, отписване, преоценка). Живее структурно в годишния файл
(виж глава 2 и глава 4 за двете паралелни дървета на оценка ValuationSAP/ValuationDAP,
към които тези транзакции се обвързват).
CorrespondingAccountsReport не е част от тази секция
Ако сте виждали "Главна книга" споменавана редом със SourceDocuments - тя всъщност е самостоятелна, отделна секция на върха на дървото (не подсекция на SourceDocuments) и съществува само в месечния файл. Разгледахме я подробно в глава 2.
Какво да запомните от тази глава
- SalesInvoices и PurchaseInvoices споделят една и съща InvoiceStructure, обърната по
посока на контрагента - CustomerInfo/SupplierInfo е истински
xs:choice. - Delivery е незадължителен контейнер; истинският избор е вътре в него, между MovementReference, DeliveryDate и DeliveryPeriod.
- ShipTo/ShipFrom описват реалния адрес на доставка, не автоматично адреса на контрагента.
- Покупка, осчетоводена директно като разход (не като запас), носи
ProductCode = "0". - При митнически декларации AccountID на ниво фактура и на ниво ред може легитимно да се различават.
- Обратното начисляване на ДДС се появява едновременно в SalesInvoices и в PurchaseInvoices - не е дублирана грешка.
- Payments и MovementOfGoods следват вложена структура "документ → редове", аналогична на GeneralLedgerEntries; всеки PaymentLine носи собствени CustomerID/SupplierID.
- CorrespondingAccountsReport ("Главна книга") не е подсекция на SourceDocuments - тя е самостоятелна, месечна-само секция (глава 2).
Следващата глава е за контрагентите и подаващото лице - как точно се идентифицират клиенти, доставчици и самата фирма във файла.
SourceDocuments се генерират, не се преписват
Magi прилага правилата от тази глава - код на продукт, изключване на доставчик, реверсивно начисляване - автоматично при генериране.