Nordlet

← Dokumentacija / Pakeitimų žurnalas

Pakeitimų žurnalas

Naujos funkcijos, pakeitimai ir pataisymai „Nordlet“ sistemoje pagal versijas.

v0.5.0

0.5.0 - 2026-10-13 - Dabartinė versija

Pridėta

  • POST /v1/account/me grąžina mokančios paskyros tipą billing.accountType (flat_rate arba per_request).

Pakeista

  • POST /v1/sales/invoices/pdf ir /v1/sales/invoices/send spausdina išrašytą sąskaitą faktūrą su pardavėjo pavadinimu, kodu, PVM mokėtojo kodu, PVM mokėtojo statusu ir adresu, kurie buvo išsaugoti jos išrašymo metu; vėlesnis įmonės duomenų pakeitimas nebekeičia išrašytos sąskaitos faktūros PDF failo.
  • /v1/calendar/list įtraukia teikimo terminą tik tada, kai įmonė privalo jį pateikti: ES prekių ir paslaugų ataskaitas laikotarpiams, kuriais buvo vykdyti ES vidaus sandoriai, „Intrastat“ ataskaitas viršijus nacionalinę ribą arba kaip nustatyta filingOptions.intrastat, Estijos ir Latvijos mėnesines pelno mokesčio deklaracijas už mėnesius, kuriais buvo išmokėti pelno daliniai (Latvijoje – taip pat už paskutinį finansinių metų mėnesį), Norvegijos akcininkų registro ataskaitą (netaikoma ENK, ANS, DA ar KS formoms) ir Prancūzijos CA3 arba CA12 ataskaitas pagal filingOptions.frVatRegime.
  • /v1/calendar/list įtraukia Belgijos metinę pirkėjų suvestinę (be-client-listing) ir Belgijos įmonėms, kurios nėra PVM mokėtojos (taikant franšizės režimą), pradedant nuo 2025 m. ūkinės veiklos.
  • Vokietijos PVM deklaracija (de-vat-return) teikiama kas ketvirtį, nebent nustatytas įmonės PVM periodas vatPeriod, Ispanijos „Modelo 111“ forma (es-payroll-withholding) – kas ketvirtį, nebent filingOptions.esLargeCompany nustatyta kaip yes, o Rumunijos formos D394 ir D406 seka PVM periodą.
  • filingOptions laukas, esantis POST /v1/account/companies/update užklausoje, priima šiuos parametrus: intrastat, euSalesListPeriod, atUvaExempt, bePayrollPeriod, dePayrollPeriod, esSii, esSimplifiedOnly, esLargeCompany, frVatRegime ir frCompanySize.
  • Klaidų ir įspėjimų pranešimai, kurie nurodydavo į skiltį Nustatymai (Settings), dabar nurodo į Paskyrą (Account), pavyzdžiui, Account → Compliance → EU, o klaidų raktai document_reading_is_available_after_the_first_top_up_top_up_credits_in_settings ir no_peppol_access_point_is_set_up_for_this_company_enter_it_in_settings_complianc pakeisti į ..._in_account_b ir ..._in_account_compliance.

Pataisyta

  • Failai pain.001 iš POST /v1/bank/payments/export ir darbo užmokesčio grynojo darbo užmokesčio eksportas dabar apima skolininko banką (DbtrAgt, o jei BIC nežinomas – NOTPROVIDED), kurio reikalauja pain.001.001.03 schema; failai be šio lauko nepraeidavo schemos patvirtinimo.
  • POST /v1/account/companies/create dabar išsaugo kiekvieną priimamą profilio lauką (legalForm, incorporatedOn, vatPeriod, fiscalYearEndMonth, filingOptions, smeExemptionNumber, registryName, shareCapital, accountsKeptBy, bookkeeperName, auditorName, auditorRegistrationNumber, auditRequired); anksčiau šie laukai buvo priimami, bet ignoruojami.

0.4.0 - 2026-10-11

Pridėta

  • POST /v1/billing/account/set-auto-top-up įjungia arba išjungia automatinį sąskaitos papildymą: kai dėl sunaudotų paslaugų likutis nukrenta iki nulio arba tampa neigiamas, „Nordlet“ nuskaičiuoja pasirinktą sumą nuo išsaugotos kortelės per „Stripe“ sąskaitą faktūrą ir apmokėjus papildo likutį; POST /v1/billing/account/get grąžina autoTopUp.
  • POST /v1/billing/account/set-overdraft-cap nustato, kiek giliai į minusą gali smukti likutis (numatytoji reikšmė – 100 EUR, maksimali – 1000 EUR) paskyroms, kurios bent kartą atliko mokėjimą; POST /v1/billing/account/get grąžina overdraftCapCents.
  • POST /v1/billing/flat-rate/create priima planą plan (starter, business arba scale, numatytasis – starter) ir atveria „Stripe“ apmokėjimo langą pasirinkto plano kainai; planas išsaugojams sėkmingai baigus mokėjimą.
  • POST /v1/billing/flat-rate/confirm aktyvuoja fiksuoto mokesčio planą pagal užbaigtos „Stripe Checkout“ sesijos ID, todėl pirkėjui nereikia laukti „webhook“ pranešimo.
  • POST /v1/billing/topup/confirm įskaito apmokėtą „Stripe Checkout“ papildymą pagal sesijos ID nelaukiant „webhook“ pranešimo, o POST /v1/billing/topup/create priima returnTo: "onboarding", kad grąžintų pirkėją į plano puslapį, o ne į kreditų puslapį.
  • POST /v1/billing/account/set-account-type nustato paskyros tipą (flat_rate arba per_request); POST /v1/billing/account/get grąžina accountType.
  • POST /v1/billing/sales/invoice-templates/{create,update,get,list,delete} išsaugo pavadintus sąskaitų faktūrų ir kreditinių sąskaitų šablonus (partneris, valiuta, apmokėjimo terminas dienomis, PVM schema, prekių ar paslaugų tiekimo tipas, numeravimas, serijos žyma, užsakymo numeris, nuolaida, parašai, „Intrastat“ laukai, pastabos ir eilutės), kuriuos programa naudoja užpildydama naują dokumentą.

