Issues concerning xml validation & chorus pro

94 views
Skip to first unread message

David Vera

unread,
Jan 2, 2023, 10:01:31 AM1/2/23
to ZUGFeRD
As promised, I submit some of the problems I met using Mustang for creating Minimum Facturx. Some of them may be issues. Other may need from my part to find out the right "setup".
I created a git repository where I implement a Basic Fx based on your code. 
Here is the link to the repository: 

   https://github.com/dveraDsi/facturx-demo

I tried to create a xml based on the xml provided in the Factur-X 1.0.06 norm I retrieved here: 


For checking validity of the facturx generated, I use the following URL: 



1. For Chrorus pro, credit note must be 380: 
In code the default value is set to 381. I didn't try to send it to Chorus Pro. Here is your implementation in Invoice class.

    public Invoice setCreditNote() {
        this.documentCode = "381";
        return this;
    }

based on official facturx documentation, I should be able to set different values. The types of documents used are:
  •  380: Commercial Invoice
  • 381: Credit note
  • 384: Corrected invoice
  • 389: Self-billied invoice (created by the buyer on behalf of the supplier)
  • 261: Self billed credit note (not accepted by CHORUSPRO)
  • 386: Prepayment invoice
  • 751: Invoice information for accounting purposes (not accepted by CHORUSPRO)
2. I have gross price that is appearing in my XML while I didn't set it :
This should be optional I guess.
    <ram:SpecifiedLineTradeAgreement>
        <ram:GrossPriceProductTradePrice>
            <ram:ChargeAmount>4.1000</ram:ChargeAmount>
            <ram:BasisQuantity unitCode="C62">1.0000</ram:BasisQuantity>
        </ram:GrossPriceProductTradePrice>
    </ram:SpecifiedLineTradeAgreement>

3. We can't override line total amount: 
For example, calculated value should be 82.00 but there's a reduction on price. 
Overriding line total amount is not working. I tried to set the value with : 

     .setLineTotalAmount(new BigDecimal("81.90"))   

I also tried to do this in Item object. Without success.

4. Payment type code should be modified: 58 is not valid for Chorus
58 can not be used for Chorus, we should set it to 30 -> BT-81

In particular, the following codes can be used:
  • 10: Species
  • 20: Check
  • 30: Transfer (includes SEPA transfer for CHORUSPRO) 
  • 42: Payment on bank account
  • 48: Payment by credit card
  • 49: Direct debit (includes SEPA Direct Debit for CHORUSPRO)
  • 57 : Standing Agreement
  • 58: SEPA transfer (not used for CHORUSPRO: code 30)
  • 59: SEPA Direct Debit (not used for CHORUSPRO: code 49)
  • 97: Report
  • ZZZ: agreed amoung trading partners on interim basis 
5. Bank Information issue: 
In bank Id, we should be able to provide IBAN without BIC
I used : 
    .addBankDetails(new BankDetails(ownIBAN, ownBIC))

It generates: 
        <ram:PayeePartyCreditorFinancialAccount>
          <ram:IBANID>FR2012421242124212421242124</ram:IBANID>
        </ram:PayeePartyCreditorFinancialAccount>
        <ram:PayeeSpecifiedCreditorFinancialInstitution>
          <ram:BICID>COBADEFFXXX</ram:BICID>
        </ram:PayeeSpecifiedCreditorFinancialInstitution>

6. Total Prepaid amount
We can't set total prepaid amount. 

   /**
    * get the TotalPrepaidAmount located in
    * SpecifiedTradeSettlementMonetarySummation (v1) or
    * SpecifiedTradeSettlementHeaderMonetarySummation (v2)
    *
    * @return the total sum (incl. VAT) of prepayments, i.e. the difference between
    * GrandTotalAmount and DuePayableAmount
    */
   default BigDecimal getTotalPrepaidAmount() {
       return BigDecimal.ZERO;
   }

7. XML Schema invalid: 
> The Factur-x XML file is not valid against the official XML Schema Definition. Here is the error, which may give you an idea on the cause of the problem: Element '{urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100}Description': This element is not expected., line 26.
When I create a product, description property is added: 

      <ram:SpecifiedTradeProduct>
        <ram:Name>Huile d'olive à l'ancienne</ram:Name>
        <ram:Description/>
      </ram:SpecifiedTradeProduct>


4. For a product, I can't add global ID:  SOLVED...
I was expecting this output: 
    <ram:GlobalID schemeID="0160">3518370200090</ram:GlobalID>
    <ram:Name>Biscuits aux raisins 300g</ram:Name>

