Miksei skeemavalidointi riitä?

Yleinen uskomus on, että XML-aineisto on kunnossa, kun se on sanoman rakennekuvauksen (skeema) mukaan validi. Tämä myytti ei pidä alkuunkaan paikkaansa. Seuraavassa asia on havainnollistettu laskusanomaesimerkin avulla.

Laskun kuva:

Finvoice laskun kuva

Tämä laskun kuva on muodostettu Finvoice 2.01-sanomasta, joka on skeeman mukaan validi. Alla on kyseisen sanoman XML-rakenne.

Laskusanoman XML-rakenne:

   
    <?xml version="1.0" encoding="ISO-8859-15"?>
<Finvoice Version="2.01" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="..\..\Documents\standardit\Finvoice\2.01\Finvoice_2.01_2013-04-01.xsd">
    <SellerPartyDetails>
        <SellerOrganisationName>  </SellerOrganisationName>
    </SellerPartyDetails>
    <BuyerPartyDetails>
        <BuyerOrganisationName>  </BuyerOrganisationName>
    </BuyerPartyDetails>
    <InvoiceDetails>
        <InvoiceTypeCode>INV01</InvoiceTypeCode>
        <InvoiceTypeText> </InvoiceTypeText>
        <OriginCode> Original </OriginCode>
        <InvoiceNumber> </InvoiceNumber>
        <InvoiceDate Format=" CCYYMMDD "> 00000000 </InvoiceDate>
        <InvoiceTotalVatIncludedAmount AmountCurrencyIdentifier=" xxx "> 00 </InvoiceTotalVatIncludedAmount>
    </InvoiceDetails>
    <InvoiceRow>
    <!-- Ei yhtään pakollista tietoa rivitasolla! -->
    </InvoiceRow>
    <EpiDetails>
        <EpiIdentificationDetails>
            <EpiDate Format=" CCYYMMDD "> 00000000 </EpiDate>
            <EpiReference></EpiReference>
        </EpiIdentificationDetails>
        <EpiPartyDetails>
            <EpiBfiPartyDetails>
            </EpiBfiPartyDetails>
            <EpiBeneficiaryPartyDetails>
                <EpiAccountID IdentificationSchemeName=" IBAN "> 1 </EpiAccountID>
            </EpiBeneficiaryPartyDetails>
        </EpiPartyDetails>
        <EpiPaymentInstructionDetails>
            <EpiInstructedAmount AmountCurrencyIdentifier=" xxx "> 00,00 </EpiInstructedAmount>
            <EpiCharge ChargeOption=" BEN " />
            <EpiDateOptionDate Format=" CCYYMMDD "> 00000000 </EpiDateOptionDate>
        </EpiPaymentInstructionDetails>
    </EpiDetails>
</Finvoice>   
  

Yllä olevassa esimerkkissä lasku ei sisällä käytännössä mitään lainsäädännön tai käytännön edellyttämistä tiedoista. Muutamia tietoja on asetettu rakennuskuvauksessa pakollisiksi, mutta nekin voivat sisältää täysin virheellisiä, puutteellisia ja ristiriitaisia tietoja.

Mistä ongelma johtuu?

Rakennekuvauksen (W3C XML Schema) tehtävänä on kuvata XML-sanoman sallittu rakenne. Sen ilmaisuvoima ei riitä laskennallisten muotovaatimusten (IBAN, BIC, y-tunnus, OVT, maksuviite) eikä eheysvaatimusten (summat, päivämäärien suhde toisiinsa, muut ehdollisuudet) kuvaamiseen.

Lisäksi samalla rakennekuvauksella pyritään usein kattamaan useita sanomatyyppejä (kauppalasku, hyvityslasku, tilaus, etc.), toimialatarpeita ja käyttötapauksia. Tällöin yleensä päädytään siihen, että skeeman mukaan lähes kaikki tiedot ovat vapaaehtoisia, koska aina löytyy tapaus, jossa tiettyä tietoa ei voida asettaa pakolliseksi. Tällöin skeeman rooliksi jää vain "pelikentän" rajaaminen ja pelin säännöt tulee kuvata sekä tarkistaa muulla tavoin.

Miten ongelma ratkaistaan?

Ehdolliset pakollisuudet, monimutkaiset muotovaatimukset ja erilaiset eheysvaatimukset voidaan kattaa sääntötarkistuksilla.

Truugon perusideana on tarjota palvelu, jossa käyttäjät voivat laatia ja julkaista testausprofiileja, jotka kattavat sekä skeemavalidoinnin että sääntötarkistukset. Loppukäyttäjän (testaajan) ei tarvitse kuin ladata sanoma palveluun saadakseen välittömästi kattavan ja selkokielisen palautteen.

Mikseivät organisaatiot ole aiemmin tarjonneet testauspalvelua kumppaneilleen?

Oman testauspalvelun rakentaminen on harvoin järkevää, koska palvelun kehittäminen ja ylläpito nielisivät säästetyt resurssit. Truugon ajatuksena on tarjota testauspalvelualusta, jolloin organisaatioiden vastuulle jää vain testausprofiilien kehitys.

Tanskan ja Ruotsin julkishallinnossa sanomarajapintojen käyttöönottojen tehostaminen aloitettiin sääntötarkistukset kattavien testauspalveluiden avulla jo vuosikymmen sitten. Suomessa sähköistäminen lähti aikanaan vauhdilla liikkeelle, mutta sittemmin toimintatavat eivät ole juuri kehittyneet ja olemme pudonneet edelläkävijästä perässähiihtäjäksi. Nykyaikaiset tehokkuuteen ja asiakaspalvelun laatuun panostavat organisaatiot ovat ymmärtäneet yskän ja vihdoin laajempaakin kansallista heräämistä on tapahtumassa.

Miten saan palvelun käyttööni?

Aloituskynnys voisi tuskin olla enää matalampi, sillä peruspalvelu on maksuton! Rekisteröidy ja tutustu palveluun sitoumuksetta. Lisäominaisuudetkin saat käyttöösi muutamalla kympillä kuukaudessa.

Olemme luoneet palveluun myös muutamia demoprofiileja, joiden avulla voit tutustua palvelun toimintaan tarkemmalla tasolla.

Helpointa on ottaa Truugo aluksi omaksi työkaluksi. Kun olet vakuuttunut palvelun hyödyistä, on Truugo vaivatta laajennettavissa oman tiimin apuvälineeksi ja/tai itsepalveluksi kumppaneille.

Rekisteröidy palveluun » luo testausryhmä ja toteuta testausprofiili » kutsu asianosaiset testaamaan