Eliberează capitalul de lucru blocat în stocul excedentar.
marql găsește stocul peste acoperirea țintă pe SKU și locație, evaluează capitalul din exces pornind de la costurile tale reale și îl transformă într-un plan cu responsabil, termen și dată de control.
Identificat
2.728 €
capital la cost
- prioritizat în €
- calculat din datele-sursă
- efect doar după măsurare
Se vinde. Stocul rămâne excedentar.
La Maison Marché apa minerală nu este stoc mort: ultima vânzare a fost azi. Dar acoperirea a ajuns la 110 zile, față de un bufer-țintă de 7 zile. marql a calculat excesul față de bufer plus termenul de livrare, a evaluat la cost capitalul blocat în el și a pus opțiunile pe masă.
- 110
- zile de acoperire
- 7
- buferul-țintă
- 2.728 €
- capital la cost
- 35
- zile de abatere
De la abatere la efect măsurat.
Semnalul, diagnosticul, acțiunea de management și evaluarea rezultatului sunt un singur proces — fără ruptura dintre analiză și ce face efectiv cineva.
Stocul excedentar se vede înainte de închiderea perioadei.
Rularea zilnică pe SKU × locație găsește unde zilele de acoperire depășesc ținta și ordonează abaterile după capitalul pe care îl ține fiecare exces.
Monitorizare automată · SKU × locație
Arată cauza abaterii și variantele de acțiune.
marql separă stocul mort de un SKU care se vinde, dar are acoperire prea mare, citind viteza de vânzare, factorul meteo și disponibilitatea în celelalte locații. Apoi propune: oprirea reaprovizionării, accelerarea vânzării prin promoție, transfer între locații sau ajustarea pragului.
7 factori citiți · calcul verificat pe date
Cantitatea recomandată vine dintr-un model de stocuri.
ShelfSense citește stocul curent, consumul mediu zilnic (ADU), termenul de livrare și buferul-țintă. AI-ul explică logica; cantitatea în exces și capitalul din ea se calculează determinist.
Stoc 4.625,6 · prognoză 39,2 unități/zi
Efectul se recunoaște doar după perioada de control.
După confirmarea acțiunii, marql fixează perioada de bază și fereastra de măsurare. Impact Ledger ține separate șase stări — „identificat”, „se măsoară”, „dovedit”, „fără efect”, „neconcludent” și „mai rău” — și îngheață venitul față de care se măsoară efectul în momentul în care decizia e confirmată, așa că rezultatul nu poate fi umflat ulterior.
Perioadă de bază · control unde există · istoricul modificărilor
110 zile pot fi răspunsul corect.
Calculul de mai sus nu se discută: 4.076,8 unități sunt peste acoperirea-țintă, iar capitalul din ele se evaluează la 2.728 € pornind de la cost. Se discută dacă asta e o greșeală. În cel puțin cinci situații obișnuite acoperirea e mare intenționat, iar cine acționează totuși pe semnal distruge o decizie deja luată bine de altcineva.
Constituire sezonieră
Cumperi sezonul, nu săptămâna. Acoperirea măsurată față de o normă de 7 zile la jumătatea constituirii pentru un vârf aflat la șase săptămâni e corectă aritmetic și lipsită de sens operațional — stocul e înaintea cererii, nu în urma ei.
Același SKU, aceleași săptămâni anul trecut: dacă ritmul de atunci era de câteva ori mai mare decât cel actual, acoperirea e o constituire. Dacă anul trecut arată ca anul acesta, nu este.
Cantitatea minimă de comandă a furnizorului
Când MOQ-ul e un palet și locația vinde patruzeci de unități pe săptămână, cea mai mică comandă acceptată de furnizor înseamnă deja unsprezece săptămâni de acoperire. Achiziția nu are nimic greșit. Norma a fost scrisă pentru SKU-uri care pot fi comandate în cantitatea de care ai efectiv nevoie.
MOQ împărțit la consumul mediu zilnic. Dacă doar asta depășește norma, nicio comandă acceptată de furnizor nu o poate respecta, iar norma e ce trebuie schimbat.
Achiziție cu preț blocat
O creștere confirmată, o promoție la furnizor sau expunerea valutară pot face cumpărarea în avans mai ieftină decât cumpărarea la acoperire. Stocul nu e capital inactiv; e o acoperire de risc cu un câștig cunoscut și o dată.
Economia pe unitate față de costul de stocare pe unitate pe durata deținerii. Și dacă decizia e scrisă altundeva decât în memoria achizitorului — o acoperire de risc neînregistrată nu se deosebește de o supra-comandă.
Pre-constituire pentru o promoție programată
Acoperirea înaintea unei campanii care are dată, mecanism și prognoză nu este exces. Este campania. Alerta e devreme, nu greșită.
O promoție în calendar a cărei prognoză consumă acoperirea, și un responsabil numit pentru rest, dacă nu se vinde.
Acoperire deliberată împotriva riscului de aprovizionare
Un SKU cu sursă unică, o întârziere în vamă, un furnizor care a ratat deja de două ori — săptămânile suplimentare cumpără disponibilitate, iar lipsa de la raft la un produs de bază costă de obicei mai mult decât stocarea lui.
Dacă termenul de livrare din sistem e cel contractat sau cel observat în realitate. O normă calibrată pe un contract pe care nimeni nu-l respectă va semnala prudența ca risipă în fiecare săptămână.
Pe scurt
Niciunul dintre aceste cazuri nu face banii să reapară: capitalul e blocat cu adevărat în toate cinci, iar asta merită știut. Se schimbă doar răspunsul: „păstrăm, și iată de ce”, nu „eliberăm”. marql poate recunoaște motivul doar acolo unde motivul e în date — un calendar de promoții, o cantitate de comandă, un termen de livrare observat. Unde nu este, SKU-ul e semnalat și achizitorul suprascrie decizia, iar suprascrierea e înregistrarea utilă.
Semnalul era corect. Decizia a eșuat oricum.
Cinci moduri în care o decizie pe stoc excedentar merge prost după ce abaterea s-a confirmat, în ordinea în care apar: cauza citită greșit, destinația greșită, prețul greșit, remediul greșit și contabilizarea greșită. Sunt construite, nu observate — nu stau cifrele niciunui lanț în spatele lor.
O singură acțiune pentru stoc mort și pentru un SKU rapid
Două rânduri stau unul lângă altul în aceeași listă, ambele peste 100 de zile de acoperire. Unul nu a vândut nicio unitate în șase săptămâni. Celălalt a vândut în dimineața asta. O reducere lichidează primul și dăruiește marjă la al doilea, care s-ar fi vândut la preț întreg — mai încet decât voiai, dar la preț întreg. Oprirea reaprovizionării rezolvă al doilea și nu face nimic pentru primul, fiindcă nu e nimic în comandă.
Citește cauza înainte de a alege acțiunea. Data ultimei vânzări, rotația pe fereastră și dacă există ceva în comandă: trei câmpuri care despart un SKU oprit de unul supra-acoperit, și care indică acțiuni opuse.
Un transfer către o locație care nici ea nu poate vinde
Excesul e real și remediul pare evident — mută marfa într-o locație care are același SKU. Doar că locația care primește e la 40 de zile față de aceeași normă de 7 zile; e doar mai puțin vizibil greșită. Stocul ajunge, alerta se stinge la expeditor, iar același capital rămâne blocat la o adresă mai încolo, acum cu costul transferului adăugat.
Un transfer contează ca remediu doar dacă acoperirea proprie a locației care primește rămâne în norma ei după ce marfa ajunge. Adică cererea acelei locații, nu media rețelei. Dacă nicio locație nu trece testul, asta e o problemă de preț sau de achiziție, nu de distribuție.
O reducere care costă mai mult decât stocarea
O reducere suficient de adâncă ca să lichideze patru mii de unități în două săptămâni dăruiește mai multă marjă brută decât costa excesul ca să fie ținut. În joc sunt două numere diferite — capitalul din exces și cât costă pe săptămână să-l ții acolo — iar reducerea trebuie să bată al doilea, nu primul. Raportată la capital, aproape orice reducere pare justificată. Raportată la costul săptămânal de stocare, majoritatea celor adânci nu sunt.
Compară marja dăruită cu costul de stocare pe perioada în care ai ține altfel marfa, plus riscul de casare la expirare. La un SKU cu termen lung și fără dată de expirare, „nu faci nimic” e adesea cea mai ieftină acțiune disponibilă.
Ridicarea pragului în loc de anularea comenzii
Norma e 7 zile, acoperirea e 110, iar cea mai rapidă cale de a opri alerta e să decizi că norma era greșită. Uneori era — asta e secțiunea anterioară. Dar când norma era corectă, mutarea ei transformă o problemă de achiziție în una de raportare: capitalul rămâne exact unde era, semnalul nu mai ajunge, iar următoarea supra-comandă e invizibilă.
Schimbarea pragului e un rezultat legitim doar când e argumentată din cerere, termen de livrare sau cantitate de comandă, și doar când lasă o înregistrare despre cine a schimbat-o, de la ce și de ce. Dacă norma se mută și comanda deschisă nu, nu s-a rezolvat nimic.
Înregistrarea economiei înainte de închiderea ferestrei
Acțiunea se execută, acoperirea scade, iar cei 2.728 € se trec drept recuperați. Apoi se află că săptămâna în care s-a mișcat stocul a fost săptămâna în care un concurent s-a închis pentru renovare, sau că un val de căldură a vândut apa fără ajutor. Atribuirea asta deciziei umflă registrul, iar orice cifră înregistrată după ea moștenește eroarea.
Perioada de bază și fereastra de măsurare se fixează la confirmarea acțiunii, niciodată alese după ce rezultatul e cunoscut. Impact Ledger trebuie să aibă dreptul să răspundă „fără efect” și „date insuficiente” — un registru care spune doar „dovedit” nu măsoară nimic.
Pe scurt
Niciunul din cele cinci nu e o eroare de aritmetică — semnalul a fost corect în toate. Patru sunt o acțiune greșită aleasă dintr-un număr corect, iar al cincilea e o acțiune corectă înregistrată necinstit. De asta există secțiunile de o parte și de alta: una întreabă dacă numărul înseamnă ce pare, cealaltă spune cine are dreptul să acționeze pe el.
Începe cu ce contează
Care SKU-uri blochează capital de lucru fără să se rotească suficient de repede?
- 01Unde e concentrat stocul excedentar — pe SKU, categorie și locație?
- 02Este stoc mort, un SKU cu rotație lentă sau un surplus temporar?
- 03Unde oprim reaprovizionarea, unde reducem prețul, unde promovăm, unde transferăm?
- 04Care locații pot prelua SKU-ul, ținând cont de cererea și de stocul lor?
- 05Cât capital de lucru se poate elibera fără să crească lipsa de la raft?
- 06Fă planul: acțiune, responsabil, termen și dată de control.
De ce e nevoie ca să calculăm excesul.
Vânzări pe SKU × locație
Cantitate, venit, data ultimei vânzări, locația și categoria.
Stoc curent + cost de achiziție
Fără costuri se poate număra cantitatea în exces, dar capitalul blocat în el nu se poate evalua — așa că coloana cu bani rămâne goală, nu estimată.
Termen de livrare + marfă comandată
Furnizor, comenzi deschise, depozit central, termen de valabilitate și transferurile între locații care sunt efectiv posibile.
Cum s-a calculat
Scanarea, fereastra și aritmetica.
O scanare la nivel de SKU parcurge rândurile zilnice pe produs — vânzări, cost, stoc — și numește exact SKU-urile din spatele sumei, astfel încât fiecare poartă contribuția proprie, nu o parte dintr-un total.
Rânduri zilnice pe SKU, pe o fereastră de 7–28 de zile, lungimea depinzând de verificare. Verificările de trend compară două ferestre adiacente de lungime egală.
- unități în exces = stoc curent − consum mediu zilnic × (termen de livrare + bufer-țintă)
- capital în exces = unități în exces × cost unitar
- Sincronizare POS / ERP
- product_sales_daily · inventory_daily
- scanare SKU
- incident
- inventory_daily
- qty_in_stock, cost_value, category_name
- product_sales_daily
- items_count, cost, category_name
Cele două ecuații de mai sus reproduc exact capturile. Zilele de acoperire nu decurg din ele: nu sunt stocul curent împărțit la prognoza tipărită lângă el, fiindcă o verificare de abatere și un model de stocuri citesc consumul pe ferestre diferite ale acelorași rânduri zilnice. De aceea blocul tipărește modelul, nu o singură împărțire — și de aceea cifra pe care o produce este capital evaluat la cost, nu o cheltuială. Cât costă pe săptămână deținerea acelui capital e un număr separat, și e cel pe care o reducere trebuie să-l bată.
Verifică pe cifrele tale
Cele două ecuații de mai sus, cu câmpurile la vedere. Se deschide pe datele acestui playbook, așa că prima cifră pe care o afișează e cea din titlu — schimbă orice câmp și aritmetica urmează.
- Unități în exces
- 4.076,8
- Capital în exces
- 2.728 €
Nu calculează zilele de acoperire și nu calculează cât costă pe săptămână deținerea stocului. Prima are nevoie de fereastra de consum pe care pagina asta nu a fixat-o; a doua are nevoie de o rată de stocare, iar inventarea uneia ca să pară calculatorul complet e exact genul de cifră pe care acest playbook există ca să o refuze.
O acțiune are nevoie de un nume. Numele decurge din perimetru.
Ciclul se încheie cu o acțiune care are responsabil, termen și dată de control — iar responsabilul e partea pe care pagina o lăsa necompletată. Cine anume nu ține de vechime. Ce poate decide un rol e limitat de ce poate vedea acel rol, iar marql livrează trei perimetre care văd lucruri diferite: aceeași dimineață pune un stoc excedentar într-un inbox și nu în altul.
Manager de magazin
Doar propriile locații și o parte din incidentele deschise ale rețelei. E și singurul perimetru care primește percentile de cohortă — unde stau marja și bonul mediu ale fiecărei locații față de o rețea anonimă de locații comparabile.
- Realitatea de la fața locului: dacă marfa e fizic acolo, dacă se poate vinde și dacă e în starea în care o crede sistemul.
- Execuția unei reduceri sau a unui capăt de transfer, odată ce adâncimea și destinația sunt stabilite.
- Ridicarea unui contra-caz: promoția pe care nimeni nu a înregistrat-o, paletul care nu s-a putut împărți, livrarea venită de două ori.
Transferul, adâncimea reducerii și pragul. Fiecare are nevoie de o cifră din afara acestui perimetru — cel mai limpede transferul, al cărui test întreg e cum arată acoperirea locației care primește, după. Iar locația aceea nu e în acest inbox.
Dacă acoperirea în propriile locații revine în normă și dacă contra-cazul ridicat s-a confirmat.
Manager regional
Un grup de locații, care duce incidente invizibile pentru perimetrul de magazin de sub el — inclusiv un stoc excedentar la o locație din afara listei acelui manager de magazin.
- Transferul, fiindcă acesta e primul perimetru care vede ambele capete ale unuia.
- Alegerea între a muta marfa și a o reduce — comparația pe care se sprijină modul de eșec 02.
- Care exces de locație e problema rețelei și care e una locală.
Achiziția care a creat excesul și norma însăși, acolo unde e stabilită central. O regiune poate reechilibra marfa pe care o are deja; nu o poate de-comanda.
Acoperirea pe grup și cât din exces s-a mutat, în loc să fie redus de preț.
Proprietar
Toată rețeaua, fără bloc de cohortă — la acest perimetru nu mai rămâne cu ce să te compari în afară de tine însuți.
- Oprirea reaprovizionării și anularea a ce e în comandă: singurele acțiuni care ating cauza, nu simptomul.
- Pragul și înregistrarea despre cine l-a mutat, de la ce și de ce — modul de eșec 04 e exact ce se întâmplă fără acea înregistrare.
- Onestitatea registrului: decizia de a nu înscrie o economie înainte de închiderea ferestrei de control.
Exact lucrul după care acest perimetru întinde totuși mâna — judecata dacă un anumit palet, din anumit depozit, se poate vinde. E singurul fapt pe care îl deține cel mai mic perimetru și nu îl deține cel mai mare.
Capitalul de lucru eliberat în rețea și dacă același SKU revine trimestrul următor.
Pe scurt
Acestea sunt cele trei perimetre pe care le livrează produsul, nu o afirmație despre cum ar trebui organizat un lanț. Un lanț cu birou de achiziții are un scaun pe care niciunul din cele trei nu îl descrie — un category buyer deține comanda într-un fel în care nu o deține niciun rol de magazin — iar playbook-ul acesta nu va inventa scaunul respectiv. Potrivește-ți propriile titluri pe perimetre, nu invers: perimetrul e cel care limitează decizia, iar un titlu care nu vede locația care primește nu deține transferul, oricum s-ar numi.
Tot ce e mai sus, pe un singur tabel.
Nimic din asta nu are nevoie de marql. Scanarea, ordonarea și registrul sunt ce automatizează produsul; metoda de dedesubt e formată din patru decizii și vreo două duzini de câmpuri, și merge pe hârtie. Ia-o. Dacă o lucrezi manual un trimestru și aritmetica merită în continuare după-amiaza pe care o costă, ăsta e argumentul pentru automatizare — iar dacă nu merită, ai cheltuit o după-amiază, nu un abonament.
E mort sau doar supra-acoperit?
Modul de eșec 01 e o singură acțiune aplicată la două probleme diferite. Trei câmpuri le despart, și toate trei sunt într-un export de vânzări.
Când s-a vândut ultima dată acest SKU în această locație?
- Nu în intervalul termenului de livrareTratează-l ca stoc mort. Reaprovizionarea nu e pârghia — nu mai e nimic de oprit. Trece la partea 03 și compară o reducere cu casarea.
- Recent, într-un ritm constantE supra-acoperit, nu mort. Continuă.
Mai e ceva în comandă sau pe drum?
- DaAsta e cauza. Anulează sau oprește înainte de orice altceva — orice altă acțiune tratează simptomul, iar următoarea livrare o desface.
- NuExcesul e deja pe raft. Continuă.
Se aplică unul dintre contra-cazurile din secțiunea 03 — o constituire, o cantitate minimă, un preț blocat, o promoție programată, riscul de aprovizionare?
- DaNotează care, cine a decis și când trebuie revizuit. Nicio acțiune. Înregistrarea e ce oprește lucrul acesta să vină ca o surpriză în fiecare săptămână.
- NuContinuă.
Există o locație a cărei acoperire proprie rămâne în norma ei după ce primește excesul?
- DaTransferă. Verifică acoperirea locației care primește după mutare, nu media rețelei — acesta e modul de eșec 02.
- NuDistribuția nu rezolvă asta. Trece la partea 03.
Unul din cinci finaluri: anulezi comanda, transferi, reduci prețul, casezi, sau notezi un motiv și nu faci nimic.
Se poate atinge norma, în general?
Contra-cazul 02 în formă de fișă. Un rând pe clasă de SKU, nu pe SKU — răspunsul e același pentru tot ce cumperi la palet.
- Consum mediu zilnic
- Unități pe zi pe o fereastră în care ai încredere. Scrie fereastra lângă cifră: fără ea, cifra nu spune nimic.
- Termen de livrare
- Observat, nu contractat. Dacă ultimele trei livrări au întârziat, cel observat e cel real.
- Bufer-țintă
- Zilele de acoperire pe care le vrei peste termenul de livrare. Acesta plus termenul e ce măsoară excesul.
- Cantitate minimă de comandă
- Cea mai mică cantitate pe care furnizorul o acceptă efectiv, în aceleași unități ca consumul.
- MOQ ÷ consum mediu zilnic
- Zilele de acoperire pe care cea mai mică comandă legală le creează deja, înainte ca cineva să fi supra-comandat ceva.
- Norma e atingibilă?
- Compară rândul de mai sus cu termenul de livrare plus buferul. Dacă e mai mare, nicio comandă acceptată de furnizor nu poate respecta norma — și norma e ce trebuie schimbat, nu achizitorul.
Fie o normă de care poți ține pe cineva răspunzător, fie o normă despre care acum știi că e imposibilă și ar trebui să înceteze să dea alerte.
E reducerea mai ieftină decât deținerea?
Modul de eșec 03 în formă de fișă — comparația care se sare, fiindcă raportată la capital orice reducere pare justificată.
- Unități peste normă
- Stoc curent minus consum mediu zilnic ori (termen de livrare plus bufer), din partea 02.
- Capital în exces
- Acele unități la cost unitar. Acesta e numărul cu care NU se compară reducerea.
- Cost de stocare pe săptămână
- Cât costă săptămânal deținerea excesului — capital, spațiu, asigurare, pierderi. Dacă nu ai o rată la îndemână, scrie-o pe cea pe care o presupui și marchează-o ca presupunere.
- Săptămâni cât l-ai ține altfel
- La consumul curent, cât durează până excesul se stinge de la sine.
- Cost de stocare pe orizontul acela
- Costul săptămânal ori săptămânile. Acesta e numărul pe care o reducere trebuie să-l bată.
- Marja dăruită
- Reducerea pe unitate ori unitățile pe care te aștepți să le miști, la adâncimea pe care o iei în calcul.
- Risc de casare
- Zero la un SKU cu termen lung și fără dată de expirare. La orice perisabil, unitățile care probabil expiră, la cost unitar.
Dacă marja dăruită depășește costul de stocare pe orizont plus riscul de casare, „nu faci nimic” e acțiunea mai ieftină — și merită notată ca decizie, nu ca omisiune.
Fixează măsurarea înainte să acționezi.
Modul de eșec 05 în formă de fișă, și singura parte cu termen: fiecare câmp de aici se completează înainte de acțiune, fiindcă odată cunoscut rezultatul niciunul nu mai poate fi ales onest. Indiciile spun ce cere chiar registrul marql, așa că un tabel rulat la acest standard și produsul rulat la el răspund la aceeași întrebare.
- Acțiunea, într-o propoziție
- Ce se face, la care SKU, în care locații.
- Responsabil
- Un nume, cu un perimetru care vede efectiv ce cere acțiunea — secțiunea 07.
- Baza, înghețată acum
- Cifra față de care se va măsura efectul, scrisă și nerecalculată ulterior. marql o îngheață în momentul confirmării deciziei; într-un tabel, a îngheța înseamnă a lipi valoarea, nu a lăsa o formulă care se va mișca.
- Fereastra de măsurare
- Date exacte după acțiune, alese acum, nu când cifrele încep să arate bine. Rândurile din registrul marql rulează în jur de patru săptămâni — suficient să cuprindă cicluri săptămânale întregi.
- Indicatorul
- Zile de acoperire pe acest SKU în aceste locații. Un singur indicator — al doilea e felul în care se alege un rezultat favorabil după fapt.
- Locații de control potrivite
- Locații comparabile care nu primesc acțiunea. marql nu declară un rând dovedit pe mai puțin de patru locații de control potrivite; fără deloc, cade pe volatilitatea proprie a unității — o afirmație mai slabă, care merită etichetată ca atare.
- Pragul care bate zgomotul
- Testul marql e un interval de predicție Student-t la α unilateral = 0,10 față de acele controale. Într-un tabel, echivalentul onest e un prag scris înainte să te uiți — orice decis după e o preferință, nu un rezultat.
- Ce ar anula fereastra
- O promoție care acoperă mai mult de jumătate din ea, o schimbare de preț, o schimbare de furnizor, o lipsă de stoc sau un vârf de discount. Oricare dintre ele și verdictul onest e neconcludent, nu dovedit.
- Ce se consideră „fără efect” și ce „mai rău”
- Ambele, scrise înainte să le cunoști. Un protocol care nu poate ieși negativ nu măsoară nimic.
Un rând care se poate închide în șase direcții — identificat, se măsoară, dovedit, fără efect, neconcludent, mai rău. Dacă ultimele trei sunt inaccesibile în versiunea ta, primele trei nu merită avute.
Pe scurt
Asta e toată metoda. Ce adaugă marql nu e o ecuație mai bună: rulează scanarea zilnic pe fiecare SKU și fiecare locație, nu pe cea observată de cineva, ordonează abaterile după capitalul din ele ca după-amiaza să se ducă pe cea mai mare, și ține registrul astfel încât un rând închis să nu poată fi redeschis și „îmbunătățit” pe tăcute. Aritmetica de mai sus e aceeași în ambele cazuri.
09 · Granița dovezii
Potențial de eliberare
≠ efect dovedit.
2.728 € este capitalul aflat în stocul peste nivelul-țintă, evaluat la cost. Nu este cât costă pe săptămână deținerea acelui stoc, nu este o economie realizată și nu este ROI-ul marql.
Efectul dovedit se înregistrează abia după acțiunea executată, perioada de bază și închiderea ferestrei de control. Dacă datele sunt insuficiente sau rezultatul e distorsionat de un factor extern, Impact Ledger marchează efectul ca nedovedit.
De unde vin ecranele
Cele patru suprafețe prin care a trecut decizia
Vrei să vezi
euro pe care i-a găsit?
Demoul pornește de la casele de marcat și contabilitatea pe care le folosești deja. Lasă-ne datele și alege o oră.