Bevételi szabályrendszer (Income policies)

Definíció#

A bevételi szabályrendszer a QUiCK cégszintű, determinisztikus szabálymotorja, amely minden beérkező bevételi számlát a beérkezés pillanatában a számla saját adatai alapján kategorizál: bevételtípust, munkaszámot, főkönyvi számot és címkét rendel hozzá, a számlát tételenként vagy áfakulcsonként több sorra bonthatja, és meghatározott számlákat kizárhat az importból.

A szabályrendszer határai:

• A szabályrendszer a beérkező bevételi számlákra fut. Kézzel rögzített bevételi bizonylatra futása nem dokumentált.

• A szabályrendszer kizárólag a számlán szereplő adatból dolgozik: partneradatok, számlaszám, rendelésszám, deviza, áfaterület, fizetési mód, tételnevek és tételmegjegyzések. Nem ismer ügyfél-életút információt (új vagy megújító ügyfél, előzmények), és nem ismer a számlán kívüli forrást.

• A szabályrendszer nem gépi tanulás. Minden döntése előre beállított feltétel, és ugyanarra a számlára mindig ugyanazt az eredményt adja.

• A szabályrendszer nem azonos a partner-alapú automatikus kategorizálással, amely szabály hiányában a partner korábbi számlájának kategóriáját javasolja. A két mechanizmus viszonyát a Működés lépésről lépésre blokk írja le.

• A szabályrendszer nem azonos a bevétel részleteinél végzett kézi kategorizálással és bontással, és nem azonos az API-n vagy MCP-n keresztül végzett utólagos tömeges átkategorizálással. Ezek a szabályrendszer eredményét bármikor felülírhatják.

Cél és kontextus#

A bevételi számlák a legtöbb cégnél kevés, jól elkülöníthető mintát követnek: a számlázóban külön számlatömbök, ismétlődő tételnevek, állandó partnerek, rendelésszám-előtagok. A bevételi szabályrendszer ezt a szabályosságot fordítja le automatikus kategorizálásra, hogy a bevétel a beérkezés pillanatában a megfelelő kategóriában, a megfelelő címkével és bontással álljon a kimutatásokban, könyvelői beavatkozás nélkül.

A szabályrendszer a QUiCK komfort-létráján a folyamatos automatizálás foka: a kézi kategorizálás és a partner-alapú javaslat után az a szint, ahol a kategorizálás a számla tartalmából, előre rögzített üzleti szabály szerint történik. A kontroll megmarad: minden szabály címkét adhat, így a szabály által kategorizált számlák elkülöníthetők a kézzel kategorizáltaktól, és a szabály eredménye a bevétel részleteinél bármikor módosítható.

Tipikus üzleti felhasználások:

• Díjtípusok számlatömb szerint. Egy oktatási intézmény a számlázóban díjtípusonként külön számlatömböt használ (tandíj, étkezés, klubfoglalkozás, regisztrációs díj). Ha a számlaszám az étkezési tömb előtagját tartalmazza, akkor a szabály az Étkezés bevételtípust adja. A kimutatás díjtípusonként a beérkezés pillanatától helyes.

• Előfizetési csomag a tételnévből. Egy szoftverszolgáltató számláin a tételnév tartalmazza a csomag nevét. Ha a tételnév tartalmazza az Okosbox szót, akkor a szabály az Okosbox előfizetés bevételtípust adja és az éves címkét. Az új és a megújító előfizetést a szabály nem különbözteti meg, mert ez az információ a számlán nem szerepel.

• Kiemelt vevő projektre. Egy fővállalkozói szerződés minden számlája egy munkaszámhoz tartozik. Ha a partner adószáma a megrendelő adószáma, akkor a szabály a szerződés munkaszámát és a projekt címkéjét adja. A projekt bevétele munkaszám szerint szűrhető.

• Értékesítési csatorna a rendelésszámból. Egy webshop a Számlázz.hu rendelésszám mezőjébe csatornakódot ír. Ha a rendelésszám WS- előtaggal kezdődik, akkor a szabály a Webshop bevétel típust adja; ha MP- előtaggal, akkor a Marketplace bevétel típust. A csatornánkénti árbevétel automatikusan elkülönül.

