Nucleu

Ce ne trimite Iris înapoi?

Din ședință: „Dă-mi interfața, dă-mi semnătura.”

Nu e o listă simplă de câmpuri, are mai multe niveluri: documentul, liniile lui, grupele de deductibilitate, notele contabile. Exemplul de la tablă: un bon cu șase linii — trei de mâncare, una de băutură, un bacșiș, un discount — dă trei grupe și două note contabile. Forma asta decide ce poate arăta produsul și ce putem trimite mai departe în SAGA. Fără ea nu putem scrie cheltuiala, Lotus n-are pe ce potrivi, iar în SAGA n-avem ce duce.

Findocs scrie direct în baza Atom, sau prin API-ul Atom?

Din ședință: „Scriu direct în baza de date, asta e o variantă. Cealaltă e, dacă nu vreau să scriu eu Findocs în bază, îi dau lui Atom API.”

Pentru client, nicio diferență. Pentru ce urmează, multă: dacă mâine mai scrie cineva în Atom în afară de Findocs, un API e singurul loc în care regulile se aplică o dată pentru toți.

Unde verificăm duplicatele, și ce îi spunem clientului?

Din ședință: „De obicei nu se face aici, se face la destinație, pentru că Iris n-o să fie singurul sistem care bagă date. E o întrebare bună.”

Verificarea se face probabil la capătul din urmă, în Atom, fiindcă Iris n-o să fie singurul care bagă date. Partea de produs e alta: dacă un client încarcă același bon a doua oară, îi spunem „îl avem deja" și se duce să verifice, sau îl ignorăm în tăcere și el rămâne convins că a pierdut un document? Și după ce spunem că două documente sunt același: același fișier, sau același furnizor cu același număr și aceeași sumă? A doua variantă prinde și poza făcută de două ori, din unghiuri diferite.

Ce facem cu documentele care nu sunt tranzacții?

Din ședință: „Vine un om și încarcă o declarație vamală de import. Nu ies note contabile, că e o declarație sau un proces verbal. Dar trebuie să ajungă după aia în Vertigo.”

O declarație vamală de import sau un proces verbal trebuie citite, dar nu produc note contabile. Drumul de mai sus se termină cu „se creează o cheltuială sau o factură". Astea nu creează niciuna, deci ies din drum și nu știm unde ajung: ce status au, unde le vede clientul, unde le vede contabilul.

Ce recipisă primim de la SAGA că un document a intrat?

Vlad, 9 septembrie: „Documente primite de client — avem nevoie de recipisă de procesare de la SAGA? Facturi de intrare → notă contabilă, facturi de ieșire → NC, extras de cont → NC.” În ședință, tot Vlad: „tu trebuie să salvezi în Vertigo o confirmare de la SAGA că s-au salvat lucrurile acolo.” Prodi: „după ce ai importat în SAGA, să poți să citești din SAGA e foarte valoros.”

Azi nu există nicio recipisă: importul e un om care apasă „Import date”, iar API-ul lui Alex știe doar de job-ul de onboarding. Fără o confirmare, Nucleul nu știe niciodată dacă o factură trimisă a și intrat, deci nu poate nici bloca editarea cu încredere (3.1), nici deduplica (1.3), nici marca „în contabilitate” pe ecranul clientului. Confirmarea are două niveluri: rezultatul job-ului (fișier acceptat, respins, cu ce erori) și dovada din bază — factura există în Firebird, cu numărul și data ei.

Propunerea noastră, de confirmat: fiecare fișier trimis la SAGA e un job în API-ul lui Alex, cu rezultat (acceptat / respins + erorile lui SAGA); după job, robotul citește înapoi din Firebird documentele cu numărul și data trimise și întoarce lista celor găsite. Nucleul marchează „în contabilitate” doar pe cele găsite. Recipisa se păstrează în Vault, lângă fișierul trimis.

De unde știe Iris cum e firma: comodat, mașini, plafoane?

Din ședință: „Dacă e combustibil și ai comodat și e 50%.”

Ca să spună „combustibil, 50%", Iris trebuie să știe că firma are sediul în comodat și ce mașini are — lucruri care nu scriu pe bon. Fără ele dă un răspuns generic, care e greșit exact la clienții cu mașini și cu sediul în comodat — adică la mulți dintre ei. Aici întrebăm de unde citește; cine ține datele la zi e la 10.1.

