Meest gestelde vragen

  1. Zorg voor een GLN (Global Locatie Code)
  2. Ben in het bezit van SALES Standaard ondersteunende software
  3. Bepaal welke informatie moet worden meegestuurd,
    (denk aan bijv. het bon-nummer of projectnummer)
  4. Genereer een SALES Standaard xml-factuur uit uw pakket
  5. Valideer de factuur of deze voldoet aan de standaard en controleer of de juiste informatie is overgenomen. Wordt er ook een pdf meegestuurd, zorg dan voor dezelfde naamgeving als het xml bestand. (GLN van de verkoper _ factuurnummer . pdf)
  6. Verstuur de xml-factuur naar de afnemer!

De kosten voor deelname gaat naar rato van de omzet. De staffel-tabel vindt u hier

 

Als u locaties wilt identificeren, gebruikt u een Global Location Number (GLN). Hiermee is het mogelijk om fysieke locaties en rechtspersonen uniek en eenduidig te identificeren. Een GLN is een nummer van 13 posities lang, waarmee een bedrijf als unieke partij geïdentificeerd wordt. GLN’s vormen de “sleutel” voor het ophalen van informatie uit databases.

Als u zich inschrijft als deelnemer, en u heeft nog geen GLN, dan kan Ketenstandaard Bouw en Installatie een GLN voor u genereren. Ook kunt u meerdere GLN’s aanvragen (voor meerdere vestigingen bijvoorbeeld). Hier zijn geen extra kosten mee gemoeid.

Dit kan tot 4 cijfers achter de komma. Meer regels voor het gebruik van getallen vindt u in de gebruikersregels (Technische specificaties van de SALES berichten, pagina 8)

In de berekening dient bij alle tussenstappen afgerond te worden op 2 decimalen. Dit geldt ook voor de factuur. Het is de verantwoordelijkheid van de leverancier om te zorgen dat dit klopt. Dit uitgangspunt wordt door alle boekhoudpakketten gehanteerd als extra controle. Zie ook de gebruikersregels (Financiële afhandeling Bouw en Installatiesector Versie 001, pagina 15)

Als u het xml bericht opent, vindt u helemaal bovenaan de karakterset (encoding). Er is afgesproken dat UTF-8 de standaard is. Het gebruiken van een andere encoding, zoals bijvoorbeeld ISO-8859-1, kan voor problemen zorgen.

Uitgangspunt is dat aannemers de bestanden door elkaar moeten kunnen gebruiken. De statuscode bij een artikel moet dan kloppen anders is niet duidelijk welk artikel leverbaar is. De statuscode geeft aan of een product inlopend (125), nieuw / beschikbaar (126), vervallen (130) of uitlopend is (94E). Het komt namelijk regelmatig voor dat een leverancier een product niet meer kan leveren of produceren. Dit wordt met de statuscode weergegeven. Je zou dus alle artikelen met bijv. de status uitlopend moeten kunnen selecteren en in 1x verwijderen.

Hier kunnen meerdere oorzaken voor zijn. Zaken die wij in het verleden zijn tegen gekomen zijn:

  • Op de pdf wordt een kredietpercentage percentage van 2% getoond en in de xml staat 1.99%. Een verschil tussen deze getallen levert dus een andere uitkomst op.
  • Het verkeerd afronden van prijzen in de PDF dan wel de XML kan zorgen voor verschillen.
  • Het totaal van de factuur is niet gelijk aan het totaal van de onderliggende regels in het xml bericht 

Dit element moet gevuld worden met het ‘Totaal factuurkortingen/toeslagen’ dit is de optelling van de factuur kortingen en toeslagen (dus niet van de regelkortingen en toeslagen).

Elementen die in de XSD gedefinieerd zijn met minlength=1 mogen niet leeg worden weergegeven in het schema. Als zo’n veld geen waarde heeft moet deze worden weggelaten.
(Technische specificaties van de SALES berichten, pagina 7)

De verboden tekens, zie de bovenste rij van de tabel, kunt u toepassen door een andere naamgeving of de CDATA notering toe te passen:

Verboden &
Notatie < > & ' "
 

Dit kunt u oplossen met de CDATA notering. De tekens binnen de notering worden nu wel geaccepteerd mits u binnen het maximaal aantal tekens blijft van het betreffende veld.

Hierin geeft u weer tegen welke XSD gevalideerd moet worden. Voor het factuurbericht van de INSbou003 wordt dit dan xsi:noNamespaceSchemaLocation="Factuur_insbou003.xsd".

(Technische specificaties van de SALES berichten, pagina 7)

Het gebruik van verzamelfacturen is niet meer nodig als je alle SALES berichten gebruikt. Sterker nog het is onwenselijk. De software van ontvangers wordt namelijk veel te complex als de automatische match tussen de verschillende orders en de verzamelfactuur moet worden gemaakt. Het heeft ook geen meerwaarde, ook niet voor leveranciers. De technische commissie van de SALES Standaard is onder aanvoering van de leveranciers en softwarehuizen geen voorstander van verzamelfacturen. In de INSBOU004 zit ook geen verzamelfactuur-bericht meer.

Dit moet staan in de “schemalocation”. In de header van het xml-bericht als u dit opent.

(Technische specificaties van de SALES berichten, pagina 7)

Wilt u weten of een bedrijf al lid is van Ketenstandaard Bouw en Installatie? Dan kunt u zoeken via het algemene zoek-venster op de website.

Zoeken in website...

Ja, de digitale communicatie standaard voldoet aan de eisen van het BOMOS model (Beheer en Ontwikkel Model voor Open Standaarden) opgesteld door het forum Open Standaarden. Voor meer informatie: www.forumstandaardisatie.nl

Het Global Trade Identification Number (voorheen EAN-code) bestaat uit 14 cijfers. Dit ligt zo vast in de afspraken van de standaard. Als uw GTIN code uit 13 cijfers of minder bestaat vult u deze op door het toevoegen van een of meerdere nullen. Op deze manier, GTIN: 08714601735406.

(Technische specificaties van de SALES berichten, pagina 9)

Blijf up to date

Laden...