Wat is de beste manier om pure tekstregels van een factuur toch op te nemen in de UBL syntax?

A) Via <cbc:Note>
of
B) Via een standaard InvoiceLine met waarde 0.00


Wat moet er juist komen bij de volgende elementen van <cac:InvoiceLine>
<cbc:InvoicedQuantity> xx.xx </cbc...>
en
<cac:Price>
<cbc:BaseQuantity> xx.xx </cbc...>

Ik vul in beiden de Hoeveelheid van de lijn in bv 1.50, maar als ik dit dan vergelijk met de XML code die wordt gegenereerd door het boekhoudpakket maakt deze er '1' van, terwijl de factuur zelf spreekt op '1.50' of '2'

Puur op logica zou ik zeggen bij InvoicedQuantity '1.50' (De werkelijk aantallen) en bij BaseQuantity '1.00 (De basis waarop het verkochte aantal is gebaseerd)

Hallo,

Nieuw op deze Community.
Ben voor ons kantoor een UNIT aan het schrijven (in pascal) voor het aanmaken van E-FFF facturen . Het UBL en in uitbreiding de Peppol E-FFF syntax is redelijk goed gedocumenteerd, maar in sommige opzichten wel verwarrend.

Ik zal waarschijnlijk regelmatig gebruik maken van jullie expertise, maar de kennis die ik hieromtrent opdoe ook met plezier delen.

mvg,
Bart

PS: Toevallig niemand aanwezig zijn die kennis heeft over het gebruik van Unit4 Venice SDK & Delphi (of pascal). Ik zoek daar ook nog wat hulp omtrent.

Heeft er hier iemand ervaring met UBL en grootboekrekeningen? Onze software maakt facturen aan in UBL om dan in te lezen in Expert M Plus (= boekhoudpakket) en we proberen ook de grootboekrekeningen mee te geven per InvoiceLine.

Via de tag <AccountingCostCode>710000</AccountingCostCode> werkt het alvast niet. Is daar een goede manier voor?

Post has attachment
De BTW verlegd heeft nog niet veel aandacht bij de UBL facturen. Dit kan worden vastgelegd in de paragraaf TaxCategory het veld cbc:ID schemeAgencyID="6" schemeID="UNCL5305">AE</cbc:ID>

De vraag is nu wat is het verschil tussen de waarde "B" en "AE"?

Er is een redelijk aantal facturen die wij ontvangen in UBL (voor onze klanten) die fouten bevatten. Wij proberen hierop te anticiperen en deze toch te verwerken. De afrondingen is 1 van de problemen. Die kunnen ontstaan doordat de BTW per regel berekend afwijkt van de BTW berekening over het totaal. Hoe zou je met de ontvangen facturen met afrondingsproblemen moeten omgaan?

Mijn zorg zou wel zijn dat als ik met het veld PayableRoundingAmount
bij uitgaande facturen er geen ontvanger is die hier raad mee weet.

Post has attachment
Eindelijk een goede online documentatie van SImplerInvoicing!

Post has attachment
"Creditnota, Proforma factuur, Afzender zonder BTW-nummer, Facturen aan de (Rijks)overheid met een OIN-nummer, Afwijkende BTW-tarieven, BTW-verlegd, Export, Vrijgesteld van BTW, Margeregling, Betalingskorting, Kredietbeperking, Tarieven inclusief BTW, Urenspecificaties, RGS-code, G-Rekening, Vreemde valuta, Projectfacturen, Detailhandel met inruil, etc."
 
Interesse in deze en andere factuurscenario's en de vertaalslag naar UBL? Kijk dan snel op http://www.ictplaza.nl/brx/5749/1

Post has attachment
Waar leg ik het klantnummer vast bij een Verkoopfactuur die ik verstuur?
Dit wordt vastgelegd in het veld: SupplierAssignedAccountID
"An identifier refering to an account for the Customer assigned by the Supplier"
Let op dus NIET in CustomerAssignedAccountID.
Zie ook http://www.oioubl.info/Classes/en/Invoice.AccountingCustomerParty.html
OIOUBL
OIOUBL
oioubl.info

Het komt regelmatig voor dat de UBL die wordt aangeleverd niet correct is of niet compleets is. Een van de velden die wel eens ontbreekt is het BTW bedrag <cac:TaxAmount>. Yuki verwerkt deze toch en bepaalt zelf het bedrag door het verschil te nemen van Bedrag inclusief BTW en bedrag Exclusief BTW

Post has attachment
Wait while more posts are being loaded