[EE] Allahindlusprotsent ei anna soovitud tulemust

Mida teha siis, kui artikli hind on 240€ aga sa tahaksid seda müüa 85€-ga.

Tundub lihtne ülesanne: peaksime panema allahindluse 240-85€ ehk 155€. Aga Meritisse saab sisestada protsenti. Allahindlusprotsent peaks olema 64.583333… DiscountPct välja tüübiks on Decimal(18.2). Ümardades protsendi 64.58-ks saame allahindlussummaks hoopis 154.99. Seega hakkab rida käibemaksuvabalt maksma mitte 85 vaid 85.01. Sellise täpsuse juures (2 kohta peale koma) pole matemaatiliselt võimalik saada numbrit 155.

Selleks, et saada kliendi jaoks summa ümmarguseks, on kolm varianti:

  1. Lisada 0% käibemaksuga ümardus, negatiivse kogusega ja hinnaga 0.01. See tundub esmapilgul kole, aga raamatupidajad on seda võimalust matemaatika ja finantsi ühendamiseks kasutanud aastaid. See on täiesti okei lähenemine.
  2. APIga saab salesinvoice payloadi lisada lisaks TotalAmountile ka RoundingAmount väärtuse. Pildil olevat näidet saaks ümardada, kui RoundingAmount: -0.02.
  3. Kirjuta artikli hinnaks allahinnatud hind ja HCommentisse: “Arvele on rakendatud püsikliendi allahindlus 65%”.

Variant 1: lisa artikkel

Variant 2: RoundingAmount

{
   "Customer": {
     "Name": "Muri2 Maasikas",
     "NotTDCustomer": "false",
     "Address": "Tuleviku tee 6, Lohkva, Luunja vald, Tartumaa",
     "CountryCode": "EE",
     "PhoneNo": "",
     "Email": "mari@example.com"
   },
   "DocDate": "20200106",
   "DueDate": "20200116",
   "TransactionDate": "20200106",
   "InvoiceNo": "A00017",
   "CurrencyCode": "EUR",
   "InvoiceRow": [{
     "Item": {
       "Code": "MAAKLER",
       "Description": "Esimene Rida",
       "Type": 2
     },
     "Quantity": "1.000",
     "Price": "240",
     "DiscountPct": "64.58",
     "DiscountAmount": "154.99",
     "TaxId": "b9b25735-6a15-4d4e-8720-25b254ae3d21"
   }, {
     "Item": {
       "Code": "MAAKLER",
       "Description": "Teine rida",
       "Type": 2
     },
     "Quantity": "1.000",
     "Price": "240",
     "DiscountPct": "64.58",
     "DiscountAmount": "154.99",
     "TaxId": "b9b25735-6a15-4d4e-8720-25b254ae3d21"
   }],
   "TotalAmount": "170.02",
   "RoundingAmount": "-0.02",
   "TaxAmount": [{
     "TaxId": "b9b25735-6a15-4d4e-8720-25b254ae3d21",
     "Amount": "34.00"
   }]
 }

Selle tulemus oleks selline:

Variant 3: juba alla hinnatud hinnaga artikkel

Kui on vaja täpsustamist, siis palun saatke meil ja ma võin pikemalt rääkida.

Miks?

Miks te üldse tegite nii? Sest poes on ka allahindluse protsendid, mitte iga toote kohta allahindluse number. Selline tava.

Miks te ei anna valikuvõimalust? Sest meil on kümned tuhanded kasutajad, kes vajavad uuendusi ja lisafunktsioone, mis hoiavad neile aega ja raha kokku – ja vaid käputäis kasutajaid, kelle jaoks oleks mugavam anda kaasa allahindlus numbrina.

Kas see kunagi muutub? Väga võimalik, aga mitte nii pea.

[EE] HComment & FComment

2019 Detsembri alguses lisandus muutus SENDINVOICE (müügiarved) endointis seoses HComment ja FComment atribuutidega. Varem käitus API nii, et kui JSONis kumbagi ei olnud, siis loodi müügiarve ilma nende kommentaarideta. Nüüd võetakse kommentaarid kliendikaardilt, kui seal on – juhul kui APIsse saadetud JSONis on atribuudid määramata. Kui JSONis on, siis kirjutatakse arvele, olenemata kliendikaardi infost.

[EN] How is VAT calculated in sales invoices

Merit Aktiva follows book keeping standard that states among other principles, that:

  • Every row has its own VAT calculation, because every row has its own general ledger record.
  • Every row is rounded before summed, to avoid fractions to accumulate.

[EE] Kas Merit võiks hoopis meiega ühenduda?

Merit Aktiva ja Palk on oma olemuselt register. Tänane poliitika on selline, et teeme seda mida oskame. See on raamatupidaja (ja personaliosakonna) töövahend. Meil on mõned enda arendatud liidesed, mis mõjutavad praktiliselt kõiki meie kasutajaid:

  • Pangad: Swedbank, SEB, LHV, Põhjamaades Nordic API Gateway.
  • Riik: deklaratsioonide saatmine (Eestis vahendab meid Swedbank, Poolas on otseühendus otse sealse maksuametiga).
  • Äriregister, autentimine ID-kaardi ja Mobiil-ID-ga.

Kas me peaksime võimaldama webhooke määrata? Millised oleks use-caseid? Kui sellele oleks äriline vajadus, mis aitaks meie klientidel rohkem raha teenida ja vähem kulutada, siis peame neid võimalusi kindlasti tõsiselt kaaluma.