Verdergaan naar hoofdinhoud

Commissie SALES standaard

Zoeken
Sales Commissie
Vastgoed Commissie
  
Commissie SALES standaard > Discussie > Betere afhandeling debetfacturen en creditfacturen  

Discussie: Betere afhandeling debetfacturen en creditfacturen

De inhoud van dit item wordt als e-mailbericht verzonden aan de persoon of groep die aan het item is toegewezen.
VersiegeschiedenisVersiegeschiedenis

Titel

Betere afhandeling debetfacturen en creditfacturen 

Soort verzoek

Wijziging huidige functionaliteit 

Prioriteit

2) Should 

Releasenummer

INSBOU 005 

Hoofdtekst discussie

Tijden implementaties, maar ook tijdens het ontwikkelen van software ontstaan er veel discussies over hoe creditnota's te implementeren. De codes 380 en 384 zijn te verblijvend omschreven en bieden geen goede aansluiting bij financiƫle administraties. Alleen op -bedragen sturen is te summier. In het ergste geval heb je een nota met zowel - als + bedragen. Het eindgetal biedt dan alleen soelaas, maar hoe dan te importeren? Ook daar zijn geen gebruiksregels voor opgesteld (bijvoorbeeld + en - nooit door elkaar gebruiken).

RFC tekst

380 zou Debetnota/factuur zijn (inclusief debetcorrecties) immers debetcorrecties blijven gewoon facturen 384 zou Creditnota/factuur moeten zijn voor alle negatieve nota's. Het uitprogrammeren binnen financiƫle software wordt anders te lastig en er is geen goede herkenning van een creditnota.

Antwoorden

Luuk d'HoogheGeen aanwezigheidsgegevens (27-2-2018 10:47): Gedeeltelijk toekennen. Besproken tijdens de vergadering van 6 feb. HW: in de praktijk geen problemen, er is wel verwarring m.b.t. 384 als correctiefactuur. Anderen hebben ook weinig problemen met de huidige werkwijze. JM: de correctiefactuur heeft altijd betrekking op prijswijzigingen, er zijn geen goederenbeweging. Conclusie: de 380 voor zowel debet als credit facturen gebruiken en 384 voor feitelijke correcties (dus een"nog" niet betaalde factuur), betreft bijvoorbeeld mutatie van dagprijzen. De definities worden verduidelijkt in de gebruikersregels en de functionele attributenlijst. Er ontstaat verwarring omdat een credit ook wordt gezien als een correctie. Het veld verruimen in de definitie, ook voor het refereren aan een credit bij 380. Doorzetten naar IC Wijzigingverzoeken [SALES Cie 06-02-2018]
Luuk d'HoogheGeen aanwezigheidsgegevens (19-12-2017 16:21): [SALES 21-11-17] Lopend, Cie-leden checken intern de huidige werkwijze. Wie kan er wel met een - en + omgaan? Waar gaat het mis? Wel is al geconstateerd dat de documentatie moet worden aangepast. Deze is nu niet eenduidig (genoeg). Bv mogen er - en + bedragen op verschillende regels staan of wanneer is het betaald / niet betaald.
Peter van de SandeGeen aanwezigheidsgegevens (13-11-2017 16:10): Eens met Hans, Zo gebruiken wij het ook al heel lang.
Westerkamp, JanGeen aanwezigheidsgegevens (21-9-2017 15:45): Eens met Hans, zo werken andere sectoren die GS1 bedient al jaren zonder problemen.
Hans HilkerGeen aanwezigheidsgegevens (19-9-2017 8:59): Eens met Hans Walrave. Het gaat bij 380/384 niet om het teken, maar om het feit dat er een correctie wordt uitgevoerd op een eerdere factuur (incl. een verplichte verwijzing naar die factuur). Dit ook bij ons al ruim 20 jaar naar behoren.
Hans WalraveGeen aanwezigheidsgegevens (18-9-2017 16:14): 384 is een correctie-factuur. 384 Corrected invoice. Commercial invoice that includes revised information differing from an earlier submission of the same invoice. Dat is iets anders dan een credit-factuur. die heeft code 381, met het eindbedrag positief, of code 380 met het eindbedrag negatief. Dat werkt op die manier al heel lang goed binnen EDI en UBL, dus niet direct waarom er iets aangepast moet worden.

Compatibiliteit

Niet bekend 

Verwante discussies

 

Van toepassing op

 

Wijzigingverzoek

 

Status van discussie

Gesloten 

Toegewezen aan

CCS 
Bijlagen
Versie: 7.0 
Gemaakt om 12-9-2017 12:21  door Luuk d'Hooghe 
Laatst gewijzigd op 27-2-2018 10:47  door Luuk d'Hooghe