Súgó

Képernyők (17)

• Áttekintés — Az év egy képernyőn. Fölül az eredményhíd mutatja, mekkora a különbség aközött, amit a könyvelés lát, és amit a tulajdonos lát — és pontosan miből áll ez a különbség.
• Költségtételek — Minden könyvelt költségtétel egy listában, szűrhetően. Innen indul a felosztás: kiválasztasz egy tételt, és szétosztod a valódi célok között.
• Bevétel — A bevételi oldal tételesen: melyik számla melyik üzletághoz és projekthez tartozik. Ebből lesz a fedezet másik fele.
• Projektek — Projektenkénti fedezet: bevétel mínusz a projektre terhelt költség. Innen látszik, melyik gépeladás hozott pénzt és melyik nem.
• Partnerek — Partnerenkénti összesítés: mennyit vettünk tőle és mennyit adtunk el neki. Ez váltotta ki a külön RotoMetrics-elszámolást.
• Osztályok — Az osztályok (szerviz, kereskedelem, adminisztráció) költségei és bevételei. A közös kalapba tett költségek innen oszlanak szét.
• Jutalék — Jutalékszámoló szcenáriókkal: a projektfedezetből üzletágankénti kulccsal jutalékalap, abból közös kalap és egyéni rész, az egyéni rész a projekt résztvevői között megosztva.
• Alkatrész / segédanyag — Egy szállítói gyűjtőszámla sorokra bontása: melyik tétel melyik ügyfélhez ment és milyen árréssel. Itt nem százalékot osztunk — a sortétel az elemi egység.
• Jóváhagyás — A javasolt sortétel-bontások jóváhagyása. A javaslatot nem a tulaj készíti — aki tudja, kinek ment, az javasol; a tulaj hagy jóvá.
• Állandó szabályok — A minden hónapban ugyanoda menő költségek (bér, irodabérlet, telefon) egyszeri beállítása, hogy ne kelljen tételenként felosztani. Itt jelölöd azt is, melyik költséghely állandó.
• Párosítás — Költséghelyek és bevételek hozzárendelése projektekhez és üzletágakhoz. Ez tölti fel azt, ami az áttekintésen „nincs besorolva"-ként szerepel.
• CRM-felderítés — Megnézni, mi van a MiniCRM-ben, mielőtt bármit átvennénk: kategóriák, és kategóriánként az első 20 adatlap. Csak olvas, semmit nem ment.
• Import — A havi ÁFA-munkafüzet beolvasása. A könyvelt adat innen kerül a rendszerbe — és innentől módosíthatatlan.
• Napi automata — Az élő táblázat napi behúzása pCloudról, és a futások állapota. Így nem kell kézzel importálni minden hónapban.
• Napló — Minden változás nyoma: ki, mit, mikor, mi volt előtte és mi lett utána. A vezetői réteg bármikor újrahúzható — a napló miatt ez nem jelent adatvesztést.
• Fiók és felhasználók — A saját jelszavad cseréje, és — ha tulaj vagy — a felhasználók kezelése: felvétel, szerep, ki- és bekapcsolás.
• API-kulcsok — A külső hozzáférések egy helyen, hogy ne a Railway változóihoz kelljen nyúlni. Az értékek titkosítva kerülnek az adatbázisba, és a felületen soha nem jelennek meg újra.

A számok magyarázata

Ezek a „? Miből számoltuk?” dobozok szövegei, egy helyen. Nem képernyőkről szólnak, hanem arról, hogy egy-egy szám miből áll össze.

