The first immediate aim of this document is to establish a reference framework for the pilots engaged in the implementation of the architecture for the eBIZ-TCF project.

Thus it is worth to clearly define what is expected in terms of ‘conformance’ with the architecture, in general, but more specifically, for the pilots.

The criteria of conformance, that are outlined here, indicate what is expected from pilots and applications that want to follow the architecture.

There are four main types of elements in the architecture (see previous paragraphs):

• the organisational and procedural aspects implementing the business scenarios
• the semantic and data models to exchange information
• the product and party classification and identification
• the middleware and communication protocols.

The minimal criteria of conformance can be summarised in this way:

• the organisational and procedural aspects related to business scenarios

  Upstream the proposed scenarios are assumed as a reference that could be modified or partially implemented with high degree of freedom;

  Downstream the architecture specifies the ‘mandatory’ minimum set of transactions of each process; the pilots, once defined the process they are interested in, must implement at least this minum set of transactions.

• the semantic and data models to exchange information

  The data models of the exchanged messages always must be strictly validated with the reference XML Schemas (XSDs).

  Downstream there is also the necessity of a second check using the Use Profiles that presently are not implemented by XSDs for automatic validation (they restrict the basic UBL XSDs specifications).

  In both the cases it is mandatory to use versions of the specifications that are not former than those mentioned in the architecture report.

  To validate instances of electronic documents (upstream or downstream) an official on-line Validator has been published (click here for more info)

• the product and party classification and identification

  Downstream the product and party (even location) information must be represented by GLN and GTIN global identifiers issued by GS1.

  The only exception could be for ‘local networks’ communications: in this case if the pilots are not able to implement the global identifications in due time, it is acceptable that local network communications use other identification systems (in this case the ‘schemaName’ must be declared explicitly according to the adopted use profiles);

  Anyway it must be demonstrated the capability to translate the local identification system towards the global ones before starting to broaden the communication towards other partners.

  Upstream any kind of identifier can be accepted for product/part identification (but the issuing organisation must be declared clearly), is a duty of the parties to avoid misunderstandings; the parties and locations usually are explicitly and extensively described.

• the middleware and communication protocols.

  Inter-company (in a Peer-to-Peer mode or via a connectivity hub) and inter-hub data exchange must be supported with SOAP over HTTP or SMTP. Intercompany data exchange must satisfy minimal level of security. Inter-hub data exchanges must guarantee the indentity of the originator of business documents and assure for non-repudiation of received messages.