Asiaa sähköisestä taloushallinnosta, Heeroksesta ja vähän muustakin elämästähttp://blog.heeros.com/heeros/blog.nsfen-usFri, 19 Mar 2010 09:00:38 +0300 Fri, 19 Mar 2010 09:00:38 +0300 Matti Lattu Miten sähköpostitulva taltutetaan
- lähettäjän täytyy muistaa laittaa se päälle

- ne generoivat osittain turhaa viestiliikennettä

- varmuuttaa siitä, kulkevatko kuittaukset eri postiohjelmien ja palvelinten kautta ei ole. Käsittääkseni "return receipt" -toiminto ei ole standardoitu sähköpostiohjelmissa

Mielestäni ei viestiä tarvitse kuitata luetuksi, ellei se sisällä jotain kysymystä tai sellaista asiaa, että siihen on syytä ottaa kantaa. Useinhan vaikeneminen tulkitaan myöntymykseksi, eli jos ei samaa mieltä on ainakin syytä vastata]]>
- lähettäjän täytyy muistaa laittaa se päälle

- ne generoivat osittain turhaa viestiliikennettä

- varmuuttaa siitä, kulkevatko kuittaukset eri postiohjelmien ja palvelinten kautta ei ole. Käsittääkseni "return receipt" -toiminto ei ole standardoitu sähköpostiohjelmissa

Mielestäni ei viestiä tarvitse kuitata luetuksi, ellei se sisällä jotain kysymystä tai sellaista asiaa, että siihen on syytä ottaa kantaa. Useinhan vaikeneminen tulkitaan myöntymykseksi, eli jos ei samaa mieltä on ainakin syytä vastata]]> http://blog.heeros.com/heeros/blog.nsfdx/miten-sahkopostitulva-taltutetaan.htm?opendocument&comments#19.03.201009.00.38PROA8X.htm Thu, 18 Mar 2010 23:39:32 +0300 Erno Alho Miten sähköpostitulva taltutetaan
Itseäni on viime aikana kaivellut sähköpostien suhteen kuittaamisen problematiikka. Tuleeko joka ikinen viesti kuitata vastaanotetuksi, esim. kiittämällä yhteydenotosta? Kohteliasta toki, mutta toisaalta myös tietyllä tapaa turhaa liikennöintiä, joka rasittaa kumpaakin päätä. Mikäli halutaan varmistaa viestin perilllemeno, voidaan käyttää useimmissa (kaikissa?) sähköpostiohjelmissa olevaa erillistä kuittauspyyntöä.]]>
Itseäni on viime aikana kaivellut sähköpostien suhteen kuittaamisen problematiikka. Tuleeko joka ikinen viesti kuitata vastaanotetuksi, esim. kiittämällä yhteydenotosta? Kohteliasta toki, mutta toisaalta myös tietyllä tapaa turhaa liikennöintiä, joka rasittaa kumpaakin päätä. Mikäli halutaan varmistaa viestin perilllemeno, voidaan käyttää useimmissa (kaikissa?) sähköpostiohjelmissa olevaa erillistä kuittauspyyntöä.]]> http://blog.heeros.com/heeros/blog.nsfdx/miten-sahkopostitulva-taltutetaan.htm?opendocument&comments#18032010233932PROTE9.htm Tue, 26 Jan 2010 07:35:52 +0300 Matti Lattu Verkkolaskutukseen siirtyminen on saatava helpommaksi
Olen itse miettinyt myös sitä, että täytyy pankeillekin tulla paljon ylimääräistä ylläpitotyötä näiden yhteyksien selvittelystä. Sopimuksien helpottaminen luulisi auttavan myös heitä.]]>
Olen itse miettinyt myös sitä, että täytyy pankeillekin tulla paljon ylimääräistä ylläpitotyötä näiden yhteyksien selvittelystä. Sopimuksien helpottaminen luulisi auttavan myös heitä.]]> http://blog.heeros.com/heeros/blog.nsfdx/verkkolaskutukseen-siirtyminen-on-saatava-helpommaksi.htm?opendocument&comments#26.01.201007.35.52PRO8KY.htm Mon, 25 Jan 2010 09:33:45 +0300 Arto Miettunen Verkkolaskutukseen siirtyminen on saatava helpommaksi http://blog.heeros.com/heeros/blog.nsfdx/verkkolaskutukseen-siirtyminen-on-saatava-helpommaksi.htm?opendocument&comments#25.01.201009.33.45PROAVN.htm Wed, 20 Jan 2010 12:39:09 +0300 Matti Lattu Spämmi vaivaa taas pahasti http://blog.heeros.com/heeros/blog.nsfdx/spammi-vaivaa-taas-pahasti.htm?opendocument&comments#20.01.201012.39.09PROEHJ.htm Thu, 10 Dec 2009 23:09:52 +0300 Matti Lattu Spämmi vaivaa taas pahasti http://blog.heeros.com/blog.nsfdx/spammi-vaivaa-taas-pahasti.htm?opendocument&comments#10.12.200923.09.52PWESTQ.htm Thu, 10 Dec 2009 09:30:21 +0300 Arto Miettunen Spämmi vaivaa taas pahasti http://blog.heeros.com/blog.nsfdx/spammi-vaivaa-taas-pahasti.htm?opendocument&comments#10.12.200909.30.21PWEATJ.htm Thu, 3 Dec 2009 08:32:05 +0300 Matti Lattu IDe-a ei toimi
- Kommentoin itse aikataulun osalta Bo Haraldin ajatusta että järjestelmä on käytössä 2010 vuoden alkupuolella. Käsittääkseni raportointikoodiston valmistuminen on seuraava varsinainen askel. Jos se tapahtuu aikataulun mukaisesti keväällä 2010, IDe-a:n aikataulu venynee Kauppalehden jutussa kerrotusta.