• Miért van két nézet? — Mert két kérdésre kell válaszolni, és a kettő nem ugyanaz.
• Miért nem lehet átírni a költséghelyet? — Mert az a könyvelt adat, és azt adatbázis-szintű őr védi.
• Hogyan működik a felosztás? — Százalékosan, pontosan 100%-ig, és a régi verzió sem vész el.
• Miből jön az eredményhíd? — A könyvelői eredményből, két korrekcióval. Egyik sem szépítés.
• Hogyan számoljuk a projektfedezetet? — Bevétel mínusz a projektre ténylegesen ráterhelt költség.
• Mire jó az arányszám és a vetített bér? — Mert mindenki több kalapot visel, és ezt a mérlegnek tükröznie kell.
• Miből lesz a jutalékalap? — A fedezetből, nem a bevételből.
• Hol a cselekvésrész? — Az 1.0-ban nincs: csak a pénzügyi eredmény számít.
• Mit őriz a napló? — Minden átpakolást, időbélyeggel, indoklással, előtte-utána állapottal.
• Mi történik importkor, és mi a visszavonás? — A séma hangosan bukik, a sorok elnézően jönnek be, és minden visszavonható.
• Hogyan tároljuk az API-kulcsokat? — Titkosítva, és a felületen soha nem jelennek meg újra.
• Milyen szerepek vannak, és ki mit lát? — Négy szerep. A jogosultság a lekérdezésben érvényesül, nem a megjelenítésben.
• Miért van partnerenkénti nézet, és mi lett a Rotometricsszal? — Mert a külön Rotometrics-táblázat a havi lapok kézi másolata volt.
• Honnan jön a bevétel? — A kimenő számlákból — ha be vannak töltve. Különben a törzsadatból.
• Hogyan javasol a gép tétel–projekt párosítást? — Abból, ami a tételen látszik — és csak akkor, ha egyértelmű.
• Miért tároljuk az árfolyamot, és miért nem kérdezzük le mindig? — Mert egy pénzügyi kimutatás nem változhat meg magától.
• Miért sortételes az alkatrész-bontás? — Mert egy szállítói számla 10–15 ügyfélhez tartozik.
• Hogyan bontok gyűjtőszámlát? — Egy kitöltött példa: Bacciottini-számla, 3 sor, 2 projekt.
• Ki javasol és ki dönt? — Az iroda javasol, a tulaj dönt. Két szerep, egy szabály.
• Mit jelent a zöld, a sárga és a piros pont? — Mennyire bízhatsz a gép javaslatában azon a soron.

Miért van két nézet?

Mert két kérdésre kell válaszolni, és a kettő nem ugyanaz.

A könyvelői nézet azt mutatja, amit a főkönyv és a NAV lát: minden tétel azon a költséghelyen, ahova könyvelve lett. Ez az adat soha nem módosul.

A vezetői nézet ugyanazokra a tételekre rakott felosztási réteg. Egy számla megosztható több cél között — projekt, üzletág, osztály, közös kalap, jutalékelőleg —, és ebből számol a projektfedezet meg a jutalékalap.

A lényeg: a vezetői réteg NEM írja át a könyvelői adatot, hanem fölötte él. Bármikor újrahúzható, és minden változás bekerül a naplóba.

Miért nem lehet átírni a költséghelyet?

Mert az a könyvelt adat, és azt adatbázis-szintű őr védi.

A tétel költséghely-kódja és nettó összege módosíthatatlan. Nem azért, mert a felület nem engedi, hanem mert egy adatbázis-trigger dob, ha bárki mégis megpróbálja.

Ha valamit „rossz helyre könyveltek", azt nem javítani kell, hanem felosztani: a vezetői rétegben odakerül, ahova valójában tartozik. A könyvelő és a NAV felé menő szám közben érintetlen marad.

Hogyan működik a felosztás?

Százalékosan, pontosan 100%-ig, és a régi verzió sem vész el.

Egy tétel több cél között osztható szét. A részek összege pontosan 100% kell legyen — a Mentés 99%-nál nem aktív. Ez szándékos: 99%-nál a projektfedezet csendben hamis lenne.

A mentés append-only. A korábbi sorok nem törlődnek, csak érvénytelenné válnak, és újak szúródnak be ugyanabban a tranzakcióban. Így a „húzzuk újra" nem jelent adatvesztést.

Ahol még nincs kézi felosztás, ott a könyvelésből következő alap-hozzárendelés számít. Ezért a projektfedezet akkor is értelmes számot ad, ha még senki nem pakolt át semmit.