• Export és közösségi értékesítés. Ha a számla devizaneme EUR, vagy az áfaterület EU, akkor a szabály az Export árbevétel típust, a hozzá tartozó főkönyvi számot és az export címkét adja. A belföldi és a külföldi árbevétel a könyvelés előtt elkülönül.

• Vegyes áfakulcsú számlák bontása. Egy vendéglátó vagy kiadó számláján 5%-os és 27%-os tétel is szerepel. Ha a szabály áfakulcs szerinti bontást ír elő, akkor a számla kulcsonként külön sorra bomlik, minden sor a saját nettó, áfa és bruttó összegével. A kulcsonkénti forgalom külön látszik.

• Több szolgáltatás egy számlán. Egy számlán előfizetés és kedvezmény, vagy termék és szállítási díj szerepel. Ha a szabály tételenkénti bontást ír elő, akkor minden tétel külön sorra kerül a saját összegével, negatív tétel esetén negatív összeggel. A sorok azonos bevételtípust kapnak; ha a sorok eltérő típust igényelnek, akkor a második sor típusát a bevétel részleteinél kell átállítani. A bontás és az összegek a beérkezéskor készen állnak.

• Bevezetési határnap. Egy szabály a bevezetés napjától érvényes. Ha a számla kelte a határnap előtti, akkor a szabály nem fut, a történeti állomány érintetlen marad.

• Technikai számlák kizárása. Egy belső cég próbaszámlái vagy egy adott partner számlái nem tartoznak a bevételek közé. Ha a számla az import-kizárási szabályra illeszkedik, akkor a számla nem jön létre a QUiCK-ben.

• Nyomon követhetőség. Ha minden szabály saját címkét ad, akkor a szabály által kategorizált számlák a címke alapján szűrhetők, és a kézi kategorizálás ellenőrzése a címke nélküli számlákra szűkül.

Mikor ezt, mikor mást#

A bevételi szabályrendszer annak a cégnek hasznos, amelynek bevételi számlái ismétlődő mintát követnek, és amely a kategorizálást a számla tartalmához, nem a partnerhez köti. Alternatívái:

• Partner-alapú automatikus kategorizálás. Szabály nélkül a QUiCK a partner korábbi számlájának kategóriáját adja az új számlának. Ez akkor elég, ha egy partner mindig ugyanazt a bevételtípust kapja. Ha a bevételtípus a számla tartalmától függ (tételnév, számlatömb, rendelésszám, deviza), akkor a bevételi szabályrendszer a megfelelő eszköz.

• Kézi kategorizálás a bevétel részleteinél. Egyedi, nem ismétlődő számláknál a kézi kategorizálás a megfelelő eszköz. A kézi kategorizálás a szabály eredményét felülírja, és a felülírás megmarad.

• Tételenként eltérő bevételtípus egy számlán. Ha egy számla tételei különböző bevételtípust igényelnek, akkor a bevételi szabályrendszer a bontást elvégzi, de a soronként eltérő típust nem adja meg. A soronként eltérő típust a bevétel részleteinél, vagy az API és az MCP bevétel-módosító műveletével (assignments lista) kell beállítani.

• Utólagos tömeges átkategorizálás. Már beérkezett számlák szabály szerinti átsorolására a szabályrendszer nem alkalmas, mert a szabály csak a beérkezéskor fut. Már beérkezett számlák tömeges átsorolása az API és az MCP bevétel-módosító műveletével történik.

• Számlázó-oldali számlatömbök. A szabályrendszer akkor a legmegbízhatóbb, ha a számlázóban a bevételtípusok külön számlatömbben, egységes tételnévvel vagy rendelésszám-előtaggal jelennek meg. A számlázó beállítása a szabályrendszer bemenete, nem alternatívája.

Belépési pontok#

A bevételi szabályrendszernek nincs saját képernyője a QUiCK felületén. A szabályok beállítása két úton történik:

• Ügyfélszolgálat. A szabályok beállítása, módosítása és törlése az ügyfélszolgálaton kérhető. A kéréshez a kategorizálási igényt üzleti nyelven kell megadni: melyik számlaadat alapján melyik bevételtípus, címke, munkaszám vagy főkönyvi szám kerüljön a számlára.

• QUiCK MCP és nyilvános API. A szabályok a QUiCK MCP get_company és update_company_info műveleteivel, illetve a nyilvános API 2/company-info/ és 2/company-info/update/[CÉG_ID]/ végpontjaival olvashatók és írhatók. Az írás a teljes szabálykészletet cseréli.