Cine ține mijlocul fix după ce cheltuiala îl creează, noi sau SAGA?

Din ședință: „Ăsta mai poate genera și inventar sau mijloace fixe, în timp ce ăsta nu.”

Inventarul nu apare nicăieri ca bucată de sine stătătoare — apare doar ca urmare a unei cheltuieli. Dacă îl ține SAGA, noi doar marcăm „cheltuiala asta a creat un mijloc fix" și predăm mai departe. Dacă îl ținem noi, ne trezim cu un registru de mijloace fixe — durate, amortizare lunară, scoatere din uz — adică un modul întreg care nu e în nicio estimare. Întrebarea se pune în prima lună, la primul laptop cumpărat.

Vlad, 9 sept — „Imobilizări amortizabile + extrabilanțier — vin din SAGA sau din Iris în urma unei conspectări?” Ce știm de pe 8 sept: mijlocul fix se naște în Iris (din factură), dar registrul și amortizarea trăiesc în SAGA — amortizarea o scrie SAGA singur la închidere, fără niciun fișier de-al nostru. Extrabilanțierul (clasa 8) e tot în balanță. Deci: Iris îl recunoaște, SAGA îl ține, Vertigo îl citește din listarea SAGA (A4) sau din balanță. Dacă SAGA are import de mijloace fixe — Alex (B8).

Când pleacă factura la SAGA, și de când nu se mai poate modifica?

Din ședința de pe 8 septembrie — Raluca: „la români, după ce a plecat în e-Factura și ai acceptul de la ANAF; la străini, imediat.” Cristi: „nu vreau să import în fiecare zi — după ce se termină luna, 100 de facturi deodată… în momentul în care pleacă către SAGA, aș bloca-o de la editare.” Prodi: „o dată pe zi sau ceva… trebuie să existe un timp după care nu mai poți modifica factura aia.”

Lista de facturi din Dublin nu vine din SAGA — e invers, SAGA primește o copie. Deci trebuie o politică: după cât timp pleacă factura, și din clipa aia ea e blocată la editare (corecția rămâne doar prin stornare). Trei variante s-au auzit: la 24 de ore de la emitere (Cristi: „cred că 24 de ore — noi am zis asta”), la acceptul ANAF pentru cele românești, sau abia la închiderea lunii, în lot. Cifrele de sus de pe ecranul Facturi („emis”) rămân ale lui Dublin, în timp real — nu vor bate niciodată cu SAGA la un moment dat, și e în regulă.

Propunerea noastră, de confirmat: pentru facturile românești, pleacă la acceptul ANAF pe e-Factura; pentru străini, la 24 de ore de la emitere. Din clipa în care a plecat, factura e blocată — orice corecție e o stornare. Importul în SAGA se face în lot, dar lotul poate fi zilnic; blocarea nu depinde de el.

Ce înseamnă că un document e „neînchis"?

Din ședință: „Trebuie să știi care-s open items, care-s facturile de aici și de aici.”

Prima întrebare, fiindcă fără ea Lotus n-are prin ce să caute. O factură plătită pe jumătate e neînchisă? Una restantă de anul trecut? Una stornată? Un avans? Răspunsul decide și ce vede clientul pe ecranul de restanțe.

Propunerea noastră, de confirmat: un document e neînchis cât timp ce s-a plătit pe el e mai puțin decât suma lui, oricât de vechi ar fi. Stornarea îl închide. O plată fără document nu e „avans", e o plată fără pereche, și rămâne așa până apare documentul.

După ce potrivim o plată cu un document, și în ce ordine?

Din ședință: „Nimic. S-au desenat formele rezultatului, niciodată criteriile după care se ajunge la ele.”

Nu s-a spus niciodată. Suma singură nu ajunge: două facturi de 500 de lei în aceeași lună nu se deosebesc. Data nici atât. O referință de plată ar ajuta, dar există doar dacă o cerem pe factură — și atunci se schimbă ecranul de emitere din bucata 3. Ordinea criteriilor decide câte potriviri ies singure și câte ajung la un om, adică decide dacă produsul chiar ajută sau doar e corect.

Propunerea noastră, de confirmat: în ordinea asta, și ne oprim la prima care prinde. 1) Referința de plată, dacă există și e exactă. 2) Suma exactă, de la un plătitor pe care îl știm după CUI sau IBAN. 3) Suma exactă, la o dată apropiată de scadență. 4) O sumă mai mică decât o factură neînchisă a aceluiași plătitor — plată parțială. Orice altceva merge la om.