Pakeista

  • API užklausos ir programa grąžina 402 kodą tik tada, kai likutis pasiekia minusinę mėnesio ribą (vietoj nulio), taikoma paskyroms, kurios bent kartą atliko mokėjimą.
  • Fiksuoto mokesčio planai apima išrašytas sąskaitas faktūras (500 / 3000 / 20000 per mėnesį), o ne užklausas; flat_rate API raktai veikia kol kreditai yra virš nulio, taikant 0.002 EUR tarifą už užklausą (vietoj 403 atsakymo); per_request paskyros moka 0.002 EUR už užklausą be plano mokesčio, o plano laukai includedRequests / requestOverageEur pakeisti į includedInvoices / invoiceOverageEur.
  • Įtraukta duomenų bazės saugykla dabar prilyginta įtrauktai failų saugyklai kiekviename plane: „Starter“ – 1 GB (buvo 256 MB), „Business“ – 5 GB (buvo 1 GB), „Scale“ – 30 GB (buvo 2 GB); sąskaitų išrašymo plano sąraše esantis laukas includedDatabaseBytes pakeistas atitinkamai.
  • POST /v1/account/companies/activate nebeekonomizuoja 50 EUR mokesčio ir nebegrąžina 402 klaidos, o archyvuotoms įmonėms nebetaikomas 1 EUR mėnesinis mokestis.
  • Smėlio dėžės (sandbox) įmonės (isSandbox: true) visada teikia ir siunčia e. sąskaitas faktūras administracijų testiniams galiniams punktams, nepaisant sistemos ar įmonės aplinkos nustatymų, ir joms galima įjungti automatinį teikimą.

Pašalinta

  • Partnerių laukai otherCode ir foreignTaxNumber: POST /v1/partners/{get,list} jų nebegrąžina, o POST /v1/partners/{create,update} juos vartoja ignoruodami; jokie procesai jais nesinaudojo.

0.3.14 - 2026-10-11

Pakeista

  • POST /v1/reference/exchange-rates/list ir visi valiutų keitimai dabar naudoja Lietuvos banko EUR valiutos kursus už paskyruosius 5 metus, kurie atnaujinami kasdien; nebereikia siųsti užklausos reference/exchange-rates/sync kiekvienai dienai atskirai.

0.3.13 - 2026-10-10

Pataisyta

  • POST /v1/bank/securities/import priima didesnes nei 1 MB išrašų rinkmenas; anksčiau į jas būdavo atsakoma 413 klaida „Request body is too large“.

0.3.12 - 2026-10-10

Pridėta

  • POST /v1/bank/securities/import priima „Interactive Brokers Realized Summary“ CSV formato failą (content, neprivalomas fileName) naujo tipo broker banko sąskaitai ir įkelia jos prekybos sandorius, dividendus, išskaičiuotą mokestį, palūkanas bei mokesčius į didžiąją knygą po vieną žurnalo įrašą per dieną, konvertuojant į įmonės bazinę valiutą pagal tos dienos kursą. Akcijos, pasirinkimo sandoriai (options) ir ateities sandoriai (futures) suderinami FIFO (pirmas gautas, pirmas išduotas) būdu per visus importus. Pozicijai, įsigytai iki pirmojo importuoto išrašo, savikaina apskaičiuojama pagal „Interactive Brokers“ bazę. Įvykdyto arba perleisto pasirinkimo sandorio premija patenka į bazinių akcijų savikainą arba pajamas, o pasibaigusio galiojimo pasirinkimo sandorio premija tampa realizuotu rezultatu. Eilutės, kurios jau buvo importuotos (toks pats tipas, simbolis, data ir laikas bei suma), praleidžiamos. Įmokos, korporaciniai veiksmai ir valiutos keitimai yra pateikiami sąraše, bet neįtraukiami į apskaitą. POST /v1/bank/securities/list ir /get grąžina importuotus duomenis bei jų operacijas. Apskaitos taisyklės securities.investments, securities.gain, securities.loss, securities.dividendIncome, securities.withholdingTax, securities.interestIncome, securities.interestExpense ir securities.fees parenka sąskaitas.

0.3.11 - 2026-10-10