Miből jön az eredményhíd?

A könyvelői eredményből, két korrekcióval. Egyik sem szépítés.

A könyvelői eredmény: az összes bevétel (projektek és üzletágak) mínusz az összes könyvelt költség.

Első korrekció — NAV ÁFA-befizetés: a 280-as költséghely összege. Ez átfolyó pénz: a vevőtől beszedett adót továbbítjuk. Költségként jelenik meg, de nem a cég vagyonát csökkenti.

Második korrekció — készlet: az „átnyúló" típusú projektekre terhelt költség. Beszerzett, de még nem értékesített gép. A könyvelés az évben költségnek látja, a tulajdonos raktárban álló értéknek.

A vezetői eredmény a három szám összege. A záró sor mindig pontosan az előzők összege — ezt teszt őrzi.

Hogyan számoljuk a projektfedezetet?

Bevétel mínusz a projektre ténylegesen ráterhelt költség.

A ráterhelt költség a vezetői felosztásból jön: minden tételből annyi számít a projektre, amennyi százalékban oda lett osztva.

Ahol nincs felosztás, ott a könyvelésből jövő alap-hozzárendelés érvényes. Ahogy a felosztások készülnek, a szám finomodik, nem ugrik.

A „készlet — nem értékesített" projekteknél a fedezet szándékosan negatív: a gép megvan, csak még nem adtuk el. Ez a szám megy át az eredményhídba korrekcióként.

Mire jó az arányszám és a vetített bér?

Mert mindenki több kalapot visel, és ezt a mérlegnek tükröznie kell.

Kristóf nem „logisztikás", hanem 55%-ban logisztika és 45%-ban értékesítés. Ha egy embert egyetlen osztályhoz kötnénk, az osztálymérleg már az első napon hamis lenne.

A vetített bér a bérköltséget osztja szét osztályokra ezeken az arányokon át. A részek összege pontosan a bérköltség — kerekítési maradék nélkül.

FONTOS KORLÁT: amíg nincs személyenkénti bér az importban, fejenként egyenlő résszel számolunk. Ez szándékosan durva. Amint a bérsorok személyhez kötve jönnek, a szám pontosabb lesz, a mechanika nem változik.

Miből lesz a jutalékalap?

A fedezetből, nem a bevételből.

A jutalékalap a projektfedezet és az üzletág jutalékkulcsának szorzata. A fedezet az, ami a projekten ténylegesen maradt: bevétel mínusz a projektre terhelt közvetlen költség. Az állandó költségek az 1.0-ban nem számítanak bele.

Az alap egy része a KÖZÖS KALAPBA megy, a többi az EGYÉNI RÉSZ. Az egyéni részen a projekt résztvevői osztoznak (50/50, 75/25…), a közös kalapot pedig az év végén a kollégák kapják a beállított részesedés szerint — az is, aki problémát old meg, de nem termel számot.

Minden szám szcenárióként állítható, menthető és összevethető. Az ÉLESÍTETT szcenárió megy a hivatalos elszámolásba. Garanciális visszatartás alapból nincs; a korábban kifizetett előleg levonódik. A kifizetés soha nem negatív.

Veszteséges projekt után nincs jutalék, de a negatív fedezet látszik — nem tüntetjük el.

GARANCIÁLIS JAVÍTÁS: ha egy költséget a felosztóban „garanciális javítás"-nak jelölsz, az a projekt fedezetét csökkenti (utókalkuláció), a jutalékalapot viszont nem — az az eredeti kalkulációból megy. A projektlistán a költség alatt „ebből garanciális", a fedezet alatt „eredeti kalk." látszik.

Hol a cselekvésrész?

Az 1.0-ban nincs: csak a pénzügyi eredmény számít.

A cselekvésrész (határidőtartás, lejárt teendők, CRM-aktivitás) a 2026-09-29-i megbeszélés döntése szerint kikerült az 1.0-ból.

Minőségi mutatót előbb a kollégákkal kell megbeszélni, és mérni is tudni kell. Amíg ez nincs, a jutalék teljes egészében a projektfedezetből számol.

