Explore

Acounto

1) Cél és kontextus

Miért létezik?

Hogy a QUiCK-ben kezelt expense bizonylatai átkerüljenek az Acounto-ba.

Hogy visszakövethető legyen minden feltöltési próbálkozás (státusz, hibaüzenet, időpontok).

🧭 Mikor használd?

Ha egy expense-hez tartozó számlát/bizonylatot az Acounto-ban is látni kell.

Ha hibakeresés kell: “miért nem ment át?”, “mikor próbáltuk?”, “mi volt a hiba?”.

Nem célja

Nem kétirányú szinkron (a kód alapján ez egyirányú feltöltés).

Nem általános dokumentumtár-kezelés, hanem konkrét feltöltési folyamat naplózása.

⁠

2) Mit tud? (üzleti funkciók)

✅ Funkciók

Expense bizonylat feltöltése az Acounto felé (fájl + azonosítók).

Kérésnapló (request log) létrehozása minden feltöltéshez.

Státuszkezelés: pending → success / failure.

Hibaüzenet + HTTP státuszkód tárolása sikertelenségnél.

API kulcs ellenőrzése (validációs hívással).

⁠

3) Hogyan működik? 🧩 (happy path)

A rendszer létrehoz egy AcountoRequestLog bejegyzést (pending státusszal) az expense-hez.

A feltöltés háttérfeladatként (Celery task) indul el a request log azonosítójával.

A feltöltő kliens elküldi a fájlt az Acounto API-nak (multipart feltöltés).

Siker esetén a napló success, hiba esetén failure lesz, és elmentjük a hiba részleteit.

Input:

Expense (azonosító, számlaszám, csatolt fájl/artifact).

Output:

Acounto oldali feltöltés eredménye + nálunk egy request log státusszal és időpontokkal.

⁠

4) Integrációk és exportok

Integráció: Acounto API

Mi a célja? Expense bizonylat fájl feltöltése.

Mit ad át?

resourceType: expense

externalId: az expense belső azonosítója

invoiceNumber: expense invoice number

file: a csatolt dokumentum (mimetype detektálással)

Hitelesítés: x-api-key HTTP header (értékét nem logoljuk itt).

Export

Nincs külön “export” funkció; ez API alapú feltöltés.

⁠

5) Előfeltételek / beállítások

Cégszintű Acounto integráció + API kulcs szükséges (a kulcs a cég integrációs beállításából jön).

Opcionális kapcsoló: a feltöltés globálisan letiltható egy konfigurációval (DISABLE_ACOUNTO_UPLOAD).

⁠

6) Limitációk ⚠️

Csak olyan expense tölthető fel, amihez ténylegesen tartozik fájl (artifact).

A folyamat naplóz, de a kódrészlet alapján a “felhasználói UI lépés”/trigger nem látszik ebből az anyagból. (TBD)

Csomag/jogosultságfüggés: cégintegráció + API kulcs beállítás kell.

⁠

7) Jellemző hibák 🛠️

Tünet: “Nem ment át Acounto-ba / failure státusz”

Első ellenőrzés: request log bejegyzés státusza + hibaüzenete + HTTP kód.

Megoldási irány:

ha “Invalid api key.” → integrációs kulcs ellenőrzése/újragenerálás.

ha “Cannot find expense…” → az adott expense elérhetősége/jogosultságai, törlés/archiválás gyanú.

⁠

8) Fejlesztési tervek 🧪

A forrásból nem derül ki konkrét roadmap. (TBD)

⁠

9) Biztonság és adatkezelés 🔒

Az Acounto felé API kulccsal történik a hívás (x-api-key header).

Nálunk tárolt napló: státuszok, időpontok, hibaüzenet, HTTP kód, fájlnév, és az expense/cég kapcsolás.

A request log admin felületen szűrhető (időintervallum, cég, státusz).

⁠

10) Kapcsolódó linkek

(Nincs megadott külső link a forrásban.)

⁠

11) Kulcsszavak / szinonimák (AI retrieval)

Kulcsszavak: Acounto, integráció, expense, számla feltöltés, bizonylat, request log, státusz, API kulcs

Szinonimák: számla → bizonylat → dokumentum; feltöltés → upload → szinkron (egyirányú)

Kapcsolódó fogalmak: Celery task, pending/success/failure, event log (hibaesemény)

⁠

Acounto integráció — GYIK (edge case-ek)

K: Mi történik, ha a feltöltés le van tiltva? V:

A folyamat logikailag “megáll”: nem indul el az Acounto upload. (Konkrét user-facing üzenet nem látszik a forrásból.)

K: Miért lehet “failure” a státusz, ha az Acounto válasza nem JSON? V:

Ilyenkor a rendszer megpróbálja JSON-ként értelmezni, és ha nem sikerül, a nyers válasz tartalma kerül hibaüzenetként eltárolásra.

K: Milyen státuszok vannak a naplóban? V:

pending: feltöltés elindítva / sorban.

success: sikeres feltöltés, last_synced_at frissül.

failure: sikertelen, hibaüzenet + HTTP kód mentésre kerül.

K: Hogyan ellenőrzi a rendszer, hogy jó-e az API kulcs? V:

Egy Acounto “resource-by-dates” lekérdezést futtat az aktuális napra, és HTTP hibánál “Invalid api key.” hibát dob.

⁠

12) QA CHECKLIST (automatikus)

Van cím + 1 mondatos definíció? ✅

TL;DR blokk megvan (Cél/Kinek/Eredmény/Elérhetőség)? ✅

Cél és kontextus érthető? ✅

Funkciók üzletileg leírva, nem túl technikai? ✅

Happy path lépéses? ✅

Integráció/export (ha releváns) benne van? ✅ (integráció igen, export nem releváns)

Limitációk + tipikus hibák megvannak? ✅

Nincs ígéret, nincs ár, nincs változó infó? ✅

Szellős, jól tagolt, olvasható? ✅

⁠

13) JELZÉSEK (kötelező)

Hiányzó információk / TBD

[TBD] Pontosan mi indítja el az Acounto feltöltést a felhasználói folyamatban (UI gomb, automata státuszváltás, webhook, stb.).

[TBD] Hol és kik tudják beállítani a cég Acounto API kulcsát (admin felület / integrációs képernyő).

[TBD] Van-e üzleti szabály a duplikált feltöltések elkerülésére a UI-ban (a kódban van rá segédfüggvény, de a használata itt nem látszik).

Feltételezések

Feltételezés: az Acounto integráció cégszintű, és csak ott működik, ahol az integráció konfigurálva van.

KONFLIKTUSOK

Ütközés: nem látható ellentmondás a megadott források között.

Kockázat: közepes — a trigger/UI hiánya miatt a “hogyan használja a felhasználó” rész csak részben dokumentálható.

Döntés szükséges? igen — mi legyen a preferált user flow (manuális gomb vs automata esemény)?

Want to print your doc?
This is not the way.

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.