Pridėta

  • POST /v1/platform-sellers/list, /get, /create, /update ir /delete registruoja pardavėjus valdomoje platformoje, nurodant mokesčių rezidenciją ir mokesčių mokėtojo kodą (TIN), adresą, gimimo datą, IBAN, nuolatines buveines bei per metus ir ketvirtį gautą atlygį, mokesčius, rinkliavas ir veiklų skaičių už prekių pardavimą, nekilnojamojo turto nuomą (su turto adresu ir tipu), asmenines paslaugas bei transporto priemonių nuomą.
  • POST /v1/declarations/eu/dac7/preview ir /dac7/xml sugeneruoja metinę DAC7 platformos operatoriaus ataskaitą (Direktyva (ES) 2021/514): nustato, kurie pardavėjai yra deklaruojami ir kodėl kiti yra pašalinti, taip pat suformuoja XML failą (VMI DPI-DAC7-LT v0.4 struktūrą Lietuvoje ir ES DPI XML Schema v1.09 Austrijoje, Belgijoje, Bulgarijoje, Kipre, Čekijoje, Vokietijoje, Estijoje, Suomijoje, Airijoje, Maltoje, Portugalijoje, Rumunijoje, Slovakijoje ir Slovėnijoje). Kalendoriuje sukuriamas sausio 31 d. DAC7 terminas (<cc>-dac7) įmonėms, turinčioms platformos pardavėjus; jis siunčiamas tiesiogiai į VMI TIES (atitikties sistemą lt-ties) ir į BMF DPMG saityno paslaugą (at-dpmg), o kitur pateikiamas atsisiuntimui.
  • POST /v1/declarations/eu/digital-reporting/list nurodytam laikotarpiui pateikia ES vidaus sandorius, kuriuos privaloma atskirai deklaruoti nuo 2030 m. liepos 1 d. (Direktyvos 2006/112/EB 262–264 straipsniai su pakeitimais, padarytais Direktyva (ES) 2025/516): ES vidaus prekių tiekimą, tiekimus su atvirkštiniu PVM apmokestinimu ir įsigijimus su savarankiškai apskaičiuotu PVM, nurodant kiekvieno sąskaitos faktūros duomenis, valstybės narės, kuriai teikiama ataskaita, kodą, terminą ir trūkstamus duomenų elementus.
  • POST /v1/declarations/eu/own-goods-transfers/compute sugeneruoja mėnesinę specialiosios nuosavų prekių perkėlimo schemos deklaraciją (369xa-369xk str., taikoma nuo 2028 m. liepos 1 d.) pagal atsargų perkėlimus tarp sandėlių skirtingose valstybėse narėse, įvertintus savikaina eurais pagal paskirties ir išsiuntimo valstybę narę, nurodant terminą.
  • Sandėliai priimami ir grąžinami su countryCode lauku (POST /v1/inventory/warehouses/create, /list), o naujasis POST /v1/inventory/warehouses/update leidžia pakeisti sandėlio pavadinimą (name) arba šalies kodą (countryCode).
  • POST /v1/reference/vat/resolve priima paslaugos rūšį serviceKind (short_term_accommodation, passenger_road_transport) kartu su serviceCountryCode, underlyingSupplierGaveVatNumber, underlyingSupplierChargesVat, prekių rūšį goodsKind (installed, energy_network) ir goodsLocationCountryCode. Nuo 2028 m. liepos 1 d. jis taiko platformos prezumuojamo tiekėjo taisyklę trumpalaikiam apgyvendinimui ir keleivių vežimui keliais (28a, 136b str.) bei išplėstinį Sąjungos OSS režimą prekėms, parduodamoms ten, kur jos laikomos, montuojamoms prekėms ir energijos tiekimui (369b str. b, d, e punktai, 369aa str.).
  • Išmokų paketai (POST /v1/bank/settlements/list, /get, /import, /post) grąžina clearedNet, clearingDifference ir clearingOpenCount, o kiekviena eilutė grąžina clearingBankAccountId, clearingBooked, clearingDifference ir clearingUnposted: kiekvienai išmokos eilutei, kurios mokėjimas arba grąžinimas jau buvo importuotas iš „Stripe“ mokėjimų eksporto, jie parodo banko sąskaitą, kurioje ji saugoma, ten laikomą sumą, skirtumą nuo išmokos pervedimo ir tai, ar šis pervedimas vis dar neįtrauktas į apskaitą. Visos vieno mokėjimo grąžinimo eilutės palyginamos bendrai su grąžinta „Stripe“ eksporto suma. /post suvestinė grąžina clearedAmount.
  • Banko sąskaitos priimamos ir grąžinamos su type (bank arba stripe, numatytoji reikšmė – bank) lauku POST /v1/bank/accounts/create, /update ir /list užklausose, o /list filtruoja pagal šį tipą. „Stripe“ sąskaita neturi IBAN: bandymas jį nurodyti grąžina 422 klaidą, o sąskaitos tipo pakeitimas į stripe išvalo IBAN lauką.

Pakeista

  • DAC7 atitikties sistemos (lt-ties, at-dpmg, <cc>-dac7) nebepriima aplinkos parametro environment užklausoje POST /v1/declarations/configs/update (pateikus grąžinama 400 klaida). DAC7 failas sistemoms lt-ties ir at-dpmg siunčiamas į testavimo paslaugą ir žymimas kaip bandomieji duomenys (OECD11); failas bet kuriai kitai DAC7 šaliai žymimas kaip realūs duomenys (OECD1).

Pataisyta

  • POST /v1/ledger/accounts/list, katalogo elementų, el. prekybos prekių ir personalo pozicijų atsakymai nebegrąžina 500 klaidos įmonėms, kurių išsaugoti pavadinimai vis dar apima rusų kalbą (ru), kuri buvo pašalinta 0.3.3 versijoje; tokie pavadinimai pašalinami iš lauko translations ir ištrinami iš duomenų bazės.
  • POST /v1/bank/settlements/post nebeekranizuoja mokesčio, grąžinimo ar „Stripe“ komisinio mokesčio antrą kartą, jei jis jau buvo importuotas iš „Stripe“ mokėjimų eksporto (POST /v1/bank/statements/import): tokia eilutė dabar perkelia savo grynųjų sumą iš ją laikančios banko sąskaitos, o komisinis mokestis ir gautinos sumos nėra registruojami pakartotinai. Skirtumas tarp šios sumos ir išmokos eilutės pateikiamas įspėjimuose (warnings). Paketui, kuriame neliko ko registruoti, grąžinamas journalTransactionId su reikšme null.
  • POST /v1/bank/statements/import su „Stripe“ mokėjimų eksportu praleidžia mokesčius, komisinius ir grąžinimus, kurie jau buvo užregistruoti su išmokų paketu, suskaičiuoja juos lauke skipped ir nurodo išmokų pavadinimus įspėjimuose (warnings).

0.3.10 - 2026-10-09