A 2.0-ban, a CRM-bekötés után visszajöhet mint külön, állítható súly.

Mit őriz a napló?

Minden átpakolást, időbélyeggel, indoklással, előtte-utána állapottal.

Felosztás mentése, sortétel ügyfélhez rendelése, jóváhagyás, elutasítás, arányszám-állítás, jutalékbeállítás, import és visszavonás — mind bekerül.

A napló a „húzzuk újra, de maradjon meg minden" kérés megvalósítása. Semmit nem törlünk: ami változik, annak a korábbi állapota is megmarad.

A napló a vezetői réteg története, ezért csak a tulaj látja.

Mi történik importkor, és mi a visszavonás?

A séma hangosan bukik, a sorok elnézően jönnek be, és minden visszavonható.

Ha hiányzik egy kötelező oszlop, egyetlen sort sem írunk be, és megnevezzük, mi hiányzik. Jobb a tegnapi igazság, mint a mai kásahegy.

Soronként viszont elnéző az import: egy rossz dátum nem buktatja el a másik 221 sort. A kimaradt sorok bekerülnek a riportba, sorszámmal és okkal.

A Próba gomb semmit nem ír: megmutatja, mi jönne be. Érdemes mindig azzal kezdeni.

A visszavonás nem töröl. A sorok maradnak, csak érvénytelenné válnak, és sehol nem számítanak bele semmibe. Egy kattintással visszakapcsolhatók.

Hogyan tároljuk az API-kulcsokat?

Titkosítva, és a felületen soha nem jelennek meg újra.

Ezek élő hozzáférések idegen rendszerekhez: levélküldés, pCloud, AI. Ha valaki megszerzi az adatbázis-mentést, a nyílt kulcsokkal azonnal dolgozhatna.

Ezért AES-256-GCM titkosítással tároljuk őket. A titkosítás kulcsa az ADMIN_SESSION_SECRET-ből származik, ami környezeti változó — NEM az adatbázisban van. Egy ellopott mentés önmagában nem elég a visszafejtéshez.

A kulcs értéke soha nem jelenik meg a felületen és soha nem kerül a naplóba. A napló csak azt rögzíti, hogy melyik kulcsot állították be vagy törölték, mikor és ki.

Két forrás van, egyértelmű sorrendben: ha a felületen be van állítva, az számít; ha nincs, a Railway környezeti változója. Így a régi beállítás tovább él, de felülírható újratelepítés nélkül.

A „Kipróbálom" gomb élő hívást indít az adott szolgáltatáshoz. Egy elgépelt kulcs különben csendben marad, amíg valaki nem vár levelet vagy napi importot.

Milyen szerepek vannak, és ki mit lát?

Négy szerep. A jogosultság a lekérdezésben érvényesül, nem a megjelenítésben.

Tulaj: mindent lát és szerkeszt, ő dönt a javaslatokról, és ő kezeli a felhasználókat.

Könyvelő: csak a könyvelői nézet, csak olvasás — a vezetői réteget nem kapja meg. CSV-exportot viszont igen, mert neki az a fő használat.

Kereskedő: csak azok a projektek és tételek, ahol ő a felelős. Az idegen tétel nem „letiltott", hanem NEM LÉTEZIK: a darabszámban és az összegben sem jelenik meg.

Iroda: sortételt bonthat és javasolhat, de nem hagy jóvá.

A jelszónál a hosszúság számít, nem a karakterkeverék — a minimum 12 karakter. Más jelszavát senki nem tudja megnézni, és nem küldünk jelszót e-mailben.

Az utolsó aktív tulaj nem kapcsolható ki, és a szerepe sem vehető el. Enélkül ki lehetne zárni magunkat a rendszerből.

Miért van partnerenkénti nézet, és mi lett a Rotometricsszal?

Mert a külön Rotometrics-táblázat a havi lapok kézi másolata volt.

A munkafüzetben volt egy „RotoMetrics utalások" lap 540 sorral. Sokáig úgy tűnt, hogy ez külön elszámolás, aminek külön modul kell.