- varsinkin esityksessäsi Verkkolaskuforuumissa lähtökohtasi oli, ettei pk-yritykselle ole tarjolla hyviä ratkaisuita verkkolaskutukseen. Tästä olen jyrkästi eri mieltä. Heeroksella löytyy ratkaisu (jota tilitoimistot tarjoavat asiakkailleen) ja monia muitakin hyviä löytyy.

- syy, mikseivät kaikki pk-yritykset ja tilitoimistot ole lähteneet mukaan verkkolaskutukseen ei varmaankaan ole siis järjestelmien puute, vaan kyse on jostain muusta. Tällöin en näe, miten kokonaan täysin uusi, rakenteilla oleva toimintamalli auttaisi tässä asiassa, vaan asennemuokkausta ja "sanan julistusta" tarvitaan.

- Epäilen verkkolaskutiedoston kohdistamista kyseiseen maksutapahtumaan. Laskun kuvan muodostaminen suoraan XML:stä on lisäksi yksi suurimpia syitä, miksi pankkien verkkolaskupalveluita hyljeksitään

- Ilmeisesti tekniikkaa skannatun laskun yhdistäminen maksutapahtumaan ei olla vielä päätetty. Mielestäni IDe-a:ssa piti vaatimuksena olla verkkolaskutus,

- Raportointikoodisto ja tiliöintiviite on sisänsä kannattettavia asioita. Tiliöintiviitteen saaminen laskulle vaatii kaikkien laskutusohjelmien muutoksia ja ylipäätään tapaa kommunikoida halutut tiliöintitiedot laskun vastaanottajan ja laskuttajan välillä.

Vuoden päästä ollaan varmaan viisaampia, mihin suuntaan maailma on kääntynyt.]]>
- Kommentoin itse aikataulun osalta Bo Haraldin ajatusta että järjestelmä on käytössä 2010 vuoden alkupuolella. Käsittääkseni raportointikoodiston valmistuminen on seuraava varsinainen askel. Jos se tapahtuu aikataulun mukaisesti keväällä 2010, IDe-a:n aikataulu venynee Kauppalehden jutussa kerrotusta.

- varsinkin esityksessäsi Verkkolaskuforuumissa lähtökohtasi oli, ettei pk-yritykselle ole tarjolla hyviä ratkaisuita verkkolaskutukseen. Tästä olen jyrkästi eri mieltä. Heeroksella löytyy ratkaisu (jota tilitoimistot tarjoavat asiakkailleen) ja monia muitakin hyviä löytyy.

- syy, mikseivät kaikki pk-yritykset ja tilitoimistot ole lähteneet mukaan verkkolaskutukseen ei varmaankaan ole siis järjestelmien puute, vaan kyse on jostain muusta. Tällöin en näe, miten kokonaan täysin uusi, rakenteilla oleva toimintamalli auttaisi tässä asiassa, vaan asennemuokkausta ja "sanan julistusta" tarvitaan.

- Epäilen verkkolaskutiedoston kohdistamista kyseiseen maksutapahtumaan. Laskun kuvan muodostaminen suoraan XML:stä on lisäksi yksi suurimpia syitä, miksi pankkien verkkolaskupalveluita hyljeksitään

- Ilmeisesti tekniikkaa skannatun laskun yhdistäminen maksutapahtumaan ei olla vielä päätetty. Mielestäni IDe-a:ssa piti vaatimuksena olla verkkolaskutus,

- Raportointikoodisto ja tiliöintiviite on sisänsä kannattettavia asioita. Tiliöintiviitteen saaminen laskulle vaatii kaikkien laskutusohjelmien muutoksia ja ylipäätään tapaa kommunikoida halutut tiliöintitiedot laskun vastaanottajan ja laskuttajan välillä.

Vuoden päästä ollaan varmaan viisaampia, mihin suuntaan maailma on kääntynyt.]]> http://blog.heeros.com/blog.nsfdx/ide-a-ei-toimi.htm?opendocument&comments#03.12.200908.32.05PWE9P4.htm Tue, 1 Dec 2009 21:25:16 +0300 Vuokko Mäkinen IDe-a ei toimi
1) Tekniset ongelmat aina ratkaistaan, mutta suurimpana haasteena on se, että tässä nojaudutaan pankkien järjestelmiin. Pankit ovat ratkaisseet tähän asti laskujen kuvien ja liitteiden esittämisen tehokkaasti: jätetään kuvat ja liitteet tylysti pois. Voit siis lähettää laskun, missä on mukana liitteitä, mutta jos se toimitetaan pankin verkkolaskupalveluun, liite on vain hävinnyt matkalla. Heeros ja moni muu verkkolaskujen kanssa toimija ottaisi kyllä ilolla vastaan muutoksen pankkien järjestelmään. Samassa yhteydessä pankit voisivat luopua Finvoice-välityssopimuksen vaatimisesta.

Vastine: IDe-a:n ratkaisun voi toteuttaa kuka tahansa, ratkaisu ei ole riippuvainen pankin järjestelmästä. Pankkiin ratkaisu kytkeytyy maksuliikenteen ja tiliotteen myötä, näitähän käytetään jo nyt. Jos järjestelmätoimittaja tuottaa maksuliikennenpalveluja ja voi noutaa pankin tiliotteen järjestelmäänsä, voi tuottaa myös IDe-a palvelut. Verkkolaskujen välittäjäkin voi olla kuka tahansa, kunhan laskujen linkkitieto voidaan kuljettaa maksatuksen yhteydessä. Tätähän tapahtuu jo nykyisillä maksuliikenne ohjelmillakin, linkki ei vain nykyisin yhdistä verkkolaskua vaan suoritustiedoston.