A szabályrendszer eredménye a bevétel részleteinél látható: a bevételtípus és a bontás az assignment sorokban, a címke a számla fejlécének címkéi között, a munkaszám és a főkönyvi szám az assignment sor könyvelési mezőiben.

Előfeltételek#

• Beérkező számla. A szabály a számla beérkezésekor fut. Ha a számla már a szabály beállítása előtt beérkezett, akkor a szabály nem fut rá, és a számla kategóriája változatlan marad.

• Érvényes szabálykészlet. A szabálykészlet "v": 2 verziójú JSON-objektum, amely a hozzárendelő szabályokat (policies) és az import-kizárási szabályokat (ignore_policies) tartalmazza. Ha a szabálykészlet formailag hibás, akkor a mentés mezőszintű hibával elutasításra kerül, és a korábbi szabálykészlet marad érvényben.

• Létező bevételtípus, címke és főkönyvi szám. A szabály a bevételtípust és a címkét név szerint, a főkönyvi számot kód szerint hivatkozza. A mentés nem ellenőrzi a hivatkozás létezését. Ha a hivatkozott bevételtípus, címke vagy főkönyvi szám nem létezik, akkor a szabály első futásakor automatikusan létrejön, és a számla erre az új elemre kerül. Elgépelt név vagy kód ezért új, párhuzamos kategóriát hoz létre.

• Haladó könyvelés a főkönyvi számhoz. A főkönyvi szám hozzárendelése a haladó könyvelés beállítást igényli. Ha a haladó könyvelés nincs bekapcsolva, akkor a főkönyvi szám hozzárendelése nem érvényesül.

• Fizetési mód kódja. A fizetési mód szerinti kihagyás a QUiCK fizetésimód-kódját várja (például transfer). Ha a szabály a számlázó nyers fizetésimód-szövegét tartalmazza (például átutalás), akkor a mentés hibával elutasításra kerül.

• Rendelésszám a számlázóban. A rendelésszám szerinti feltétel a számlázóban kitöltött rendelésszámra illeszt, amely a QUiCK-ben a számla másodlagos azonosítója (secondary_id). Ha a számlázóban a rendelésszám üres, akkor a rendelésszám szerinti feltétel nem illeszkedik.

Működés lépésről lépésre#

1. A számla beérkezik. A szabályrendszer a számla első beérkezésekor fut, egyetlen alkalommal. A későbbi szinkronizálás, amely a fizetettséget frissíti, a szabályrendszert nem futtatja újra.

2. Import-kizárás. A szabályrendszer először az import-kizárási szabályokat értékeli. Ha a számla egy import-kizárási szabályra illeszkedik, akkor a számla nem jön létre a QUiCK-ben, és a további lépések nem futnak. Az import-kizárási szabály a számla nyers adataira illeszt: partner neve vagy adószáma, számlaszám, számlatípus, fizetési mód, deviza, forrás.

3. Feltételek kiértékelése. A szabályrendszer minden hozzárendelő szabály feltételeit kiértékeli. Egy feltétel a számla egy mezőjére illeszt: tartalmazza (contains), ezzel kezdődik (begins) vagy reguláris kifejezés (regex). Az illesztés alapértelmezésben nem különbözteti meg a kis- és nagybetűt; a szabály feltételenként kérhet betűhelyes illesztést. Ha egy szabályban több feltétel van, akkor mindegyiknek teljesülnie kell; ha a szabály VAGY-kapcsolatot ír elő, akkor elég egy feltétel teljesülése. A tételnévre vagy tételmegjegyzésre illesztő feltétel akkor teljesül, ha a számla legalább egy tétele illeszkedik.

4. Kihagyási feltételek. Ha a szabály határnapot ír elő, és a számla kelte (vagy a szabályban megadott más dátummezője) a határnap előtti, akkor a szabály nem fut. A határnapon kelt számlára a szabály már fut. Ha a szabály többtételes számlán kihagyást ír elő, és a számlán egynél több tétel van, akkor a szabály nem fut. Ha a szabály adott fizetési módra kihagyást ír elő, és a számla fizetési módja szerepel a listán, akkor a szabály nem fut. Ha egy tétel-feltétel többes találatra kihagyást ír elő, és a számlán egynél több tétel illeszkedik, akkor a szabály nem fut, és a szabály által előírt bontás sem történik meg.