Cine recunoaște ce e o linie din extras, și ce face când nu știe?

Din ședință: „Poate să fie fee sau comision, fee sau taxă, o amendă, un invoice, un expense.” Și, mai încolo, despre Iris: „habar n-are de open items.”

E primul pas al lui Lotus și decide în ce listă caută mai departe. Dacă n-o face Iris, o fac niște reguli scrise de cineva. Și trebuie hotărât și cazul „nu știu": linia rămâne nerecunoscută pe ecran, o întrebăm pe client, sau ajunge la contabil?

Plata are nevoie de Iris, sau nota ei contabilă se știe mereu?

Din ședință: „Poate am o abordare înainte, dar in my mind, din ce am citit eu, plățile se duc pe un cont specific.”

Cele două răspunsuri de mai sus. Aici hotărăște un contabil, nu noi: există cazuri în care contul-pereche al unei plăți nu se poate afla din tranzacția pe care o închide? Dacă nu există, Lotus se descurcă singur, fără să întrebe pe nimeni.

Cum intră plata în numerar și retragerea de la bancomat?

Din ședință: „Bună întrebare. Cred că cash-ul nu se standardizează ca atare, ci se face decont.”

La prima vedere e o contradicție cu o decizie deja luată: plata bifată manual „nu se acceptă", dar o plată cash nu apare în niciun extras. Prodi a dat însă o ieșire, ca ipoteză: firma n-are casă, omul plătește din buzunar și firma îi decontează prin bancă — deci plata adevărată apare în extras, ca decont. Dacă e așa, contradicția dispare, dar bonul trebuie legat de decont, nu de o plată directă. Rămân două lucruri de confirmat de un contabil: că decontul e drumul, și ce facem cu firmele care chiar au registru de casă.

Cum închidem în SAGA o cheltuială trimisă acum o săptămână, fără s-o dublăm?

Din ședință: „Cum ajunge o plată care reconciliază o cheltuială de la noi să stingă o cheltuială pe care eu mai devreme am importat-o în SAGA cu un cod unic?”

S-a hotărât că trimitem cheltuiala în SAGA de la început și revenim când vine plata. Ce nu s-a hotărât e cum arată revenirea: a doua notă trebuie să cadă exact peste prima, prin codul unic, iar SAGA trebuie s-o primească drept completare, nu drept tranzacție nouă. Fără asta, ori dublăm, ori curățăm de mână. E și singurul loc în care codul nostru unic trebuie să însemne ceva într-un sistem care nu e al nostru.

Ce corecții îi permitem omului nostru când nimic nu se potrivește?

Din ședință: „Îți trebuie omul în Vertigo.”

S-a spus doar că „îți trebuie omul în Vertigo". Cum arată ecranul lui e în spec-ul Vertigo; aici e întrebarea dinaintea ecranului — ce operații trebuie să permită Nucleul. Poate lega el de mână o plată de o factură? Poate împărți o plată pe două documente? Poate marca o linie drept comision, fără document? Poate desface o potrivire făcută automat? Fiecare din astea e o operație pe date, cu urme în SAGA. Fără lista lor, Lotus rezolvă cât poate și restul rămâne nicăieri.

Plata fără document: pe ce cont o punem, și cine ține lista?

Din ședința de pe 8 septembrie — Raluca: „Nu se știe din SAGA treaba asta.” Cristi: „pe SAGA nu-l interesează să fie customer friendly… noi în Nucleu trebuie să ținem o tabelă supersimplă cu plățile fără documente.” Otilia: „473 poate să aibă analitic — 473 OMV.”

Ecranul de cheltuieli din Dublin zice „două plăți din extras nu au documente”. SAGA nu poate produce lista asta: odată înregistrat extrasul, banii sunt pe un cont (542 avans spre decontare, pe om) și nu se mai știe care plată așteaptă document. Dacă generalizăm — 900 de lei pe 542, fără să știm 400 de la cine și 300 de la cine — nu mai există potrivire retroactivă când clientul aduce factura peste o lună. Două lucruri de hotărât: contul (542 pe om, sau 473 cu analitic pe furnizor, cum propune Otilia) și cine ține lista — Nucleul, într-o tabelă proprie. Asta e, în cuvintele de azi, ce rămâne lui Lotus.