Vastine: Jos kyseessä on pankin järjestelmä, on todennäköistä, että välitettävät laskut ovat Finvoice formaattia, jolloin erillisiä kuvia ei kuljeteta. Laskutiedostosta voidaan tuottaa laskun kuva nykyisinkin. Mikäli liitteet ovat välttämättömiä esim. laskusisällön puutteellisuuden vuoksi, erillisten liitteiden tuottaminen/noutaminen voidaan ratkaista laskulla olevan linkin kautta.

2) Ehdotuksesta ei myöskään käy ilmi, keitä nämä laskun kopion tiliotteen liitteeksi toimittavat "palveluntarjoajat" ovat. Verkkolaskuoperaattoreita? Ohjelmistotaloja? Jotain uusia tahoja? Ainoat tahot, jotka mielestäni tähän pystyisivät, ovat verkkolaskuoperaattorit, mutta niillä on jo toimiva systeemi laskun kuvan toimittamiseksi.

Vastine: Kun verkkolaskuja lähetetään, ne päätyvät johonkin järjestelmään, vaikkapa Heerokseen. Kun ko verkkolasku on hyväksytty ja tiliöity se päätyy maksatukseen jollakin pankkiohjelmalla, maksutiedosto sisältää ko laskun saajan tilinumeron ja maksuviitteen, joista muodostuu kohdistustieto verkkolaskutiedoston liittämiseksi ko maksutapahtumaan. Tässä esimerkissä palveluntarjoaja on Heeros.

3) Pienempiä kysymyksiä on, että miten hoidetaan väistämättä tulevat paperilaskut, saati tiettyjen tahojen suosimat sähköpostilaskut.

Vastine: Kirjanpitojärjestelmät, joissa pankin tiliote (nykyisin TITO) käsitellään kirjanpitoon mahdollistavat jo tänä päivänä kuvatiedoston liittämisen tositeriviin linkin kautta.

Vastine: Jos käytössä on hyväksymisjärjestelmä, nuo sähköpostilaskut (pdf) lisätään nykyisinkin jo kierrätysjärjestelmään.

4) Entäs arkistointi, ilmeisesti aineisto arkistoidaan "jonnekin" eli verkkolevylle tai DVD:lle. Miten laskun tiliöinti tehdään? Ei sekään itsestään tule, ennenkuin menetelmiä on kehitetty nykyistä pitemmälle.

Vastine: Useimmat nykyisistä arkistointiratkaisuista mahdollistavat käsitellyn tiliotteen arkistoinnin siten, että tapahtumariviin liittyvät dokumentit arkistoituvat samalla. Kaikista arkistointijärjestelmistä voidaan tuottaa aineistoa myös mm.DVD:lle

Vastine: Jos käytössä on kierrätysjärjestelmä tai muu laskujen käsittelyohjelma, tiliöinnit syntyvät laskujen tallennuksen tms toimenpiteen yhteydessä, ja siirtyvät maksutapahtuman linkin avulla maksutapahtumalle (näin voidaan menetellä jo nykyisinkin). Jos käytetään pankin verkkopankkiratkaisua, tiliöinnit luontevasti syntyvät kirjanpito-ohjelmassa, jossa sähköinen tiliote (TITO) käsitellään.

5) Kirjanpidollisesti järjestelmä johtaa väistämättä kassaperusteiseen kirjanpitoon.

Vastine: Monilla yrityksillä tehdään kirjanpito jo nykyisinkin maksuperusteisesti, ainoastaan myyntilaskujen osalta kirjataan arvonlisäverotuksen vuoksi myös uudet avoimet myyntilaskut vähintäinkin laskuperusteisesti. Tähän ei ole mitään estettä IDe-a:a käytettäessä. Kirjanpitoon tehdään nykyisinkin muistiokirjauksia, eikä näiden käsittely muutu. Yhtälailla näistä tositteista voidaan liittää kuvatiedostot linkiksi varsinaiseen kirjanpito-ohjelmaan.

6) Esimerkiksi jos myyntilaskut kirjataan tiliotteelta, ei tiedetä mistä laskuista ei ole saatu suorituksia .

Vastine: IDe-an lähtökohtana ovat verkkolaskut myynnissä, ne tuotetaan jollakin järjestelmällä, joka tuottaa laskuille myös maksuviitteen. Jokainen saatu suoritus kohdistuu avoimeen myyntilaskuun maksuviitteellä. Kaikki ne laskut, joille ei suoritusta ole kohditettu ovat laskutusjärjestelmässä avoimia. Mikäli joku maksaa suorituksen ilman viitettä, kohdistus joudutaan luonnollisesti tekemään käsin. Tämä käytäntö ei poikkea millään muotoa nykyisestä menettelystä.

7) Mikäli myyntisaatavat kirjataan erillisestä myyntireskontrasta, jouduttaisiin tilanteeseen, jossa ostolaskut ovat kassaperusteisia (ostovelkatiliä ei käytetä) ja myyntilaskut suoriteperusteisia.

Vastine: Näin tehdään monissa pienissä kirjanpidoissa nykyisinkin, eikä kaikilla ole edes myyntireskontraa käytössä

8) Samoin palkkojen ja muistiotositteiden kirjaaminen täytyisi tehdä jotenkin käsin, niitä ei saa tiliotteelta.

Vastine: Tämä ei muutu mitenkään nykykäytännöstä. Tiliotteella oleva palkanmaksutapahtuma on sinänsä oma tosite, johon liittyvät varsinaiset palkkakirjanpidon viennit tehdään erillisellä muistioviennillä.

9) Kassavirtalaskelman tekeminen tuntuu myös hankalalta, kun tiedot ostoista ja myynneistä tulee tiliotteelta eli käytännössä kassaperusteisesti. Ostoveloista ja myyntisaatavista ei ole tietoa, mutta jostain tempaistaan kassavirtaennuste.

