De logica die Yuki hanteert
Komt een aankoop creditnota bij je binnen als aankoopfactuur, dan zit de oorzaak in de XML van de e-factuur en niet in een instelling in Yuki. Yuki bepaalt het documenttype uit twee gegevens samen:
- Het documenttype dat de verzender meegeeft,
- en het teken van het bedrag.
Die twee worden met elkaar gecombineerd als een vermenigvuldiging.
| Documenttype in de XML | Teken van het bedrag | Yuki maakt hiervan | |
| <cbc: Credittypecode> 381 </cbc:Credittypecode> | Creditnota | - | aankoopfactuur (min maal min is plus) |
| <cbc: Credittypecode> 381 </cbc:Credittypecode> | Creditnota | + | creditnota (min maal plus is min) |
| <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> | Aankoopfactuur | - | creditnota (plus maal min is min) |
| <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> | Aankoopfactuur | + | aankoopfactuur (plus maal plus is plus) |
Yuki wijkt niet van deze logica af en er is geen instelling in het domein waarmee je dit per leverancier uitzet.
Wat je nu doet
Zet de boeking handmatig recht in het document dat in de workflow staat.
Hoe je het voorkomt
Neem contact op met de verzendende partij of met het facturatieplatform waarmee zij werken. Vraag hen om creditnota's voortaan met positieve bedragen in de XML aan te leveren bij documenttype creditnota. Dat is de enige manier om deze documenten structureel correct te ontvangen.