MLInvoice 2.0.1 julkaistu

Started by Ere Maijala, 03.01.22 - klo:21:32

Previous topic - Next topic

Ere Maijala

Tervehdys!

MLInvoice 2.0.1 on julkaistu. Tässä versiossa on vain korjauksia versiosta 2.0.0 löytyneisiin ongelmiin.

Uusi versio on ladattavissa osoitteesta https://labs.fi/files/mlinvoice-2.0.1.zip. Tarkemmat tiedot muutoksista löytyvät sivulta https://labs.fi/mlinvoice_features.php#changelog.

t. Ere

Timzu

Moi,

Hyvityslaskun tekeminen ei näytä enää onnistuvan.
Herjaa vain "Tietuetta ei löytynyt"


Ere Maijala

Kiitos tiedosta, näin näkyy olevan. Korjataan seuraavaan versioon. Sitä odotellessa ongelman voi kiertää näin:

1. Ota hyvitettävän laskun id talteen selaimen osoiteriviltä. Osoitteessa näkyy jossain kohdassa &id=numero, esim. &id=519 jossa tuo 519 on laskun ID.
2. Klikkaa hyvityslasku-nappulaa.
3. Vaihda osoiteriviltä &id=_ID_ muotoon &id=numero jossa siis _ID_ pitäisi olla laskun ID.

--Ere

ele

#3
Laskun luonnissa kokonaissummarivillä desimaaleja on edelleen liikaa ainakin jos yksikköhinnan desimaalien määräksi on laitettu joku muu kuin 2.

Lisäksi äsken huomasin että ainakin tuoteraportissa summien laskennassa on joku ongelma, rivillä oleva kokonaishinta vastaa veroton + alv -hintaa, mutta summarivillä desimaalit ovat tippuneet pois.



Edit: Unohtui vielä kysyä että miten toi summalaskenta oikein virallisesti pitikään mennä? Mulla on omaan käyttöön muutama näkymä joista sitten lasken mm. kirjanpitotietoja. Desimaalit eivät ole aina ihan täsmänneet, mutta riittävän lähellään ollaan oltu ettei ole kiinnostanut selvittää missä homma menee pieleen. Olen näköjään laskenut laskuriveille pyöristetyn alv0 kokonaishinnan ja jatkanut sen pohjalta sitten laskuja, mutta ilmeisesti MLInvoice käyttää pohjana alvillista pyöristettyä hintaa?

use mlinvoice;

CREATE OR REPLACE VIEW xxx.laskut AS
SELECT
  a.id,
  invoice_no lasku_no,
  a.company_id asiakas_id,
  b.company_name asiakas,
  invoice_date laskupvm,
  due_date erapvm,
  payment_date maksupvm,
  DATEDIFF(due_date, payment_date) maksun_ero_eräpäivään,
  state_id,
  YEAR(invoice_date) vuosi,
  DATE_FORMAT(invoice_date, '%Y-%m') kuukausi
FROM
  mlinvoice_invoice a
  LEFT JOIN mlinvoice_company b
  ON a.company_id = b.id
WHERE a.deleted = 0
ORDER BY invoice_no;

CREATE OR REPLACE VIEW xxx.laskurivit AS
SELECT
  a.id,
  a.invoice_id,
  CONCAT_WS('',NULL,b.product_name, ' ', a.description) tuote,
  a.row_date pvm,
  a.pcs maara,
  a.price hinta,
  a.discount ale,
  ROUND(a.pcs * a.price *
        (1 - IFNULL(a.discount, 0) / 100) /
        IF(a.vat_included = 0, 1, 1 + a.vat / 100), 2) rivisumma_alv0,
  a.vat alv_prosentti,
  a.vat_included,
  a.order_no
FROM
  mlinvoice_invoice_row a
  LEFT JOIN mlinvoice_product b
  ON a.product_id = b.id
WHERE a.deleted = 0
ORDER BY a.invoice_id, a.order_no;


Edit2: Verottajan syventävien ohjeiden https://www.vero.fi/syventavat-vero-ohjeet/ohje-hakusivu/48090/laskutusvaatimukset-arvonlis%C3%A4verotuksessa/#6.1-pakolliset-laskumerkinn%C3%A4t kohdassa 6.1.10 sanotaan että pyöristys tehdään vasta laskun loppusummasta, eli toi mun laskurivipohjainen lähestymistapa tosiaan ei ole oikein. Hankalaksihan tämä menee jos laskulla on useampia alv-kantoja ja sitten lopulta sinne saattaa ilmestyä vielä pyöristys suuntaan tai toiseen.

Ere Maijala

Pyöristäminen on aina ollut vaikea juttu, mutta tarkoitus on tosiaan tehdä virallisten ohjeiden mukaisesti.

Kokonaissummarivillä näytetään edelleen kaikki desimaalit, koska siitä voi olla jotain hyötyä käyttäjälle.

Tuoteraportin laitan korjaukseen.

--Ere

ele

Mikähän tuossa pyöristämisessä olisi paras lähestymistapa? Lähinnä tulee mieleen että laskulle voisi sisältyä pyöristysrivejä jotka sitten vietäisiin kantaan saakka.