Vastine: Jos avoimet myyntilaskut ja ostolaskut ovat samassa järjestelmässä, josta myös nähdään pankkitilin saldo, ei liene kenellään ohjelmistotoimittajalle ongelmallista tuottaa raportti joka kertoo kassavirran. Ohjelmistotoimittajan omasta kunnianhimosta riippuu, miten kattavan kassaennusteen tuottaa.

10) Aikataulullisesti haaste on erittäin kunnianhimoinen, jos 2010 alkupuolella joku taho suunnittelee kirjanpitoa näin hoitavansa.

Vastine: Tällä hetkellä on olemassa ohjelmistoja, jotka mahdollistavat kirjanpidon tuottamisen juuri näin. IDe-a vähentää kirjanpitoon liittyvää työtä oleellisesti ja mahdollistaa useiden tapahtumien automaattisen käsittelyn. Tämän lisäksi IDe-a mahdollistaa keskitettynä ratkaisuna yrittäjälle mahdollisuuden hallita rahatilannettaan aivan erilailla kuin nykyisin. Pienille yrityksille tällaisia mahdollisuuksia ei juurikaan ole tarjolla. IDe-a voidaan toteuttaa hyvin moniin kirjanpito-, maksuliikenne- ja tiliotteen käsittelyohjelmiin. Näistä pitää koostaa yritykselle keskitettyjä hyvin toimivia ratkaisuja, jolla edistämme voimakkaasti verkkolaskujen käyttöönottoa myös pk-yrityksissä. IDe-an myötä myös pk-yritys hyötyy verkkolaskujen käytöstä

11) Raportointikoodiston luonnoksen pitäisi valmistua 2009 loppuun mennessä ja siitä puolisen vuotta on vielä kommentointiaikaa. Tähän kun vielä lisätään toivotut lakimuutokset ja erilaisten laskutusohjelmien muutokset (laskulle pitää saada informaatiota tiliöintiä varten, ns tiliöintiviite), niin valitettavasti aikataulu on mahdoton.

Vastine: Raportointikoodiston kehitystyö jatkuu aikataulun mukaisesti. Raportointikoodiston käyttöönotto ei edellytä mitään lakimuutoksia. Ensisijaisesti raportointikoodisto linkittyy kirjanpitojärjestelmän tilikarttaan ja voidaan ottaa käyttöön heti koodiston valmistuttua.

Vastine: Tiliöintiviitteen käyttöönotto olisi ostolaskujen käsittelijöille erinomaisen hyödyllistä, se säästäisi paljon työtä ja vaivaa sisäisen laskennan koodien metsästyksestä ja kirjaamisesta. Tilöintiviite palvelee erityisesti esim. rakennusliikkeen työmaaseurantaa, jossa jokainen lasku kohdistetaan työmaalle ja litteroidaan. Tavaran tilaaja voisi jo tilatessaan liittää tiliöintiviitteen tilaukseen, josta se palaisi ostolaskulla.

12) Kaikenkaikkiaan tulee mieleen, että nyt yritetään pyörää keksiä uudestaan. Kirjanpito-ohjelmia Suomi on pullollaan ja verkkolaskutus on lähtenyt jo vyörymään eteenpäin. Käytännössä toimivan verkkolaskujen vastaanoton ja lähetyksen voi yhdistää melkein mihin tahansa kirjanpito-ohjelmistoon. Selainkäyttöinen reskontra on tarjolla ja sähköinen arkistointi on myös arkipäivää. Kirjanpito voidaan automatisoida erilaisilla oletuksilla ja automaatiotiliöinneillä.

Vastine: Jostain syystä nämä ratkaisut eivät kuitenkaan ole siinä laajuudessaan käytössä kun toivoisi. Pienet yritykset eivät ole näitä palveluja kokeneet omikseen.

13) Mielestäni voimat kannattaisi käyttää nyt jo meneillään olevan verkkolaskutuksen läpimurron vauhdittamiseksi.

Vastine: Juuri tätä työtä olemme FIA:ssa tekemässä.]]>
1) Tekniset ongelmat aina ratkaistaan, mutta suurimpana haasteena on se, että tässä nojaudutaan pankkien järjestelmiin. Pankit ovat ratkaisseet tähän asti laskujen kuvien ja liitteiden esittämisen tehokkaasti: jätetään kuvat ja liitteet tylysti pois. Voit siis lähettää laskun, missä on mukana liitteitä, mutta jos se toimitetaan pankin verkkolaskupalveluun, liite on vain hävinnyt matkalla. Heeros ja moni muu verkkolaskujen kanssa toimija ottaisi kyllä ilolla vastaan muutoksen pankkien järjestelmään. Samassa yhteydessä pankit voisivat luopua Finvoice-välityssopimuksen vaatimisesta.

Vastine: IDe-a:n ratkaisun voi toteuttaa kuka tahansa, ratkaisu ei ole riippuvainen pankin järjestelmästä. Pankkiin ratkaisu kytkeytyy maksuliikenteen ja tiliotteen myötä, näitähän käytetään jo nyt. Jos järjestelmätoimittaja tuottaa maksuliikennenpalveluja ja voi noutaa pankin tiliotteen järjestelmäänsä, voi tuottaa myös IDe-a palvelut. Verkkolaskujen välittäjäkin voi olla kuka tahansa, kunhan laskujen linkkitieto voidaan kuljettaa maksatuksen yhteydessä. Tätähän tapahtuu jo nykyisillä maksuliikenne ohjelmillakin, linkki ei vain nykyisin yhdistä verkkolaskua vaan suoritustiedoston.

Vastine: Jos kyseessä on pankin järjestelmä, on todennäköistä, että välitettävät laskut ovat Finvoice formaattia, jolloin erillisiä kuvia ei kuljeteta. Laskutiedostosta voidaan tuottaa laskun kuva nykyisinkin. Mikäli liitteet ovat välttämättömiä esim. laskusisällön puutteellisuuden vuoksi, erillisten liitteiden tuottaminen/noutaminen voidaan ratkaista laskulla olevan linkin kautta.

