Korjatkaa nyt jo ne ALV pyöristykset käteislaskuilla

[nicklasuusitalo]

Onko ongelma muka vain meillä vai miten muut olette seuraavan ongelman ratkaisseet?

Senttipyöristykset vuodesta toiseen, ohjeena joskus vuosia sitten saatu 

https://community.visma.com/t5/Visma-Nova-kayttovinkit/Laskutuksen-brutto-tapa-ja-mahdolliset-sentti...

Meillä varasto verollisena ja tästä syystä sitten käteiskaupassa käytetty aina maksutapana käteistä vaikka asiakas maksaisi pankkikortilla, jolloin Nova pyöristää loppusumman. Tuotteiden hinnat pääsääntöisesti 10 ja 5 sentillä jaollisia, mutta nyt kun alv nousee ei posketonta kasaa nimikkeitä ole millään mahdollista pyöristellä heti... Hinnastojen luontikaan ei tue 5 snt jaollisia pyöristyksiä vaan ainoastaan 10 tai 1 snt.

Tänäänkin hyvä esimerkki: tuotteiden alvilliset hinnat 3,60 ja 9,90 verollinen loppusumma Novan laskuopilla 13,49. Tähän laskentaan kun saadaan lisää desimaaleja tai ylimääräisiä pyöristyksiä pois niin saadaan paikkansa pitävät summat ilman loppusummapyöristyksiä tai työläitä purkkavirityksiä.

Jatkossa kun tuotteiden hinnat voivatkin olla vaikka 12,61 ja 13,82 ei pankkikortilla maksava asiakas varmasti halua maksaa käteispyöristyksen 26,45 tai Novan laskuopin mukaista 26,44...

[Marko Koivuniemi]

Pakkohan tänne oli tulla kertomaan ilosanomaa uudesta 10.6.2. osapäivityksestä: 

• Kun tilauksella/laskulla on ALV kentässä valinta 2.Alv sisältyy (brutto), myös rivin veroton kenttään lasketaan arvo 4 desimaalilla.

[Maija Jussila]

Aamulla ei ainakaan ollut... kynällä korjasin tulosteeseen...

[petriku]

Eikös tuo vasta huomenna 3.12.2024 julkaista?
https://community.visma.com/t5/Visma-Nova-uutiset/Visma-Nova-10-6-2-valipaivitys-julkaistaan-3-12-20...

[Hannele Grönfors]

Hei,

Kiitämme kaikkia palautteistanne. Otamme tutkintaan laskujen bruttotavan (alv sisältyy) laskennan haasteet.

[Maija Jussila]

Se laskenta oli oikein ennen jotain päivitystä. Jotenkin kummasti Prisman kuiteissa on luvut ihan oikein ja kaikkien muidenkin paitsi tällä ohjelmalla tehtyjen. Onneksi meillä on ilmainen verkkokauppaohjelma joka osaa käsitellä oikein. Hävettää vain korjailla käsin kuitteihin ja selitellä summien paikkansapitämättömyyttä. Joka kuukausi myös ärsyttää korjailla nuo senttiheitot. Ihan turhaa työtä. Näiden ohjelmien pitäisi helpottaa työtä, ei vaikeuttaa!

[Marko Koivuniemi]

Prisman kuiteissa ei näy rivikohtaisia verottomia lukuja /veron määrää vaan alv-erittely lopussa.

=> Tuolla mainuttu:  "Tärkein syy tähän on se, että arvonlisäveron lopullinen summa lasketaan vasta laskun verottomasta loppusummasta, ja se pyöristetään 2 desimaaliin per verokanta.
=> Minusta tuntuu että Visma tosiaan tulkitsee tämän asian eri tavalla kuin Prisma. => Kumpiko on oikeampi onkin sitten ihan eri asia.

Mutta jäipäs asias vaivaamaan ja otin S-ryhmän apista yhden esimerkkikuitin jota pyörittelin. Kun rivikohtaisesti on näkyvissä vain loppusumma niin virhettä "ei ole" - vaikka oikeasti se siellä taustalla on ihan samanlaisena. Me vain uskomme mitä kuitissa on ja se riittää. 