5. Nincs illeszkedő szabály. Ha egyetlen hozzárendelő szabály sem illeszkedik, akkor a számla a partner-alapú automatikus kategorizálás szerint kap bevételtípust: a partner korábbi számlájának kategóriáját. Ha a partnernek nincs korábbi számlája, akkor a számla bevételtípus nélkül jön létre.

6. Egy vagy több illeszkedő szabály. Ha legalább egy szabály illeszkedik, akkor a partner-alapú automatikus kategorizálás nem fut, és a számla adatait kizárólag az illeszkedő szabályok adják. Ha több szabály illeszkedik, akkor mindegyik lefut a szabálykészlet sorrendjében: a címkék összeadódnak, az egyértékű mezőket (bevételtípus, munkaszám, főkönyvi szám) a sorrendben hátrébb álló szabály felülírja. A szabálykészlet sorrendje ezért jelentéssel bír: az általános szabály elöl, a specifikus szabály hátul áll. Ha a szabálykészlet többes találatra kihagyást ír elő, és több szabály illeszkedik, akkor egyik sem fut, és a számla bevételtípus nélkül jön létre.

7. Bontás. Ha egy illeszkedő szabály tételenkénti bontást ír elő, akkor a számla annyi sorra bomlik, ahány tétele van, minden sor a tétel saját nettó, áfa és bruttó összegével, negatív tétel esetén negatív összeggel. Ha egy illeszkedő szabály áfakulcsonkénti bontást ír elő, akkor a számla áfakulcsonként egy sorra bomlik. A sorok összege minden esetben megegyezik a számla fejlécével. A bontást egyetlen illeszkedő szabály előírása is elvégzi; a többi illeszkedő szabály adatai a bontott sorokra kerülnek.

8. Adatok írása. A bevételtípus, a munkaszám és a főkönyvi szám az assignment sorokra kerül, bontás esetén minden sorra azonos értékkel. A címke a számla fejlécének egyszerű címkéi közé kerül, bontástól függetlenül egyszer. Ha a szabály másolást ír elő, akkor a hozzárendelt érték nem a szabályban megadott szöveg, hanem a feltételben vizsgált mező teljes tartalma; tételre illesztő feltételnél az illeszkedő tétel teljes neve vagy megjegyzése, több illeszkedő tétel esetén az utolsó illeszkedő tételé. A másolás a szabály minden adat-kulcsára vonatkozik.

9. Hibaág. Ha a szabály nem létező bevételtípusra, címkére vagy főkönyvi számra hivatkozik, akkor a szabályrendszer a hiányzó elemet létrehozza, és a számlát erre helyezi; hibaüzenet nem keletkezik. Ha az illeszkedő szabályok egyike sem ad bevételtípust, akkor a számla bevételtípus nélkül jön létre, mert a partner-alapú automatikus kategorizálás nem fut. Ha a szabálykészlet mentése formailag hibás, akkor a mentés elutasításra kerül, és a korábbi szabálykészlet marad érvényben.

Állapotok és állapotváltások#

• A szabály futása. A szabály a számla első beérkezésekor fut, egyetlen alkalommal. Nem fut a szabálykészlet mentésekor a már beérkezett számlákra, nem fut a fizetettséget frissítő szinkronizáláskor, és nem fut a bevétel kézi módosításakor. Már beérkezett számlára a szabály semmilyen későbbi eseményre nem fut.

• A szabály eredményének felülírása. A szabály által adott bevételtípus, bontás, címke, munkaszám és főkönyvi szám a bevétel részleteinél, az API-n és az MCP-n bármikor módosítható. A módosítás megmarad: a fizetettséget frissítő szinkronizálás nem állítja vissza a szabály eredményét.

• A szabálykészlet módosítása. A szabálykészlet mentése azonnal érvényes, és a következő beérkező számlára már az új szabálykészlet fut. A mentés a teljes szabálykészletet cseréli: a mentésből kihagyott szabály megszűnik. Az MCP-n keresztül a szabálykészlet nem törölhető, csak üres szabálykészletre cserélhető ({"v": 2, "policies": [], "ignore_policies": []}); a nyilvános API-n a null érték törli a szabálykészletet.