2) Ehdotuksesta ei myöskään käy ilmi, keitä nämä laskun kopion tiliotteen liitteeksi toimittavat "palveluntarjoajat" ovat. Verkkolaskuoperaattoreita? Ohjelmistotaloja? Jotain uusia tahoja? Ainoat tahot, jotka mielestäni tähän pystyisivät, ovat verkkolaskuoperaattorit, mutta niillä on jo toimiva systeemi laskun kuvan toimittamiseksi.

Vastine: Kun verkkolaskuja lähetetään, ne päätyvät johonkin järjestelmään, vaikkapa Heerokseen. Kun ko verkkolasku on hyväksytty ja tiliöity se päätyy maksatukseen jollakin pankkiohjelmalla, maksutiedosto sisältää ko laskun saajan tilinumeron ja maksuviitteen, joista muodostuu kohdistustieto verkkolaskutiedoston liittämiseksi ko maksutapahtumaan. Tässä esimerkissä palveluntarjoaja on Heeros.

3) Pienempiä kysymyksiä on, että miten hoidetaan väistämättä tulevat paperilaskut, saati tiettyjen tahojen suosimat sähköpostilaskut.

Vastine: Kirjanpitojärjestelmät, joissa pankin tiliote (nykyisin TITO) käsitellään kirjanpitoon mahdollistavat jo tänä päivänä kuvatiedoston liittämisen tositeriviin linkin kautta.

Vastine: Jos käytössä on hyväksymisjärjestelmä, nuo sähköpostilaskut (pdf) lisätään nykyisinkin jo kierrätysjärjestelmään.

4) Entäs arkistointi, ilmeisesti aineisto arkistoidaan "jonnekin" eli verkkolevylle tai DVD:lle. Miten laskun tiliöinti tehdään? Ei sekään itsestään tule, ennenkuin menetelmiä on kehitetty nykyistä pitemmälle.

Vastine: Useimmat nykyisistä arkistointiratkaisuista mahdollistavat käsitellyn tiliotteen arkistoinnin siten, että tapahtumariviin liittyvät dokumentit arkistoituvat samalla. Kaikista arkistointijärjestelmistä voidaan tuottaa aineistoa myös mm.DVD:lle

Vastine: Jos käytössä on kierrätysjärjestelmä tai muu laskujen käsittelyohjelma, tiliöinnit syntyvät laskujen tallennuksen tms toimenpiteen yhteydessä, ja siirtyvät maksutapahtuman linkin avulla maksutapahtumalle (näin voidaan menetellä jo nykyisinkin). Jos käytetään pankin verkkopankkiratkaisua, tiliöinnit luontevasti syntyvät kirjanpito-ohjelmassa, jossa sähköinen tiliote (TITO) käsitellään.

5) Kirjanpidollisesti järjestelmä johtaa väistämättä kassaperusteiseen kirjanpitoon.

Vastine: Monilla yrityksillä tehdään kirjanpito jo nykyisinkin maksuperusteisesti, ainoastaan myyntilaskujen osalta kirjataan arvonlisäverotuksen vuoksi myös uudet avoimet myyntilaskut vähintäinkin laskuperusteisesti. Tähän ei ole mitään estettä IDe-a:a käytettäessä. Kirjanpitoon tehdään nykyisinkin muistiokirjauksia, eikä näiden käsittely muutu. Yhtälailla näistä tositteista voidaan liittää kuvatiedostot linkiksi varsinaiseen kirjanpito-ohjelmaan.

6) Esimerkiksi jos myyntilaskut kirjataan tiliotteelta, ei tiedetä mistä laskuista ei ole saatu suorituksia .

Vastine: IDe-an lähtökohtana ovat verkkolaskut myynnissä, ne tuotetaan jollakin järjestelmällä, joka tuottaa laskuille myös maksuviitteen. Jokainen saatu suoritus kohdistuu avoimeen myyntilaskuun maksuviitteellä. Kaikki ne laskut, joille ei suoritusta ole kohditettu ovat laskutusjärjestelmässä avoimia. Mikäli joku maksaa suorituksen ilman viitettä, kohdistus joudutaan luonnollisesti tekemään käsin. Tämä käytäntö ei poikkea millään muotoa nykyisestä menettelystä.

7) Mikäli myyntisaatavat kirjataan erillisestä myyntireskontrasta, jouduttaisiin tilanteeseen, jossa ostolaskut ovat kassaperusteisia (ostovelkatiliä ei käytetä) ja myyntilaskut suoriteperusteisia.

Vastine: Näin tehdään monissa pienissä kirjanpidoissa nykyisinkin, eikä kaikilla ole edes myyntireskontraa käytössä

8) Samoin palkkojen ja muistiotositteiden kirjaaminen täytyisi tehdä jotenkin käsin, niitä ei saa tiliotteelta.

Vastine: Tämä ei muutu mitenkään nykykäytännöstä. Tiliotteella oleva palkanmaksutapahtuma on sinänsä oma tosite, johon liittyvät varsinaiset palkkakirjanpidon viennit tehdään erillisellä muistioviennillä.

9) Kassavirtalaskelman tekeminen tuntuu myös hankalalta, kun tiedot ostoista ja myynneistä tulee tiliotteelta eli käytännössä kassaperusteisesti. Ostoveloista ja myyntisaatavista ei ole tietoa, mutta jostain tempaistaan kassavirtaennuste.