Propunerea noastră, de confirmat: 473 cu analitic pe partener pentru plățile care au un furnizor recognoscibil (OMV, eMAG), 542 pe persoană pentru restul; Nucleul ține tabela plăților fără document, cu partenerul și suma pe fiecare rând, și o închide când vine documentul.

SAGA calculează taxele în întregime, sau doar le înregistrează?

Din ședință: „Dacă îl întrebi pe Bogdan, oricând o să-l întrebi, o să-ți spună: nu-ți trebuie, îl face SAGA.”

Prodi a spus că ăsta ar fi răspunsul lui Bogdan — „nu-ți trebuie, le face SAGA" — dar în ședință nu s-a confirmat, și pe el s-a sprijinit o estimare de o zi. E diferența dintre un ecran care afișează și un modul care calculează, cu plafoane, cu recalculare și cu un moment în care se trage linia.

Cine scoate tipul, scadența și suma din declarația depusă, și cum?

Din ședință: „Și cum iau taxele? Pentru că în fișierul ăla de multe ori nu scrie pattern-ul taxelor.”

Un lucru ni-l putem da seama singuri: declarația pe care o scoate SAGA este lista taxelor — tip și sumă, altfel n-ar fi declarație — iar scadența vine din calendarul fiecărui tip de declarație, nu din fișier. Deci datele există. Ce nu există e cineva care să le transforme în rânduri. De aici cele patru răspunsuri de mai sus: Iris le citește din PDF, sau le luăm din balanță, sau din altă parte.

Propunerea noastră, de confirmat: SAGA scrie declarația, deci SAGA are rândurile. Cerem robotului același lucru ca la 7.1 — odată cu PDF-ul, să aducă și rândurile: tip și sumă. Scadența o punem noi, din calendar. Nu trece nimic prin Iris.

Cum ajung datele de la 4 Secunde la noi?

Din ședință: „Întrebarea e cum se întâmplă concret. Ia cineva un fișier și îl încarcă undeva într-un site, sau…”

Întrebarea s-a pus exact așa și a rămas în aer: „ia cineva un fișier și îl încarcă undeva?" E diferența dintre automat și manual. Dacă o face un om, o face lunar, pentru fiecare client, la fiecare declarație — la zece clienți nu se simte, la cincizeci devine exact munca pe care produsul trebuia s-o scoată.

Vlad, 9 sept — ce îi trebuie lui Vertigo la fiecare declarație: perioada, data depunerii, indexul ANAF, recipisa. Și întrebarea lui: „care este fluxul declarațiilor din SAGA? cum ajung recipisele în Nucleu?” Azi: SAGA scoate fișierul, depunerea se face prin 4 Secunde, recipisa vine din SPV — drumul de la recipisă la Nucleu e exact întrebarea asta.

Cine marchează o taxă ca plătită?

Din ședință: „Dacă nimeni nu actualizează tabelul ăla, o să fie mereu de plată. Cum devine plătit? Păi nu știu, poate vine un extras de cont și o stinge.”

„Dacă nimeni nu actualizează tabelul ăla, o să scrie mereu de plată." Singura idee spusă a fost „poate vine un extras de cont și o închide". Dacă răspunsul e extrasul, atunci taxele intră în bucata 4, iar Lotus trebuie să potrivească și plăți către stat — adică 4 și 5 sunt un singur drum, nu două.

Ce trece de la SalarEasy spre SAGA: note contabile, sau date brute?

Dacă sunt note gata făcute, Nucleul doar le duce. Dacă sunt date brute, cineva le transformă — și atunci apare un al treilea loc în care se produc note contabile, cu regulile lui de întreținut.

Propunerea noastră, de confirmat cu Alex: SalarEasy dă nota contabilă de salarii gata făcută, cum fac programele de salarizare în general. Nucleul doar o duce în SAGA și păstrează o copie pentru ecrane. Noi nu producem note de salarii.

Vlad, 9 sept — în checklist-ul ERP, importul cheltuielilor salariale are trigger „primire fișier de la Vertigo” și calea Operații → Articole contabile — adică intră ca note contabile, nu ca stat de plată. Deci fișierul pleacă din Vertigo; cine îl produce (SalarEasy sau Vertigo) rămâne întrebarea.

Ce copiem la noi din salarizare, și când?

