Seznam změn

2026-07-08 — datum zálohy, poskytovatel kurzu pro CZ/SK

Dvě aditivní, zpětně kompatibilní změny.

  • Datum zálohy na cestovních příkazech. Požadavky na vytvoření a aktualizaci nyní přijímají nepovinný advancePaymentDate (yyyy-MM-dd) a odpověď cestovního příkazu jej vrací. Pokud je při vytvoření vynechán, server použije datum záznamu. Určuje datum kurzu pro zálohu a u českých tenantů referenční datum kurzu pro stravné.
  • Poskytovatel kurzu pro CZ/SK. GET /api/v1/reference/exchange-rates nyní dokumentuje úplnou sadu poskytovatelů: HNB pro HR, ECB pro SI a SK, CNB pro CZ. Pole source může být "CNB" a baseCurrency je nativní měna poskytovatele (EUR pro HNB/ECB, CZK pro CNB). Chování se nemění; dokumentace nyní odpovídá běhu.

2026-06-11 — počty jednotlivých jídel, původ FX, kód nedostupného směnného kurzu

Tři doplňkové změny rozhraní. Všechny jsou zpětně kompatibilní: stávající payloady fungují beze změny a nová pole v odpovědích jsou pouze doplňky, které můžete ignorovat, dokud je nebudete potřebovat.

  • Počty jednotlivých jídel při vytváření/aktualizaci diet. Požadavky na diety nyní přijímají breakfastsProvided, lunchesProvided a dinnersProvided (celočíselné počty jednotlivých jídel) plus volitelné denní mealsProvidedAllocation. Představují kanonický model pro zápis: server z těchto počtů přepočítává srážky. Stávající agregát v1 mealsProvided je stále přijímán; pokud pole pro jednotlivá jídla chybí, server mapuje agregát jako dříve, takže starší klienti nejsou ovlivněni. Odpovědi nadále vracejí odvozené mealsProvided (oběd + večeře, formát podle HR Pravilnik) vedle počtů jednotlivých jídel, takže cesty pro čtení zůstávají beze změny.
  • Původ FX v odpovědích. Odpovědi pro výdaje a diety získávají exchangeRateSource a odpověď pro cestovní záznam získává advancePaymentExchangeRateSource, které zaznamenávají, odkud pochází použitý kurz: kód poskytovatele ("HNB", "ECB") pro oficiální kurz, "MANUAL" pro kurz zadaný uživatelem, nebo null pro řádek ve stejné měně (bez převodu) či starší řádek uložený před sledováním původu. Pouze pro čtení; žádná změna v požadavku.
  • Nový chybový kód EXCHANGE_RATE_UNAVAILABLE (HTTP 400). Spustí se, když poskytovatel FX pro daného tenanta nezveřejní žádný kurz pro danou měnu v požadovaném datu a neexistuje žádný historický kurz, na který by se dalo přejít. Jedná se o selhání z rodiny validací se standardním tělem errors klíčovaným podle polí, takže můžete specificky rozlišit případ nedostupného FX a vyzvat k ručnímu zadání kurzu. Přidáno do katalogu chyb.

2026-05-23 — časy itineráře diet ukládány jako skutečné UTC (oprava)

Časy diet ukládané přes POST /api/v1/travel-entries/{id}/per-diems/from-itinerary se nyní ukládají jako skutečné UTC okamžiky. Dříve byl odjezd/příjezd každého úseku zapsán pomocí hodnoty místního času (wall-clock) označené jako UTC bez posunu (místní úsek v 08:00 byl uložen jako 08:00Z místo 07:00Z/06:00Z), takže řádky vygenerované z itineráře se neshodovaly s ručně přidanými řádky o 1–2 hodiny a zobrazovaly se opožděně. Schémata požadavku a odpovědi se nemění, ale hodnoty departureTime/arrivalTime, které tento endpoint vrací (a které vrací i pozdější čtení stejných řádků), nyní odrážejí opravený UTC okamžik. Náhled bezstavové kalkulačky stále vrací místní časy. Částky diet nejsou ovlivněny.

2026-05-23 — kalkulačka diet + uložení celé cesty

Rozhraní pro výpočet diet je sjednoceno a získává paritu ukládání celé cesty s webovou aplikací locco.

  • Nový POST /api/v1/utilities/per-diems/calculate — bezstavová kalkulačka. Odešlete itinerář (jeden úsek = itinerář se 2 zastávkami) a získáte zpět vypočítané řádky s aplikovaným přerozdělením na úrovni itineráře. Žádný kontext záznamu, nic se neukládá.
  • Nový POST /api/v1/travel-entries/{id}/per-diems/from-itinerary — přebudování diet cestovního záznamu z itineráře v jednom volání. Server znovu spustí svůj vlastní engine nad zastávkami (odeslaným částkám se nikdy nedůvěřuje), aplikuje jídla pro jednotlivé úseky klíčovaná podle (countryCode, departureTime) (dvojice, které vrací kalkulačka), a poté atomicky nahradí diety záznamu. Tím se reprodukuje přerozdělení na úrovni itineráře a upgrady vnitrostátních jednotek, což odesílání řádků po jednom nedokáže.
  • Odstraněno POST /api/v1/travel-entries/{id}/per-diems/compute a POST /api/v1/per-diems/calculate-simple. Oba jsou nahrazeny pomocí utilities/per-diems/calculate — jeden úsek je prostě itinerář se 2 zastávkami. Převeďte integrace na novou kalkulačku.

2026-05-22 — podpora slovinského trhu

Počáteční podpora pro slovinské tenanty. Aktualizujte svého klienta z obnoveného OpenAPI snapshotu na /api-reference/:

  • Slovinské obce — nový GET /api/v1/reference/slovenian-municipalities vrací seznam obcí SURS pro rozbalovací nabídky míst ve slovinských cestovních formulářích. Volatelné z jakéhokoli tenanta.
  • Daňová rezidence zaměstnance — záznamy zaměstnanců získávají pole residency (Resident / NonResident) pro vykazování slovinských diet a daní ze mzdy. Výchozí hodnota je Resident.

2026-04-28 — spuštění v1.0

První stabilní vydání locco partner API. Každé rozhraní je propojeno, otypováno a pokryto OpenAPI snapshotem na /api-reference/:

  • Cestovní záznamy — plný CRUD plus přechody workflow (odeslat, schválit, zamítnout, zrušit, vyžádat změny), s atomickým vytvářením, které v jednom volání přijímá vnořené výdaje, diety, alokace na nákladová střediska a přílohy.
  • Přílohy — přímé nahrávání k cestovnímu záznamu přes POST /api/v1/travel-entries/{id}/attachments. Multipart, až 5 souborů na požadavek.
  • Webhooks — registrace odběru s jednorázovým zobrazením signing-secret, historie doručování pro každý odběr a endpoint pro opakování neúspěšných nebo vyčerpaných doručení.
  • Výplaty — výpis záznamů připravených k výplatě, vytváření dávek, výpis historie, smazání dávky.
  • Zaměstnanci, Oddělení, Vozidla, Nákladová střediska — CRUD + výpis, s hodnotami vlastních polí u zaměstnanců.
  • Reference — chorvatské obce, směnné kurzy HNB, tabulka sazeb diet, seznamy povolených zemí a povolených měn společnosti.
  • Společnost — čtení profilu.

Hodnoty výčtů pro Status, TravelType, PayoutMethod a další jsou zdokumentovány v OpenAPI schématu jako seznamy povolených hodnot enum: [...], takže generovaní klienti se vážou na kanonické řetězce ("PendingApproval", "BankTransfer" atd.) spíše než na neprůhledné hodnoty.