Vastine: Jos avoimet myyntilaskut ja ostolaskut ovat samassa järjestelmässä, josta myös nähdään pankkitilin saldo, ei liene kenellään ohjelmistotoimittajalle ongelmallista tuottaa raportti joka kertoo kassavirran. Thu, 29 Oct 2009 08:06:35 +0300 Matti Lattu Verkkolaskujen kustannuksia selvitetty http://blog.heeros.com/blog.nsfdx/verkkolaskujen-kustannuksia-selvitetty.htm?opendocument&comments#29.10.200908.06.35PWE976.htm Thu, 29 Oct 2009 08:03:43 +0300 Matti Lattu Sähköpostilaskusta
SINV ei mielestäni myöskään poista sitä ongelmaa että sähköpostit hukkuvat helposti.]]>
SINV ei mielestäni myöskään poista sitä ongelmaa että sähköpostit hukkuvat helposti.]]> http://blog.heeros.com/blog.nsfdx/sahkopostilaskusta.htm?opendocument&comments#29.10.200908.03.43PWE95D.htm Tue, 27 Oct 2009 18:31:29 +0300 Juhani Jaakola Sähköpostilaskusta
Sekä laskun lähettäjän että vastaanottajan edut huomioiva ratkaisu on käyttää määrämuotoista sähköpostiviestiä, joka on mahdollista lukea konekielisesti.

Olen ehdottanut tähän ratkaisuksi SINV-protokollaa. Katsokaa Googlesta hakusanoilla simple invoicing protocol sinv tai linkeistä:

{ Link }

{ Link }

SINV-mallissa ei tarvita verkkolaskuoperaattoria lainkaan. Lisäksi laskutuksen osapuolien tunnistaminen käy helposti sähköpostiosoitteilla, mitään laajennettuja OVT-tunnuksia ei tarvita.]]>
Sekä laskun lähettäjän että vastaanottajan edut huomioiva ratkaisu on käyttää määrämuotoista sähköpostiviestiä, joka on mahdollista lukea konekielisesti.

Olen ehdottanut tähän ratkaisuksi SINV-protokollaa. Katsokaa Googlesta hakusanoilla simple invoicing protocol sinv tai linkeistä:

{ Link }

{ Link }

SINV-mallissa ei tarvita verkkolaskuoperaattoria lainkaan. Lisäksi laskutuksen osapuolien tunnistaminen käy helposti sähköpostiosoitteilla, mitään laajennettuja OVT-tunnuksia ei tarvita.]]> http://blog.heeros.com/blog.nsfdx/sahkopostilaskusta.htm?opendocument&comments#10272009063129PMPWEMDQ.htm Tue, 27 Oct 2009 18:16:04 +0300 N N Verkkolaskujen kustannuksia selvitetty
Usein verkkolaskuoperaattorin aloituskustannukset ja kuukausikustannukset puhumattakaan laskukohtaisista kustannuksista tekevät verkkolaskujen lähettämisestä kallista lystiä pienyrittäjille.

Nettipohjainen (tai oikeastaan selainpohjainen) "palvelu" tarkoittaa sitä, että joudut naputtelemaan laskun tiedot nettilomakkeelle, vaikka laskun tiedot ovat järjestelmässäsi.

Pienyrittäjälle kaikkein helpoin tapa laskuttaa on lähettää lasku sähköpostin RTF-liitteenä.]]>
Usein verkkolaskuoperaattorin aloituskustannukset ja kuukausikustannukset puhumattakaan laskukohtaisista kustannuksista tekevät verkkolaskujen lähettämisestä kallista lystiä pienyrittäjille.

Nettipohjainen (tai oikeastaan selainpohjainen) "palvelu" tarkoittaa sitä, että joudut naputtelemaan laskun tiedot nettilomakkeelle, vaikka laskun tiedot ovat järjestelmässäsi.

Pienyrittäjälle kaikkein helpoin tapa laskuttaa on lähettää lasku sähköpostin RTF-liitteenä.]]> http://blog.heeros.com/blog.nsfdx/verkkolaskujen-kustannuksia-selvitetty.htm?opendocument&comments#10272009061604PMPWEM44.htm Thu, 22 Oct 2009 14:17:41 +0300 Matti Lattu Matkakuumetta http://blog.heeros.com/blog.nsfdx/matkakuumetta.htm?opendocument&comments#22.10.200914.17.41PWEF9L.htm Tue, 1 Sep 2009 22:10:53 +0300 Matti Lattu Sähköpostilaskusta http://blog.heeros.com/blog.nsfdx/sahkopostilaskusta.htm?opendocument&comments#01.09.200922.10.53PWEQHC.htm Mon, 31 Aug 2009 09:07:29 +0300 Lassi Mäkinen Sähköpostilaskusta
Laskun käsittelytapa riippuu siitä, missä formaatissa se saapuu sähköpostin välityksellä asiakkaalle. Lasku voi tulla esimerkiksi seuraavissa formaateissa: PDF, Word, Excel, tekstitiedosto, sähköpostiviestin runkoteksti ja yleisesti käytössä oleva XML-tiedosto (esimerkiksi Finvoice).

Kaikki nämä tiedostot voidaan tulostaa paperille tai arkistoida sähköisessä muodossa. Houkuttelevimmat sähköisesti arkistoitavat ovat PDF ja Finvoice. Todennäköisimmin paperille tulostetaan Word, Excel, tekstitiedosto tai sähköpostiviestin runko. Nämäkin voidaan tulostaa PDF-tiedostoksi esimerkiksi ilmaisella PDFill-ohjelmalla. Silloin ei paperia tarvita lainkaan.

Pienessä yrityksessä ei ole mitään järkeä skannata ostolaskuja, jos niiden määrä vuodessa on enintään yksi mapillinen. Mappiarkistot ovat sallittuja ja tämän kokoisissa yrityksissä myös suositeltavia.

On siis hyvin epätodennäköistä, että joku ensin tulostaisi laskun paperille ja sen jälkeen skannaisi sen sähköiseen muotoon.