Pridėta

  • „Peppol“ dokumentų siuntimas ir gavimas per įmonės pačios prieigos taško paskyrą („Recommand“, „Storecove“ arba „e-invoice.be“): atitikties sistema peppol (POST /v1/declarations/configs/update) priima parametrus provider (recommand, storecove arba e-invoice-be), accountId („Recommand“ įmonės ID arba „Storecove“ juridinio asmens ID; „e-invoice.be“ nenaudoja), apiKey, apiSecret (tik „Recommand“), webhookSecret ir pasirinktinį apiBaseUrl. POST /v1/peppol/webhooks/{provider}/{companyId} apdoroja prieigos taško „webhook“ pranešimus vienai „Nordlet“ įmonei, patikrinant juos pagal „webhook“ paslaptį: X-Signature HMAC kėbulo parašą „Recommand“ atveju, X-Signature HMAC kanoninio JSON parašą „e-invoice.be“ atveju, HTTP Basic autentifikavimą su slaptažodžiu „Storecove“ atveju. Kiekvienas gautas dokumentas tampa dokumento kopija (document capture) su provider: "peppol" ir nauju lauku senderId, bei išsiunčia „webhook“ įvykį document_capture.peppol_received. Neturint prieigos taško, „Nordlet“ tik sugeneruoja „Peppol“ failus.
  • POST /v1/peppol/participants/lookup (su partnerId arba participantId) nurodo, ar gavėjas yra užregistruotas „Peppol“ tinkle, kokius „Peppol BIS Billing 3.0“ dokumentus jis priima ir jo prieigos taško adresą.
  • POST /v1/sales/invoices/peppol-status grąžina ir išsaugo „Peppol“ tinklu išsiųstos sąskaitos faktūros pristatymo statusą (pending, delivered, rejected, failed) iš „Recommand“ arba „e-invoice.be“, o „Storecove“ atveju, kuri pristatymą praneša tik per „webhook“, grąžina 422 klaidą; sąskaitos faktūros grąžina naujus laukus peppolMessageId, peppolStatus, peppolDetail, peppolSentAt ir peppolCheckedAt, o prieigos taško pranešti statuso pasikeitimai sukelia „webhook“ įvykius sale_invoice.peppol_delivered, sale_invoice.peppol_rejected ir sale_invoice.peppol_failed.
  • POST /v1/capture/documents/confirm priima tipą type (invoice arba credit_note); dokumentų kopijos turi lauką extraction.documentType, todėl gauta kreditinė sąskaita patvirtinama kaip pirkimo kreditinė sąskaita. Ji taip pat priima oppositeLines ir oppositeDocumentNumber: priešingo ženklo eilutės išsaugomos kaip antras to paties tiekėjo priešingo tipo dokumentas (pirkimo kreditinė sąskaita naujai sąskaitai faktūrai, pagal nutylėjimą numeruojama „<dok. numeris>-CR“, arba pirkimo sąskaita faktūra šalia kreditinės sąskaitos – „-INV“), grąžinamas kaip oppositeInvoice. Gauti „Peppol“ dokumentai užpildo extraction.oppositeLines neigiamomis eilutėmis ir nuolaidomis, kurių negali priskirti jokia to paties PVM tarifo eilutė.

Pakeista

  • POST /v1/sales/invoices/peppol-send dabar siunčia per įmonės pačios prieigos tašką ir grąžina status bei detail; neturint prieigos taško, grąžinama 422 klaida. Prieigos taško atsisakymas (pavyzdžiui, gavėjo nesančių „Peppol“ tinkle) grąžina 422 klaidą su priežastimi, o sąskaita faktūra, kurios pristatymas nepavyko (failed) arba buvo atmestas (rejected), gali būti išsiųsta pakartotinai. peppol atitikties sistemoje laukas provider dabar turi būti vienas iš recommand, storecove arba e-invoice-be (laisvas tekstas nebeleidžiamas), o laukas environment pašalintas.

Pataisyta

  • „Peppol“ UBL sąskaitos faktūros ir kreditinės sąskaitos už ES vidaus tiekimą dabar apima pristatymo datą ir pristatymo šalį (cac:Delivery), kurių reikalauja „Peppol“ taisyklės BR-IC-11 ir BR-IC-12.

0.3.9 - 2026-10-08