• Bevételtípus, címke és főkönyvi szám létrejötte. A szabályban hivatkozott, nem létező bevételtípus, címke vagy főkönyvi szám a szabály első futásakor jön létre, nem a szabálykészlet mentésekor. Olyan szabály hivatkozása, amely soha nem fut, nem hoz létre semmit.

• Bevételtípus nélküli számla. Ha legalább egy szabály futott, de egyik sem adott bevételtípust, vagy a többes találat miatti kihagyás történt, akkor a számla bevételtípus nélkül jön létre, és címke sem jelzi a kihagyást. A bevételtípus nélküli számla kézi kategorizálásra vár.

• Import-kizárás. Az import-kizárási szabályra illeszkedő számla nem jön létre. Az import-kizárási szabály törlése után a korábban kizárt számla utólagos beérkezése nem dokumentált.

• Sztornó számla. A sztornó számla beérkezésekor a szabályrendszer futása és az eredeti számlára hivatkozó feltétel (referred_invoice_number) viselkedése nem dokumentált.

• Állapotsemleges műveletek. A szabálykészlet olvasása (get_company, 2/company-info/) állapotsemleges. A bevétel részleteinek megtekintése állapotsemleges.

Limitációk és specialitások#

• Tételenként eltérő adat. A szabályrendszer a számlát tételenként bontja, de a bevételtípust, a munkaszámot és a főkönyvi számot minden sorra azonos értékkel adja. A tételre illesztő feltétel azt dönti el, hogy a szabály fut-e a számlára; nem köti az adatot az illeszkedő tétel sorához. Tételenként eltérő bevételtípus a bevétel részleteinél vagy az API és az MCP bevétel-módosító műveletével állítható be. Ismert fejlesztési igény.

• Másolás kinyerés nélkül. A másolás a feltételben vizsgált mező teljes tartalmát adja; a reguláris kifejezés csoportja nem nyerhető ki, és bontásnál soronként eltérő érték nem másolható. Ismert fejlesztési igény.

• Címke csak a fejlécen. A szabály címkéje a számla fejlécének egyszerű címkéi közé kerül; assignment sorra a szabály nem tesz címkét.

• Automatikus létrehozás. A szabályrendszer a nem létező bevételtípust, címkét és főkönyvi számot tervezetten, automatikusan létrehozza; a mentés a hivatkozás létezését szándékosan nem ellenőrzi. A szabálykészlet mentése után a hivatkozott neveket és kódokat a bevételtípus-, címke- és főkönyviszám-törzs ellen ellenőrizni kell, mielőtt az első számla beérkezik.

• Csak címkét adó szabály. Ha egy szabály csak címkét ad, és a számlára más szabály nem ad bevételtípust, akkor a számla bevételtípus nélkül jön létre, mert az illeszkedő szabály a partner-alapú automatikus kategorizálást kiváltja. Tervezett viselkedés; a csak címkét adó szabály mellé bevételtípust adó szabály szükséges.

• Egyszeri futás. A szabály a beérkezéskor fut, visszamenőleg nem. Már beérkezett számlák szabály szerinti átsorolása kézzel vagy az API és az MCP bevétel-módosító műveletével történik. Tervezett viselkedés.

• Életút-információ hiánya. A szabály a számlán nem szereplő információt (új vagy megújító ügyfél, előzmény, szerződés) nem ismeri; ilyen alapú kategorizálás szabállyal nem adható meg.

• Nincs felület, napló és próbafuttatás. A szabályrendszernek nincs saját képernyője; a beállítás az ügyfélszolgálaton vagy az MCP-n és a nyilvános API-n történik. A számlán nem látszik, melyik szabály futott; a szabály által adott címke az egyetlen nyom. Egy szabálykészlet hatása csak új számla beérkezésével mérhető. Ismert fejlesztési igény.

• Számla-szintű munkaszám. A szabály invoice_job_number kulcsa elfogadásra kerül, de az értéke a bevétel részleteinél és az API válaszában nem jelenik meg. Ismert tisztázandó.

• Nem dokumentált viselkedések. Az import-kizárás visszavonása utáni utólagos beérkezés, a magánszemély-szűrő (private_person_indicator), a sztornó számlák kezelése, a számla-módosítás utáni újraszinkronizálás és a kézzel rögzített bevételi bizonylatok kezelése nem dokumentált.