Loading…
Tilbage

Profilbillede

Særlig valideringsregel for OIOUBL CreditNote konverteret fra PEPPOL BIS3

Kasper Grøndahl Christensen

Jeg faldt lidt tilfældigt over valideringsregel F-LIB375 for CreditNote:

    <!--RULE -->
<xsl:template match="doc:CreditNote/cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount" priority="3996" mode="M37">

        <!--ASSERT -->
<xsl:choose>
<xsl:when test="not(starts-with(.,'-')) or (/*/cac:AdditionalDocumentReference/cbc:DocumentTypeCode[@listAgencyName = 'ERST'] = 'PEPPOLBIS32OIOUBL')" />
<xsl:otherwise>
<Error>
<xsl:attribute name="context"><xsl:value-of select="concat(name(parent::*),'/',name())" /></xsl:attribute>
<Pattern>not(starts-with(.,'-')) or (/*/cac:AdditionalDocumentReference/cbc:DocumentTypeCode[@listAgencyName = 'ERST'] = 'PEPPOLBIS32OIOUBL')</Pattern>
<Description>[F-LIB375] Invalid <xsl:text />
<xsl:value-of select="name(.)" />
<xsl:text />. Must not be negative, unless it has been converted from PEPPOL BIS3</Description>
<Xpath><xsl:for-each select="ancestor-or-self::*">/<xsl:value-of select="name()" />[<xsl:value-of select="count(preceding-sibling::*[name(.)=name(current())])+1" />]</xsl:for-each>
</Xpath>
</Error>
</xsl:otherwise>
</xsl:choose>

... og nu undrer jeg mig over hvorfor der er særlige regler for dokumenter konverteret fra BIS3, og om det virkelig er hensigtsmæssigt!? Det betyder jo i princippet at ethvert modtagende system må være parat til at håndtere denne undtagelse? Står det beskrevet i OIOUBL specifikationen (og hvor)?

Det kunne også friste svage sjæle til at markere deres dokumenter med denne AdditionalDocumentReference for at få dem igennem valideringen?

I praksis ved jeg ikke om det er et problem (endnu). Men det virker meget mærkeligt. Jeg faldt kun over reglen, fordi et system der prøver at sende gennem os, har leveret en negativ CreditNote som vi afviser, og derfor ser denne fejlmelding, der nævner at der er en særlig regel for BIS3 konverterede dokumenter!?!

Hej Kasper

Tak for din observation som lyder interssant.

Jeg kan imidlertid ikke læse skematronregler godt nok til at forstå dybden af problemet.

Er det muligt at du eller andre kan udlægge teksten i forretnings-begrebsmæssige termer, så "lægmand" og "ikke-latinkyndige" medlemmer af menigheden kan forstå dagens tekst :-). Hvad er det der ikke må være negativt og hvad er det man angiver i AdditionalDocumentreference?

/Klaus

Hej Klaus

Det er CreditNote/LegalMonetaryTotal/TaxInclusiveAmount der ikke må være negativ, medmindre der er en instans AdditionalDocumentReference med en DocumentTypeCode der har listAgencyName="ERST" og værdien "PEPPOLBIS32OIOUBL"

Med andre ord så er det ikke tilladt at have en negativ total inklusive moms/afgifter i en kreditnota (hvilket er logisk og altid har været reglen, som også fremgå af OIOUBL dokumentationen: http://oioubl.info/Classes/da/MonetaryTotal.html). MEN så er der en undtagelse: Hvis dokumentet er markeret som konverteret fra BIS3, så tillader schematronen alligevel at totalen inklusiv moms/afgifter er negativ. Dette kan jeg ikke se er dokumenteret i OIOUBL standarden - og det forekommer mig at være en dårlig situation at sætte modtagerne i. Da de jo så alligevel er nødt til at forholde sig til negative kreditnotaer.

Håber det tydeliggør min undren? :-)

Mvh. Kasper

Hej Dan

Tak for at undersøge og vende tilbage! Det lyder i mine ører helt rigtigt at holde fast i at en kreditnota skal have en positiv total, og så rette schematronen til ved næstkommende lejlighed.

Mvh. Kasper

 Hej Kasper

 Godt spottet ?

 Jeg undersøger om det ligger en forretningsovervejelse bag dette eller om der er tale om en tidligere ”overvejelse” der har sneget sig ind i den officielle valideringen

/Dan

 

 

 

Hej Kasper

Mange tak for den tydelige forklaring. - Og enig, det betyder jo reelt at vi skal potentielt skal kunne håndtere negative OIOUBL kreditnotaer. Og det er i hvertfald ikke status hos os. Så vi har et potentielt problem,hvis det står til troende.

@ Dan - dejligt hvis det er noget du kan opklare.

/Klaus

 

Hej 

Efter at havde undersøgt sagen, kan jeg oplyse, at det ikke er tilladt at have en negativ total inklusive moms/afgifter i en dansk kreditnota.

Der er oprettet et ændring ønske om at få fjernet denne valideringsregel, således der er overensstemmelse mellem validering og krav til kreditnota

/Dan

ændret af Dan H. Overgaard (04.06.2021)

Hej Dan

Tak for din undersøgelse af 4. juni.

/Klaus

Hej Kasper og andre

Baggrunden for i sin tid at implementere reglen var af hensyn til de offentlige myndigheder der vælger at konvertere Peppol til OIOUBL ved modtagelsen.

I forbindelse med, at en negativ Peppol faktura i konverteringen laves til en OIOUBL kreditnota er der behov for at "vende" alle beløbene, således at OIOUBL kreditnotaen får en positiv total. Det betyder samtidig, at eventuelle positive beløb i Peppol fakturaen bliver konverteret til negative beløb, for at beregningerne fortsat holder.

I det scenarie, hvor en Peppol faktura bliver negativ på grund af et forudbetalt beløb (se eksemplet "BIS3_NegativInvoice_Example_PrePayment.xml" i CIUS pakken fra ERST) kan TaxInclusiveAmount i Peppol fakturaen være positiv, og det vil således være nødvendigt at konvertere det til et negativt beløb i OIOUBL Kreditnotaen. 

En negativ TaxInclusiveAmount er således ikke nødvendigvis ensbetydende med en negativ kreditnota, og da der netop er tale om en speciel situation, som kun forventes at opstå i forbindelse med konverteringen fra Peppol, blev det besluttet, at lægge den yderligere kontrol ind, der tjekker for, at der er tale om en konvertering fra Peppol.

Jeg håber, man vil tage ovennævnte scenarie med i betragtning, inden schematronreglen ændres.

Venlig hilsen

Charlotte Skovhus, mySupply

Tak, Charlotte, for din uddybende forklaring - der unægteligt sætter reglen i et andet lys :-)

Lad mig opsummere: Reglen er indført for at håndtere den situation, hvor der er forudbetalt et beløb der er større end den endelige pris der faktureres. Der er derfor behov for at tilbagebetale en del af denne forudbetaling, og der udstedes derfor en kreditnota på det beløb der tilbagebetales. I den kreditnota angives de fakturerede varer med negative beløb (da disse ikke skal tilbagebetales) samt det forudbetalte beløb som et positivt beløb - og totalen af kreditnotaen er dermed positiv. Beløbet inklusive skat (TaxInclusiveAmount) er imidlertid negativt, da der ikke er nogen tilbagelegerede varer eller lignende på kreditnotaen, men der er stadig tale om en kreditnota, da der betales penge tilbage fra leverandør til kunde.

Det lyder som et fuldt legalt (omend måske lidt sjældent) scenarie, som bør kunne dækkes af OIOUBL, uanset om der er konverteret fra PEPPOL eller ej?

Dermed bør OIOUBL dokumentationen vel opdateres til at tillade TaxInclusiveAmount < 0 (det er ikke tilladt i dag jvf. http://oioubl.info/Classes/da/MonetaryTotal.html) og reglen i schematronen skal vel så være generelt gældende?

Jeg synes fortsat det er mærkeligt at have en regel der kun gælder for dokumenter konverteret fra PEPPOL BIS 3 :-)

Alternativet kunne være at tillade negative fakturaer i de tilfælde hvor det er forudbetaling der gør fakturaen negativ. Men det vil nok være noget mere omfattende at implementere, for de systemer der i dag understøtter OIOUBL.

Igen, tak, Charlotte, det er første gang nogen har forklaret mig et scenarie, hvor jeg faktisk kan forstå meningen med en negativ faktura - selvom jeg har spurgt flere steder af flere omgange - men ved forudbetaling giver det egentlig lidt mening.

Jeg skifter hermed standpunkt: Denne regel bør bibeholdes og gøres generel, og OIOUBL standarden/dokumentationen bør opdateres (selvfølgelig under hensyntagen til versioneringsreglerne).

Hvad tænker I andre?

Og så lige til sidst: Det er stadig ikke fordi jeg har set et problem i praksis, jeg undrede mig bare over denne regel, og tænkte det skulle undersøges nærmere :-)

Mvh. Kasper

Hej Charlotte

Tak for uddybningen.

Jeg har lagt det på sagen, så det kan indgå i fremtidige overvejelser om en opdatering/ændring er nødvendig 

/Dan

ændret af Dan H. Overgaard (09.06.2021)