Pridėta

  • Nauja apskaitos taisyklė cash.advances (Lietuvos sąskaitų plane – 2435, Rumunijos – 542) įvardija darbuotojams išmokėtų avansų grynaisiais sąskaitą; /v1/cash/advance-holders/balances ir /v1/reports/advance-reconciliation skaičiuoja tik su ja susijusius kasos orderius.
  • Vengrijos KSH „Intrastat“ nustatymai (POST /v1/declarations/configs/update, sistema hu-ksh-intrastat) papildyti nauju lauku questionnaireMinutes (klausimyno pildymui sugaištas laikas sveikomis minutėmis); OSAP 2010 ir 2012 įkėlimo failai įrašo jį į VGEA002, kurio reikalauja KSH-ELEKTRA prieš pateikiant klausimyną, o kol šis laukas nenustatytas, failas pateikiamas su įspėjimu.
  • /v1/account/api-keys/list grąžina naują lauką createdByUserId (naudotojas, kuris sukūrė arba atnaujino raktą).
  • POST /v1/sales/invoices/issue priima returnToStock: true kreditinei sąskaitai: jos eilučių prekės grįžta į atsargas ta savikaina, kuria jos išėjo kredituotoje sąskaitoje faktūroje, o parduotų prekių savikaina (6000) kredituojama tokia pačia suma. Bandymas grąžinti daugiau, nei buvo parduota sąskaitoje, atmetamas grąžinant 422 klaidą.
  • /v1/assets/settings/get ir /update (autoDepreciation) bei /v1/agreements/settings/get ir /update (autoBilling) įjungia automatinį mėnesinį nusidėvėjimą ir sutarčių sąskaitų išrašymą: kiekvieną naktį užregistruojamas praėjusio mėnesio nusidėvėjimas ir sugeneruojamos mokėtinų sutarčių sąskaitos faktūros.
  • Pirkimo sąskaitų faktūrų eilutės priima laukus deferralStartDate ir deferralEndDate: sąskaitos registravimas priskiria eilutę ateinančių laikotarpių sąnaudoms (apskaitos taisyklė purchases.prepaidExpenses, Lietuvos sąskaitų plane – 2900, Rumunijos – 471), ir kiekvieną laikotarpio mėnesį suma perkeliama į sąskaitos sąnaudų sąskaitą kas naktį arba per POST /v1/purchases/deferrals/post; /v1/purchases/deferrals/list parodytas grafikas.
  • POST /v1/payroll/runs/reverse anuliuoja patvirtintą darbo užmokesčio žiniaraštį sukurdama veidrodinį žurnalo įrašą ir nustato jo statusą į reversed, kad tam pačiam mėnesiui būtų galima sukurti pataisytą žiniaraštį; siunčiamas „webhook“ įvykis payroll_run.reversed.
  • Lietuvos įmonėms POST /v1/payroll/runs/create be eilučių lines prideda nepanaudotų atostogų kompensaciją darbuotojui, kurio sutartis baigiasi tą mėnesį: likusios atostogų dienos, padaugintos iš vidutinio trijų praėjusių mėnesių dienos užmokesčio (arba sutarties algos, jei už juos nėra patvirtinto darbo užmokesčio žiniaraščio), apmokestinamos kaip papildoma išmoka.
  • Komandiruotės: /v1/hr/per-diem-rates/{create,list,delete} saugo įmonės dienpinigių tarifus pagal paskirties šalis, o /v1/hr/business-trips/{create,get,list,approve,delete} registruoja komandiruotę; automatinis mėnesinis darbo užmokesčio žiniaraštis už mėnesį, kurį baigiasi komandiruotė, išmoka patvirtintus dienpinigius kaip neapmokestinamą priedą.
  • POST /v1/bank/transactions/match-many suderina vieną banko mokėjimą su keliomis tos pačios valiutos sąskaitomis faktūromis vienu žurnalo įrašu; /v1/bank/transactions/unmatch anuliuoja juos visus.
  • POST /v1/cash/orders/create priima saleInvoiceId arba purchaseInvoiceId: orderis įtraukiamas į apskaitą pagal gautinas ar mokėtinas sumas ir pakeičia sąskaitos faktūros apmokėtą sumą bei apmokėjimo statusą.
  • /v1/cash/expense-reports/{create,get,list} padengia darbuotojo avansą grynaisiais per išlaidas, apmokėtas iš šio avanso (debetuojamos sąnaudos ir gautinas PVM, kredituojama cash.advances); /v1/cash/advance-holders/balances ir /v1/reports/advance-reconciliation grąžina naują lauką settled.
  • Kasos aparato (POS) pamainos ir kvitai: /v1/pos/shifts/{open,get,list,close} ir /v1/pos/receipts/{create,get,list}; uždarant pamainą, jos kvitai sugrupuojami į vieną Z ataskaitą, užregistruotą kaip per /v1/pos/reports/create, ir grąžinama tikėtina bei suskaičiuota grynųjų pinigų suma bei jų skirtumas.
  • POST /v1/partners/merge perkelia visus pasikartojančio partnerio dokumentus ir įrašus, įskaitant žurnalo įrašus, į paliekamą partnerį, o dublikatą paslepia.
  • POST /v1/ledger/journal/transactions/create priima pasirinktinį lauką currency; nurodžius valiutą, besiskiriančią nuo įmonės bazinės valiutos, vietoje ignoravimo grąžinama 422 klaida.
  • POST /v1/purchases/invoices/register priima returnFromStock: true kreditinei sąskaitai, kredituojančiai sąskaitą faktūrą: jos eilučių prekės iš savo partijų išvyksta iš sandėlio pagal gaunamą sąskaitą faktūrą ta savaikaina; atsargų sąskaita kredituojama ta savaikaina, o bet koks skirtumas nuo kredituotos sumos keliauja į parduotų prekių savikainą. Jei grąžinama daugiau, nei sąskaita gavo ar nei liko tose partijose, grąžinama 422 klaida.
  • Lenkijos darbuotojai turi naują darbuotojo lauką plKodUrzedu – 4 skaitmenų mokesčių inspekcijos, kurioje deklaruota gyvenamoji vieta, kodą (pateikiamas POST /v1/hr/employees/fields, saugomas payrollOptions).
  • POST /v1/sales/invoices/apply-advance priima pasirinktinį lauką amount ir pritaiko avansą dalimis keliose sąskaitose faktūrose; pagal nutylėjimą pritaikomas nepanaudotas avansas arba neapmokėta sąskaitos faktūros dalis (atsižvelgiant į tai, kuri mažesnė), proporcingai anuliuojant avanso PVM paskutinei daliai tenkančia proporcija. Avansinių sąskaitų faktūrų atsakymuose pateikiamas laukas advanceAppliedAmount.
  • POST /v1/bank/transactions/match, /match-many ir /record priima documentType: 'payroll_run' patvirtintam darbo užmokesčio žiniaraščiui: išeinantis banko mokėjimas, apimantis visą žiniaraščio neapmokėtą grynąjį atlyginimą arba jo dalį, įregistruojamas iš grynojo darbo užmokesčio sąskaitos, kuriai žiniaraštis buvo patvirtintas (debetas) prieš banko sąskaitą (kreditas), o didesnė nei likusi skola suma atmetama grąžinant 409 klaidą; /v1/bank/transactions/unmatch tai anuliuoja, o /v1/bank/transactions/suggest-matches siūlo patvirtintus žiniaraščius išeinantiems mokėjimams.
  • Darbo užmokesčio žiniaraščiai, grąžinami /v1/payroll/runs/{create,get,list,approve,reverse}, turi naują lauką paidAmount – iki šiol su banko mokėjimais suderintą grynąjį atlyginimą.