A lap viszont maga kiírja: „ez a lap a havi lapok RotoMetrics-tételeinek kézi másolata. Minden módosítást két helyen kell átvezetni. Használd helyette a havi lapok partnerszűrőjét." Ellenőrizve: 509 számlaszámból 509 átfedés.

Ha beimportálnánk, 510 számlát könyvelnénk el kétszer. Ezért NEM importáljuk — az adat már bent van a havi lapokról.

Ami hiányzott, az a partnerszűrő. Ez a nézet azt adja meg, és nem csak a Rotometricsra: minden szállítóra és vevőre ugyanúgy működik, költséggel és bevétellel egy sorban.

Honnan jön a bevétel?

A kimenő számlákból — ha be vannak töltve. Különben a törzsadatból.

A munkafüzet havi lapjain a kimenő és a bejövő számlák együtt állnak. A kimenők a bevételoldal: ezek külön táblába kerülnek, mert a bevételt nem osztjuk fel költséghelyek között.

A bevételi költséghelyek (500-tól felfelé) üzletághoz köthetők: alkatrész, segédanyag, szerviz. Ami nincs üzletághoz kötve — tipikusan a gépértékesítés —, az benne van az eredményhídban, de az üzletág-fedezetben nem jelenik meg; az projekthez tartozik.

Ha nincs tételes bevétel betöltve, a híd visszaesik a projekt- és üzletág-törzsbe kézzel beírt számra. Ilyenkor a főoldal KIÍRJA, hogy az történt — a vezetői eredmény addig tájékoztató, nem hiteles.

A bevételre ugyanaz a kóser védelem vonatkozik, mint a tételre: a könyvelt költséghely és a nettó összeg adatbázis-szinten módosíthatatlan.

Hogyan javasol a gép tétel–projekt párosítást?

Abból, ami a tételen látszik — és csak akkor, ha egyértelmű.

A projektazonosító a CRM-ből jönne, de a hozzáférés még nincs meg. Addig a párosítás abból dolgozik, ami a tételen látszik: partner, megnevezés, jelzés, összeg.

A legerősebb jel a tételen szereplő projektazonosító. Utána a partneregyezés, végül a megnevezés szóátfedése. Ha a tétel nagyobb, mint a projekt bevétele, az levonást és külön jelölést kap.

Ha két projekt majdnem ugyanolyan jól illik, a gép NEM javasol. A holtverseny nem döntés — az ilyen tétel marad kézre.

Minden javaslat megmondja, miért javasolja. Enélkül nem lehet felelősen elfogadni.

Az elfogadott javaslat ugyanolyan felosztás-sor, mint a kézi — csak meg van jelölve, hogy gépi javaslatból származik.

Miért tároljuk az árfolyamot, és miért nem kérdezzük le mindig?

Mert egy pénzügyi kimutatás nem változhat meg magától.

Egy 2025-ös eurós számlát a 2025-ös árfolyamon kell forintosítani. Ha minden megjelenítéskor a mai árfolyamot húznánk le, a tavalyi kimutatás holnap más számot mutatna.

Ezért az MNB napi árfolyamait eltároljuk, napra és pénznemre bontva. A napi automata frissíti őket.

Az egység nem mindig 1: az MNB a jenre 100-as egységgel ad árfolyamot. Aki ezt kihagyja, százszoros értéket számol — ezért külön mezőben tartjuk.

A napi automata minden futása naplózódik, sikeres is és hibás is. Enélkül nem derülne ki, ha csendben leáll — és pont az a veszélyes eset.

Miért sortételes az alkatrész-bontás?

Mert egy szállítói számla 10–15 ügyfélhez tartozik.

Egy hónapban milliók mennek el beszerzésre, és az sok ügyfél. Itt nem azt kérdezzük, hány százalék megy hova, hanem azt, hogy KINEK adtuk el és MILYEN ÁRRÉSSEL.

Ezért az elemi egység a sortétel, nem a számla. Minden sor egy ügyfélhez tartozik, saját eladási árral.

