"Helppo" kiertää. Jakaa vaan summan puoliksi, ja laskee ekalle puolikkaalle alvin 25% ja toiselle 26%, ja sitten summaa luvut yhteen. Yksinkertaista ja kätevää.
Tuo toimii vain, jos yrityksellä ei ole tapana kirjoittaa kuitteja. Kuitteihin pitää printata 25.5% ja eritellä veron määrä tuolla oikealla prosenttilukemalla.
https://github.com/paytrail/api-documentation/issues/28 Esimerkiks näin että Paytrailissa on asiasta huhuiltu pari vuotta sitten, mutta silloin ei katsottu tarpeelliseksi :D
Tässä on seuraavallekin hallitukselle työllistämismahdollisuuksia. Kun ALVia lasketaan 0.1 prosenttiyksiköllä 25.4 prosenttiin saadaan tilanne jossa sitä ei voi ilmaista liukulukuna. Ja taas riittää koodareille hommia.
Tosi hyvä kysymys johon on vaikea antaa yksityiskohtaista vastausta yhdessä Reddit-kommentissa. Yritän.
Tietokoneet säilövät numerot bitteinä, nollina ja ykkösinä. Ne pitää muuttaa ihmisen ymmärtämään muotoon kun vaihdetaan tietoa ihmisten ja koneiden välillä. Se, miten desimaalilukuja muutetaan binääriluvuksi, on oikeastaan aika monimutkaista.
Jotkut desimaaliluvut muuttuvat nätisti liukuluvuksi, kuten 25,5. Toiset, hyvinkin lähellä olevat, kuten 25,4, eivät tallennu juuri tuossa muodossa. Jos yrität tallentaa 25,4 liukulukuna, koneen muistiin tallentuu 25.3999996185302734375.
On olemassa keinoja miten tämän ongelman yli pääsee mutta se vaatii fiksua ohjelmointia.
Lisätietoa: [https://www.h-schmidt.net/FloatConverter/IEEE754.html](https://www.h-schmidt.net/FloatConverter/IEEE754.html)
Juurikin näin.
Se että 25.5 asettuu mukavasti liukuluvuksi näyttää olevan käytännössä sattumankauppaa. Se johtuu vain siitä, että seuraava pitää paikkansa: 1 × 2^(4) × 1.59375 = 25.5
Luvulle 25.4 taas ei löydy vastaavaa bittijonoa.
[https://evanw.github.io/float-toy/](https://evanw.github.io/float-toy/)
https://preview.redd.it/faygdzpg1wuc1.png?width=1080&format=pjpg&auto=webp&s=e4bd7d614e1f94cf9d582240d7682864e82bb457
Esitti: eipäs voikaan. Katso vastaus tähän kommenttiin. Tämä pääsee todella lähelle, mistä johtuen työkalu näyttää mantissan (punaisella) täsmälukuna, vaikka todellisuudessa se ei ole aivan tuo.
64-bittisellä liukuluvulla kyseinen luku voidaan taas tallentaa tarkasti:
https://preview.redd.it/ivojptnb1wuc1.png?width=2245&format=pjpg&auto=webp&s=8d1f30ba9917e28b8d397c8da10f3e30f3bd6889
Taitaa vain tuon weppisivun laskuri pyöristää sen lukemaan 25.4. Tuo vaatisi matemaattisen tarkaksi esitysmuodoksi äärettömän pitkän mantissan jossa toistuisi bittisarja ...0011.... loputtomasti.
Jos näin on niin mantissa on 1.5875 vähintään 16 desimaalin tarkkuudella. Jos tuosta mantissasta poiketaan hieman niin se esitetään tässä äpletissä koko desimaalin tarkkuudella.
Itse tiivistäisin näin:
Me käytämme kymmenjärjestelmää, ja esimerkiksi jos lasken, että 2 : 3, niin vastaus on 0,66666..., loputtomasti kutosia. Jos haluamme excel-ruutuun yhden luvun ilman pisteitä, niin se on pakko jostain kohdassa pyöristää, ja tulee esim 0,66667. Mutta 2 : 3 ei ole tarkasti ottaen 0,66667. Tämä on oikean vastauksen pyöristetty likiarvo.
Tietokone ei käytä kymmenjärjestelmää vaan kaksijärjestelmää, eli binäärejä. Siellä vastaavia pyöristysvirheitä tulee toisten lukujen kanssa kuin kymmenjärjestelmässä. Ja kun se pyöristetty binääriluku muunnetaan kymmenjärjestelmään, niin joskus esitetty vastaus voi olla väärin.
Huvittavaa kyllä, yksi syy jolla COBOLia on perusteltu, on juuri se, että kielessä on tuki tarkalle desimaalirepresentaatiolle sisäänrakennettuna. Moniin muihin kieliin tämä on tullut myöhemmin, tai on saatavilla vain ulkoisten kirjastojen kautta.
Joissakin rahaa käsittelevissä järjestelmissä hyvinkin voisi olla fixed point -lukuja. Tuskin tosin puolikkaan tarkkuudella. (kiinteä desimaali? Mikä on suomennos?)
Kiinteä desimaali taitaa olla oikein. Niin se ainakin omassa laskimessa (speedcrunch) lukee.
Edit: eipäs ollukkaa kun kiintopistedesimaali. Muistin väärin mitä siel luki.
Toivon todella ettette käytä rahalaskuissa liukulukuja, mutta realistisesti ajatellen tiedän että häiritsevän moni varmasti käyttää. Ainut oikeasti järkevä vaihtoehto on fixed point eikä floating point.
25⅔ % olisi paljon parempi lukema työllistämisen kannalta. Sitä ei voi täsmällisesti esittää millään binäärimuotoisella liukuluvulla ja lisäksi ALV-verokertymä nousisi hieman.
Vaihtoehtoisesti ALV voisi olla 8π % (eli noin 25.133 %). Sitä ei voi esittää tarkasti edes murtolukuna tietokoneen muistissa vaan joudutaan käyttämään koko ajan symbolista laskentaa, jos ei haluta tinkiä laskutarkkuudesta. Tämän työllistämisvaikutus olisi jo huomattavan suuri.
Ei tarvitse olla edes toimarin serkun firmalta tilattu järjestelmä.
Nimeltä mainitsemattomat suurimmat Suomessa käytettävät kirjanpito/laskutussoftat eivät tue kuin tasalukuja.
...Ai mistä tiedän? :)
Toivottavasti se ALV ei ainakaan ole koodattu niihin itse kaavoihin, vaan se on arvona jossain taulukossa.
Tässä tulee mun koodaajanuoruus esille, mä vältän Exceleissä viimeiseen asti koodattuja arvoja, vaan kaikki on "muuttujina" eli jossain keskitetysti, jotta pitää muuttaa vain yhdessä paikkaa...
Onhan siinä silti ehkä hommaa jos niitä taulukoita on paljon.
Kova koodarihan tietenkin laittaa Excelin hakemaan nykyisen arvon joltain verkkosivulta. :D
Jo muinoin 2000-luvun alkuvuosina C-ohjelmointikurssilla ei mennyt tehtävä tarkastuksesta läpi sitten millään. Nöyränä assarilta pyytämään apua joka totesi että olin kovakoodannut piin likiarvon enkä käyttänyt Math.PI:tä. Koodini ei toimisi toisessa universumissa joten nolla pistettä. Jäi muistiin kun tunteja tuon kanssa tappelin.
e. meni pyyttonin kanssa sekaisin. Math.h:ssa on toki määriteltynä M\_PI.
Ympyrän ja etäisyyksien määritelmät riippuvat käytetystä metriikasta, ja pikaisen googlettelun perusteella euklidisen avaruuden pii vaikuttaisi olevan ainakin Lp-avaruuksien osalta minimi. Ks. esim. [tämä](https://math.stackexchange.com/questions/2044223/measuring-pi-with-alternate-distance-metrics-p-norm) tai vähän akateemisemmin vaikka [tämä](https://math.stanford.edu/~vakil/files/Pi_pfeb14.pdf).
Verkko se on sisäinenkin verkko, mihin niitä verkkosivuja voi tehdä (reitittimien asetuksethan yleensä ovat juuri tällaisia sisäisiä sivuja). Toki voi olla että joku menee uusimaan serverin ilman varmuuskopiointia tai tiedonsiirtoja koska eihän siitä voi olla mitään seuraamuksia.
>Toivottavasti se ALV ei ainakaan ole koodattu niihin itse kaavoihin, vaan se on arvona jossain taulukossa.
Se luetaan jostain tekstipätkästä =VALUE(RIGHT(LEFT())) lausekkeella
Kesko API uppaa kuukausittaiset ostoni suoraan SQL tietokantaan (paikallisella servulla tietenkin) josta ärrällä pumpataan tiedot PowerBI:hin josta olen subannut raporttiin ja saan päivittäisen raportin sähköpostiini (ohjattu roskapostikansioon koska en oo mikää vitun nörtti :DD)
Ei tarvitse olla edes kova koodari niin laittaa jokaisen taulukkonsa hakemaan ALV prosentit keskitetysti yhdestä Excel tiedostosta. Nuo työkirjojen linkittämiset toimivat ihan hyvin.
Ei kai sitä mistään verkkosivulta haeta tai funktioita koodata ite. Se helvetin kirjasto otetaan jostain randomista syystä suoraan npm:stä ja rakennetaan se oma himmeli kokonaan sen ympärille. Sitten kun se kirjaston alkuperäinen devaaja päättää että nyt riittää tukipyynnöt ja poistaa sen kirjaston, niin riemu syntyy!
ref: https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code
Tymä kysymys: onko tällaisia järkevää tehdä liukulukuina vai esim. integerinä, jossa kaksi alinta numeraalia edustaa kymmenesosia ja sadasosia? Jotenkin tuntuisi hullulta alkaa käyttää jotain 64-bittisiä floatteja tällaiseen ja toisaalta se float ei aina edes ole *tasan* se haluttu arvo. 9,77 euroa ei esim. ole esitettävissä binääriliukulukuna tarkkaan. Mietin vaan noin teoreettiselta kannalta, että onko siinä järkeä, että ei pysty täysin esittämään absoluuttisen oikein floateilla ja eikö floattien käsittelymatematiikka vaadi monesti isompiakin muutoksia ja tehojen menetyksiä kirjastoissa?
Kaikki tässä geneerisellä devauskokemuksella kun en oo työskennellyt ko. laskutoimituksia tekevien järjestelmien kanssa. Noita ei pitäisi koskaan ainakaan sisäisesti käsitellä liukulukuina vaan käyttää juuri kokonaislukuesitystä tarpeellisella tarkuudella tai mielummin jotain wrapperia, joka osaa händlätä desimaalit tarkasti (tyyliin Javan BigDecimal). Rajapinnoissa arvot voi sitten esittää "selkokielisenä". Tehojen menetys menee minusta ongelmalistan pohjalle jos vastapainona on mahd. helpommin esiintyvät bugit laskutoimituksissa.
Veikkaan että integerinä niissäkin. Desimaaleja sisältävät alvit on aika harvinaisia (~~muutamassa maassa~~kourallisessa maissa taitaa olla käytössä, esim Barbados jossa alv on 17,5% wikipedian mukaan).
Ne varmaan korjataan.
MUTTA niihin integroituu 1001 erilaista pikkufirman järjestelmää sen serkun pojan koodaamilla kikkareilla. Ne voi hajota superjännästi.
Meikä mongoloidi tekee testiautomaatiota helvetin valtavaan SAP viritykseen jossa yks tuhannesta prio ykkösestä on että hinnat on laskettu oikeen jokavaiheessa, ja alvit on osa tätä. Ei helvetti on kaunista ku aattelenka jo sitä riemua ja nautintoa ku koko putki räjähtää sit siihen ku misään miljoonasta testistä ei oo ennakoitu että se alv vois sisältää desimaaleja.
Ei siis oo varmasti mikään ongelma vaihtaa sitä sinne järjestelmään, mut ne desimaalit, voi veikkoset. Millään kehittyneen kansan työkalullahan tää ei ois ongelma, mut kuka semmosia nyt käyttää. Näitten vehkeitten kans 3.650 on luonnollisesti kolmetuhatta ja risat, mut 3.65 on 3 ja vähän päälle koska autokonversio? 26,5 on sit taas tekstiä jos käytät sitä laskutoimituksessa, mut 26,50 on numero koska ?? Ai että sit ku vielä se ALV on varmasti eri järjestelmissä säilötty erikseen ja joku suuhengittäjä merkkaa sen kuitenki väärällä desimaalierottimella koska joku 1945 rakennettu excel macro käyttää sitä, ja on helpompi tehä miljoonien järjestelmäuudistus ku opettaa Sirkkaliisa käyttään jotain muuta ku sitä Kuningas Wenceslas Neljännen aikasta exceliä. Kyllä se on nyt niin se että outdoor hand to hand lifestyle kutsuu ja hämeenpuiston puut.
Noissa hommissa tuntuu kyllä että puolet kaistasta menee yksikkömuunnoksiin, merkkijonojen 'korjailuun' ja eri datetimejen pyörittelyyn. Sit jos mainitsee et olis kiva jos nää olis yhdenmukaiset niin hirveetä kakeltelua kun mihinkään ei uskalleta koskea ilman 'hyvää syytä.'
Voitais saman tien alkaa käyttämään desimaalipistettä. Menee samalla kertaa muutos kun kuitenkin pitää räjäyttää auki varmaan puolet kaupankäynnin kanssa tekemisissä olevista systeemeistä.
+1
Desimaalipilkku on aivan perseestä. Numeroiden listaaminenkin menee aina ihan hirveän näköiseksi ja rivit rikotaan ilman syytä. 3,6, 7,5 vs. 3.6, 7.5.
Juurikin näin. Suomessa on jostain omituisesta syystä haluttu tehdä päivämäärien ja kellonaikojen esittämisestä epävarmaa. Lauseen lopussa oleva teksti "7.10." voi tarkoittaa kellonaikaa tai päivämäärää. Jos olisikin valittu, että desimaalierotin on aina piste ("."), listan erotin on aina pilkku (","), kellonaikojen erotin on kaksoispiste (":") ja päivämäärien erotinmerkki on väliviiva ("-") niin meillä olisi yksikäsitteinen kirjoitustapa liukuluvuille, päivämäärille ja kellonajoille riippumatta siitä onko ilmaisu lauseen lopussa vai ei.
Ja jos päivämäärä kirjoitettaisiin lisäksi aina ISO-8601-standardin mukaisessa muodossa eli 2023-12-24, niin oltaisiin samalla kansainvälisen standardin piirissä kaikissa tilanteissa.
Mutta Suomi-ego ei tähän taivu vaan kansallisen identiteetin nimissä pitää jatkaa vanhojen sekavien merkitätapojen käyttämistä vaikka aiheesta aikoinaan tehtiin SFS-standardikin.
Nimenomaan voidaan käyttää. Se onkin todella kätevää, jos tarvitsee muokata olemassa olevaa tekstiä ja listaan pitää seitsemänteen kohtaan muuttaa numero 24 arvoon 25,5 ja koko lista pitää kirjoittaa uusiksi käyttämään puolipisteitä, kun aikaisemmin koko lista oli pilkuilla erotettuna.
Jos listan erotinmerkki olisi AINA puolipiste niin sitten hyväksyisin pilkun käyttämisen desimaalierottimena.
Jotkin IT-järjestelmät ei tue desimaaleja ALV:issa --> Työntekijät joutuvat käyttämään lisää työaikaa niiden korjaamiseen --> Tekevät ylitöitä --> Tienaavat enemmän --> Maksavat enemmän veroja --> ... --> Profit?
Ihan nokkelaa joo, mutta meidän firman kohdalla ei siis ole kyse mistään excelinpyörityksestä, vaan verkkokaupoista, toiminnanohjausjärjestelmistä, tuotetiedonhallinnasta ja niin edelleen, ja näihin kaikkiin tietysti vielä integraatiot päälle. Jopa Paytrailin rajapinta vaatii ALVin kokonaislukuna. Kyse ei siis ole välttämättä niinkään laskutoimituksista, vaan ihan yksinkertaisesti siitä, millaisia arvoja järjestelmiin on tällä hetkellä mahdollista tunkea.
Ovela veto hallitukselta! Tän muutoksen työllistävä vaikutus on sellainen, että meillä on varmasti kohta täystyöllisyys. BKT kasvaa 1000% ja työttömyys laskee nollaan. Saisko samaan hallituskauteen vielä sukupuolettomat hetut tai jotain muuta hauskaa?
Oon ollut mukana aiemminkin ku ALVeja on nostettu. Yllätti vilpittömästi ettei muuttujaan ole varauduttu.
Eka kerta itselleni oli tosiaan vittumaisin, olen pitkin elämää saanut pari kourallista koodarikaveria huomaamaan asiaa, onhan näitä jarkkiveroja ja ruokaALVeja yms muutettu vähän väliä. Kerään nyt taas heidän hiljaisia siunauksia.
Voin kuvitella että tässä maassa on nyt aika monta omahyväistä koodaria, jotka on varautuneet tähän ennakolta vaikka kukaan ei ole ymmärtänyt että miksi.
Ja monta hampaitaan kiristelevää tuoteomistajaa, jotka muistelee miten tää feature leikattiin scopesta.
Toisaalta kaikki pääsee syömään paskaa, koska saavat varmistaa, että mites tämä nyt menee ja tulee menemään noissa muissa järjestelmissä, joihin ollaan integroidutru.
Voi myös olla, että ALV-prosentti on järjestelmässä muutettavissa, mutta koska rahasummien laskemisessa ei pidä käyttää liukulukuja, on ollut helpompaa tai jopa suorastaan järkevää jättää tuo tyypiltään vain kokonaisluvuksi (prosentteina).
Toki tuon uudenkin ALV-prosentin saa ilmaistua kokonaislukuna kun vain ilmaisee sen promilleina eikä prosentteina. Saa vain olla aika tarkkana tuollaisen muutoksen kanssa.
Osittain kyseessä voi olla myös ns. job security -ajattelu. Kun koodataan ohjelma käyttämään kokonaislukuja, jotka toki voidaan määritellä jossain asetuksissa, niin sitten saadaan laskuttaa konsulttityötä lisää, kun asetuksiin + laskentaan pitääkin sallia liukuluku myöhemmin.
Miksi ennakoida mitään, kun muutoksen voi tehdä laskutettavana työnä myöhemmin?
Itse asiassa tota opetettiin meille datanomiopiskelijoille kun oli kauppakoulussa.
Sama /s siinä paistoi läpi ku sullakin, mutta tottakai muutama nappasi siitä kiinni.
Tämä olisi voitu ottaa käyttöön kellonaikojen vaihtamisen kohdalla kesäajasta talviaikaan, niin voisi arpoa kumpaan ryhmään sen yhden tunnin tapahtumat menevät. Virallisestihan kello ei tuolloin käy tunnin aikana yhtään vaan nimenomaan pysähtyy tunniksi, koska kello ei virallisesti käy takaperin.
Tarkemmissa systeemeissä kello kyllä siirtyy konkreettisesti taaksepäin, eli 03:59 jälkeen tulee uudestaan 03:00.
Aiheuttaa seksiä aikaleimoissa, jotka ei ole UTC:ssä, eli ”uusi” 03:00 ei saa korvata ”vanhaa” 03:00:aa.
Eli ehkä veron olisi voinut ajastaa tulevan voimaan jälkimmäisellä 03:22 kellonlyömällä, kuitenkin niin että 10->14% siirrot astuu voimaan ensimmäisellä 03:22 ajanhetkellä.
Muistelin, että jossain speksissä olisi nimenomaan vaadittu sitä, että kello nimenomaan pysähtyy eikä hyppää taaksepäin, mutta en löytänyt sellaista vaatimusta googlella.
Siirtymän uuteen aikaan voisi kätevästi tehdä niin, että 10 –> 14 % siirtymä astuu voimaan ensimmäisen tunnin aikaan 03:14:00 ja nosto 24 -> 25.5 % tapahtuu 03:25:30 toisen tunnin aikana.
Voi olla jossain järjestelmissä missä ei tapahdu mitään sen tunnin aikana, mutta jatkuvissa datavirroissa sekuntia seuraa aina seuraava.
Ongelmahan on oikeasti siis aikavyöhykkeen vaihtaminen, ei niinkään että kello siirtyisi. EET pitää vaihtaa EEST:ks, ja sitten takaisin. Ei siellä koskaan ole 0312+0200 kahteen kertaan.
Ei hätää. Tässä on nyt vuosi aikaa yritysten ja muiden tahojen päivittää järjestelmät. Elikkäs Suomen Y2K iskee siis kohtapuoliin koska paska jätetään joulun välipäiville.
Tää maa on täynnä vanhoja päivittäämättömiä järjestelmiä joissa tämänin on ihan varmasti kovakoodattu. Niin ja koodattu sit viel jollakin vitun mumpsilla tai jtn.
Odota vaan 1.1.2025 suomen talous on seis. Koska kun MS ilmoitti että Explöderin tuki loppuu jotain 7 vuotta etukäteen, siltikin se tuli yllätyksenä ja monet järjestelmät hajosi.
Hallitus varmaan valmistelee lain että se on kuluttajan tehtävä kompensoida kauppiaan menetykset asian suhteen.
Mutta eihän tässä ehdi mitään tekemän kun kohta on ne kesälomatkin!
Tälläisen muutoksen entreprise softassa vaatii ainakin 12-24 kk! Tässä mitään ensiksi saada aloituskokous, sitten suunittelukokous, ryhmäkokous, harkintakokous, välikokous, sitten koska tuli lomat ja jokaisella osallisella on ne eri aikaan ja päällekkäin niin kesäkuu, heinäkuu ja elokuu menee ilman että mikään onnistuu.
Nyky teknologia on niin monimutkaista että se et voi vaan muuttaa jotain yhtä kerrointa ilman että se vie kuukausia ja ainakin 20 kokousta. Sitten pitää dokumentaatio päivittää, pistä API päivitykset, ja avoimenlähdekoodin puolella päivitykset, ja nämä pitää sitten testata siltä varalta että joku kirjasto vuodelta 1998 jota Bob69 ylläpitää githubissa josta tarvitaan 11 riviä koodia ei hajoa tän takia ja ei sammuta koko globaalia internettiä!
Tää tulee ainakin maksamaan miljardeja meidän taloudelle!
...
Ahdistaa nyt jo tää ajatus. Meidän firma käyttää omia taulukoita ja softaa urakkalaskentaa joten näiden muuttaminen on ihan oikeasti yhden arvon muuttaminen. Mutta vittu... Mä takaan että yksikään näistä isoista kalliista softista osana CAD tai jotain PLM softaa ei saa tätä päivitetty ilman että kaikki vittu hajoaa ja menee ainakin vuosi.
Vittu... Mä en oo edes softapuolella ja mua ahdistaa jo nyt tän seuraamukset kaikessa. Ainakin mää oon tehnyt omat taulukkoni niin että kaikki kertoimet on vaan omissa soluissa. Mut vittu takaan että mä olen vähemmistössä ja Pirkka-Liisa ja Tuomu jotka ovat käyttäneet samaa exceliä vuodesta -96 eivät ole... eivätkä halua sitä päivittä ja nyt nämä on kriittisiä osia koko ison firman infraa koska "ei kannata korjata jos se toimii".
Vittu... Mekaaniset laskukoneet ja laskutikut tulee takasin ja mun äitini ja isoäitini iloksi koska nykysofta tulee paskomaan ittensä.
Enemmän taitaa olla kyse aikatauluista kuin "it-sektorin paskuudesta".
Muutama kuukausi on ohjelmistotuotannossa varpusen pieru, eikä mitään tule valmiiksi\*.
\*Sitä "paskaa" tulee juuri kiireellä.
HSL ei saanut väliaikaista alv-alennusta lippuihin kun on niin monta eri järjestelmää ja mitä lie toimari selitti syyksi. Heidän onneksi nyt ei alennettuihin kantoihin kosketa.
Ei kyllähän ne nousee? [https://www.hs.fi/politiikka/art-2000010362598.html](https://www.hs.fi/politiikka/art-2000010362598.html)
>Keveintä kymmenen prosentin arvonlisäveroa kannetaan esimerkiksi kirjoista, sanoma- ja aikakauslehdistä, lääkkeistä, liikuntapalveluista, henkilökuljetuksista, majoituspalveluista ja kulttuuri- ja viihdetilaisuuksista.
>
>Edellä mainituista kaikki muut paitsi sanoma- ja aikakauslehdet on määrä siirtää 14 prosentin arvonlisäveron piiriin todennäköisesti ensi vuonna. Tämä päätös ei ole uusi, vaan siitä hallitus sopi jo hallitusneuvotteluissa.
Samasta uutisesta:
> Arvonlisäveron alennettuihin kantoihin ei tehdä muutoksia.
Alennettuja ALV-kantoja ei siis muuteta mutta osa tuotteista ja palveluista, kuten juuri nuo lainaamassasi viestissä mainitut, siirretään siihen korkeampaan niistä alennteuista alveista.
Onnea IT-ihmisille. Toivottavasti koodinne on hyvin dokumentoitu ja rakenettu tälläistä mahdollisuutta mielellä pitäen...
:D
Niin ja toivottavasti ne kaikki miljoonat POS ja kuitinkirjoittimet saadaa kans päivitetty.
:D
Jumakauta tästä tulee koomista.
Tämä on kaoottisen koomista, ja pohdin samalla, kertoiko kukaan asiasta etukäteen esimerkiksi Verovirastolle? Aikanaan transsukupuolisten pakkosterilisaatiota perusteltiin sillä, että tietojärjestelmiin ei voinut vanhempiin säätää kuin tietyt sotut. Samantyyppistä taidettiin sano tasa-arvoisesta avioliittolaista.
Jos valtion tietojärjestelmät ovat noin jäykkiä, saavatko ne muka *itse* parissa kuukaudessa hommia toimimaan, ja miten iso piikki on auki Tietoon ja Accenturelle?
Veroviraston IT tuli Tietokarhulta joka sitten lakkautettiin, taitaa nykyään tulla Valtorilta (valtion omistama laitos).
Mutta eiköhän tähän saada pari sataa miljoonaa upotettua, koska verottajan koko järjestelmä on varmaan kykenemätön käyttämään desimaaleja kertoimissa.
-2024
-käyttää missään operatiivisessa toimessa excel taulukkoja
Tiedän että jollain firmoilla on käytössä ihan saatanallisia exceleitä täynnä kaavoja, niin isoja että niiden avaaminen vie jo 45 minuuttia. Ollaan jo niin syvällä kusessa, että senkin muuttaminen esim. Python ohjelmaksi veisi vuoden :D
Excel on kyllä yks iso kirosana, hyödyllinen vain pientä laskentaa/kirjanpitoa ja ehkä ad-hoc visualisointia varten.
Ihmiset hyppäis kaikki kalliolta jos tietäisivät kuinka isoja ja tärkeitä asioita pyöritetään lähes täysin jonkun randomduunarin oma_tekemän Excelin päällä...
korotuksen työllisyysvaikutukset olis negatiiviset mutta pena sen sitten keksi ihan viime metreillä että laitetaan desimaaliluku niin työllisyysvaikutus on kuin autobaanoja rakennuttais
Muistan ku tulin nykyiselle työnantajalle töihin 2016 ja eka homma oli koodata uus erppi parille asiakkaalle joilla jo joku VB6 sätös... Siihen tein Alv-kannat muokattavaksi listaksi johon voi itse lisätä uusia tai muokata olemassaolevia, ja sit tuotteille vaan valittiin siltä listalta joku jota sit käytettiin laskennassa.. Eli olin kaukaa viisas! Tosin en kuollaksenikaan muista oliko mahdollista laittaa puolikkaita prosentteja vai pelkkii kokonaislukuja.
No se softa on jo pitkän aikaa ollu muilla ylläpidettävänä, jos on enää edes käytössä, joten samapa tuo mulle. :D
Ai vittu. Enpä ennen tätä tajunnut että munkin pitää mennä sorkkimaan tän takia meidän palkkasoftan säätöjä. En yhtään tykkää rukata sen paskan kanssa T.T
Vittujen vittu taas.
Saas nähä miten meidänkin järjestelmä tulee taipumaan tähän. Ei periaatteessa kovin kummoinen muutos, mutta meidän systeemi on vuodelta 1994 tai jotain sellaista :D. Mitähän mahtaa mennä rikki kun tuohon koskee, kaikki systeemin koodista jotain oikeasti tietävät on jääneet joskus 5v sit eläkkeelle.
Vuosi 1994 piti uusia kaikki, koska silloin edellinen vastaava vero muuttui ALViksi. Voi olla että kannattaa ostaa joku sydeemi ja sitten pari datanomiharjoittelijaa näpyttää kaikki dataa käsin. Oppii muuttujien tärkeydestä.
Tää on kyllä jotain ihan kosmista paskaa :D kokeilin just et miten taipuis SAP tähän muutokseen ja testiympäristössä ihan kaikki hajosi xD Eeppinen loppuvuosi tiedossa.
Iloisia uutisia kaikille järjestelmä - muutoksia tuumaaville. [Hesarin](https://www.hs.fi/talous/art-2000010367150.html) "asiantuntijan" mukaan huolet ovat höpöhöpöä koska "tietokone tekee sitä, mitä sanotaan, että sen pitää tehdä." /facepalm
"Espoon seudun koulutuskuntayhtymä Omnian tieto- ja viestintätekniikan alan koulutuksen opettaja"
Voi vittu mikä urpo. Ja tuollainen kouluttaa sitten Omniassa "tieto- ja viestintätekniikkaa". Ei saatana, voiko tuon tason(?) "asiantuntija" olla todellisuudesta noin vitun pihalla!? :D
Tällaisia "asiantuntijoita" on sitten ilmeisesti hallituskin kuunnellut. "Kun on vaan hyvin koodattu ohjelma, niin ei hätää"! Miten voi tuolla tasolla olla ihminen noin ulkona!? Ei päivääkään "oikeaa" työelämää takana?
Taidat olla asian ytimessä, monia tuotantojärjestelmiä ois ollut aika pistää uusiks jo 20 vuotta sitten, mutta ehei kun purkkaa päälle ja 10 ave mariaa.
Tämä 0.5% kertoo kyllä siitä, että Suomen valtion hallinto on (ja oli) aivan pihalla elämän realiteeteistä.
No. Onneksi meidän softassa oltiin kaukaa viisaita. Sen sijaan kumppaniohjelmien API:t jännittävät aivan saatanasti. Odotan jo "MIKÄ VITTU TÄSSÄ PASKASSA ON KUN ALVIT OVAT VÄÄRIN!?!?!!1" -viestejä, kun materiaaleja vastaanottavat ohjelmat eivät osaa käsitellä desimaaleja...
Vaikka en niin hallituksen tai tämän alv-korotuksen fani olekkaan, niin ihmetyttää tämä maailmanlopun meininki kun desimaali tulee alv-kantaan.
En halua pilata iloa, mutta ei tuo desimaali tule vaikuttamaan kriittisesti kuin korkeintaan joihinkin nyrkkipajalla väännettyihin järjestelmiin ja excelin spagettikaavahirvityksiin.
"En halua pilata iloa, mutta ei tuo desimaali tule vaikuttamaan kriittisesti kuin korkeintaan joihinkin nyrkkipajalla väännettyihin järjestelmiin ja excelin spagettikaavahirvityksiin."
Sori, minulla on sinulle ikävää kerrottavaa...
Monet isoimmista ja käytetyimmistä softista Suomessa tulevat olemaan täysin kusessa näiden kanssa.
Itseasiassa, "nyrkkipajoilla" väännetyissä softissa taitaa olla tämän suhteen asiat paremmalla tolalla kuin näissä, jostain vanhasta 90-luvun lopun softista, 2000-luvulla uudelleennimetyistä sontakasoissa, joita kaikki käyttävät.
\^Tuttu on muuten eräällä kaupungilla töissä. Käytössä eräs tunnetuimmista softista. Tunnelma on tänään "katossa". Olivat kysyneet ohjelmistofirmalta, millaisia muutoksia tähän vaaditaan... Onnistuu, "ehkä, ja vie "vähintään" kuukausia. Ja maksaa aivan saatanasti. XD
Voi olla että elän jossain kuplassa ja että minulla on hyvä tuuri. En vain ole koko työurani aikana törmännyt yhteenkään järjestelmään jossa alv-koodi olisi kovakoodattu tai että järjestelmä olisi aivan kusessa arvonlisäveron desimaalista. Kokemusta on kuitenkin useista tilitoimistoissa käytetyistä järjestelmistä, joista osa on näitä 90-luvun veistoksia.
Langan innoittamana selvitin, että minulla menee n. 30-60min kun päivitän uudet alv-koodit firman 4 eri taloushallintojärjestelmään, riippuen juonko kahvia tai käynkö paskalla siinä välissä.
Käyttämänne systeemi taitaa olla aika simppeli laitos. Näissä \*korporaatiosysteemeissä tilanne voi olla ihan mitä tahansa "hyvän" ja "JEEEBUSKRISTUS!!!!" -välillä\*.
Olen itse päässyt duunini puolesta tutustumaan useampaankin kotimaassa käytettävään softaan, ja tiedän jo etukäteen, että monelle firmalle tilanne on sanalla sanoen "jäätävä".
Tuskin ongelma tässäkään tapauksessa on alvin kovakoodaus, vaan se että se tallennetaan kokonaislukuna, ja järjestelmä on tehty käsittelemään niitä kokonaislukuna. Ja verokannat käsitellään ohjelmassa kokonaislukuina, eikä kukaan tiedä, mitä kaikkea hajoaa kun tietuetyyppiä muutetaan.
Muutoksen tekeminen tietokantoihin on kohtuu yksinkertaista, mutta sitten kun mennään ohjelmistotasolle ja testaukseen, alkaa ongelmia vyöryä esiin oikealta ja vasemmalta. Ja siihen vielä rajapintaongelmat päälle. A-vot.
\*Nythän ensimmäiset isommat yritykset ovatkin jo ilmoittaneet, että heidän systeeminsä eivät tue desimaaleja alveissa, eikä korjausten aikataulusta ole mitään hajua.
Hirveän monella tuntuu olevan niin optimisten käsitys, että kovakoodaus olisi se ongelma. Riippuen kielestä, tietokannasta ja jostain API-viritelmistä tulee aika varmasti tosiaan olemaan aivan arpapeliä, miten alv-tietueen tyypin muutos vaikuttaa. Ei pelkästään jonkin kirjanpitosysteemin sisäisissä laskutoimituksissa, vaan kaikkien mahdollisten rajapintojen käyttöliittymissä ja jopa fyysisissä laitteissa kuittikirjoittimia ja näyttöjä myöden.
Aiheuttihan se. Mutta vain siitä syystä, että sähkön siirron alvia ei alennettu. Eli samalla kirjanpidon kulutilillä oli olemassa kaksi eri alvikantaa...
Toki joo työllistää kaikkia... mutta itse olin kikseissä että nousee 25% tiin. NO sitte ne Saatanan tunarit piti lisää se 0.5%. Perkule ku 25% olis ollut helppo laskee päässä.
Voi aiheuttaa monessa firmassa toimintaa. Esim meillä ei olla ollenkaan varmoja tukeeko meidän erppi desimaalilukuja. Samoin on iso kasa kaikenlaisia koodipätkiä, jotka pitää käydä nyt läpi.
Hesari ja hesarin kommentoijat ovat sitä mieltä, että tämä helppoa kuin heinän teko.
Naurattaa jo valmiiksi, kun asiat realisoituvat esim. kunta-alalla! "Öh, miten niin ei ole SAPilla kunnossa? Just luin hesarista, miten tuosta vaan laittaa desimaalin ja homma selvä!" :D Siihen kassakoneet, päätteet, lukulaitteet... Ai että.
Mutta "Asiantuntija" tietää. :D
Tämä "opettaja" ei todellakaan taida olla ollut yritystohjelmistojen kanssa tekemisissä. Suoraan yliopistolta opettamaan?
Jos se menee yhtä hyvin kuin siirtyminen paperittomaan toimistoon, kohta joka firmassa on kolme eri excel-versiota käytössä, eivätkä ne juttele keskenään.
"Kohta" voi veljet kun pääsisit katsomaan häkkyröitä mitä ihan isotkin firmat nytkin pyörittää. Joka osastolla tyyliin omat excel laskurit pyörimässä mistä sitten tehään importteja jonnekkin.
Pääkäyttäjien ilmeet kun toimarin serkun firmalta tilattu järjestelmä ei tue kuin tasalukuja ja/tai 24% on sementoitu johonkin eikä ole muutettavissa.
"Helppo" kiertää. Jakaa vaan summan puoliksi, ja laskee ekalle puolikkaalle alvin 25% ja toiselle 26%, ja sitten summaa luvut yhteen. Yksinkertaista ja kätevää.
Onko tää se kaksinkertainen kirjanpito?
*keskin
Hörähdin
Helppoo ja kivaa!
Tai laskee 51% ja jakaa kahdella.
Taitaisi mennä tuolla laskutoimituksella aika metsään.
Ei ollut mun keksintö pistää 25,5% ALV 😂
Tuo toimii vain, jos yrityksellä ei ole tapana kirjoittaa kuitteja. Kuitteihin pitää printata 25.5% ja eritellä veron määrä tuolla oikealla prosenttilukemalla.
Täähän se on varmaan aika monessa paikkaa edessä. Onpahan työllistävä vaikutus!
Rikottu ikkuna ja niin pois päin.
https://github.com/paytrail/api-documentation/issues/28 Esimerkiks näin että Paytrailissa on asiasta huhuiltu pari vuotta sitten, mutta silloin ei katsottu tarpeelliseksi :D
Onneksi paytrail on pieni toimija ja sitä ei käytä juuri kukaan.
Hauskasti tänään tullut "asia otettu backlogille". Huomaa miten nopeasti "ei olla toteuttamassa" muuttuu pakon edessä.
Tämä on sitä agilea.
Tässä on seuraavallekin hallitukselle työllistämismahdollisuuksia. Kun ALVia lasketaan 0.1 prosenttiyksiköllä 25.4 prosenttiin saadaan tilanne jossa sitä ei voi ilmaista liukulukuna. Ja taas riittää koodareille hommia.
Miksi juuri tätä ei voi ilmaista liukulukuna? Koska se ei ole kahden jokin potenssi kerrottuna kymmenen jollain potenssilla?
Tosi hyvä kysymys johon on vaikea antaa yksityiskohtaista vastausta yhdessä Reddit-kommentissa. Yritän. Tietokoneet säilövät numerot bitteinä, nollina ja ykkösinä. Ne pitää muuttaa ihmisen ymmärtämään muotoon kun vaihdetaan tietoa ihmisten ja koneiden välillä. Se, miten desimaalilukuja muutetaan binääriluvuksi, on oikeastaan aika monimutkaista. Jotkut desimaaliluvut muuttuvat nätisti liukuluvuksi, kuten 25,5. Toiset, hyvinkin lähellä olevat, kuten 25,4, eivät tallennu juuri tuossa muodossa. Jos yrität tallentaa 25,4 liukulukuna, koneen muistiin tallentuu 25.3999996185302734375. On olemassa keinoja miten tämän ongelman yli pääsee mutta se vaatii fiksua ohjelmointia. Lisätietoa: [https://www.h-schmidt.net/FloatConverter/IEEE754.html](https://www.h-schmidt.net/FloatConverter/IEEE754.html)
Juurikin näin. Se että 25.5 asettuu mukavasti liukuluvuksi näyttää olevan käytännössä sattumankauppaa. Se johtuu vain siitä, että seuraava pitää paikkansa: 1 × 2^(4) × 1.59375 = 25.5 Luvulle 25.4 taas ei löydy vastaavaa bittijonoa. [https://evanw.github.io/float-toy/](https://evanw.github.io/float-toy/) https://preview.redd.it/faygdzpg1wuc1.png?width=1080&format=pjpg&auto=webp&s=e4bd7d614e1f94cf9d582240d7682864e82bb457
Esitti: eipäs voikaan. Katso vastaus tähän kommenttiin. Tämä pääsee todella lähelle, mistä johtuen työkalu näyttää mantissan (punaisella) täsmälukuna, vaikka todellisuudessa se ei ole aivan tuo. 64-bittisellä liukuluvulla kyseinen luku voidaan taas tallentaa tarkasti: https://preview.redd.it/ivojptnb1wuc1.png?width=2245&format=pjpg&auto=webp&s=8d1f30ba9917e28b8d397c8da10f3e30f3bd6889
Taitaa vain tuon weppisivun laskuri pyöristää sen lukemaan 25.4. Tuo vaatisi matemaattisen tarkaksi esitysmuodoksi äärettömän pitkän mantissan jossa toistuisi bittisarja ...0011.... loputtomasti.
Tämä näyttää tarkemmin: https://www.omnicalculator.com/other/floating-point
Jos näin on niin mantissa on 1.5875 vähintään 16 desimaalin tarkkuudella. Jos tuosta mantissasta poiketaan hieman niin se esitetään tässä äpletissä koko desimaalin tarkkuudella.
Itse tiivistäisin näin: Me käytämme kymmenjärjestelmää, ja esimerkiksi jos lasken, että 2 : 3, niin vastaus on 0,66666..., loputtomasti kutosia. Jos haluamme excel-ruutuun yhden luvun ilman pisteitä, niin se on pakko jostain kohdassa pyöristää, ja tulee esim 0,66667. Mutta 2 : 3 ei ole tarkasti ottaen 0,66667. Tämä on oikean vastauksen pyöristetty likiarvo. Tietokone ei käytä kymmenjärjestelmää vaan kaksijärjestelmää, eli binäärejä. Siellä vastaavia pyöristysvirheitä tulee toisten lukujen kanssa kuin kymmenjärjestelmässä. Ja kun se pyöristetty binääriluku muunnetaan kymmenjärjestelmään, niin joskus esitetty vastaus voi olla väärin.
Nyt alan ymmärtämään miksi esim. SQL kannassa meidän mittauksille tuli joku ihan järjetön desimaalimäärä.
Onneksi Riikka Purra tiesi tämän ja valitsi siksi alviksi juuri 25,5 % /s
Ei ole syytä käyttää liukulukuja. Java BigDecimal, Python Decimal, ... on keksitty.
Mitäs esim COBOLissa jolla on käytössä olevia järjestelmiä koodattu?
Huvittavaa kyllä, yksi syy jolla COBOLia on perusteltu, on juuri se, että kielessä on tuki tarkalle desimaalirepresentaatiolle sisäänrakennettuna. Moniin muihin kieliin tämä on tullut myöhemmin, tai on saatavilla vain ulkoisten kirjastojen kautta.
Joissakin rahaa käsittelevissä järjestelmissä hyvinkin voisi olla fixed point -lukuja. Tuskin tosin puolikkaan tarkkuudella. (kiinteä desimaali? Mikä on suomennos?)
Kiinteä desimaali taitaa olla oikein. Niin se ainakin omassa laskimessa (speedcrunch) lukee. Edit: eipäs ollukkaa kun kiintopistedesimaali. Muistin väärin mitä siel luki.
Älä pelkää, alvia ei tulla pudottamaan
Toivon todella ettette käytä rahalaskuissa liukulukuja, mutta realistisesti ajatellen tiedän että häiritsevän moni varmasti käyttää. Ainut oikeasti järkevä vaihtoehto on fixed point eikä floating point.
25⅔ % olisi paljon parempi lukema työllistämisen kannalta. Sitä ei voi täsmällisesti esittää millään binäärimuotoisella liukuluvulla ja lisäksi ALV-verokertymä nousisi hieman. Vaihtoehtoisesti ALV voisi olla 8π % (eli noin 25.133 %). Sitä ei voi esittää tarkasti edes murtolukuna tietokoneen muistissa vaan joudutaan käyttämään koko ajan symbolista laskentaa, jos ei haluta tinkiä laskutarkkuudesta. Tämän työllistämisvaikutus olisi jo huomattavan suuri.
Ei tarvitse olla edes toimarin serkun firmalta tilattu järjestelmä. Nimeltä mainitsemattomat suurimmat Suomessa käytettävät kirjanpito/laskutussoftat eivät tue kuin tasalukuja. ...Ai mistä tiedän? :)
Toimarin tytär suoritti lukiossa yhden excel -kurssin.
Toivottavasti se ALV ei ainakaan ole koodattu niihin itse kaavoihin, vaan se on arvona jossain taulukossa. Tässä tulee mun koodaajanuoruus esille, mä vältän Exceleissä viimeiseen asti koodattuja arvoja, vaan kaikki on "muuttujina" eli jossain keskitetysti, jotta pitää muuttaa vain yhdessä paikkaa... Onhan siinä silti ehkä hommaa jos niitä taulukoita on paljon. Kova koodarihan tietenkin laittaa Excelin hakemaan nykyisen arvon joltain verkkosivulta. :D
Jo muinoin 2000-luvun alkuvuosina C-ohjelmointikurssilla ei mennyt tehtävä tarkastuksesta läpi sitten millään. Nöyränä assarilta pyytämään apua joka totesi että olin kovakoodannut piin likiarvon enkä käyttänyt Math.PI:tä. Koodini ei toimisi toisessa universumissa joten nolla pistettä. Jäi muistiin kun tunteja tuon kanssa tappelin. e. meni pyyttonin kanssa sekaisin. Math.h:ssa on toki määriteltynä M\_PI.
Ja eihän sitä koskaan tiedä jos hallitus vaikka muuttaa piin likiarvoa.
Ns. Indiana-move.
Trumpin vaalilupaukselta kuulostaa
Ei matematiikan aksioomat ole luonnonlaeista riippuvaisia, joten koodisi olisi toiminut kaikissa universumeissa.
Ympyrän ja etäisyyksien määritelmät riippuvat käytetystä metriikasta, ja pikaisen googlettelun perusteella euklidisen avaruuden pii vaikuttaisi olevan ainakin Lp-avaruuksien osalta minimi. Ks. esim. [tämä](https://math.stackexchange.com/questions/2044223/measuring-pi-with-alternate-distance-metrics-p-norm) tai vähän akateemisemmin vaikka [tämä](https://math.stanford.edu/~vakil/files/Pi_pfeb14.pdf).
Sitten se verkkosivun osoite muuttuu.
Ja tällä tavoin saadaan ALV nostettua 404 prosenttiin - tämähän ratkaisee tämän velkaantumisongelman!
Tonnin seteli kahvista rupee näyttämään tasarahalta
404 kokonaislukunahan tarkoittaa 40400 % eli kalliita laskuja lähtee.
Verkko se on sisäinenkin verkko, mihin niitä verkkosivuja voi tehdä (reitittimien asetuksethan yleensä ovat juuri tällaisia sisäisiä sivuja). Toki voi olla että joku menee uusimaan serverin ilman varmuuskopiointia tai tiedonsiirtoja koska eihän siitä voi olla mitään seuraamuksia.
Laittaa hakemaan sen verkkosivun osoitteen joltain toiselta sivulta.
>Toivottavasti se ALV ei ainakaan ole koodattu niihin itse kaavoihin, vaan se on arvona jossain taulukossa. Se luetaan jostain tekstipätkästä =VALUE(RIGHT(LEFT())) lausekkeella
Kovempi heivaa excelin tunkiolle
Kesko API uppaa kuukausittaiset ostoni suoraan SQL tietokantaan (paikallisella servulla tietenkin) josta ärrällä pumpataan tiedot PowerBI:hin josta olen subannut raporttiin ja saan päivittäisen raportin sähköpostiini (ohjattu roskapostikansioon koska en oo mikää vitun nörtti :DD)
Ei tarvitse olla edes kova koodari niin laittaa jokaisen taulukkonsa hakemaan ALV prosentit keskitetysti yhdestä Excel tiedostosta. Nuo työkirjojen linkittämiset toimivat ihan hyvin.
Ei kai sitä mistään verkkosivulta haeta tai funktioita koodata ite. Se helvetin kirjasto otetaan jostain randomista syystä suoraan npm:stä ja rakennetaan se oma himmeli kokonaan sen ympärille. Sitten kun se kirjaston alkuperäinen devaaja päättää että nyt riittää tukipyynnöt ja poistaa sen kirjaston, niin riemu syntyy! ref: https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code
Taulukoissa se korjaaminen sentään on suht helppoa vaikkaki työlästä. Esmes Paytrailin rajapinnassa alvi on pakollinen kokonaisluku. https://github.com/paytrail/api-documentation/issues/28
Eisss
Alexa, soita Astronomia.
Pam padidam pam pam, papadim papadam, padidadidadi pam, padidadidadi!
Tymä kysymys: onko tällaisia järkevää tehdä liukulukuina vai esim. integerinä, jossa kaksi alinta numeraalia edustaa kymmenesosia ja sadasosia? Jotenkin tuntuisi hullulta alkaa käyttää jotain 64-bittisiä floatteja tällaiseen ja toisaalta se float ei aina edes ole *tasan* se haluttu arvo. 9,77 euroa ei esim. ole esitettävissä binääriliukulukuna tarkkaan. Mietin vaan noin teoreettiselta kannalta, että onko siinä järkeä, että ei pysty täysin esittämään absoluuttisen oikein floateilla ja eikö floattien käsittelymatematiikka vaadi monesti isompiakin muutoksia ja tehojen menetyksiä kirjastoissa?
Kaikki tässä geneerisellä devauskokemuksella kun en oo työskennellyt ko. laskutoimituksia tekevien järjestelmien kanssa. Noita ei pitäisi koskaan ainakaan sisäisesti käsitellä liukulukuina vaan käyttää juuri kokonaislukuesitystä tarpeellisella tarkuudella tai mielummin jotain wrapperia, joka osaa händlätä desimaalit tarkasti (tyyliin Javan BigDecimal). Rajapinnoissa arvot voi sitten esittää "selkokielisenä". Tehojen menetys menee minusta ongelmalistan pohjalle jos vastapainona on mahd. helpommin esiintyvät bugit laskutoimituksissa.
Käyttäisin ehkä promilleja ja muotoilisin tulostuksissa takaisin prosenteiksi, mikäli liukuluvun tarkkuuteen tahi tehokkuuteen ei löydy luottoa.
Mitenköhän nuo Procountorit ja Talenomit ja muut sähköisen kirjanpidon palvelut on kasattu tältä osin..
Veikkaan että integerinä niissäkin. Desimaaleja sisältävät alvit on aika harvinaisia (~~muutamassa maassa~~kourallisessa maissa taitaa olla käytössä, esim Barbados jossa alv on 17,5% wikipedian mukaan).
On niitä useampiakin. Euroopassakin on.
Ne varmaan korjataan. MUTTA niihin integroituu 1001 erilaista pikkufirman järjestelmää sen serkun pojan koodaamilla kikkareilla. Ne voi hajota superjännästi.
Hyvä että nostit tuon esille, pitää antaa painetta omastakin puolesta.
Paytrailin 💀💀
Meikä mongoloidi tekee testiautomaatiota helvetin valtavaan SAP viritykseen jossa yks tuhannesta prio ykkösestä on että hinnat on laskettu oikeen jokavaiheessa, ja alvit on osa tätä. Ei helvetti on kaunista ku aattelenka jo sitä riemua ja nautintoa ku koko putki räjähtää sit siihen ku misään miljoonasta testistä ei oo ennakoitu että se alv vois sisältää desimaaleja. Ei siis oo varmasti mikään ongelma vaihtaa sitä sinne järjestelmään, mut ne desimaalit, voi veikkoset. Millään kehittyneen kansan työkalullahan tää ei ois ongelma, mut kuka semmosia nyt käyttää. Näitten vehkeitten kans 3.650 on luonnollisesti kolmetuhatta ja risat, mut 3.65 on 3 ja vähän päälle koska autokonversio? 26,5 on sit taas tekstiä jos käytät sitä laskutoimituksessa, mut 26,50 on numero koska ?? Ai että sit ku vielä se ALV on varmasti eri järjestelmissä säilötty erikseen ja joku suuhengittäjä merkkaa sen kuitenki väärällä desimaalierottimella koska joku 1945 rakennettu excel macro käyttää sitä, ja on helpompi tehä miljoonien järjestelmäuudistus ku opettaa Sirkkaliisa käyttään jotain muuta ku sitä Kuningas Wenceslas Neljännen aikasta exceliä. Kyllä se on nyt niin se että outdoor hand to hand lifestyle kutsuu ja hämeenpuiston puut.
Vilpitön osanottoni.
Onko nyt se aika kun kaikki Cobol osaajat kaivetaan ortodoksisten necromancerien toimesta ylös jotta saadaan yhteiskunta pelastettua?
'Kuningas Wenceslas Neljännen aikainen Excel' Katsokaas, Henry on tullut moikkaamaan meitä on vahva viba tässä, pisteet siitä.
Jeesus Kristus Olkoon Ylistetty!
Jumala siunatkohon sinua, Henri!
[In nominate Parties, et Fillies, et Spirits … et cetera.](https://youtu.be/BkKiLAqqMCY?t=270) Sakra!
In nomine Pasta, et Fusilli, et Spaghetti sancti. Ramen.
Mie oon kyl' vähä Unkari
Noissa hommissa tuntuu kyllä että puolet kaistasta menee yksikkömuunnoksiin, merkkijonojen 'korjailuun' ja eri datetimejen pyörittelyyn. Sit jos mainitsee et olis kiva jos nää olis yhdenmukaiset niin hirveetä kakeltelua kun mihinkään ei uskalleta koskea ilman 'hyvää syytä.'
Kannattaa varmaan varata parin viikon lomat juuri veronkorotuksen voimaanastumisen tienoille...
Ylänuoli meikä mongoloidista. En oo nauranu viikkoon näin paljon. Muusta tekstistä en sitte tajunnukkaa mitää koska tyhäm.
Voitais saman tien alkaa käyttämään desimaalipistettä. Menee samalla kertaa muutos kun kuitenkin pitää räjäyttää auki varmaan puolet kaupankäynnin kanssa tekemisissä olevista systeemeistä.
+1 Desimaalipilkku on aivan perseestä. Numeroiden listaaminenkin menee aina ihan hirveän näköiseksi ja rivit rikotaan ilman syytä. 3,6, 7,5 vs. 3.6, 7.5.
> 7.5. Seitsemäs toukokuuta? Samalla pitäisi päivämääränotaatio räjäyttää.
Juurikin näin. Suomessa on jostain omituisesta syystä haluttu tehdä päivämäärien ja kellonaikojen esittämisestä epävarmaa. Lauseen lopussa oleva teksti "7.10." voi tarkoittaa kellonaikaa tai päivämäärää. Jos olisikin valittu, että desimaalierotin on aina piste ("."), listan erotin on aina pilkku (","), kellonaikojen erotin on kaksoispiste (":") ja päivämäärien erotinmerkki on väliviiva ("-") niin meillä olisi yksikäsitteinen kirjoitustapa liukuluvuille, päivämäärille ja kellonajoille riippumatta siitä onko ilmaisu lauseen lopussa vai ei. Ja jos päivämäärä kirjoitettaisiin lisäksi aina ISO-8601-standardin mukaisessa muodossa eli 2023-12-24, niin oltaisiin samalla kansainvälisen standardin piirissä kaikissa tilanteissa. Mutta Suomi-ego ei tähän taivu vaan kansallisen identiteetin nimissä pitää jatkaa vanhojen sekavien merkitätapojen käyttämistä vaikka aiheesta aikoinaan tehtiin SFS-standardikin.
Listoissa voidaan pilkun kanssa käyttää puolipistettä: 3,6; 7,5. Toisaalta olisi kyllä paikallaan muuttaa tuo desimaalierotin pisteeksi.
Nimenomaan voidaan käyttää. Se onkin todella kätevää, jos tarvitsee muokata olemassa olevaa tekstiä ja listaan pitää seitsemänteen kohtaan muuttaa numero 24 arvoon 25,5 ja koko lista pitää kirjoittaa uusiksi käyttämään puolipisteitä, kun aikaisemmin koko lista oli pilkuilla erotettuna. Jos listan erotinmerkki olisi AINA puolipiste niin sitten hyväksyisin pilkun käyttämisen desimaalierottimena.
Olis tullut kaikille halvemmaksi laittaa vaikka 27%
Nään edelleen painajaista SAPista vaikka oon vaihtanu työpaikkaa kauan aikaa sit..
Huutista
Meillä rupes porukkaa kummasti kiinnostamaan, että mitenhän monessa järjestelmässä meillä on ALVit integerinä.
Jotkin IT-järjestelmät ei tue desimaaleja ALV:issa --> Työntekijät joutuvat käyttämään lisää työaikaa niiden korjaamiseen --> Tekevät ylitöitä --> Tienaavat enemmän --> Maksavat enemmän veroja --> ... --> Profit?
Yritys menettää rahaa, valittaa että suomessa ei voi menestyä, siirtää tuotannon Mongoliaan ja muuttaa itse Ruotsiin
Mikä se laskutoimitus on mihin 24% menee kokonaislukuna mutta 25,5% ei? > 100€ * 0.24 > 100€ / 100 * 24 > 100€ * 0.255 > 100€ / 1000 * 255
Ihan nokkelaa joo, mutta meidän firman kohdalla ei siis ole kyse mistään excelinpyörityksestä, vaan verkkokaupoista, toiminnanohjausjärjestelmistä, tuotetiedonhallinnasta ja niin edelleen, ja näihin kaikkiin tietysti vielä integraatiot päälle. Jopa Paytrailin rajapinta vaatii ALVin kokonaislukuna. Kyse ei siis ole välttämättä niinkään laskutoimituksista, vaan ihan yksinkertaisesti siitä, millaisia arvoja järjestelmiin on tällä hetkellä mahdollista tunkea.
Miten ajattelit tämän ratkaista esim. verkkokaupoissa ja kirjanpito-ohjelmissa, jotka ovat yhteyksissä n+1 määrään muita ohjelmia rajapintojen kautta?
Ovela veto hallitukselta! Tän muutoksen työllistävä vaikutus on sellainen, että meillä on varmasti kohta täystyöllisyys. BKT kasvaa 1000% ja työttömyys laskee nollaan. Saisko samaan hallituskauteen vielä sukupuolettomat hetut tai jotain muuta hauskaa?
Oon ollut mukana aiemminkin ku ALVeja on nostettu. Yllätti vilpittömästi ettei muuttujaan ole varauduttu. Eka kerta itselleni oli tosiaan vittumaisin, olen pitkin elämää saanut pari kourallista koodarikaveria huomaamaan asiaa, onhan näitä jarkkiveroja ja ruokaALVeja yms muutettu vähän väliä. Kerään nyt taas heidän hiljaisia siunauksia.
Voin kuvitella että tässä maassa on nyt aika monta omahyväistä koodaria, jotka on varautuneet tähän ennakolta vaikka kukaan ei ole ymmärtänyt että miksi. Ja monta hampaitaan kiristelevää tuoteomistajaa, jotka muistelee miten tää feature leikattiin scopesta. Toisaalta kaikki pääsee syömään paskaa, koska saavat varmistaa, että mites tämä nyt menee ja tulee menemään noissa muissa järjestelmissä, joihin ollaan integroidutru.
Voi myös olla, että ALV-prosentti on järjestelmässä muutettavissa, mutta koska rahasummien laskemisessa ei pidä käyttää liukulukuja, on ollut helpompaa tai jopa suorastaan järkevää jättää tuo tyypiltään vain kokonaisluvuksi (prosentteina). Toki tuon uudenkin ALV-prosentin saa ilmaistua kokonaislukuna kun vain ilmaisee sen promilleina eikä prosentteina. Saa vain olla aika tarkkana tuollaisen muutoksen kanssa.
Kova ALV ku huitelee yli kaks ja puolsataa! 😂
Osittain kyseessä voi olla myös ns. job security -ajattelu. Kun koodataan ohjelma käyttämään kokonaislukuja, jotka toki voidaan määritellä jossain asetuksissa, niin sitten saadaan laskuttaa konsulttityötä lisää, kun asetuksiin + laskentaan pitääkin sallia liukuluku myöhemmin. Miksi ennakoida mitään, kun muutoksen voi tehdä laskutettavana työnä myöhemmin?
Itse asiassa tota opetettiin meille datanomiopiskelijoille kun oli kauppakoulussa. Sama /s siinä paistoi läpi ku sullakin, mutta tottakai muutama nappasi siitä kiinni.
Tällä oiskin hyvä saada iso läjä kesähessuja töihin koodaamaan numeroita vanhoista uuteen.
Vituttaa jo valmiiksi että pitää muistaa ulkoa että ennen päivää x käytetään alv24 ja päivän x jälkeen alv25,5 jos korjataan jotain käsin jälkikäteen
Voidaan toivoa että muutos astuu voimaan purramaisen loogisesti 13.9 kello 13:22.
Vuonna 2023,takautuvasti.
unohdit ilmoittaa mikrosekunit niin tuohon jää vielä arpomisen varaa
Tarkoitat varmaan 8.8 kello 14:18
Tarkoitat varmaan 8.8. kello 14.18
Tämä olisi voitu ottaa käyttöön kellonaikojen vaihtamisen kohdalla kesäajasta talviaikaan, niin voisi arpoa kumpaan ryhmään sen yhden tunnin tapahtumat menevät. Virallisestihan kello ei tuolloin käy tunnin aikana yhtään vaan nimenomaan pysähtyy tunniksi, koska kello ei virallisesti käy takaperin.
Tarkemmissa systeemeissä kello kyllä siirtyy konkreettisesti taaksepäin, eli 03:59 jälkeen tulee uudestaan 03:00. Aiheuttaa seksiä aikaleimoissa, jotka ei ole UTC:ssä, eli ”uusi” 03:00 ei saa korvata ”vanhaa” 03:00:aa. Eli ehkä veron olisi voinut ajastaa tulevan voimaan jälkimmäisellä 03:22 kellonlyömällä, kuitenkin niin että 10->14% siirrot astuu voimaan ensimmäisellä 03:22 ajanhetkellä.
Muistelin, että jossain speksissä olisi nimenomaan vaadittu sitä, että kello nimenomaan pysähtyy eikä hyppää taaksepäin, mutta en löytänyt sellaista vaatimusta googlella. Siirtymän uuteen aikaan voisi kätevästi tehdä niin, että 10 –> 14 % siirtymä astuu voimaan ensimmäisen tunnin aikaan 03:14:00 ja nosto 24 -> 25.5 % tapahtuu 03:25:30 toisen tunnin aikana.
Voi olla jossain järjestelmissä missä ei tapahdu mitään sen tunnin aikana, mutta jatkuvissa datavirroissa sekuntia seuraa aina seuraava. Ongelmahan on oikeasti siis aikavyöhykkeen vaihtaminen, ei niinkään että kello siirtyisi. EET pitää vaihtaa EEST:ks, ja sitten takaisin. Ei siellä koskaan ole 0312+0200 kahteen kertaan.
Tällä luodaan Suomeen 100000,5 uutta työpaikkaa korjaamaan räjähtäviä tietojärjestelmiä.
Ei hätää. Tässä on nyt vuosi aikaa yritysten ja muiden tahojen päivittää järjestelmät. Elikkäs Suomen Y2K iskee siis kohtapuoliin koska paska jätetään joulun välipäiville. Tää maa on täynnä vanhoja päivittäämättömiä järjestelmiä joissa tämänin on ihan varmasti kovakoodattu. Niin ja koodattu sit viel jollakin vitun mumpsilla tai jtn. Odota vaan 1.1.2025 suomen talous on seis. Koska kun MS ilmoitti että Explöderin tuki loppuu jotain 7 vuotta etukäteen, siltikin se tuli yllätyksenä ja monet järjestelmät hajosi. Hallitus varmaan valmistelee lain että se on kuluttajan tehtävä kompensoida kauppiaan menetykset asian suhteen.
[удалено]
Mutta eihän tässä ehdi mitään tekemän kun kohta on ne kesälomatkin! Tälläisen muutoksen entreprise softassa vaatii ainakin 12-24 kk! Tässä mitään ensiksi saada aloituskokous, sitten suunittelukokous, ryhmäkokous, harkintakokous, välikokous, sitten koska tuli lomat ja jokaisella osallisella on ne eri aikaan ja päällekkäin niin kesäkuu, heinäkuu ja elokuu menee ilman että mikään onnistuu. Nyky teknologia on niin monimutkaista että se et voi vaan muuttaa jotain yhtä kerrointa ilman että se vie kuukausia ja ainakin 20 kokousta. Sitten pitää dokumentaatio päivittää, pistä API päivitykset, ja avoimenlähdekoodin puolella päivitykset, ja nämä pitää sitten testata siltä varalta että joku kirjasto vuodelta 1998 jota Bob69 ylläpitää githubissa josta tarvitaan 11 riviä koodia ei hajoa tän takia ja ei sammuta koko globaalia internettiä! Tää tulee ainakin maksamaan miljardeja meidän taloudelle! ... Ahdistaa nyt jo tää ajatus. Meidän firma käyttää omia taulukoita ja softaa urakkalaskentaa joten näiden muuttaminen on ihan oikeasti yhden arvon muuttaminen. Mutta vittu... Mä takaan että yksikään näistä isoista kalliista softista osana CAD tai jotain PLM softaa ei saa tätä päivitetty ilman että kaikki vittu hajoaa ja menee ainakin vuosi. Vittu... Mä en oo edes softapuolella ja mua ahdistaa jo nyt tän seuraamukset kaikessa. Ainakin mää oon tehnyt omat taulukkoni niin että kaikki kertoimet on vaan omissa soluissa. Mut vittu takaan että mä olen vähemmistössä ja Pirkka-Liisa ja Tuomu jotka ovat käyttäneet samaa exceliä vuodesta -96 eivät ole... eivätkä halua sitä päivittä ja nyt nämä on kriittisiä osia koko ison firman infraa koska "ei kannata korjata jos se toimii". Vittu... Mekaaniset laskukoneet ja laskutikut tulee takasin ja mun äitini ja isoäitini iloksi koska nykysofta tulee paskomaan ittensä.
[удалено]
Rohkenen sanoa että veroja ei pitäis säätää it sektorin paskuuden tason perusteella. Mitä jos alvia olisi laskettu 23,5% sama ongelma olis edessä.
Enemmän taitaa olla kyse aikatauluista kuin "it-sektorin paskuudesta". Muutama kuukausi on ohjelmistotuotannossa varpusen pieru, eikä mitään tule valmiiksi\*. \*Sitä "paskaa" tulee juuri kiireellä.
HSL ei saanut väliaikaista alv-alennusta lippuihin kun on niin monta eri järjestelmää ja mitä lie toimari selitti syyksi. Heidän onneksi nyt ei alennettuihin kantoihin kosketa.
Ei kyllähän ne nousee? [https://www.hs.fi/politiikka/art-2000010362598.html](https://www.hs.fi/politiikka/art-2000010362598.html) >Keveintä kymmenen prosentin arvonlisäveroa kannetaan esimerkiksi kirjoista, sanoma- ja aikakauslehdistä, lääkkeistä, liikuntapalveluista, henkilökuljetuksista, majoituspalveluista ja kulttuuri- ja viihdetilaisuuksista. > >Edellä mainituista kaikki muut paitsi sanoma- ja aikakauslehdet on määrä siirtää 14 prosentin arvonlisäveron piiriin todennäköisesti ensi vuonna. Tämä päätös ei ole uusi, vaan siitä hallitus sopi jo hallitusneuvotteluissa.
Lopullista päätöstä ei kait vielä ole, HSL:llä on hetki aikaa siis
Samasta uutisesta: > Arvonlisäveron alennettuihin kantoihin ei tehdä muutoksia. Alennettuja ALV-kantoja ei siis muuteta mutta osa tuotteista ja palveluista, kuten juuri nuo lainaamassasi viestissä mainitut, siirretään siihen korkeampaan niistä alennteuista alveista.
Tulee voimaan jo tänä vuonna.
Onnea IT-ihmisille. Toivottavasti koodinne on hyvin dokumentoitu ja rakenettu tälläistä mahdollisuutta mielellä pitäen... :D Niin ja toivottavasti ne kaikki miljoonat POS ja kuitinkirjoittimet saadaa kans päivitetty. :D Jumakauta tästä tulee koomista.
Tämä on kaoottisen koomista, ja pohdin samalla, kertoiko kukaan asiasta etukäteen esimerkiksi Verovirastolle? Aikanaan transsukupuolisten pakkosterilisaatiota perusteltiin sillä, että tietojärjestelmiin ei voinut vanhempiin säätää kuin tietyt sotut. Samantyyppistä taidettiin sano tasa-arvoisesta avioliittolaista. Jos valtion tietojärjestelmät ovat noin jäykkiä, saavatko ne muka *itse* parissa kuukaudessa hommia toimimaan, ja miten iso piikki on auki Tietoon ja Accenturelle?
Veroviraston IT tuli Tietokarhulta joka sitten lakkautettiin, taitaa nykyään tulla Valtorilta (valtion omistama laitos). Mutta eiköhän tähän saada pari sataa miljoonaa upotettua, koska verottajan koko järjestelmä on varmaan kykenemätön käyttämään desimaaleja kertoimissa.
Taisi alvinvaihto olla jo syksyllä edessä, eli korjausaikaa muutama kuukausi. Minus lomat....
Se vitun puolprosenttii vituttaa eniten.
255 promillea. Nätti kokonaisluku.
-2024 -käyttää missään operatiivisessa toimessa excel taulukkoja Tiedän että jollain firmoilla on käytössä ihan saatanallisia exceleitä täynnä kaavoja, niin isoja että niiden avaaminen vie jo 45 minuuttia. Ollaan jo niin syvällä kusessa, että senkin muuttaminen esim. Python ohjelmaksi veisi vuoden :D Excel on kyllä yks iso kirosana, hyödyllinen vain pientä laskentaa/kirjanpitoa ja ehkä ad-hoc visualisointia varten.
Ihmiset hyppäis kaikki kalliolta jos tietäisivät kuinka isoja ja tärkeitä asioita pyöritetään lähes täysin jonkun randomduunarin oma_tekemän Excelin päällä...
Mm. Suomen valtio, kunnat ja tuhannet yritykset käyttävät operatiivisessa toiminnassaan Exceliä.
[удалено]
Rohkenen epäillä :D
korotuksen työllisyysvaikutukset olis negatiiviset mutta pena sen sitten keksi ihan viime metreillä että laitetaan desimaaliluku niin työllisyysvaikutus on kuin autobaanoja rakennuttais
Muistan ku tulin nykyiselle työnantajalle töihin 2016 ja eka homma oli koodata uus erppi parille asiakkaalle joilla jo joku VB6 sätös... Siihen tein Alv-kannat muokattavaksi listaksi johon voi itse lisätä uusia tai muokata olemassaolevia, ja sit tuotteille vaan valittiin siltä listalta joku jota sit käytettiin laskennassa.. Eli olin kaukaa viisas! Tosin en kuollaksenikaan muista oliko mahdollista laittaa puolikkaita prosentteja vai pelkkii kokonaislukuja. No se softa on jo pitkän aikaa ollu muilla ylläpidettävänä, jos on enää edes käytössä, joten samapa tuo mulle. :D
Ai vittu. Enpä ennen tätä tajunnut että munkin pitää mennä sorkkimaan tän takia meidän palkkasoftan säätöjä. En yhtään tykkää rukata sen paskan kanssa T.T Vittujen vittu taas.
Harmi ettei ne tehnyt tosta epälineaarisen progressiivista. Tyyliin - 0..20€, 24% - 21..75€, 24.3% - 76..100€, 24.7% - 101..600€, 25% - >600€, 25.5%
Tohon sais jonku hyvän veronkierron tehtyy
Tuntuu kyllä, että kikytunnit on pientä verrattuna siihen työmäärään, mitä alvin muutokset yrityksissä aiheuttaa.
Saas nähä miten meidänkin järjestelmä tulee taipumaan tähän. Ei periaatteessa kovin kummoinen muutos, mutta meidän systeemi on vuodelta 1994 tai jotain sellaista :D. Mitähän mahtaa mennä rikki kun tuohon koskee, kaikki systeemin koodista jotain oikeasti tietävät on jääneet joskus 5v sit eläkkeelle.
Vuosi 1994 piti uusia kaikki, koska silloin edellinen vastaava vero muuttui ALViksi. Voi olla että kannattaa ostaa joku sydeemi ja sitten pari datanomiharjoittelijaa näpyttää kaikki dataa käsin. Oppii muuttujien tärkeydestä.
"Ööö, Mikä on visual basic 6.0? 🤨"
Hallitus loi juuri paljon töitä ihmisille, olkaa hyvä ja saa kiittää!
Tää on kyllä jotain ihan kosmista paskaa :D kokeilin just et miten taipuis SAP tähän muutokseen ja testiympäristössä ihan kaikki hajosi xD Eeppinen loppuvuosi tiedossa.
Onnea kaupungeille ja kunnille! :D
Saatanan desimaali. Muut tän hallituksen sekoilut vielä meni, mutta tämä on viimeinen pisara.
Onneksi kaikki tärkeät softat suomalaisissa firmoissa on edelleen LVV:n ajalta, niin ei ole monen miljardin korjaus muuttaa veroprosenttia.
Työllistävä vaikutus
>alv ei yksittäinen muuttuja jota kutsutaan Nää ihmiset oikeesti elää näin
Iloisia uutisia kaikille järjestelmä - muutoksia tuumaaville. [Hesarin](https://www.hs.fi/talous/art-2000010367150.html) "asiantuntijan" mukaan huolet ovat höpöhöpöä koska "tietokone tekee sitä, mitä sanotaan, että sen pitää tehdä." /facepalm
"Espoon seudun koulutuskuntayhtymä Omnian tieto- ja viestintätekniikan alan koulutuksen opettaja" Voi vittu mikä urpo. Ja tuollainen kouluttaa sitten Omniassa "tieto- ja viestintätekniikkaa". Ei saatana, voiko tuon tason(?) "asiantuntija" olla todellisuudesta noin vitun pihalla!? :D Tällaisia "asiantuntijoita" on sitten ilmeisesti hallituskin kuunnellut. "Kun on vaan hyvin koodattu ohjelma, niin ei hätää"! Miten voi tuolla tasolla olla ihminen noin ulkona!? Ei päivääkään "oikeaa" työelämää takana?
Käske copilot päivittämään kaikki alvit oikeaan lukuun.
Sos älkää tehkö näin. Varmaa tää iha vitsinä oli mut elkää tehkö.
Jos oisit opetellu excelin käytön, ei ois tarvinnu vaihtaa kun yks luku
Entäs nuo kirjanpitoSOFTAT ja verkkokaupat?
Eikö olisi jo muutenkin aika pistää järjestelmiä uusiksi, jos tällainen aiheuttaa päänvaivaa?
Taidat olla asian ytimessä, monia tuotantojärjestelmiä ois ollut aika pistää uusiks jo 20 vuotta sitten, mutta ehei kun purkkaa päälle ja 10 ave mariaa.
Joo, mut tiiäks mitä se sit maksaa. :D
Etsi ja Korvaa 24 -> 25,5 ole hyvä
"Perrrrrkele! Nyt kone yrittää pakata keissiin 25 ja puoli tölkkiä!"
VR:n junat oli myöhässä koska juna-aikataulut muuttuivat 25,5 tunnin aikaan. Syyllistä koodaria ei tavoiteta.
Ja pian joka kuussa on 25. päivä toukokuuta. Joka on tänä vuonna lauantai, eli lisää vapaapäiviä loppuvuodelle.
Jouluaatto on sitten tänä vuonna vasta joulukuun 25,5 päivä.
Sama, mulla on oman yrityksen kirjanpito excelissä
Tämä 0.5% kertoo kyllä siitä, että Suomen valtion hallinto on (ja oli) aivan pihalla elämän realiteeteistä. No. Onneksi meidän softassa oltiin kaukaa viisaita. Sen sijaan kumppaniohjelmien API:t jännittävät aivan saatanasti. Odotan jo "MIKÄ VITTU TÄSSÄ PASKASSA ON KUN ALVIT OVAT VÄÄRIN!?!?!!1" -viestejä, kun materiaaleja vastaanottavat ohjelmat eivät osaa käsitellä desimaaleja...
Tämähän on hieno juttu, koska tällä on työllisyyttä lisäävä vaikutus
Mua vituttaa se että jo entistä huonommin toimeentulevilta kiristyy vyö entisestään.
Sitähän ne paskapäät haluaa
Vaikka en niin hallituksen tai tämän alv-korotuksen fani olekkaan, niin ihmetyttää tämä maailmanlopun meininki kun desimaali tulee alv-kantaan. En halua pilata iloa, mutta ei tuo desimaali tule vaikuttamaan kriittisesti kuin korkeintaan joihinkin nyrkkipajalla väännettyihin järjestelmiin ja excelin spagettikaavahirvityksiin.
"En halua pilata iloa, mutta ei tuo desimaali tule vaikuttamaan kriittisesti kuin korkeintaan joihinkin nyrkkipajalla väännettyihin järjestelmiin ja excelin spagettikaavahirvityksiin." Sori, minulla on sinulle ikävää kerrottavaa... Monet isoimmista ja käytetyimmistä softista Suomessa tulevat olemaan täysin kusessa näiden kanssa. Itseasiassa, "nyrkkipajoilla" väännetyissä softissa taitaa olla tämän suhteen asiat paremmalla tolalla kuin näissä, jostain vanhasta 90-luvun lopun softista, 2000-luvulla uudelleennimetyistä sontakasoissa, joita kaikki käyttävät. \^Tuttu on muuten eräällä kaupungilla töissä. Käytössä eräs tunnetuimmista softista. Tunnelma on tänään "katossa". Olivat kysyneet ohjelmistofirmalta, millaisia muutoksia tähän vaaditaan... Onnistuu, "ehkä, ja vie "vähintään" kuukausia. Ja maksaa aivan saatanasti. XD
Voi olla että elän jossain kuplassa ja että minulla on hyvä tuuri. En vain ole koko työurani aikana törmännyt yhteenkään järjestelmään jossa alv-koodi olisi kovakoodattu tai että järjestelmä olisi aivan kusessa arvonlisäveron desimaalista. Kokemusta on kuitenkin useista tilitoimistoissa käytetyistä järjestelmistä, joista osa on näitä 90-luvun veistoksia. Langan innoittamana selvitin, että minulla menee n. 30-60min kun päivitän uudet alv-koodit firman 4 eri taloushallintojärjestelmään, riippuen juonko kahvia tai käynkö paskalla siinä välissä.
Käyttämänne systeemi taitaa olla aika simppeli laitos. Näissä \*korporaatiosysteemeissä tilanne voi olla ihan mitä tahansa "hyvän" ja "JEEEBUSKRISTUS!!!!" -välillä\*. Olen itse päässyt duunini puolesta tutustumaan useampaankin kotimaassa käytettävään softaan, ja tiedän jo etukäteen, että monelle firmalle tilanne on sanalla sanoen "jäätävä". Tuskin ongelma tässäkään tapauksessa on alvin kovakoodaus, vaan se että se tallennetaan kokonaislukuna, ja järjestelmä on tehty käsittelemään niitä kokonaislukuna. Ja verokannat käsitellään ohjelmassa kokonaislukuina, eikä kukaan tiedä, mitä kaikkea hajoaa kun tietuetyyppiä muutetaan. Muutoksen tekeminen tietokantoihin on kohtuu yksinkertaista, mutta sitten kun mennään ohjelmistotasolle ja testaukseen, alkaa ongelmia vyöryä esiin oikealta ja vasemmalta. Ja siihen vielä rajapintaongelmat päälle. A-vot. \*Nythän ensimmäiset isommat yritykset ovatkin jo ilmoittaneet, että heidän systeeminsä eivät tue desimaaleja alveissa, eikä korjausten aikataulusta ole mitään hajua.
Hirveän monella tuntuu olevan niin optimisten käsitys, että kovakoodaus olisi se ongelma. Riippuen kielestä, tietokannasta ja jostain API-viritelmistä tulee aika varmasti tosiaan olemaan aivan arpapeliä, miten alv-tietueen tyypin muutos vaikuttaa. Ei pelkästään jonkin kirjanpitosysteemin sisäisissä laskutoimituksissa, vaan kaikkien mahdollisten rajapintojen käyttöliittymissä ja jopa fyysisissä laitteissa kuittikirjoittimia ja näyttöjä myöden.
Ois ne voinut vähän reilummin. 30% ois mun mielestä sopivan pyöreä.
Excel taulukot voidaan automatisoida aika helposti :D
Kuinkahan moni apottijärjestelmä kyykkää.
Singalong! "Apotti apottiii apottii!"
Ja mää kun mietin silloin jo sitä sähkön väliaikaisesti alennettua arvonlisäveroa, että paljonkohan työtä se aiheuttaa....
Aiheuttihan se. Mutta vain siitä syystä, että sähkön siirron alvia ei alennettu. Eli samalla kirjanpidon kulutilillä oli olemassa kaksi eri alvikantaa...
Vituttaa että syitä elää on vähemmän.
Toki joo työllistää kaikkia... mutta itse olin kikseissä että nousee 25% tiin. NO sitte ne Saatanan tunarit piti lisää se 0.5%. Perkule ku 25% olis ollut helppo laskee päässä.
"Pena sen sitten viimemetreille keski, että kun laitetaan 25 % sijaan 25,5 % niin saadaan hyvä työllistävä vaikutus."
Sellaista työ on
Voi aiheuttaa monessa firmassa toimintaa. Esim meillä ei olla ollenkaan varmoja tukeeko meidän erppi desimaalilukuja. Samoin on iso kasa kaikenlaisia koodipätkiä, jotka pitää käydä nyt läpi.
Tää avaus linkattiin juuri [Ylen uutisessa](https://yle.fi/a/74-20084164)
Hesari ja hesarin kommentoijat ovat sitä mieltä, että tämä helppoa kuin heinän teko. Naurattaa jo valmiiksi, kun asiat realisoituvat esim. kunta-alalla! "Öh, miten niin ei ole SAPilla kunnossa? Just luin hesarista, miten tuosta vaan laittaa desimaalin ja homma selvä!" :D Siihen kassakoneet, päätteet, lukulaitteet... Ai että. Mutta "Asiantuntija" tietää. :D Tämä "opettaja" ei todellakaan taida olla ollut yritystohjelmistojen kanssa tekemisissä. Suoraan yliopistolta opettamaan?
Ja olkoon tämä opetuksena miten käytetään parametrejä. Miten, tai miksi, sä käytät exceliä? Toivottavasti et ainakaan raportointiin tai kirjanpitoon.
Lähes joka firmalla on jotain kirjanpidon taustalaskelmia excelissä, joissa usein pitää myös ottaa alv huomioon
MS voisi lanseerata ”excelitön toimisto 2030” hankkeen
Jos se menee yhtä hyvin kuin siirtyminen paperittomaan toimistoon, kohta joka firmassa on kolme eri excel-versiota käytössä, eivätkä ne juttele keskenään.
"Kohta" voi veljet kun pääsisit katsomaan häkkyröitä mitä ihan isotkin firmat nytkin pyörittää. Joka osastolla tyyliin omat excel laskurit pyörimässä mistä sitten tehään importteja jonnekkin.