La logique appliquée par Yuki
Si une note de crédit d'achat vous parvient comme facture d'achat, la cause se trouve dans le XML de la e-facture et non dans un paramètre de Yuki. Yuki détermine le type de document à partir de deux éléments combinés :
- le type de document transmis par l'expéditeur,
- et le signe du montant.
Ces deux éléments sont combinés entre eux comme une multiplication.
| Type de document dans le XML | Signe du montant | Ce que Yuki en fait | |
| <cbc: Credittypecode> 381 </cbc:Credittypecode> | Note de crédit | - | facture d'achat (moins fois moins égal plus) |
| <cbc: Credittypecode> 381 </cbc:Credittypecode> | Note de crédit | + | note de crédit (moins fois plus égal moins) |
| <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> | Facture d'achat | - | note de crédit (plus fois moins égal moins) |
| <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> | Facture d'achat | + | facture d'achat (plus fois plus égal plus) |
Yuki ne déroge pas à cette logique et il n'existe aucun paramètre dans le domaine permettant de désactiver ceci par fournisseur.
Ce que vous faites maintenant
Corrigez manuellement l'écriture dans le document qui se trouve dans le workflow.
Comment l'éviter
Contactez l'expéditeur ou la plateforme de facturation avec laquelle il travaille. Demandez-lui de désormais fournir les notes de crédit avec des montants positifs dans le XML, sous le type de document note de crédit. C'est la seule façon de recevoir structurellement ces documents de manière correcte.