Az árrést az eladási árra vetítve számoljuk: (eladás − beszerzés) / eladás. A beszerzésre vetített változat a haszonkulcs, az más szám.

Fogalmilag: a segédanyag elfogy (lakk, festék, mosószer), az alkatrész elkopik (csapágy, kés) — de a kezelésük egy modul.

Hogyan bontok gyűjtőszámlát?

Egy kitöltött példa: Bacciottini-számla, 3 sor, 2 projekt.

A példa: a Bacciottini egy számlán három alkatrészt számláz, nettó 1 000 000 Ft. 1. sor: hengerkés, 450 000 Ft — a Pannon Nyomda gépéhez (P-2025-014). 2. sor: csapágykészlet, 350 000 Ft — ugyanahhoz a géphez (P-2025-014). 3. sor: gumikendő, 200 000 Ft — az Alföld Print gépéhez (P-2025-021).

1. lépés — az Alkatrész képernyőn nyisd meg az „Új gyűjtőszámla" dobozt, és keresd ki a Bacciottini-számlát a könyvelt tételek közül. A szállító, a dátum és az 1 000 000 Ft onnan jön, nem gépeled újra.

2. lépés — vidd fel a három sort (kézzel, vagy számlakép feltöltésével), és mindegyiket rendeld a vevőhöz: az első kettőt a Pannon Nyomdához, a harmadikat az Alföld Printhez. Ha tudod az eladási árat, írd be — abból lesz az árrés.

3. lépés — ugyanitt, a „Projektekre" dobozban: válaszd ki a P-2025-014-et, és pipáld ki az 1. és 2. sort (800 000 Ft); aztán válaszd a P-2025-021-et, és pipáld ki a 3. sort (200 000 Ft). Pipálás helyett fix összeget is írhatsz egy projekthez — a kettő összeadódik. A „Még kiosztatlan" sor 0 Ft; ami ott marad, a közös kalapba megy. A projektekre tett összeg a számla nettóját 1 forinttal sem lépheti túl.

Mentéskor a könyvelt tétel vezetői felosztása fix forintokkal íródik (P-2025-014: 800 000 Ft, P-2025-021: 200 000 Ft) — nem kerekített százalékkal. A régi felosztás a naplóban megmarad.

Ellenőrzés: a két projekt fedezetében a ráterhelt költség 800 000 és 200 000 Ft-tal nő, a könyvelői nézetben a számla ugyanazon a költséghelyen marad, ahova könyvelték.

Ki javasol és ki dönt?

Az iroda javasol, a tulaj dönt. Két szerep, egy szabály.

Az iroda tudja, kinek küldte tovább az alkatrészt — ő javasol. A tulaj tudja azt, amit csak ő hallott a tárgyaláson — ő dönt. Ha mindketten pakolgatnának, megint nem lenne jó a szám.

Az állapotok: bontatlan → javasolt → jóváhagyott vagy elutasított. Az elutasított sor újra javasolható — ez a javítás útja.

Egy jóváhagyott sor módosítása visszaállítja javasolt állapotba, és törli a jóváhagyó nevét. Nem csúszhat át változtatás jóváhagyás nélkül — és ezt adatbázis-trigger őrzi, nem a képernyő.

Van tömeges „Mind jó" gomb, mert ez heti rutin, nem esemény.

Mit jelent a zöld, a sárga és a piros pont?

Mennyire bízhatsz a gép javaslatában azon a soron.

Zöld: a cikkszám és az ügyfél is egyértelmű. Sárga: az ügyfél valószínű, de nézd át. Piros: nem találtunk ügyfelet, vagy nem stimmel a számtan.

A bizonyosság NEM a gép önbevallása. Ellenőrizhető jelekből áll össze — és ha a mennyiség × egységár nem adja ki a sorösszeget, a sor mindig piros, akármit mond a modell.

Amit a gép ad, az javaslat, nem tény. Semmi nem kerül be megnézés nélkül, és minden AI-ból származó sor meg van jelölve.