1 / 12

Testing @ WP5 Invoice Instance Testing Sept . 20 th 2010

Oriol Bausà Invinet Sistemes. Testing @ WP5 Invoice Instance Testing Sept . 20 th 2010. Table of Contents. 20th of September, Purpose of testing Validation Process Conclusions of first tests Test an invoice sample. Purpose of testing.

dobry
Download Presentation

Testing @ WP5 Invoice Instance Testing Sept . 20 th 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Oriol Bausà Invinet Sistemes Testing @ WP5Invoice Instance TestingSept. 20th 2010

  2. Table of Contents 20th of September, • Purpose of testing • Validation Process • Conclusions of first tests • Test an invoice sample

  3. Purpose of testing • Align implementations of einvoicing solutions through BII and PEPPOL rules • A syntax common standard such as UBL is not enough • Multiple interpretations • BII and PEPPOL refine syntax standards by defining • A narrow data set for the invoice • A way of using the data elements in the data set • A set of code lists to be used within the data set • Testing has to prove that there is a common understanding when using cross border invoices in Europe

  4. Invoices received • We have received test invoices from: • Norway • Austria • Italy • Sweden • Finland • … and we have been testing them through the validation architecture

  5. Validation artifacts refinement • We have used received invoices to refine validation artifacts and rules: • New rules have been created • Require mandatory elements from the Core • Warn about elements from Full in Core data models • Errors in rules have been corrected • Rounding of calculations • Wrong logical expressions • Match the meaning of the abstract rule with a more appropriate XPATH expression • National rules have been created for Austria and Norway

  6. Validation Process Domestic / New restrictions Cross Border

  7. Validation artifacts The Invoice instance MUST be valid using the Invoice UBL XSD Schema • UBL Invoice XSD Schema • UBL-Invoice-2.0.xsd • CEN BII Schematron rules • BIICORE0001BII04BiiCoreTrdm010ubl.xsl • BIICORE0001BII05BiiCoreTrdm010ubl.xsl • BIICORE0001BII06BiiCoreTrdm010ubl.xsl • PEPPOL Schematron rules • EUGEN0001BiiCoreTrdm010ubl.xsl • National Schematron rules • NONAT0001BiiCoreTrdm010ubl.xsl (Norway legal additional rules) • ATNAT0001BiiCoreTrdm010ubl.xsl (Austria legal additional rules) Depending on the profileID, the Invoice instance MUST not raise any fatal error when validating it using the appropriate BII Schematron XSLT. Warnings are allowed Invoice instance MUST not raise any fatal error when validating it using PEPPOL Schematron XSLT. Warnings are allowed Domestic invoices MUST not raise any fatal error when validating it using appropriate Country specific Schematron XSLT. Warnings are allowed

  8. Validation artifacts

  9. Findings on first test samples • All instances follow UBL Schema • There is no common understanding on BII and PEPPOL restrictions: • Non use of mandatory CORE data elements • Use of non CORE data elements • Misunderstandings on calculations • Stressing the model to add relevant information as pairs code-value (additional document reference or note)

  10. Tools to detect these issues • Non use of mandatory CORE data elements • Create new rules in EUGEN to fail if there are missing mandatory elements. • Use of non CORE data elements • Create a warning rule in EUGEN to raise when elementos other from the CORE are used • Create a strip XSLT to create a conformant BII core data model • Misunderstandings on calculations • Calculate based on visualization style-sheet • Stress the model to add relevant information as pairs code-value (additional document reference or note) • Just explanation that this is prevents interoperability

  11. Austria Sample Invoice • Invoice XSD ✔ • BII 04 Profile Rules ✔ • PEPPOL Rules ✗ • ERROR:[PEP-T10-017]-A conformant CEN BII invoice core data model MUST have a customization identifier. • ERROR:[PEP-T10-018]-A conformant CEN BII invoice core data model MUST have a profile identifier. • ERROR:[PEP-T10-014]-For each tax subcategory the category ID and the applicable VAT tax percentage MUST be provided. • ERROR:[PEP-T10-034]-Every tax category in CEN BII MUST be defined through an identifier. • Warning:[PEP-T10-003]-Each invoice line MUST contain the quantity and unit of measure • National AT Rules ✗

  12. Finland sample • EUGEN0001 BiiCoreTrdm010 bound to UBL • Testing Rules from ubl-BiiCoreTrdm010 • ERROR:[PEP-T10-009]-If the VAT total amount in an invoice is not zero it must contain the suppliers VAT number. • Warning:[PEP-T10-001]-A supplier postal address in an invoice SHOULD contain at least, Street name and number, city name, zip code and country code. • ERROR:[PEP-T10-025]-Country in an address MUST be specified using the country code. • Warning:[PEP-T10-002]-A customer postal address in an invoice SHOULD contain at least, Street name and number, city name, zip code and country code. • ERROR:[PEP-T10-025]-Country in an address MUST be specified using the country code. • Warning:[PEP-T10-005]-A Delivery address in an SHOULD contain at least, city, zip code and country code. • ERROR:[PEP-T10-025]-Country in an address MUST be specified using the country code. • Testing Rules from CodesBiiCoreTrdm010

More Related