Mielenkiintoista jos toiminta on muuttunut kesken kaiken - voi olla kyse buginkorjauksesta tai sitten uudesta bugista. Tai sitten päivityksen yhteydessä yrityksessä itsessääon muutettu asetuksia. Mutta toivottavasti helpparin väki tai kehittäjät kurkkivat tätä ketjua ja miettivät.

[Marko Koivuniemi]

No niin.  Eli Nicklasin vihje vuoden 2020 kesäkuusta johdatti jäljittämään Novan 10.1. asennuspakettia joka minulta vielä löytyikin. Ja siinä versiosaatteessa onkin itse asia.  

[Maija Jussila]

"Muutos liittyy eurooppalaiseen verkkolaskustandardiin sekä verottajan ohjeisiin". Ihmeen hiljaa on oltu asiasta, vaikka tätä on moneen kertaan kysytty. Missään muussa yhteydessä ei ole tullut tuota viittausta. Ihmettelen vain sitä että jos verottajalta kysytään mitä mieltä se on että yksityisasiakkaalle tulee loppusumma väärin? Ja tuo verkkolaskustandardi, tässä varmaan ohjeet nettohinnoilla toimittaessa. Yleensä verkkolaskuja lähetetään yritysten kesken. Kuluttajaverkkolasku on ihan eri asia ja luulisi siinäkin olevan tärkeää että loppusumma olisi oikein??? Vai onko se yhdentekevää?? Mielestäni koko asia on silkkaa kädettömyyttä! Minulle sanottiin Vismalta että voin laittaa esityksen summasta joka kattaa tästä aiheutuneet lisätyöt, joten jos laitetaan me kaikki ja katsotaan kuinka nopeasti alkaa asia kiinnostaa 😄

[nicklasuusitalo]

Väittäisin että jäljet tuon ongelman kanssa johtavat MTRIVI ja LASKURIVI taulujen VEROTON sarakkeiden datatyyppiin jotka on päätetty olevan 2 desimaalin lukuja, eikä 4 desimaalin kuten esim. VERO.

[Marko Koivuniemi]

Voisikohan tuohon olla kehitteillä muutoksia koska riveiltä löytyy myös VEROLLINENHINTA, VEROTONHINTA ja VEROLLINENSUMMA joiden tietotyyppi on Money eli käytännössä neljän desimaalin tarkkuus sielläkin. Eivät uskalla muuttaa olemassaolevia että jokin hajoa jossain muualla. 

[Marko Waenerberg]

Juurikin varmasti tuo syynä. Luulisi olevan helppo korjata...ellei sitten johda ongelman tai virheen  kerrannaisiin toisaalla.

[nicklasuusitalo]

Jepjep eli tässä on myös se että käytännössä Brutto laskentatapa on jätetty vain koristeeksi ja kaikki laskenta tapahtuu nettotavalla eli pyöristetyt verottomat summataan ja kun näihin lasketaan vero päälle ollaan nykyisessä ongelmassa. Eli kuten Waenerberg sanoi niin esimerkin kohta 3 missä rivien laskennalliset verottomat pyöristetään kahteen desimaaliin on tämän ongelman juurisyy.

[nicklasuusitalo]

Tosiaan vuoden 2020 kesäkuussa julkaistu päivitys aiemmin toimineen systeemin rikkoi. Eli "tavallisessa" kuluttajakaupassa kuitissa merkityksellisiä on verolliset hinnat eli tuntuu järkevältä tehdä niin kuin Prismankin kuitissa on tehty eli jokaisen verokannan verolliset summat lasketaan yhtään ja niistä otetaan vasta lopuksi vero ja veroton hinta. Rivikohtaista verotonta hintaa ei vaadita ja tuntuisikin järkevältä että mikäli käyttössä laskentatapa 2 ALV sisältyy Brutto niin laskenta olisi kuvausta vastaava eli riveille voitaisiin laskea informatiiviset verottomat hinnat mutta laskennat suoritettaisiin niillä verollisilla hinnoilla. Tai jos vaikeuttaa logiikkaa liikaa riittäisi näihin korjaukseksi että laskennassa pidettäisiin mukana 3 desimaalia ja informatiiviset kentät pyöristettäisiin tai jätettäisiin 3 desimaalille, koska mikään viranomainen tai taho ei vaadi tuotekohtaista veroerittelyä vaan ainoastaan verokantakohtainen yhteiserittely on tarpeen.

