Gemini 3.6 Flash voi luoda kassanäkymän luonnoksen sekunneissa. Mitä pitää olla kunnossa ennen kuin se voi ottaa vastaan oikean maksun?
Gemini 3.6 Flash tekee kassanäkymän luomisesta lähes ilmaista. Oikean maksun vastaanottaminen riippuu kuitenkin edelleen viidestä asiasta, joita malli ei luo: samanaikaisuutta kestävästä varastonhallinnasta, täsmäävistä raporteista, oikeasta verotuksesta, PCI-yhteensopivista maksuista ja sertifioidusta laitteistosta.
Mathias NielsenCEO, Final POS
Nopeus ei ollut koskaan se puuttuva palanen. Ennen kuin mikään tekoälyn luoma kassa ottaa vastaan oikean maksun, viiden asian on oltava kunnossa: varastotilanne, joka kestää kahden kassan samanaikaisen myynnin, täsmäävät raportit (jotka vastaavat todella liikkunutta rahaa), verotus, joka sopii kyseiseen lainsäädäntöalueeseen, PCI-yhteensopiva maksujen käsittely ja sertifioitu lähimaksulaitteisto. Gemini 3.6 Flash tekee kassanäkymän ensimmäisestä luonnoksesta nopeamman ja halvemman kuin koskaan ennen. Se ei muuta mitään muista viidestä asiasta. Gemini 3.6 Flash POS -prototyyppi on todellinen etumatka; tuotantokäyttöön valmis POS-järjestelmä on täysin eri maali.
Mallien nimet, hinnat ja suorituskykytestit muuttuvat nopeasti. Alla olevat tiedot ovat tarkkoja julkaisuhetkellä; pidä niitä tilannekatsauksena.
Mitä Gemini 3.6 Flash todella muutti?
Se teki nopeasta ja halvasta koodin generoinnista entistä halvempaa ja tarkempaa. Google julkaisi Gemini 3.6 Flashin 21. heinäkuuta 2026 yhdessä Gemini 3.5 Flash-Liten kanssa¹. Se maksaa 1,50 dollaria miljoonaa syötetokenia kohden ja 7,50 dollaria miljoonaa tulostokenia kohden, käyttää noin 17 prosenttia vähemmän tulostokeneita kuin edeltäjänsä ja tekee selvän loikan koodaustarkkuudessa saavuttaen 49 prosenttia DeepSWE-vertailutestissä verrattuna 3.5 Flashin 37 prosenttiin².
Tekoälypohjaisilla rakennustyökaluilla kokeilevalle kauppiaalle tämä tarkoittaa jotain konkreettista: kassanäkymän luominen vie nyt sekunteja ja maksaa vain senttejä. Myös sen hiominen maksaa vain senttejä. Räätälöidyn POS-järjestelmän hankinnan pullonkaula on siirtynyt. Kyse ei ole enää siitä, pystyykö malli luomaan näkymät. Kyse on kaikesta siitä, minkä päällä näkymät lepäävät.
Miksi kassanäkymä ei ole POS-järjestelmä?
Koska kassanäkymä on vain käyttöliittymä, ja POS-järjestelmä on ensisijainen tietolähde (pääjärjestelmä, jossa myyntilukuja pidetään virallisina). Näyttö on se näkyvä kymmenen prosenttia. Sen alla on tilatietoja, joiden on pysyttävä oikeina jokaisessa kassapisteessä, jokaisessa palautuksessa ja jokaisen verkkohäiriön aikana, sekä rahaliikennettä, jota säädellään riippumatta siitä, oliko koodi käsin kirjoitettua vai tekoälyn luomaa. Kävimme läpi saman eron silloin, kun GPT-5.6 julkaistiin, ja se on pitänyt paikkansa jokaisen sen jälkeisen nopean mallin kohdalla.
Ilmeinen vastaväite: nämä mallit kirjoittavat nykyään tuotantotasoista koodia, joten miksi ei annettaisi Gemini 3.6 Flashin kirjoittaa myös varasto- ja verologiikkaa? Se kyllä pystyy siihen. Ongelma ei ole koodin kirjoittaminen. Ongelma on koodin oikeellisuuden todistaminen olosuhteissa, joita et koskaan näe demossa, ja sen huomaaminen, kun se ei vähin äänin pidäkään paikkaansa. Väärin renderöityvä kassanäkymä huomataan sekunneissa. Heittävä pääkirja huomataan vasta kuukauden lopussa kirjanpitäjän toimesta, ja siihen asti jokainen raportti näyttää hyvältä.
Mitä on oltava kunnossa ennen ensimmäistä oikeaa maksua?
Viisi asiaa, eikä yksikään niistä näy esikatseluikkunassa.
Varastonhallinta, joka kestää samanaikaisuutta
Samanaikaisuus (kaksi kassaa käsittelee samaa varastoa täsmälleen samalla hetkellä) on paikka, jossa generoitu varastokoodi epäonnistuu ensimmäisenä. Kaksi kassapistettä myy tuotteen viimeisen kappaleen samalla sekunnilla. Yksinkertainen koodi tarkistaa määrän, näkee yhden olevan vapaana ja päästää molemmat myynnit läpi. Nyt olet myynyt jotain, mitä sinulla ei ole, ja virhe kertautuu hiljaisesti jokaisen ruuhkatunnin myötä. Oikein toimiva järjestelmä sarjoittaa nämä kirjoitukset siten, että toinen myynti voittaa ja toinen näkee tyhjän hyllyn. Tämä on infrastruktuuritason toimintaa, ei näkymätason toimintaa, eikä mikään esikatselu koskaan näytä sitä.
Raportit, jotka täsmäävät
Täsmäytys (raporttien täsmääminen todelliseen liikkuneeseen rahaan) rikkoutuu poikkeustapauksissa: hyvitys, joka tehdään vuoron sulkemisen jälkeen, mitätöinti kassalaskennan jälkeen, osittainen hyvitys alennustuotteesta, uudelleen yritetty maksu verkkokatkon jälkeen. Jokainen poikkeustapaus, jonka generoitu raportti missaa, on pieni aukko raportin ilmoittaman summan ja pankkiin talletetun rahan välillä. Kauppiaat eivät löydä näitä aukkoja testaussuorituksissa. Ne löydetään veroilmoitusta tehtäessä.
Verotus, joka vastaa lainsäädäntöaluetta
Myyntiverot ja arvonlisäverot kumuloituvat: valtiollinen vero alueellisen veron päällä, tuotekohtaiset poikkeukset sekä verokannat, jotka muuttuvat lainsäätäjän määräämänä päivänä eivätkä oman julkaisuaikataulusi mukaan. Virhe veroissa ei ole vain pienten virheiden korjauspyyntö, se on oikeudellinen ja taloudellinen vastuukysymys. Oikea järjestelmä määrittää verot kerran ja soveltaa niitä johdonmukaisesti kaikkialla, samalla tavalla kuin veroryhmät toimivat Kauppiaskeskuksessa (Merchant Hub).
Maksukäsittely, joka läpäisee PCI-vaatimukset
PCI DSS (korttialan turvallisuusstandardi) on olemassa siksi, että korttitietoja käsittelevät vain auditoidut järjestelmät. Generoidun koodin ei pitäisi koskaan nähdä korttinumeroa. Käytännössä tämä tarkoittaa sitä, että maksut kulkevat maksunvälittäjän sertifioidun pinon läpi ja korttitiedot tokenisoidaan (korvataan korvaavalla tunnisteella) ennen kuin ohjelmistosi koskee mihinkään. Tämä on listan ehdottomin asia, ja se jää täysin minkään tekoälymallin tuottaman koodin ulkopuolelle.
Sertifioitu lähimaksulaitteisto
Lähimaksu- ja sirukorttimaksut toimivat vain maksukorttiyhtiöiden sertifioimilla maksupäätteillä, ja sertifiointi ansaitaan laitekohtaisesti laboratoriotesteillä. Sitä ei voi generoida, pyytää kehotteella eikä lisätä jälkikäteen korjaustiedostona. Jos asiakkaasi maksavat paikan päällä, jonkin sertifioidun maksupäätteen on sijoituttava heidän korttinsa ja koodisi väliin.
Missä nopeasta mallista on todella apua?
Juuri siinä, mihin tämä julkaisu keskittyi: kuvailussa, luonnostelussa ja iteroinnissa. Halpa ja nopea malli on oikea työkalu näkymien ja logiikan muotoiluun, viiden eri asettelun kokeilemiseen ennen lounasta ja kassatoiminnon hiomiseen, kunnes se sopii tiskisi todelliseen arkeen. Toimiva työnjako on se, että mallin annetaan tehdä tämä sellaisen kaupankäyntiin tarkoitetun infrastruktuurin päällä, joka jo hallitsee varaston, täsmäytyksen, verotuksen ja maksut.
Siten Finalin Build käsittelee malleja: voit yhdistää Geminin tai minkä tahansa MCP-asiakkaan ja antaa sen rakentaa kassavuosi suorassa esikatselussa, kun taas Final Pay tilittää maksut taustalla toimivan maksunvälittäjän ja sertifioidun maksupäättelaitteiston kautta. Katso vaiheittaiset ohjeet artikkelista kuinka rakentaa Gemini 3.6 Flashin avulla tai kuinka kolme suurinta mallia vertautuvat POS-toteutuksissa.
Mitä siis on oltava kunnossa ennen kuin Gemini 3.6 Flash voi ottaa vastaan oikean maksun?
Samanaikaisuutta kestävä varastonhallinta, täsmäävät raportit, lainsäädäntöaluetta vastaava verotus, PCI-yhteensopiva maksunkäsittely ja sertifioitu laitteisto. Gemini 3.6 Flash teki juuri kassanäkymästä projektin halvimman osan, eikä se koskenut mihinkään kyseiseltä listalta. Nyrkkisääntö: jos epäonnistuminen näkyisi näytön sijaan pankkitililläsi, älä anna generoidun koodin vastata siitä yksin. Luonnostele nopeimmalla mallilla, jonka saat, ja ota sitten käyttöön auditointia varten rakennetussa infrastruktuurissa. Jos haluat kokeilla tätä työnjakoa tänään, aloita Buildin käyttö.
Usein kysytyt kysymykset
Voiko Gemini 3.6 Flash rakentaa POS-järjestelmän itse?
Se voi generoida kassanäkymät ja suuren osan kassavuon logiikasta nopeasti. Se ei kuitenkaan voi tarjota PCI-yhteensopivaa maksunkäsittelyä, sertifioitua lähimaksulaitteistoa tai täsmäävää tapahtumapääkirjaa. Ne tulevat kaupankäyntialustalta, jonka päällä generoitu vuo toimii.
Mitä eroa on kassakäyttöliittymällä ja toimivalla POS-järjestelmällä?
Kassakäyttöliittymä on näkyvä näyttö. Toimiva POS-järjestelmä on ensisijainen tietolähde (pääjärjestelmä): se pitää varaston oikeana eri kassapisteissä, tuottaa raportteja, jotka vastaavat todellista liikkunutta rahaa, soveltaa oikeaa veroa ja tilittää maksut maksunvälittäjän kautta sertifioidulla laitteistolla.
Miksi tekoälyn generoima varastokoodi epäonnistuu todellisissa kaupoissa?
Samanaikaisuuden vuoksi. Kaksi kassaa voi myydä tuotteen viimeisen kappaleen samalla sekunnilla, ja yksinkertainen generoitu koodi päästää molemmat myynnit läpi. Demot eivät koskaan nosta tätä esiin, koska demoissa ajetaan harvoin kahta kassaa samaa varastoa vasten samanaikaisesti.
Mitä PCI-yhteensopivuus tarkoittaa tekoälyllä rakennetulle kassalle?
PCI DSS on korttialan turvallisuusstandardi korttitietojen käsittelylle. Käytännössä generoidun koodin ei pitäisi koskaan nähdä korttinumeroa: maksujen tulee kulkea maksunvälittäjän sertifioidun pinon läpi, ja korttitiedot tulee tokenisoida ennen kuin ohjelmistosi koskee mihinkään.
Voinko käyttää Gemini 3.6 Flashia Finalin kanssa?
Kyllä. Build tukee oman tekoälyn yhdistämistä MCP-yhteydellä: Build luo kertakäyttöisen määrityslohkon, jonka liität työkaluusi, ja malli rakentaa vuosi Finalin infrastruktuurin päälle suorassa esikatselussa. Maksut hoitaa Final Pay.