Din ședință: „Informații de aici o să le facem o copie și la noi, pentru că apar în diverse ecrane. Apar angajații. Apar niște fișiere de tip declarații, 112.”

Lista s-a oprit la „angajații, 112, și altele". Fiecare câmp copiat e un câmp care poate rămâne în urmă față de sursă, iar momentul copierii decide ce vede clientul între închiderea statului de plată și import — dacă vede statul vechi, e mai rău decât dacă nu vede nimic.

Vlad, 9 sept — pe ecranul de salarizare din prototip: „Depunere D112 — cum știm că s-a depus? Din ERP?” (răspuns: din recipisă, vezi 5.1), „plata taxelor salariale — restanțe” (din tabela de stingere, 5.3, la nivel de firmă) și: „celelalte taxe nu sunt afișate nicăieri pentru a fi observate” — Vertigo n-are un ecran de taxe pe firmă, cum are Dublin „De plată”. De adăugat în spec-ul Vertigo.

Cine pune documentele în arhivă, și când?

Din ședință: „Tot ce e document generat de SAGA, depus, că e declarație, că e bilanț, că e fișă de cont, se plasează în storage.”

Dacă e un om, atunci ecranul de contabilitate e o promisiune ținută de mână, lună de lună, pentru fiecare client — și primul lucru care se rupe când creștem.

Propunerea noastră, de confirmat: același robot care duce datele în SAGA aduce și documentele înapoi, după închiderea fiecărei luni, și le pune în arhivă cu luna și categoria pe ele. Fără om la mijloc.

Vlad, 9 sept — „ERP Conta — generare documente și declarații: de stabilit cum ajung aceste documente în Nucleu.” Aceeași întrebare, din partea Vertigo: robot pe folderele SAGA (Alex) sau upload manual (azi).

Ce documente sunt, în total, și cât de des apare fiecare?

Din ședință: „Nu sunt doar declarații, sunt și bilanțuri, fișe de cont, mai sunt și alte, sunt extra declarații.”

Categoriile de pe ecran vin exact de aici. Fără lista întreagă, ecranul e un folder în care clientul caută, nu un loc în care găsește. Iar cât de des apare fiecare decide când îi dăm clientului un task „ai un document nou".

Listă de pornire, de tăiat sau completat de un contabil: lunar — balanța de verificare și declarațiile depuse, care se aplică firmei (100, 300, 112, 394); la cerere — fișele de cont; anual — bilanțul, declarația 101, registrul-jurnal și registrul-inventar.

Cum ajung facturile din SPV la noi?

Din ședință: „Știi ce n-am mai pus? Inputul din SPV în Findocs.”

Pasul dintre SPV și Findocs n-a fost descris niciodată. Dacă merge, o parte din documente nu mai trebuie cerute deloc de la client — și dispar și task-urile care i le cereau.

Mai trec pe la Iris, sau le luăm așa cum vin?

Din ședință: „Știu exact ce este: e-Factura de la Regina Maria, de 500 de lei, din data de ieri. Sută la sută.”

O e-Factura vine deja structurată — știm exact cine, cât și când, fără să citim nimic. Dacă o trecem prin Iris, plătim o citire pentru date pe care le avem. Dacă n-o trecem, cineva tot trebuie să spună cât e deductibilă, și asta e treaba lui Iris.

Propunerea noastră, de confirmat: e-Factura sare peste Remix și peste citire — datele vin din XML — și ajunge la Iris doar pentru verdict: nota contabilă și deductibilitatea. Iris primește un document deja citit și spune doar ce înseamnă.

Cum arată reprezentarea în produs: cine e delegatul, de când, cine apasă?

Întrebările s-au pus una câte una și niciuna n-a primit răspuns. Fără asta nu merge bucata 8, și e primul lucru care se întâmplă cu un client nou. „Am înțeles că e flux operațional. Arată-mi — simulează până la capăt ce se întâmplă, pas cu pas."

Cine ține datele firmei la zi, și ce facem cu documentele deja procesate când se schimbă ceva?

Din ședință: „Ăla o să-l completăm din lista de firme.”

La 2.1 întrebarea e de unde le citește Iris; aici e cine le scrie. Concret: clientul cumpără o mașină pe 15 martie. Cine bifează, și când? Iar bonurile de combustibil din martie, deja trecute prin sistem cu datele vechi, se recalculează sau rămân așa? Fără răspuns, deductibilitatea se schimbă în urmă fără ca nimeni să vadă.