Ainut muutos mikä tähän riittäisi olisi että kenttää veroton summa ei pyöristettäisi...

[Marko Waenerberg]

Käsittääkseni ratkaisu voisi olla, että ohjelmasssa pitäisi olla rinnan tarkkaan laskettu rivikohtainen veroton summa ilman pyöristyksiä apumuuttujana. Käyttäjälle voisi edelleen siis näyttää kahteen desimaaliin pyöristetyt summat mutta taustalla apumuttujassa oleva tarkka summa seuraisi laskennan loppuun asti, jolloin vasta pyöristys tästä arvosta. Virhe/heitto tulee nyt esimerkin kohdassa 3 eli siitä, että väliarvoja (rivikohtaisia) summia pyöristetään jo kesken matkan ennen laskennan loppua?

[Marko Koivuniemi]

Kun luin tuota Visman selvennystä niin yritin pyöritellä asiaa pienessä mielessäni mutta lakisääteiset merkinnät (kaksi desimaalia) ja sisäinen laskenta ja rivikohtainen erittely on melkoinen soppa selvittäväksi. En minä ainakaan keksinyt ratkaisua. Pyöristysrivit ovat tietysti kosmeettinen haitta. Mutta tuossa esimerkissäkin kun kolmen rivin pyöristyksistä jos tulee yhteensä parin sentin heitto niin eihän sitä millään esitä sekä absoluuttisen korrektisti sekä silmille että sisäiselle laskennalle. Ja on sitten makuasia että mitä pitää korrekteimpana tapana esittää asiat. Kritiikin ymmärrän mutta jos tiedättä ns. paremman ohjelman joka toimii tässä tapauksessa paremmin niin olisi mielenkiintoista nähdä tuon Visman antaman esimerkin kaltaiset rivit - miten niissä näkyy rivitiedot vs. kokonaisuus? Minusta kyllä voisi aivan hyvin olla niin että rivitiedoissa näkyisi pyöristykset mutta yhteenvedossa näkyisi alv-laskettuna tarkoille arvoille. Mutta sekin sitten taas osuu jonkun silmään häiritsevästi. Saati sitten mitä sanoo laki. 

[Marko Waenerberg]

Samasta virheestä oltu yhteydessä tukeen jo reilu vuosi sitten.

Laskennassa välivaiheiden (esim. rivien pyöristys  alv:ta laskettaessa) tulisi matematiikan perussäännöillä laskea aina mahdollisimman tarkoilla arvoilla ja pitää mukana ns. ylimääräisiä desimaaleja loppuun asti ja vasta loppusumma pyöristää vaadittuun tarkkuuteen. Jos matkan varrella pyöristellään epätarkasti johonkin desimaaliin, loppusumma ei vaan täsmää.

[petriku]

Täältä myös yksi valittaja jonon jatkoksi. Asiakkaille jää varmasti hyvä mielikuva Vismasta/Novasta, kun selitän liika/vajaasenttisen laskun johtuvan järjestelmän kykenemättömyydestä.

[Maija Jussila]

Ei ole ongelma vain teillä. Olen tästä valittanut vaikka ja kuin pitkään, mutta ei kiinnosta Vismaa!

Mikään ei ole niin noloa kuin lähettää asiakkaalle kuitti jossa on väärä tai käsin korjattu hinta.

Tai jos lähetät laskun sähköpostilla, niin kirjoitat saatteeksi että älä maksa tuota summaa mikä laskussa on koska Vismaa ei pätkääkään kiinnosta onko teille tuleva lasku/kuitti oikein vai väärin...

Verkkokauppamme osaa veloittaa oikein, mutta sehän onkin ilmaisohjelma, eikä tällainen joka maksaa aivan törkeästi.

Suoritusten kirjauksessa tulee tuo senttiongelma esiin ja teettää sekin ihan liikaa töitä.

Mutta mitäpä kiinnostaisi, kun ei itse tarvi painia sen ongelman kanssa!

Suoraan sanoen V....aa tämä asia! Joten et ole yksin asian kanssa 🙂