Pakeista

  • Estijos e-MTA teikimai (sistema ee-emta) dabar vyksta per „Nordlet“ nuosavą „X-tee“ saugumo serverį.
  • /v1/account/members/remove taip pat panaikina kiekvieną API raktą, kurį pašalintas narys sukūrė arba atnaujino šioje įmonėje, o vartotojo paskyros ištrynimas panaikina to vartotojo raktus visose įmonėse; member.removed audito įrašas išvardija juos lauke revokedApiKeys.
  • /v1/hr/contracts/create dabar atmeta 409 klaida sutartį darbuotojui, kuris jau turi sutartį, dengiančią bet kurią naujosios sutarties dieną.
  • Dokumentų skaitymas nepasiekiamas bandomuoju laikotarpiu: POST /v1/capture/documents/upload ir /v1/capture/documents/extract grąžina 402 payment_required iki pirmojo paskyros papildymo, o gaunami e. paštu dokumentai saugomi neskaityti (statusas pending), kad juos būtų galima nuskaityti per /v1/capture/documents/extract po papildymo.
  • POST /v1/payroll/runs/create be lines lauko atmeta 422 klaida darbuotoją, turintį daugiau nei vieną sutartį per mėnesį, vietoje pranešimo, kad žiniaraštis jau egzistuoja.
  • Konsolidavimo užklausos /v1/consolidation/report, /v1/consolidation/intercompany/report, /v1/consolidation/intercompany/candidates ir /v1/consolidation/intercompany/links/list dabar grąžina 403 klaidą, nebent prisijungęs asmuo yra visų dukterinių įmonių narys, arba – API raktui – jei egzistuoja naudotojas, kuris yra savininkas, administratorius arba buhalteris tiek grupinėje pagrindinėje įmonėje, tiek kiekvienoje narėje.
  • Parduodant daiktą, pagamintą pagal gamybos užsakymą (POST /v1/sales/invoices/issue, POS ataskaitos, el. parduotuvės vykdymas, nurašymas ir inventorizacija), jo savikaina dabar nurašoma iš gatavos produkcijos sąskaitos, į kurią ją įtraukė gamybos užsakymas (Lietuvos sąskaitų plane – 2030), o ne iš prekių perpardavimui (2040).
  • Parduavimo sąskaitos faktūros parduotų prekių savikainos įrašai dabar perima pardavimo eilutės projectId ir costCenterId, todėl /v1/projects/report ir /v1/reports/cost-centers rodo prekių savikainą pagal projektą arba sąnaudų centrą.
  • Atsargų vertės dabar saugomos sveikais centais: prekių gavimas, atvežimo išlaidų dalis, gamybos užsakymo darbo ir laužo sąnaudos bei kiekviena iš partijos paimta suma suapvalinama iki centų, o gamybos užsakymo totalCost grąžina centus.
  • POST /v1/ledger/journal/transactions/create, POST /v1/migration/books/validate ir /v1/migration/books/import dabar atmeta 422 klaida žurnalo ir pradinio likučio eilutes, kurių debeto ar kredito suma turi centų dalis.
  • POST /v1/ledger/journal/transactions/create ir bet kuri dokumento eilutės įvestis, priimanti costCenterId (pardavimo ir pirkimo sąskaitos bei kiti dokumentai), dabar atmeta 422 klaida sąnaudų centrą, kurio isActive yra false; jau padaryti įrašai lieka galioti.
  • POST /v1/partners/merge nebeblokuojamas 409 klaida, kai abu partneriai turi atvirą PVM patikrinimą: dublikato atviras patikrinimas išsprendžiamas kaip superseded (išsiunčiant vat_review.resolved), o paliekamo partnerio patikrinimas lieka atviras.
  • POST /v1/bank/statements/import ir POST /v1/bank/transactions/import dabar atmeta 422 klaida išrašą arba eilutę, kurios valiuta skiriasi nuo banko sąskaitos valiutos; camt.053 failo su kelių valiutų išrašais tam pačiam IBAN atveju importuojamas tik sąskaitos valiutą atitinkantis išrašas.
  • POST /v1/bank/statements/import su ISO 20022 templateId dabar priima MT940 failus, atpažįstamus pagal jų turinį arba format: "mt940", ir taiko šablono nuorodų derinimo bei Ntry/CdtDbtInd registravimo taisykles jų eilutėms.
  • POST /v1/bank/transactions/suggest-matches dabar taip pat siūlo išrašytas avansines sąskaitas faktūras gaunamiems mokėjimams ir pardavimo kreditines sąskaitas išeinantiems grąžinimams (grąžinama kaip documentType: "sale_invoice").
  • POST /v1/inventory/landed-costs/create dabar paskirsto sumą proporcingai gautam partijų kiekiui (arba vertei); vienetų, kurie jau iškeliavo iš atsargų, dalis įregistruojama į parduotų prekių savikainą, kredituojant atsargų sąskaitą, kurioje jie buvo, o išparduota partija nebegrąžina 409 klaidos. Atsakymas ir /v1/inventory/landed-costs/get grąžina journalTransactionId.
  • POST /v1/declarations/pl/pit-11/generate ir PIT-11 kalendoriaus teikimas dabar adresuoja kiekvieno asmens PIT-11 formą to asmens gyvenamosios vietos mokesčių inspekcijai, paimtai iš darbuotojo lauko plKodUrzedu, o ne įmonės „e-Deklaracje“ įstaigai; asmuo be galiojančio kodo atmetamas grąžinant 422 klaidą.
  • Avansinės sąskaitos faktūros kreditinė sąskaita (POST /v1/sales/invoices/issue) dabar anuliuoja gautus avansus (Lietuvos sąskaitų plane – 4440), o ne debetuoja pajamas; proformos kredito ar didesnės nei likusio nepanaudoto avanso sumos kreditavimas atmetamas su 422 klaida, o POST /v1/sales/invoices/apply-advance grąžina 409 klaidą avansui, kurio kreditinės sąskaitos padengia visą jo nepanaudotą dalį.
  • POST /v1/sales/acts/create ir /v1/sales/acts/update dabar atmeta 422 klaida lauką saleInvoiceId, priklausantį kitam partneriui.
  • Mokėjimo nuorodos vietažymė {{amount}} (POST /v1/sales/invoices/payment-link, GET /v1/public/pay/{token}) dabar atitinka neapmokėtą sąskaitos faktūros likutį po mokėjimų, pritaikytų avansų ir kreditinių sąskaitų; abi užklausos grąžina 409 klaidą visiškai apmokėtai sąskaitai faktūrai, kurios PDF ir el. laiške nebelieka mokėjimo eilutės.
  • Kreditinė sąskaita, paimanti paskutinę nepanaudotą avansinės sąskaitos faktūros dalį, tiksliai anuliuoja dar atvirą avanso grynąją sumą ir PVM; jei jos pačios PVM skiriasi, jos vatTotal, netTotal ir paskutinės eilutės PVM bei grynoji suma išrašymo metu nustatomos pagal šias atviras sumas.
  • POST /v1/payroll/runs/reverse dabar atmeta 409 klaida žiniaraštį, su kuriuo susieti banko mokėjimai; pirmiausia juos reikia atšaukti.
  • POST /v1/hr/business-trips/create dabar atmeta 409 klaida komandiruotę, kuri persidengia su kita to paties darbuotojo komandiruote, kad už vieną dieną nebūtų skaičiuojami du dienpinigiai.
  • POST /v1/payroll/runs/create su lines dabar atmeta 422 klaida eilutę be gross (bruto) darbuotojui, turinčiam daugiau nei vieną sutartį per mėnesį, vietoje apmokėjimo tik už vieną sutartį.
  • POST /v1/hr/contracts/create dabar atmeta 400 klaida positionId, departmentId arba scheduleId, kuri nepriklauso pačiai įmonei.