Plafoanele: de unde vin cifra de afaceri și activul net?

Vlad, 9 septembrie: „Plafoane operaționale — cifra de afaceri, suma veniturilor, de unde se calculează? Raport activ net / capital social.”

Vertigo vrea să avertizeze când o firmă se apropie de un plafon — TVA, micro — și când activul net scade sub jumătate din capitalul social. Amândouă sunt cifre contabile, nu de facturare: cifra de afaceri e rulajul cumulat al conturilor de venituri (clasa 70), activul net vine din bilanț (active minus datorii), capitalul social din 1012. Definitiv, ele există doar după închiderea lunii, în balanță — deci același drum ca taxele (5.2). Între două închideri, cifra de afaceri se poate estima din facturile emise în Dublin; activul net nu se poate estima deloc. E aceeași graniță aflată pe 8 septembrie: SAGA calculează, noi citim o dată pe lună; între timp, doar estimări marcate ca atare.

Propunerea noastră, de confirmat: cifra de afaceri — definitiv din balanță (rulaj creditor cumulat clasa 70), estimativ din facturile emise, cu eticheta „estimare”; activul net și capitalul social — doar din balanță, o dată pe lună; plafoanele se compară cu valoarea definitivă, iar avertizarea „te apropii” folosește estimarea. Rândurile exacte din balanță le spune Cristi.

Ce anunță fiecare sistem?

„Nu prezintă mare dificultate. Cât doar să te gândești ce e relevant pentru client, ce sistem publică chestia aia și la ce moment." Gândirea aia e chiar munca, și n-a fost făcută. Feed-ul e singurul loc în care clientul vede că se întâmplă ceva cu firma lui între o factură și alta; fără o listă hotărâtă, e ori gol, ori zgomot.

Listă de pornire, de tăiat sau completat: document primit · document citit · document respins · document pe care îl aveam deja · cheltuială înregistrată · factură emisă · factură încasată · plată potrivită · plată fără pereche · declarație depusă · taxă de plată · taxă plătită · document nou de la contabilitate · salarii închise. Cu o regulă: în feed apare doar ce i-ar spune contabilul clientului la telefon, nu ce face sistemul în spate.

Cine face task-urile — cele de la începutul unui client, cele care se repetă lunar, cele din mers — și cu ce ocazie?

Din ședință: „Ăsta e un fel de task management pentru onboarding și pentru sisteme recurent. Dar nu știm cine bagă aici, cu ce ocazie.”

Trei feluri, cu trei porniri diferite: lista de la început se face o dată pe client nou; cele lunare se repetă din calendar; cele din mers ies din ce se întâmplă în bucăți — o plată fără document, o declarație de aprobat. Dacă niciunul nu apare singur, ecranul de task-uri e o listă ținută de mână de un om, și atunci nu e produs, e un tabel. Întrebarea de fond: produsul cere singur ce-i lipsește, sau doar afișează ce a cerut cineva? E diferența dintre un asistent și o cutie poștală.

Care task se închide la ce anume?

Regula e stabilită: dacă clientul încarcă extrasul din ecranul de plăți, task-ul „încarcă extrasul" trebuie să dispară singur. Dar fără perechile scrise una câte una, regula rămâne o intenție. Un task care nu dispare după ce ai făcut ce cerea e mai rău decât unul care n-a existat: îi spune omului că produsul nu l-a văzut.

Perechi de pornire, din exemplele ședinței: „încarcă extrasul de cont" se închide la extras importat · „lipsesc documente la două plăți" se închide când fiecare din cele două plăți are document · „aprobă înainte de depunere" se închide la aprobat, sau dispare dacă s-a depus pe altă cale · „ai un document nou" se închide la deschidere.

Vlad, 9 sept — la activitățile ERP din prototip (ex. „Calcul impozit trimestrial, Operații → Închidere lună → Impozit profit/venit”): „aceste acțiuni nu sunt operate de un roboțel? cum se marchează aici — automat, manual?” Răspuns de pe 8 sept: nu există robot pentru închidere, o face contabilul pe desktop. Propunere: activitatea se marchează singură când apare documentul ei — balanța încărcată închide „închidere lună”, fișierul D100 închide „impozit”; ce n-are document se bifează de mână.