Matti, vaikka olemme eri mieltä, arvostan suuresti sitä, että keskustelet avoimesti tästä asiasta. Verkkolaskutuksen hitaan yleistymisen yksi perussyistä on se, että on ollut vain yksi totuus eikä minkäänlaista keskustelua. Harvoin olen kohdannut yhtä hyvää keskustelijaa kuin Sinä olet.]]>
Laskun käsittelytapa riippuu siitä, missä formaatissa se saapuu sähköpostin välityksellä asiakkaalle. Lasku voi tulla esimerkiksi seuraavissa formaateissa: PDF, Word, Excel, tekstitiedosto, sähköpostiviestin runkoteksti ja yleisesti käytössä oleva XML-tiedosto (esimerkiksi Finvoice).

Kaikki nämä tiedostot voidaan tulostaa paperille tai arkistoida sähköisessä muodossa. Houkuttelevimmat sähköisesti arkistoitavat ovat PDF ja Finvoice. Todennäköisimmin paperille tulostetaan Word, Excel, tekstitiedosto tai sähköpostiviestin runko. Nämäkin voidaan tulostaa PDF-tiedostoksi esimerkiksi ilmaisella PDFill-ohjelmalla. Silloin ei paperia tarvita lainkaan.

Pienessä yrityksessä ei ole mitään järkeä skannata ostolaskuja, jos niiden määrä vuodessa on enintään yksi mapillinen. Mappiarkistot ovat sallittuja ja tämän kokoisissa yrityksissä myös suositeltavia.

On siis hyvin epätodennäköistä, että joku ensin tulostaisi laskun paperille ja sen jälkeen skannaisi sen sähköiseen muotoon.

Matti, vaikka olemme eri mieltä, arvostan suuresti sitä, että keskustelet avoimesti tästä asiasta. Verkkolaskutuksen hitaan yleistymisen yksi perussyistä on se, että on ollut vain yksi totuus eikä minkäänlaista keskustelua. Harvoin olen kohdannut yhtä hyvää keskustelijaa kuin Sinä olet.]]> http://blog.heeros.com/blog.nsfdx/sahkopostilaskusta.htm?opendocument&comments#31.08.200909.07.29PWE97Q.htm Fri, 28 Aug 2009 07:11:00 +0300 Matti Lattu Sähköpostilaskusta
Lisäksi laskut täytyy arkistoida jotenkin, koska ne ovat kirjanpitoaineistoa. Lasku on siis joko saatava sähköiseen arkistoon tai tulostettava ja arkistoitava mappeihin.]]>
Lisäksi laskut täytyy arkistoida jotenkin, koska ne ovat kirjanpitoaineistoa. Lasku on siis joko saatava sähköiseen arkistoon tai tulostettava ja arkistoitava mappeihin.]]> http://blog.heeros.com/blog.nsfdx/sahkopostilaskusta.htm?opendocument&comments#28.08.200907.11.00PWE6WX.htm Thu, 27 Aug 2009 11:59:13 +0300 Lassi Mäkinen Sähköpostilaskusta
Sähköposti on yksi menetelmä, jolla laskuja voidaan välittää laskuttajilta asiakkaille. Toinen menetelmä on verkkolaskuoperaattorien muodostama yhdysväylä. Kolmas menetelmä on perinteinen posti.

Myös laskuja on monenlaisia. Perinteisesti laskut ovat olleet paperiformaatissa. Sähköisesti lasku voidaan toteuttaa mm. PDF-, Word-, Excel- tai muuna tiedostona. Esimerkiksi yhtiöni Lasmak Oy on ottanut vastaan kaikkia edellä mainittuja sähköisiä laskuja. Mitään ongelmaa en ole havainnut mutta puutteena on se, ettei maksuliikenne- tai ostoreskontraohjelma pysty lukemaan niitä automaattisesti, koska ne eivät ole konekielisiä.

Verkkolasku on toteutettu XML-kuvauskielellä ja se noudattaa jotakin yhteisesti sovittua formaattia. Se on konekielinen, jolloin vastaanottava ohjelma kykenee automaattisesti lukemaan laskun tiedot järjestelmään.

Jos esimerkiksi Suomessa on käytössä vain yksi XML-kuvauskieltä käyttävä formaatti, se on silloin standardi. Finvoice alkaa pian olla standardi mutta se ei ihan vielä ole sellainen, koska mm. Tieto hannaa vääjäämätöntä kehitystä vastaan.

Sähköpostia voidaan käyttää esimerkiksi Finvoice-laskun välittämiseen. Se voidaan joko liittää sähköpostiviestin liitteeksi tai viestissä voidaan kertoa, mistä verkko-osoitteesta lasku on poimittavissa. Tämän menetelmän käyttö ei yleensä johda laskun tulostamiseen paperille, kuten väitit, vaan lasku poimitaan vastaanottajan kovalevylle.

Ainoa katkos tässä ketjussa on siinä, että pankkien ja muiden verkkolaskuoperaattorien toimittamat ohjelmat ja verkkopalvelut eivät salli edellä kuvatun tiedoston lataamista sisään järjestelmään. Juuri tämä on se keskeisin syy, miksi verkkolaskuoperaattorien sopimusverkostoa voidaan mahdollisesti pitää kartellina. Se estää esimerkiksi sähköpostia hyödyntävän ulkopuolisen kilpailun.]]>
Sähköposti on yksi menetelmä, jolla laskuja voidaan välittää laskuttajilta asiakkaille. Toinen menetelmä on verkkolaskuoperaattorien muodostama yhdysväylä. Kolmas menetelmä on perinteinen posti.

