# Date, ore și bani

Cum arată pe fir o zi, un moment și o sumă, unde contează ora României și cum se calculează TVA-ul pe facturi.

## Pe scurt

| Ce | Forma pe fir | Exemplu |
| --- | --- | --- |
| Zi | `AAAA-LL-ZZ` | `2026-11-11` |
| Lună (evidență) | `AAAA-LL` | `2026-11` |
| Moment | ISO 8601 cu fus orar | `2026-11-11T10:24:05.000Z` |
| Sumă (meniu, prețuri) | text cu exact două zecimale, în lei | `"30.00"` |
| Sumă (finanțe, evidență) | text cu exact două zecimale | `"4635.00"` |
| Monedă (finanțe, facturi) | `RON`, `EUR` sau `USD` | `"RON"` |
| Cotă TVA pe factură | `0`, `11` sau `21` | `21` |

## Zile și momente

- O **zi** este o dată calendaristică fără oră: `AAAA-LL-ZZ`.
- Un **moment** este ISO 8601 cu fus orar. Schemele acceptă orice decalaj (`Z`, `+02:00`, `+03:00`); serverul scrie de regulă în UTC, cu `Z` la final.
- Excepție: lista de rapoarte (`GET /v1/rapoarte`) dă momentul fișierului cu decalajul orei României (`+02:00` iarna, `+03:00` vara).

> [!NOTE]
> Citește momentele ca momente, nu ca text: compară-le după ce le transformi în dată, ca un `+03:00` și un `Z` să fie tratate corect.

## Ora României și UTC

Serverul rulează pe UTC. Tot ce înseamnă „azi” pentru restaurant se calculează însă pe ora României (`Europe/Bucharest`), cu trecerea la ora de vară făcută automat.

| Unde | Ce înseamnă „ziua” |
| --- | --- |
| Ofertele | data de azi la București |
| Evidența zilnică | ziua României, nu ziua UTC |

### Sarcinile programate

Codul platformei pune ora României pe fiecare sarcină cu oră fixă. Ce rulează de fapt pe serverul platformei s-a citit pe 12.11.2026 și e în [Ce rulează în fundal](#ce-ruleaza-in-fundal).

| Sarcină | În cod | Pe server |
| --- | --- | --- |
| Evidența zilnică | în fiecare zi, la 06:10 ora României | nu e instalată |
| Facturile din SPV (ANAF) | de luni până sâmbătă, la 08:30 ora României | o sincronizare SPV zilnică, la 03:00 ora României |
| Statisticile complete ale rețelelor sociale | în fiecare zi, la 03:20 ora României | instalată, dar oprită |
| Sincronizarea registrului cu FGO | la minutul 07 și 37 al fiecărei ore | nu e instalată |

## Bani

Sumele se trimit ca **text cu exact două zecimale**, cu punct: `"30.00"`, `"2.50"`. Nu sunt bani întregi (nu `3000`) și nu sunt numere zecimale (nu `30.0`).

Motivul: în baza de date sumele sunt `numeric`, iar textul trece neschimbat de la bază la pagină, fără rotunjirile unui număr cu virgulă mobilă.

| Tip | Forma | Plaja |
| --- | --- | --- |
| Sumă financiară | `^\d{1,12}\.\d{2}$` | până la 12 cifre înainte de punct |
| Sumă din evidență | ca suma financiară, dar mai mare ca zero | — |

```json title="Corect și greșit"
{ "pret": "30.00" }   // corect
{ "pret": "30" }      // 400: lipsesc zecimalele
{ "pret": 30.0 }      // 400: număr, nu text
```

> [!WARNING]
> Nu toate modulele folosesc textul. Liniile facturilor și ale documentelor fiscale primesc `cantitate` și `pret` ca **numere** JSON, iar prețul poate avea cel mult 4 zecimale. Verifică schema rutei în [referința API](#api-prezentare).

## TVA pe facturi

Ciornele de factură și proformă (`facturi-documente`) au TVA pe fiecare linie:

- cota se alege pe linie din `0`, `11` sau `21`; serverul nu pune o cotă implicită;
- clientul trimite doar `cantitate`, `pret` și `cota_tva`; valoarea, TVA-ul și totalurile le calculează serverul;
- valoarea liniei = `cantitate × pret`, rotunjită la ban; TVA-ul = valoare × cotă, rotunjit la ban;
- totalurile sunt suma liniilor: `total_fara_tva`, `total_tva`, `total`;
- un preț negativ înseamnă discount, dar baza pe fiecare cotă trebuie să rămână cel puțin zero; altfel `422` cu motivul `baza_negativa_cota_<cotă>`.

Serviciile din catalogul de clienți au o `cotaTva` între 0 și 100, aleasă de firmă.