What is best way to Choose Validation Rules for Incoming Invoice

[duke-nuke]

At start we were handling Invoice related to One country but as we are expanding we now are receiving invoices from different Countries
i was thinking what is best way to choose the Validation Rule for incoming invoice ?
do we pick based on DocumentTypeId and ProcessId
or incoming schemeId

Regards

[phax]

Usually I recommending to use ddd for this. It can auto-detect certain elements from a source file, including the VESID. Alternatively, you can also make a list based on the combination od document type ID and process ID.

My proposal is:

• on the sending side, use a mapping based on Document Type ID and Process ID
• on the received side use "ddd" as you need to read the full document anyway

[phax]

Usually you have a IValidationExecutorSetRegistry <IValidationSourceXML> vesRegistry object where you register all the rules that you support.
Via vesRegistry.getOfID (aVESID); you can check if the you support the VESID Or not.
Generally in Peppol you define what you receive and register these document types in the SMP. Therefore you should be well aware, what document types you are expecting -> make sure they are registred in the vesRegistry upfront. If you receive a document that you don't didn't register at the SMP, you can reject the message as "not serviced".

[lukasrosenke]

Hey Philip,

first of all, thank you for your libraries - they are very helpful.

I added ddd to my access point setup in order to determine the VES-ID (to ultimately retrieve a IValidationExecutorSet from IValidationExecutorSetRegistry).

I want to decode the received documents in the function

public void handleIncomingSBD (
   @Nonnull final IAS4IncomingMessageMetadata aMessageMetadata,
   @Nonnull final HttpHeaderMap aHeaders,
   @Nonnull final Ebms3UserMessage aUserMessage,
   @Nonnull final byte [] aSBDBytes,
   @Nonnull final StandardBusinessDocument aSBD,
   @Nonnull final PeppolSBDHData aPeppolSBD,
   @Nonnull final IAS4IncomingMessageState aIncomingState,
   @Nonnull final ICommonsList <Ebms3Error> aProcessingErrorMessages
)

This requires a @Nonnull final Element aRootElement to be passed into findDocumentDetails (...);. I do not understand what this element is or how to construct it most efficently - any help is appreciated.

[phax]

@lukasrosenke well, that is easy to answer: basically you need to extract the actual payload from the PeppolSBDHData: aPeppolSBD.getBusinessMessage () - this is the "actual payload" that you need to pass into validation.

[lukasrosenke]

Thank you. I hope this is not out of context but I have one more question as I am a little confused about the validation setup included in the phase4-peppol-standalone.

In the repository you wrote: "Document validation is not included" and thus one must include phive-xml and and one library with rule sets. However I found this class Phase4PeppolValidation, which automatically validates documents before they are sent, and defines a default private static final IValidationExecutorSetRegistry <IValidationSourceXML> VES_REGISTRY = createDefaultRegistry ();.
Can I use the VES_REGISTRY to validate received documents too and what do I have to pass into ValidationSourceXML.create (..., ...)?

This is my current setup:

public void handleIncomingSBD (@Nonnull final IAS4IncomingMessageMetadata aMessageMetadata,
                                 @Nonnull final HttpHeaderMap aHeaders,
                                 @Nonnull final Ebms3UserMessage aUserMessage,
                                 @Nonnull final byte [] aSBDBytes,
                                 @Nonnull final StandardBusinessDocument aSBD,
                                 @Nonnull final PeppolSBDHData aPeppolSBD,
                                 @Nonnull final IAS4IncomingMessageState aIncomingState,
                                 @Nonnull final ICommonsList <Ebms3Error> aProcessingErrorMessages) throws Exception
  {
    // In case there is an error, throw any Exception -> will lead to an AS4
    // Error to the sender

    final String sMyPeppolSeatID = APConfig.getMyPeppolSeatID ();

    // Decode SBD with DDD Library
    final DocumentDetailsDeterminator aDDD = new DocumentDetailsDeterminator (
      DDDSyntaxList.getDefaultSyntaxList (), 
      DDDValueProviderList.getDefaultValueProviderList ()
    );
    
    final DocumentDetails aDD = aDDD.findDocumentDetails (aPeppolSBD.getBusinessMessage ());

    if (aDD == null) {
      // TODO: Throw Error
    }

    // Validate SBD here
    final IValidationExecutorSetRegistry <IValidationSourceXML> aVESRegistry = Phase4PeppolValidation.getDefaultRegistry();
    final IValidationExecutorSet <IValidationSourceXML> aVES = aVESRegistry.getOfID(DVRCoordinate.parseOrThrow(aDD.getVESID()));

    final IValidationSourceXML aValidationSource = ValidationSourceXML.create (..., ...);

    final ValidationResultList aValidationResult = ValidationExecutionManager.executeValidation (
      IValidityDeterminator.createDefault (),
      aVES,
      aValidationSource
    );

    if (aValidationResult.containsNoError()) {
      // TODO: Continue with received and validated data
    } else {
      // TODO: Throw Error
    }
 }

Many thanks in advance!

[phax]

Well, it is a little bit out of place but hey - it's a discussion forum so all cool :)

The statement "Validation is not included" is maybe a bit vague, but that's on purpose. Only the EN 16931 and the Peppol rules are included - other rules for other document types are not available out of the box. Basically I want people to dig into this topic and not take it for granted.

Here are some remarks on your code from a conceptual point of view:

• In Peppol, the sender is mandated to only send valid documents. So in 99% of the cases, the data is correct.
• Doing validation on the receiving side, and rejecting messages based on your additional validation requires a good confidence. It may have legal obligations and requires good certainty.
• Please bare in mind, that Peppol has certain SLAs to be fulfilled - the response time is one of them
• DDD does not support all document types. Please make sure that all document types you want to accept are supported by DDD.
• In the future, when MLS (Message Level Status) is available, you should switch to asynchronous validation, as MLS can be sent asynchronously

And here are some remarks on the technical side:

• The first validation using a specific rule set usually takes more time than any subsequent calls - so try to avoid the service to get cold
• The validation of large messages (>25MB) may take forever - please test this locally (we're talking minutes, not just seconds)
• The duration of validation depends on the document type used and the Schematron rule implementation

So I don't want to stop you from doing what you are doing, but I want you to think it through :)

hth, Philip