Pataisyta

  • /v1/assets/assets/get ir /v1/assets/assets/list dabar grąžina 0 netBookValue likutinę vertę nurašytam ilgalaikiam turtui.
  • /v1/assets/assets/update dabar atmeta nurašytą turtą su 409 klaida, todėl jo savikaina nebegali būti keičiama po nurašymo užregistravimo.
  • Keli vienu metu atliekami /v1/assets/assets/dispose iškvietimai tai pačiai turto vertybei dabar užregistruoja nurašymą vieną kartą; kiti iškvietimai gauna 409 klaidą.
  • Tiekėjo mokėjimo failas iš /v1/bank/payments/export dabar apkarpo EndToEndId iki 35 simbolių, pavadinimus – iki 70, o mokėjimo paskirties tekstą – iki 140 simbolių, kaip leidžia SEPA, ir atmeta eurais neišreikštą sąskaitą faktūrą grąžindamas 422 klaidą.
  • Avansinių lėšų ataskaitos nebeįtraukia darbo užmokesčio išmokėjimo grynaisiais ar bet kokių kitų darbuotojui išmokėtų lėšų, kurios nėra avansas.
  • Partija, pirkta kaina su daugiau nei dviem dešimtainiais ženklais (pavyzdžiui, 3 vienetai po 10,00), galėjo palikti centą atsargų sąskaitoje po to, kai ji buvo išparduota po vieną vienetą; paskutinis iš partijos paimtas vienetas dabar paima visą likusią vertę, todėl atsargų sąskaita ir /v1/reports/stock-balance pasiekia lygiai nulį kartu.
  • /v1/payroll/runs/create be lines dabar išmoka atlyginimą darbuotojui, kurio sutartis buvo nutraukta nurodant pabaigos datą to paties mėnesio ribose, už darbo dienas iki tos datos.
  • /v1/hr/contracts/end ir /v1/hr/contracts/create dabar atmeta 422 klaida, jei pabaigos data yra ankstesnė už sutarties pradžios datą.
  • Sinchroniniai /v1/ecommerce/orders/reserve iškvietimai skirtingiems užsakymams nebegali rezervuoti daugiau prekių, nei yra sandėlyje, o užsakymas su keliomis to paties daikto eilutėmis tikrinamas pagal jų bendrą kiekį.
  • /v1/ecommerce/orders/cancel dabar atmeta 409 klaida užsakymą, kurį sinchroninis /v1/ecommerce/orders/fulfill jau įvykdė, todėl atšauktas užsakymas niekuomet nebeturės sąskaitos faktūros.
  • /v1/ecommerce/orders/create ir /v1/ecommerce/orders/fulfill dabar atmeta ištrintą klientą su 400 klaida, kaip ir /v1/sales/invoices/create.
  • /v1/partners/credit-check dabar konvertuoja atviras sąskaitas faktūras kitomis valiutomis į bazinę valiutą, todėl openReceivables sutampa su /v1/reports/partner-balances.
  • Schemos patvirtinimo klaida dabar nurodo konkretų lauką laukų klaidose (fieldErrors), pavyzdžiui, name arba lines.0.unitPriceExclVat, vietoje _.
  • Lietuvos PVM deklaracija (/v1/declarations/lt/fr0600/compute) dabar apima POS Z ataskaitų, kurių data patenka į laikotarpį, pardavimus ir pardavimo PVM.
  • Lietuvos prekių ir paslaugų ES ataskaita (/v1/declarations/lt/fr0564/compute) dabar apima sąskaitas faktūras su vatScheme: 'reverse_charge' paslaugų stulpelyje.
  • Mikroįmonės Lietuvos pelno mokesčio deklaracija PLN204 dabar prideda užregistruotą pelno mokestį (69 sąskaitos) atgal prie pelno iki mokesčių (19 laukelis) ir parodo jį lauke taxAlreadyBooked.
  • Lenkijos JPK_V7M ir VAT-UE ataskaitos dabar paima pirkimo sąskaitas faktūras pagal registracijos datą, o ne dokumento datą, kaip tai daro didžioji knyga.
  • Latvijos finansinės atskaitomybės eilutė R790 dabar rodo metų rezultatą kaip pajamas atėmus sąnaudas, o Latvijos pelno (nuostolio) ataskaitos eilutės nebeįtraukia balansinių sąskaitų, todėl R180 apima tik sąnaudas.
  • POST /v1/sales/invoices/issue dabar išrašo sąskaitą faktūrą, kurios bendra suma yra nulis (pavyzdžiui, pritaikius 100% nuolaidą), su reikšme journalTransactionId: null vietoje 500 klaidos; iš atsargų išeinančių prekių savikaina vis tiek įregistruojama.
  • Laukas lineNet per /v1/sales/acts/* dabar suapvalinamas tiksliai kaip sąskaitos faktūros eilutės (3 × 1,0050 duoda 3,02, o ne 3,01).
  • POST /v1/sales/invoices/einvoice-xml Rumunijos įmonėms dabar įrašo eilutės sumas, kurios sumuojasi į sąskaitos faktūros grynąją ir PVM grupių bendras sumas, kai pritaikius nuolaidą gaunamos centų trupmenos (EN 16931 taisyklė BR-CO-10).
  • „KSeF FA(3)“ e. sąskaita faktūra (POST /v1/sales/invoices/einvoice-xml, formatas ksef-fa3) dabar užtikrina, kad kiekvieno PVM tarifo eilučių grynosios vertės (P_11) tiksliai atitiktų to tarifo bendrą sumą (P_13_x), o tarifų bendros sumos – sąskaitos faktūros grynąją sumą, todėl nuolaidą turinti sąskaita faktūra nebesiskiria centu tarp eilučių ir bendrų sumų; kiekviena nuolaidą turinčios sąskaitos faktūros eilutė rodo nuolaidą lauke P_10.
  • POST /v1/sales/recognition/progress ties 100% ir POST /v1/sales/recognition/modify dabar atgautinai atleidžia lygiai tas ateinančių laikotarpių pajamas, kurios buvo užregistruotos eilutei, todėl užsienio valiutos procentinio baigtumo eilutė nebeatlaisvina vienu centu per daug.
  • POST /v1/sales/invoices/peppol-xml eilučių sumos ir PVM grupių apmokestinamos sumos dabar susumuoja į sąskaitos faktūros grynąją sumą, kai nuolaida sukuria centų trupmenas, todėl TaxExclusiveAmount lygus sąskaitos netTotal ir joks PayableRoundingAmount nėra įrašomas.
  • GET /v1/public/pay/{token} dabar grąžina 404 klaidą sąskaitai faktūrai, kuri vis dar yra juodraštis.
  • POST /v1/purchases/receipts/create dabar apskaičiuoja vėlesnio dalinio užsakymo eilutės gavimo savikainą pagal užsakymo kainą; anksčiau pridėta atvežimo išlaidų dalis prie ankstesnio to paties gavimo lauko jos nebesumažina (užsakymas 10 vnt. po 6,00, gaunama 5 vnt., pridedama 5,00 frachto, gaunama 5 vnt.: antrasis gavimas yra 30,00, o ne 25,00).
  • POST /v1/hr/timesheets/generate dabar sukuria darbo laiko apskaitos žiniaraštį darbuotojui, kurio sutartis baigiasi mėnesio eigoje, iki pabaigos datos, ir apima kiekvienos darbuotojo turimos sutarties dienas per mėnesį.
  • POST /v1/payroll/runs/approve dabar grąžina 422 klaidą (vietoj 500) žiniaraščiui, kuriame visos sumos yra lygios nuliui.
  • POST /v1/inventory/landed-costs/create dabar atmeta 422 klaida sumą amount, turinčią centų trupmeną, vietoje vienos sumos įrašymo ir suapvalintos sumos paskirstymo atsargoms.
  • POST /v1/capture/documents/confirm dabar yra atatomoji (atominė) operacija: nepavykęs patvirtinimas nepalieka naujo tiekėjo newSupplier, o du vienu metu atlikti to paties dokumento patvirtinimai sukuria vieną sąskaitą faktūrą, o į kitą atsakoma 409 klaida.
  • POST /v1/purchases/invoices/delete juodraščiui, sukurtam per POST /v1/capture/documents/confirm, dabar atšaukia dokumento kopiją (statusas grįžta į extracted, purchaseInvoiceId tampa null), todėl ją galima patvirtinti iš naujo arba ištrinti, vietoje 409 klaidos grąžinimo.
  • POST /v1/bank/settlements/post: iš commissionPercent apskaičiuotas komisinis mokestis dabar suapvalinamas iki sveikų centų, o pardavėjo dalis padengia likutį, todėl summary.commissionAmount, summary.sellerAmount ir žurnalo įrašai nebeturi centų trupmenų.
  • POST /v1/declarations/pl/jpk-fa/generate dabar užpilda NrFaKorygowanej lauką koreguotos sąskaitos faktūros numeriu netgi tada, kai ši sąskaita faktūra buvo išrašyta iki prašomo laikotarpio.
  • POST /v1/reports/vat-summary, /v1/reports/vat-detail, /v1/reports/eu-purchases ir /v1/reports/oss dabar teikia užsienio valiutos sąskaitas faktūras įmonės bazinėje valiutoje pagal sąskaitos faktūros valiutos kursą, kaip tai daro didžioji knyga ir PVM deklaracija, o ne sąskaitos faktūros valiuta.
  • POST /v1/reports/stock-aging su praeities data lauke asOf dabar įvertina atsargų senėjimą taip, kaip jos atrodė tą dieną, todėl jos bendra suma sutampa su /v1/reports/stock-balance tai pačiai dienai; anksčiau buvo vertinamas šiandienos likutis.
  • POST /v1/reports/online-sales dabar grąžina po vieną eilutę kiekvienam kanalui ir valiutai su nauju currency lauku ir įvertina kiekvieną užsakymą sveikais centais taip, kaip sumuojama sąskaita faktūra su tomis pačiomis eilutėmis; anksčiau jis sumuodavo nesuapvalintas eilučių sumas tarp valiutų.
  • POST /v1/reports/fec dabar priskiria banko operacijas į BQ žurnalą, kasos orderius – į CA, o darbo užmokesčio žiniaraščius – į PAIE; anksčiau visi jie buvo rašomi į OD.
  • POST /v1/declarations/pl/jpk-kr/generate dabar pažymi kiekvieną ZOiS, Dziennik ir KontoZapis elementą atributu typ="G", kaip reikalauja JPK_KR(1) schema; ankstesni failai nepraeidavo schemos patvirtinimo.
  • POST /v1/declarations/pl/jpk-mag/generate dabar registruoja atsargų trūkumą kaip RW, o į sandėlį perkeltas prekes – kaip PW.
  • POST /v1/production/orders/complete, iškviestas dukart vienu metu, dabar įvykdo užsakymą vieną kartą; antrasis iškvietimas gauna 409 klaidą.
  • POS Z ataskaitos (/v1/pos/reports/create, /v1/pos/shifts/close) dabar nurašo komplekto prekės sudedamąsias dalis iš atsargų, vietoje to, kad paliktų jas sandėlyje arba atmestų ataskaitą su 422 klaida.
  • /v1/ecommerce/orders/reserve ir /v1/ecommerce/orders/fulfill dabar rezervuoja ir nurašo komplekto prekių sudedamąsias dalis, atitinkančias prieinamumo ataskaitą /v1/ecommerce/products/list; paslaugų eilutės neberezervuoja ir nenurašo atsargų.
  • POST /v1/pos/reports/create dabar reikalauja, kad grynieji cashAmount ir kortelių sumos cardAmount suma lygiai atitiktų grynąją sumą ir PVM; bet koks neatitikimas, įskaitant cento dalis, grąžina 422 klaidą (vietoj 500).
  • POST /v1/ledger/owners/create ir /v1/ledger/owners/update dabar grąžina 422 klaidą, kai equityAccountCode nurodo sąskaitą, kurios nėra įmonės sąskaitų plane.