Как работят ERP системите: Модули, потоци от данни и скритото зад тях счетоводство
Проследяване на една транзакция през всички модули на едно ERP, съпътствана от реалните счетоводни статии, както и защо главната книга е основата, от която се чете всичко останало.
Една ERP система работи, като съхранява всяко бизнес събитие точно веднъж в единна база данни и позволява на всеки модул да чете и записва в този споделен запис. Изпратената поръчка представлява абсолютно същият запис, независимо дали я разглежда складът, търговският екип или счетоводителят. Модулът, който гарантира коректността на цялата система, е главната книга (general ledger): всяко събитие с парична стойност завършва там под формата на балансирана счетоводна статия, а всеки отчет се генерира на базата на тези статии.
Тази статия проследява една продажба през различните модули, показва генерираните от нея счетоводни статии и обяснява защо интеграцията с едно ERP се състои в работа със събития и счетоводни регистри, а не с потребителски екрани.
Споделената база данни
Преди появата на ERP системите всеки отдел разполагаше със собствена програма. Стоковите наличности се следяха в складова система, фактурите се издаваха в система за фактуриране, а счетоводството се води в отделен софтуер. Краят на месеца преминаваше в непрекъснато съгласуване между трите системи. Статията Какво представлява ERP софтуерът разглежда категорията в детайли, а механизмът, който я кара да работи, е единният модел на данните, в който:
- записа за контрагент (partner) се използва едновременно от продажбите, покупките и счетоводството,
- записа за артикул (item) съдържа складовата наличност, ценовите слоеве по метода FIFO, продажната цена и счетоводната сметка за приходите,
- всеки документ (поръчка, фактура, кредитно известие, покупка, производствена поръчка) препраща към конкретни контрагенти и артикули и генерира точно един комплект счетоводни статии,
- всяка счетоводна статия препраща към документа, който я е създал, така че всяка сума в даден отчет да може да бъде проследена до нейния източник.
Когато данните са споделени, няма нужда от междинно съгласуване между модулите. Това, което остава за сверяване, е външният свят: банковите извлечения и данъчните декларации.
Карта на модулите
| Модул | Записва (Writes) | Чете (Reads) |
|---|---|---|
| Продажби | Поръчки, фактури, кредитни известия | Контрагенти, артикули, цени, правила за ДДС |
| Покупки | Поръчки за покупка, фактури от доставчици | Контрагенти, артикули, сметки за разходи |
| Склад | Складови движения, ценови слоеве FIFO, инвентаризации | Артикули, складове |
| Производство | Производствени поръчки, вложени материали, готова продукция | Спецификации на продукти (BOM), складови наличности |
| Банка | Импортирани транзакции, съпоставки на плащания | Непогасени фактури, банкови сметки |
| ТРЗ (Payroll) | Ведомости за заплати, осигуровки, декларации | Служители, договори, данъчни таблици |
| Дълготрайни активи | Регистър на активите, амортизационни планове | Групи активи, полезен живот |
| Данъци | Справки-декларации по ДДС, VIES декларации, Intrastat, електронни фактури | Издадени и отчетени документи |
| Главна книга | Счетоводни статии, заключени периоди | Всичко изброено по-горе |
| Отчети | Нищо | Главната книга и аналитичните регистри (subledgers) |
Всеки ред, с изключение на последните два, завършва със запис в главната книга. Това е основополагащото правило, което отличава едно ERP от група свързани помежду си инструменти.
Реален поток на данните
Примерът по-долу използва API крайната точка (endpoints) на Nordlet и стандартните сметки от Литовския сметкоплан, с който тя се доставя. Всяко ERP изпълнява същите стъпки, макар кодовете на сметките и имената на заявките да се различават.
1. Поръчка
Онлайн магазин създава поръчка чрез POST /v1/ecommerce/orders/create: посочват се контрагент, редове с артикули и количества, както и държава на получателя. На този етап все още няма запис в главната книга. Поръчката представлява ангажимент, а не транзакция.
2. Резервация на стока
Заявката orders/reserve запазва количествата, така че втора поръчка да не може да продаде същите артикули. Все още липсва счетоводна статия: резервираната стока продължава да бъде фирмена собственост.
3. Изпълнение (експедиция)
Заявката orders/fulfill отразява напускането на стоките от склада. В рамките на една единствена транзакция към базата данни се случват две неща:
- Стоката се изписва по себестойност FIFO: използват се най-старите ценови слоеве за всеки артикул, което съответства на метода, описан в речника в статията Оценка на инвентара по метод FIFO (FIFO inventory valuation).
- Себестойността на тези единици се записва като счетоводна статия: дебит по сметка за отчетена стойност на продадените стоки, кредит по складова сметка.
| Сметка | Дебит | Кредит |
|---|---|---|
| 6000 Себестойност на продадените стоки | 600.00 | |
| 2040 Материали и стоки (Склад) | 600.00 |
Изпълнението на поръчката създава и чернова на фактура за съответната поръчка, като данъчният режим по ДДС се определя автоматично спрямо държавата на получателя чрез системата за ЕС ДДС (EU VAT engine).
4. Издаване на фактура
Издаването на фактурата е моментът, в който се признава приходът при продажба с дата на данъчно събитие. Документът получава своя пореден номер без пропуски в нумерацията и се генерира една балансирана статия: брутната сума се отчита по вземанията, ДДС сумата – по сметката за дължим данък, а нетната сума – по приходите.
За нетна продажба от 1 000 евро при 21% литовски ДДС:
| Сметка | Дебит | Кредит |
|---|---|---|
| 2410 Вземания от клиенти | 1,210.00 | |
| 5000 Приходи от продажба на стоки | 1,000.00 | |
| 4492 ДДС за начисляване / ДДС продажби | 210.00 |
Ако даден ред използва метод за признаване на приходите, различен от моментната продажба, нетната сума се насочва към приходи за бъдещи периоди, а системата за признаване на приходи (revenue recognition engine) ги разпределя по график. Отразяването на вземанията и ДДС остава непроменено.
Фактурата вече може да бъде изпратена като PDF файл, под формата на електронна фактура Peppol BIS 3.0 или в националния формат за електронно отчитане, изискван от законодателството на съответната страна.
5. Съпоставка с банката
Две седмици по-късно по сметката постъпват 1,210 евро. Движението се получава чрез банково извлечение през PSD2 интерфейс или чрез импорт на файл във формат camt.053. Банковият модул оценява потенциалните фактури по сума, основание за плащане, име на контрагент и IBAN, след което bank/transactions/match отразява плащането:
| Сметка | Дебит | Кредит |
|---|---|---|
| 2710 Разплащателна сметка в банка | 1,210.00 | |
| 2410 Вземания от клиенти | 1,210.00 |
Статусът на фактурата се променя на „платена“ и се изпраща уебхук (webhook) събитие sale_invoice.paid. Статията за платежно съгласуване (payment reconciliation) описва логиката на съпоставката в по-големи подробности. Плащане в друга валута отчита реализираната валутна разлика по сметката за приходи или разходи от курсови разлики в същата стъпка.
6. Справка-декларация по ДДС
В края на месеца не се налага ръчно пренасяне на данни. Справката-декларация по ДДС се изчислява директно от издадените и отчетените документи: declarations/eu/vat-return/compute за националната декларация (FR0600 в Литва) и declarations/eu/oss/compute за трансграничните продажби към крайни клиенти по режима в Съюза (OSS). Посочената по-горе продажба попада в клетката за стандартна данъчна ставка на вътрешната декларация, тъй като нейният данъчен режим е domestic.
7. Заключване на период
След подаване на данъчната декларация, командата ledger/periods/lock затваря месеца. От този момент нататък всяко счетоводно записване с дата в този период, включително закъсняло банково плащане или повторен API заявка, се отхвърля с грешка HTTP 409. Заключването задейства и признаването на всички отложени приходи за периода, така че месецът да не може да бъде затворен с натрупани приходи, останали в пасивни сметки.
Защо главната книга е основният регистър
Всеки от горепосочените модули поддържа аналитичен регистър (subledger): вземания по клиенти, задължения по доставчици, складови наличности по артикули, дълготрайни активи по инвентарни номера. Главната книга (general ledger) съдържа обобщените суми, с които тези аналитични регистри задължително трябва да съвпадат. Материалът Аналитични регистри срещу главна книга (Subledger vs general ledger) разглежда тяхната взаимосвързаност, като практическото правило е, че отчет, генериран от главната книга, и отчет, извлечен от аналитичен регистър, трябва да показват абсолютно еднакви суми. Едно ERP гарантира това, като генерира и двете нива от едни и същи счетоводни статии (journal entry).
Главната книга е надежден регистър благодарение на три основни свойства:
- Гарантиран баланс. В Nordlet базата данни отказва да приеме запис, при който сумата на дебитите не е равна на сумата на кредитите. Софтуерен дефект в даден модул не може да създаде небалансирана статия.
- Хронологичност само с добавяне (append-only). Веднъж записана счетоводна статия никога не се редактира. Допусната грешка се коригира с операция сторно и нова статия, като и двете са обвързани с оригинала. Статията за неизменяема главна книга (immutable ledger) обяснява защо одиторите държат изключително много на това изискване.
- Заключване на периоди. Заключеният месец не подлежи на промяна, което гарантира, че вече декларираните пред институциите данни остават непокътнати в системата.
Интеграция: събития и идемпотентност вместо нощни пакети с данни
По-старите ERP интеграции разчитаха на файлове, обменям се през нощта: експортиране на поръчки, импортирането им и проверка на дневниците с грешки сутрин. Съвременните ERP системи предоставят API интерфейси, а интеграцията се свежда до спазването на две основни дисциплини.
Изходящи събития (Events out). Когато настъпи промяна, ERP системата ви уведомява. Nordlet записва всяко уебхук събитие в изходяща опашка (outbox) в рамките на същата транзакция с базата данни, така че документ, чиято операция е била отменена, никога да не генерира събитие и нито едно събитие да не бъде загубено. Доставките са подписани с HMAC-SHA256 и се повтарят при грешка с нарастващ интервал (exponential backoff). Вашата система реагира на събитието sale_invoice.paid, вместо да прави справки на всеки пет минути дали дадена фактура е платена.
Безопасни повторни заявки (Safe retries in). Мрежовите връзки могат да прекъснат, но повтореният заявъчен път не трябва да създава втора фактура. Nordlet изисква хедър Idempotency-Key при всяка заявка, променяща данни: същият ключ със същите данни връща запазения отговор, същият ключ с различни данни се отхвърля, а ключовете изтичат след 24 часа. Речникът в статията Идемпотентност (idempotency) и насоките API conventions описват точното поведение на системата.
Тъй като всяка операция представлява извикване на POST /v1/{module}/{resource}/{action}, а приложението използва едни и същи крайни точки, една интеграция може да изпълни целия описан по-горе процес, без никой да отваря потребителски екран. Ръководството Как да интегрирате облачен счетоводен API в SaaS платформа показва как се изгражда подобна архитектура.
Какво четат отчетите
Отчетите не съхраняват суми. Те представляват заявки към главната книга и аналитичните регистри към определен момент в времето:
- Оборотна ведомост, баланс, отчети за приходите и разходите и за паричните потоци четат счетоводни статии по сметки и периоди.
- Възрастовата структура на вземанията и задълженията (debt aging) чете отворените вземания и задължения по падежи.
- Складовите наличности и движения четат данни от складовия регистър и неговите FIFO слоеве.
- ДДС справките четат ДДС редовете на издадените и отчетените документи.
- Отчетите по разходни центрове четат измерението на разходния център за всеки счетоводен ред.
В Nordlet отчетът се генерира във фонов режим като XLSX, PDF или JSON файл, като при готовност на файла се задейства уебхук. Консолидираните данни се извличат чрез консолидация (consolidation), която обединява счетоводните регистри на няколко компании, като отчита дела на участие и преизчисляването във валута.
Къде се появяват проблеми в практиката
Повечето затруднения с ERP системите произтичат от нарушаване на принципа за споделения запис, а не от софтуерни грешки. Най-честите примери включват:
- Паралелни таблици в Excel за дейности, които ERP системата „не може да направи“, в резултат на което възникват разминавания с официалното счетоводство.
- Ръчни счетоводни статии, използвани за корекция на резултата от даден модул вместо коригиране на самия документ, което нарушава проследимостта от отчета към източника.
- Интеграции, които записват оборотни суми вместо конкретни документи, поради което главната книга съдържа общи суми, които никой не може да обясни.
- Отворени периоди, оставени без заключване с месеци, което води до несъответствия в подадените за предходното тримесечие данни.
Статията Защо ERP внедряванията се провалят разглежда как се изграждат тези навици по време на проект, а Реалистични срокове за внедряване на ERP показва на кои етапи те обикновено се появяват.
FAQ
Какво представлява ядрото на една ERP система?
Главната книга и изграденият около нея модел на споделени данни. Всеки модул записва документи, които генерират балансирани счетоводни статии, а всеки отчет се извлича именно от тези статии.
Как протича потокът от данни през едно ERP?
Всяко събитие се регистрира еднократно под формата на документ (поръчка, фактура, складово движение, ведомост за заплати). Документът генерира счетоводни статии в главната книга и движения в съответния аналитичен регистър. Отчетите и данъчните декларации се изчисляват на базата на тези записи. Между модулите не се копира информация.
Каква е разликата между модул и интеграция?
Даден модул записва данни в същата база данни и в същата главна книга, както останалата част от системата. Интеграцията представлява външна програма, която извиква API интерфейса на ERP системата. При ERP системите с водещо API значението на тази разлика е малко, тъй като интеграцията използва същите крайна точки, които се ползват и от вградените модули.
Едно ERP автоматично ли създава счетоводни статии?
Да. Издаването на фактура, изпълнението на поръчка, съпоставката на плащане, обработката на ведомости за заплати или начисляването на амортизации водят до автоматично генериране на съответните счетоводни статии, без да е необходимо потребителят ръчно да задава дебити и кредити. Използваните сметки се определят от правила за отчитане, които могат да бъдат конфигурирани за всяка компания поотделно.
Защо ERP системите заключват счетоводните периоди?
За да се гарантира, че вече отчетените или декларирани данни за даден период не могат да бъдат променени впоследствие. Заключеният период отхвърля нови записи, което предпазва одитната следа и налага всички корекции да бъдат извършвани в текущия период, където те са напълно видими.