Myös laskuja on monenlaisia. Perinteisesti laskut ovat olleet paperiformaatissa. Sähköisesti lasku voidaan toteuttaa mm. PDF-, Word-, Excel- tai muuna tiedostona. Esimerkiksi yhtiöni Lasmak Oy on ottanut vastaan kaikkia edellä mainittuja sähköisiä laskuja. Mitään ongelmaa en ole havainnut mutta puutteena on se, ettei maksuliikenne- tai ostoreskontraohjelma pysty lukemaan niitä automaattisesti, koska ne eivät ole konekielisiä.

Verkkolasku on toteutettu XML-kuvauskielellä ja se noudattaa jotakin yhteisesti sovittua formaattia. Se on konekielinen, jolloin vastaanottava ohjelma kykenee automaattisesti lukemaan laskun tiedot järjestelmään.

Jos esimerkiksi Suomessa on käytössä vain yksi XML-kuvauskieltä käyttävä formaatti, se on silloin standardi. Finvoice alkaa pian olla standardi mutta se ei ihan vielä ole sellainen, koska mm. Tieto hannaa vääjäämätöntä kehitystä vastaan.

Sähköpostia voidaan käyttää esimerkiksi Finvoice-laskun välittämiseen. Se voidaan joko liittää sähköpostiviestin liitteeksi tai viestissä voidaan kertoa, mistä verkko-osoitteesta lasku on poimittavissa. Tämän menetelmän käyttö ei yleensä johda laskun tulostamiseen paperille, kuten väitit, vaan lasku poimitaan vastaanottajan kovalevylle.

Ainoa katkos tässä ketjussa on siinä, että pankkien ja muiden verkkolaskuoperaattorien toimittamat ohjelmat ja verkkopalvelut eivät salli edellä kuvatun tiedoston lataamista sisään järjestelmään. Juuri tämä on se keskeisin syy, miksi verkkolaskuoperaattorien sopimusverkostoa voidaan mahdollisesti pitää kartellina. Se estää esimerkiksi sähköpostia hyödyntävän ulkopuolisen kilpailun.]]> http://blog.heeros.com/blog.nsfdx/sahkopostilaskusta.htm?opendocument&comments#27.08.200911.59.13PWECK3.htm Thu, 27 Aug 2009 10:34:03 +0300 Mikko Kalliovaara Identan uudistuksista
Edelleen ratkaisematta jää tilanne, jossa toimittaja käyttää samaa y-tunnusta, samaa pankkitiliä ja useampaa lomaketta. Tällöin on vaikea keksiä mikä olisi tarpeeksi varmasti lomakkeet yksilöivä tieto.

Eri pankkitilien tapauksessa opetuksen pitäisi jo vanhassa Identan versiossa toimia oikein. Ongelmat tällöin ovat olleet Circulan päässä toimittajan tunnistamisessa ja joissain tapauksissa vaihtumista väärään on aiheutunut.

Rahoitusyhtiökäsittelyn myötä tarkensimme myös Circulassa laskujen tuonnissa toimittajien käsittelyä.

Uusi käsittely estää toimittajan vaihtumisen, mitä tapahtui aiemmin, jos Circulassa oli kaksi tai useampi toimittajaa samalla pankkitilillä.

Jatkossa Circula tutkii ensin pankkitilinnumeron, sitten y-tunnuksen ja vielä lopuksi toimittajan nimeä, kunnes päätyy yksilöivään toimittajadokumenttiin ja valitsee sen laskulle.]]>
Edelleen ratkaisematta jää tilanne, jossa toimittaja käyttää samaa y-tunnusta, samaa pankkitiliä ja useampaa lomaketta. Tällöin on vaikea keksiä mikä olisi tarpeeksi varmasti lomakkeet yksilöivä tieto.

Eri pankkitilien tapauksessa opetuksen pitäisi jo vanhassa Identan versiossa toimia oikein. Ongelmat tällöin ovat olleet Circulan päässä toimittajan tunnistamisessa ja joissain tapauksissa vaihtumista väärään on aiheutunut.

Rahoitusyhtiökäsittelyn myötä tarkensimme myös Circulassa laskujen tuonnissa toimittajien käsittelyä.

Uusi käsittely estää toimittajan vaihtumisen, mitä tapahtui aiemmin, jos Circulassa oli kaksi tai useampi toimittajaa samalla pankkitilillä.

Jatkossa Circula tutkii ensin pankkitilinnumeron, sitten y-tunnuksen ja vielä lopuksi toimittajan nimeä, kunnes päätyy yksilöivään toimittajadokumenttiin ja valitsee sen laskulle.]]> http://blog.heeros.com/blog.nsfdx/identan-uudistuksista.htm?opendocument&comments#08272009103403AMPWEAVU.htm Thu, 27 Aug 2009 06:51:06 +0300 Matti Lattu Sähköpostilaskusta
Mikäli sähköpostilasku tarkoittaa linkkiä jostain ladattavaan/katsottavaan laskuun se johtaa juuri mainitsemiini ongelmiin: lasku joko tulostetaan ja skannataan eikä sitä saada "imuroitua" omaan reskontraan tai kirjanpitoon.

Siitä olemme varmasti samaa mieltä, että laskujen välitys pitäisi saada kevyemmäksi. Esimerkiksi pankkien vaatimat finvoice-välityssopimukset jäykistävät lähettämistä.]]>
Mikäli sähköpostilasku tarkoittaa linkkiä jostain ladattavaan/katsottavaan laskuun se johtaa juuri mainitsemiini ongelmiin: lasku joko tulostetaan ja skannataan eikä sitä saada "imuroitua" omaan reskontraan tai kirjanpitoon.

Siitä olemme varmasti samaa mieltä, että laskujen välitys pitäisi saada kevyemmäksi. Esimerkiksi pankkien vaatimat finvoice-välityssopimukset jäykistävät lähettämistä.]]> http://blog.heeros.com/blog.nsfdx/sahkopostilaskusta.htm?opendocument&comments#27.08.200906.51.06PWE6JH.htm