I didn't use the product constructor. Instead I used the builder: 

    product = new Product()
          .setName("Nougat de l'Abbaye 250g")
          .addGlobalID(new SchemedID("0160", "3518370400049"))
          .setUnit("C62")
          .setVATPercent(new BigDecimal(20));

    item = new Item()
          .setProduct(product)
          .setPrice( new BigDecimal("4.10"))
          .setQuantity(new BigDecimal(20))
          .setLineTotalAmount(new BigDecimal("81.90"));
    items.add(item);


Best regards
David Vera


David Vera

unread,
Jan 2, 2023, 11:20:10 AM1/2/23
to ZUGFeRD
I fixed how to set value to 380, but the API requires now 2 elements that are not required in Minimum profile: 
In the invoice objet I can set : 

    .setDocumentCode("380")
    // required for 380 but requires delivery date !! ERROR
    .setDueDate(format.parse("13/12/2017"))
   .setDeliveryDate(format.parse("13/12/2017")) // should not be required

jochen...@gmail.com

unread,
Jan 9, 2023, 4:48:53 AM1/9/23
to ZUGFeRD
Hi,


>1. For Chrorus pro, credit note must be 380:
>In code the default value is set to 381. I didn't try to send it to Chorus Pro. Here is your implementation in Invoice class.

>based on official facturx documentation, I should be able to set different values.
The Factur-X documentation covers the standard (whose XML is based on the MUG, i.e. the european subset of UN/CEFACT CII), Mustang is just the implementation. The assumption that the implementation convers 100% of the standard is interesting, but not neccessarily correct.

If you need 380, which is the default, just don't use the setCreditMemo() function.
Mustang currently supports commercial invoice, credit note, corrected invoice (including it's additional business logic,
i.e. a corrected invoice usually requires negative quantities leading to negative line items?),
and, due to very interesting special requirements, construction invoice, which was added to the codelist in May I believe.
Which additional types do you need and why?

>2. I have gross price that is appearing in my XML while I didn't set it :
Fundamentally yes, does it hurt? Please note that the definition of gross price in UBL and UN/CEFACT
does not relate to VAT but is more of a "list price" from which customer specific prices are deduced (which then can get further allowances).


>3. We can't override line total amount:
>For example, calculated value should be 82.00 but there's a reduction on price.

that would work by adding an allowance, please have a look at https://www.mustangproject.org/invoice-class/#charges .
The reason why this may even be easier than just setting a reduced price is
a) it matches the calculation rules laid down in CEN EN16931-1 (available free of charge, in french that should probably come from AFNOR, probably https://www.boutique.afnor.org/fr-fr/norme/nf-en-169311/facturation-electronique-partie-1-modele-semantique-de-donnees-des-elements/fa060924/1684 ) and
b) it should also allow you to specify that a certain tax rate and it's amount is affected.

Your #4-#7: Interesting, I'll have a deeper look at them and reply later (probably still this week).

kind regards
Jochen

jochen...@gmail.com

unread,
Jan 12, 2023, 9:12:30 AM1/12/23
to ZUGFeRD
Hello,


>4. Payment type code should be modified: 58 is not valid for Chorus
>58 can not be used for Chorus, we should set it to 30 -> BT-81
Interesting question if and why 59 should not be possible but I doubt anybody needs specifically 59 and 30 does look more generic so I changed that.
 
>5. Bank Information issue: 
>In bank Id, we should be able to provide IBAN without BIC
Now possible in the development version.

>6. Total Prepaid amount
>We can't set total prepaid amount. 
Now possible in the current development version.

>7. XML Schema invalid: 
>> The Factur-x XML file is not valid against the official XML Schema Definition. Here is the error, which may give you an idea on the cause of the problem: Element '

Could you please attach the whole file and indicate how it was created?

You might have noticed that some automated tests like validator\src\test\java\org\mustangproject\validator\LibraryTest.java:testMinimumProfileValidity run the validator on the library output. And by it's architecture the validator should indeed check against the Minimum schema (and schematron) files. Which may actually be a difference to the FNFE validator.

thanks and kind regards,
Jochen

jochen...@gmail.com

unread,
Feb 13, 2023, 4:16:10 PM2/13/23
to ZUGFeRD
Hello,
today I published Mustang 2.6.1 with the changes except #7 (as mentioned I currently cant reproduce that) and #4.
As regards your #4 I upstreamed the issue on Friday to the joint AWV/FNFE technical meeting as in the german ZUGFeRD samples we use 58/59, I asked if I could change this to 30, as this could be more international. But it turned out the FNFE plans to or already does allow 58/59 which may under certain circumstances even be beneficial. So there was consensus to keep the official german samples as they are, and I reverted the according changes in Mustang.

kind regards
Jochen

Reply all
Reply to author
Forward
0 new messages