Italië - Debetfaktuur vermelden bij Creditnota in XML aangifte

[Heart Informatisering B.V.]

Middels Hmenu-8-5-4-5-5 kan in Italië een XML rapportage worden gegenereerd met Fakturen geleverd aan Overheidsinstellingen.

Vanaf 1 april 2015 zouden Overheidsinstellingen geen papieren Faktuur meer mogen ontvangen, en dient de Faktuur in een speciaal XML formaat te worden gegenereerd. Hoewel deze funktionaliteit geïntergreerd zou kunnen worden met de Faktuurrun, geldt dat er destijds voor gekozen is deze XML als aparte exportfunktie op te zetten. Voor de klant goedkoper, en er zal sowieso iemand moeten ingrijpen om de gegenereerde XML documenten 'te versturen' naar de betreffende Overheidsinstelling.

Hoewel eerdere berichten aangaven dat Creditorders nooit aan de orde waren bij Overheidsinstelling (ons inziens onzin, want als iedereen Credit's kan hebben waarom een Overheidinstelling dan niet), blijkt dat dit nu inderdaad wel moet kunnen. En direkt komt de volgende problematiek al om de hoek kijken: het is verplicht om de Debetfaktuur en diens Faktuurdatum te vermelden in de XMl bij e.d. Creditering.

Binnen Profit bestaat de mogelijkheid om 1 Faktuur voor 100% tegen te boeken, in welk geval de Creditnota altijd 1:1 met een bijbehorende Debetfaktuur is. Toch maakt Italië gewoon "Credit Verkooporders", en is ze "vrij" om te crediteren wat ze wil.

V.w.b. een Overheidsinstelling geldt dat deze vrijheid ineens een stuk minder is, immers, als 1:1 met de Creditnota de Debetfaktuur vermeldt moet worden, geldt dus ook dat we op 1 Creditorder nooit meerdere Debetorders mogen Crediteren (immers, iedere Debetnota is ook weer 1:1 met een Verkooporder). En, gekonstateerd in de database van de klant, dit wordt nu gebruikt (maar wordt als fout betiteld).

Ook geldt dat het voor Profit niet meer dan logisch is dat we 1 bestelling van 100 blikken in 2 etappes kunnen uitleveren; vandaag leveren er er 80 en volgende week sturen we de overige 20. Omdat er twee levermomenten zijn (op 1 Verkooporder) volgen er ook twee Fakturen (wat er bij ons weer 1 mag zijn als leveringen mogen worden samengevoegd op 1 Faktuur, maar ook dat is niet toegestaan in Italië). Resumer, waar het voor de hand liggend is dat we 80+20 leveren en 2 Fakturen hebben, geldt dat we ineens bij een Creditorder zouden moeten aangeven dat als er 10 retour komen, of dit er 10 uit de levering van 80 zijn, danwel 10 uit de levering van 20; beide leiden nl. tot een ander Faktuurnummer, en bij de creditering moeten we het juiste Faktuurnummer vermelden.

Een leuk verzinsel weer, maar de praktische invulling is minder; al was het maar omdat het allerlei zaken die in praktijk aan de orde kunnen zijn, en in Profit ondervangen zijn, uitsluit.

De aanpassingen in deze Releasenote zullen zich derhalve expliciet beperken tot het genereren van de XML aangifte. Alhier geldt dat er kontroles worden uitgevoerd die stellen dat een bepaalde Creditorder niet in de XML kan worden opgenomen, omdat ze bijv. 2 Debetorders crediteert. In dat geval zal de gebruiker de Faktuur moeten laten vervallen, en de Creditorder moeten opsplitsen (als daar al funktionaliteit voor aanwezig is; volgens de klant is dit geen probleem). En, omdat papieren Fakturen verboden zijn voor Overheidsinstellingen, geldt dat alles gekorrigeerd kan worden tot het moment dat de Faktuur in de XML eruit komt, immers, dat is de enige wijze waarop de Overheidsinstelling de Faktuur krijgt.