The Peppol Business Interoperability Specification, “BIS” from here on after, has been developed by the OpenPeppol AISBL Post Award Coordinating Community and is published as part of the Peppol specifications.

Statement of copyright

This Peppol Business Interoperability Specification (BIS) document is based on the CEN CWA prepared by the BII workshop specified in the introduction below. The original CEN CWA document contains the following copyright notice which still applies:

The CEN CWA documents and profiles prepared by the BII workshop are not specific to a business area. Subject to agreement with CEN, customizations have been made by Peppol to establish the Peppol BIS, detailing and adding further guidance on the use of BII profiles.

OpenPeppol AISBL holds the copyright in the customizations made to the original document. The customizations appear from the corresponding conformance statement which is attached to this document. For the purpose of national implementations, customizations covered by the conformance statement may be further refined and detailed by Peppol Authorities and/or other entities authorized by OpenPeppol AISBL, provided that interoperability with Peppol BIS is ensured. This Peppol BIS document may not be modified, re-distributed, sold or repackaged in any other way without the prior consent of CEN and/or OpenPeppol AISBL.

Link to main site of documentation

Main documentation site

1. Introduction to openPeppol and BIS

This BIS is a result of work within openPeppol and is published as part of the Peppol specifications.

This Peppol BIS provides a set of specifications for implementing a Peppol business process. The document is concerned with clarifying requirements for ensuring interoperability of pan-European Public eProcurement and provides guidelines for supporting these requirements and how to implement them. This Peppol BIS is based on the CEN WS/BII2 “Profile BII01 Catalogue Only”.

The purpose of this document is to describe a common format for the catalogue message in the European market, and to facilitate an efficient implementation and increased use of electronic collaboration regarding the sourcing process based on this format.

Figure 1. Relationship between BII profiles and Peppol BIS

1.1. Audience

The audience for this document is organizations wishing to be Peppol enabled for exchanging electronic business documents, and/or their ICT-suppliers.

These organizations may be:

Service providers
Contracting Authorities
Economic Operators
Software Developers

More specifically it is addressed towards the following roles:

ICT Architects
ICT Developers
Business Experts

For further information, please see Peppol BIS common text and introduction.

2. Principles and prerequisites

2.1. Business Process in scope

This Peppol BIS supports a process for suppliers to send a catalogue and for buyers to return a catalogue response. It is intended to support transmission of electronic catalogue-messages for processing in semi-automated processes by the receiver. The BIS mandates no procurement related data but supports different ways of referring to products and services. By selective use of such references it can be used as basis for automated processing of ordering and invoicing.

The intended scope for this BIS is:

B2B and B2G
Common business processes for cross industry and cross border procurement
Regional procurement within EU and EEA
For supporting purchase of goods and services and/or services that can be itemized.

This Peppol BIS supports a set of “common use cases / process”. These are processes that are used widely or understood as being relevant for most companies.

The main activities supported by this BIS are:

Description of goods and services
Maintaining content of framework contract
Item comparison
Item dependency and composition
Description of packaging and storage requirements
TAX classification (e.g. for VAT, GST and Sales Tax)
Item instance description
Maintenance of catalogue

This Peppol BIS supports requirements by providing elements for information needed to meet the requirement. This BIS also provides a set of business rules to clarify content and implementers can use them as basis for validation where it provides business value.

2.2. Peppol BIS 1A - Benefits

Catalogues are used as basis for maintenance of information about products and services that are part of a contract, like a framework agreement.

The buyer (or a catalogue provider on his behalf) can present the information in a web shop where he can ensure correctness of product description, prices and other terms that may apply.
The supplier can provide the customer with correct information at all times and ensure high data quality in orders based on the catalogue he prepares.
Implementing the catalogue provides the possibility of designing fully automated purchasing flows in which the electronic documents can be validated and matched automatically, thereby saving resources compared to manual processing.
Implementation of a catalogue can be the first step in automating the purchasing process followed by an order and an invoice, leading to entire purchasing process running from sourcing, ordering and invoicing to payment.
Buyers can accept or reject the catalogue using a catalogue response

This Peppol BIS is based on the CEN/ISSS WS/BII Profile BII01 specification, see [BII_Catalogue].

2.2.1. Parties and roles

Business partners	Description
Customer	The customer is the legal person or organization who is in demand of a product or service. Examples of customer roles: buyer, consignee, debtor, contracting authority.
Supplier	The supplier is the legal person or organization who provides a product or service. Examples of supplier roles: seller, consignor, creditor, economic operator.
Role/actor	Description
Catalogue Provider	Represents a party sending catalogues to receivers, being the supplier or on behalf of the supplier. The Catalogue Provider has to ensure that the latest catalogue is sent to the receiver.
Catalogue Receiver	Represents a party receiving catalogues and sending the request how and what parts of the catalogues have to be updated in an update process.
Buyer	The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services.
Seller	The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the customer.

Business partners

Description

Customer

The customer is the legal person or organization who is in demand of a product or service.

Examples of customer roles: buyer, consignee, debtor, contracting authority.

Supplier

The supplier is the legal person or organization who provides a product or service.

Examples of supplier roles: seller, consignor, creditor, economic operator.

Role/actor

Description

Catalogue Provider

Represents a party sending catalogues to receivers, being the supplier or on behalf of the supplier.

The Catalogue Provider has to ensure that the latest catalogue is sent to the receiver.

Catalogue Receiver

Represents a party receiving catalogues and sending the request how and what parts of the catalogues have to be updated in an update process.

Buyer

The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services.

Seller

The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the customer.

The following diagram links the business processes to the roles performed by the Business Partners:

Figure 2. Business partners and roles in the catalogue

Figure 3. Business partners and roles in the catalogue response

2.3. Interoperability

This Peppol BIS structure is based on the European Interoperability Framework 2.0 EIF. This Peppol BIS applies the Framework as follows:

Legal Interoperability

Legal:
- In implementations supporting public sector buyers, the use of this BIS has to be monitored in order to secure that the parties act in line with EU procurement directives.

Organizational interoperability

Organization (Organization/Business):
- This Peppol BIS supports B2B and B2G.
- This Peppol BIS supports cross border, regional and domestic ordering in EU and EEA.
- This Peppol BIS can function as a component in an EDI agreement within a trading community.
- This Peppol BIS supports linking of business processes within the sending and receiving organization. The process of order transmission in electronic form can be linked into internal processes of both sender and receiver, which may differ for various reasons.
Organization (Process):
- This Peppol BIS supports a set of “common business processes” that is assumed to be supported by most enterprises whether public or private. These are processes that are used widely or understood as being relevant for most companies.

Semantic interoperability

Semantic: The set of information elements is assumed to be sufficient to support organizational business and processing requirements stated above.
- A CORE business message:
  - Data model, a set of elements that the receiver MUST be able to process.
  - Business rules, a set of business rules that ensure a common way of processing the information elements. The rules are stated in a way that allows for automated validation of document instances. Issuers and receivers can verify that the exchanged document conforms to the rules of this BIS.
    Peppol adds business rules on top of the data model to clarify certain design choices left open by the CEN WS/BII. These choices are intended to lower the implementation threshold by limiting options for implementers and thereby increase interoperability of Peppol transactions.

Technical interoperability

Technical Interaction (Process and semantic implementation):
- Binding to OASIS UBL 2.1, see UBL 2.1
- ISO/IEC 19757-3 Schematron, for automation of document validation, see Schematron
Technical Interaction (eSignature Validation):
- Not mandatory in this Peppol BIS. Not supported.

3. Process and typical scenarios

3.1. Process chart

Figure 4. BPMN process covered by this BIS

Any time limits for the catalogue response must be agreed between the parties as a part of the collaboration agreement. Any further processing is outside scope of this BIS, and is in most cases done in the customers catalogue tool.

3.2. Use case 1 – New Catalogue and positive Catalogue Response

This use case includes a simple catalogue containing mandatory information and information required to get a high performance from the buyers search engine. The catalogue contains both products and services. This is the first catalogue to the receiver.

Use Case No	1
Use Case Name	A new catalogue from the Seller and accept from the Buyer.
Use Case Description	The provider sends a catalogue to the receiver. The catalogue contains the articles that the buyer and seller have agreed on in a contract. This is the first catalogue being sent on this contract. After receiving the catalogue, the buyer accepts the catalogue using a response message.
Parties involved	Catalogue Provider (same legal entity as the Supplier/Seller in this use case) Catalogue Receiver (same legal entity as the Customer/Buyer in this use case)
Assumptions	The Seller and the Buyer have a contract of products and services that the buyer may purchase from the Seller. The parties have agreed to exchange the catalogue and catalogue response messages The articles are Physical articles (pens and papers) Fruits Services
The flow	The Seller identifies the contracted items The Provider creates a Catalogue message The Provider sends the message to the Receiver The Buyer verifies the content in the message consider to accept or reject the catalogue. The Buyer sends a Catalogue response with accept. The Buyer inserts the articles from the catalogue message in the local ERP-system.
Result	The Buyer have all the articles and the contracted prices in the ERP-system and may start ordering The ordering process is easy when you have all necessary information in the ERP-system. Please note that the ordering process is not part of this BIS. For ordering, please see Peppol BIS 3A.
XML example file	See Appendix A for sample Catalogue and catalogue response files illustrating Use Case 1.

Use Case No

Use Case Name

A new catalogue from the Seller and accept from the Buyer.

Use Case Description

The provider sends a catalogue to the receiver.

The catalogue contains the articles that the buyer and seller have agreed on in a contract.

This is the first catalogue being sent on this contract.

After receiving the catalogue, the buyer accepts the catalogue using a response message.

Parties involved

Catalogue Provider (same legal entity as the Supplier/Seller in this use case)

Catalogue Receiver (same legal entity as the Customer/Buyer in this use case)

Assumptions

The Seller and the Buyer have a contract of products and services that the buyer may purchase from the Seller.
The parties have agreed to exchange the catalogue and catalogue response messages
The articles are
1. Physical articles (pens and papers)
2. Fruits
3. Services

The flow

The Seller identifies the contracted items
The Provider creates a Catalogue message
The Provider sends the message to the Receiver
The Buyer verifies the content in the message consider to accept or reject the catalogue.
The Buyer sends a Catalogue response with accept.
The Buyer inserts the articles from the catalogue message in the local ERP-system.

Result

The Buyer have all the articles and the contracted prices in the ERP-system and may start ordering
The ordering process is easy when you have all necessary information in the ERP-system.

Please note that the ordering process is not part of this BIS. For ordering, please see Peppol BIS 3A.

XML example file

See Appendix A for sample Catalogue and catalogue response files illustrating Use Case 1.

3.3. Use case 2 – Catalogue update and negative response

This is an Update of the catalogue based on Use case 1.

Use Case No	2
Use Case Name	Catalogues update from the provider and reject from the receiver.
Use Case Description	The provider sends a catalogue update to the receiver. The catalogue contains changes in the previous catalogue. After receiving the catalogue, the buyer rejects the catalogue using a response message.
Parties involved	Catalogue Provider (same legal entity as the Supplier/Seller in this use case) Catalogue Receiver (same legal entity as the Customer/Buyer in this use case)
Assumptions	The Seller has previously sent a catalogue to the Buyer. The Seller wants to update the catalogue One article is updated (GTIN is added) One new article is added One article is deleted
The flow	The Seller identifies the items to be in the Catalogue update The Provider creates a Catalogue message The Provider sends the message to the Receiver The Buyer verifies the content in the message and considers to accept or reject the catalogue. The Buyer sends a Catalogue response with reject. The Seller handles the negative response.
Result	The Buyer did not insert the changes in the ERP-system The Seller needs to correct the information in his ERP-system.
XML example file	See Appendix A for sample Catalogue and catalogue response files illustrating Use Case 2.

Use Case No

Use Case Name

Catalogues update from the provider and reject from the receiver.

Use Case Description

The provider sends a catalogue update to the receiver.

The catalogue contains changes in the previous catalogue.

After receiving the catalogue, the buyer rejects the catalogue using a response message.

Parties involved

Catalogue Provider (same legal entity as the Supplier/Seller in this use case)

Catalogue Receiver (same legal entity as the Customer/Buyer in this use case)

Assumptions

The Seller has previously sent a catalogue to the Buyer.
The Seller wants to update the catalogue
1. One article is updated (GTIN is added)
2. One new article is added
3. One article is deleted

The flow

The Seller identifies the items to be in the Catalogue update
The Provider creates a Catalogue message
The Provider sends the message to the Receiver
The Buyer verifies the content in the message and considers to accept or reject the catalogue.
The Buyer sends a Catalogue response with reject.
The Seller handles the negative response.

Result

The Buyer did not insert the changes in the ERP-system
The Seller needs to correct the information in his ERP-system.

XML example file

See Appendix A for sample Catalogue and catalogue response files illustrating Use Case 2.

3.4. Use case 3 – Replace of catalogue and positive response

This is a Replace of the catalogue based on Use case 1 and 2.

Use Case No	3
Use Case Name	Catalogues replace from the provider and accept from the receiver.
Use Case Description	The provider sends a catalogue replace to the receiver. The catalogue contains all the contracted items and replaces the previous accepted catalogue. After receiving the catalogue, the buyer accepts the catalogue using a response message.
Parties involved	Catalogue Provider (same legal entity as the Supplier/Seller in this use case) Catalogue Receiver (same legal entity as the Customer/Buyer in this use case)
Assumptions	The Seller has previously sent a new catalogue to the Buyer which has been accepted. The Seller has sent an update of the catalogue which was rejected by the buyer The Seller sends a replace catalogue All articles that the supplier had identified in the contract, including the new one in the rejected catalogue. One article from the previous accepted catalogue is not in this catalogue. Three more new articles are added. Shampoo presented in a hierarchy.
The flow	The Seller identifies the items to be in the Catalogue update The Provider creates a Catalogue message The Provider sends the message to the Receiver The Buyer verifies the content in the message and accepts the catalogue. The Buyer sends a Catalogue response with accept.
Result	The Buyer has all the articles and the contracted prices in the ERP-system and may start ordering The ordering process is easy when you have all necessary information in the ERP-system. Please note that the ordering process is not part of this BIS. For ordering, please see Peppol BIS 3A.
XML example file	See Appendix A for sample Catalogue and catalogue response files illustrating Use Case 3.

Use Case No

Use Case Name

Catalogues replace from the provider and accept from the receiver.

Use Case Description

The provider sends a catalogue replace to the receiver.

The catalogue contains all the contracted items and replaces the previous accepted catalogue.

After receiving the catalogue, the buyer accepts the catalogue using a response message.

Parties involved

Catalogue Provider (same legal entity as the Supplier/Seller in this use case)

Catalogue Receiver (same legal entity as the Customer/Buyer in this use case)

Assumptions

The Seller has previously sent a new catalogue to the Buyer which has been accepted.
The Seller has sent an update of the catalogue which was rejected by the buyer
The Seller sends a replace catalogue
1. All articles that the supplier had identified in the contract, including the new one in the rejected catalogue.
2. One article from the previous accepted catalogue is not in this catalogue.
3. Three more new articles are added. Shampoo presented in a hierarchy.

The flow

The Seller identifies the items to be in the Catalogue update
The Provider creates a Catalogue message
The Provider sends the message to the Receiver
The Buyer verifies the content in the message and accepts the catalogue.
The Buyer sends a Catalogue response with accept.

Result

The Buyer has all the articles and the contracted prices in the ERP-system and may start ordering
The ordering process is easy when you have all necessary information in the ERP-system.

Please note that the ordering process is not part of this BIS. For ordering, please see Peppol BIS 3A.

XML example file

See Appendix A for sample Catalogue and catalogue response files illustrating Use Case 3.

3.5. Use case 4 – Catalogue deletion and positive response

This is a Deletion of the catalogue based on Use case 3.

Use Case No	4
Use Case Name	Catalogue deletion.
Use Case Description	The provider sends a catalogue deletion to the receiver. The catalogue deletes the previous accepted catalogue. After receiving the catalogue deletion, the buyer accepts the catalogue using a response message.
Parties involved	Catalogue Provider (same legal entity as the Supplier/Seller in this use case) Catalogue Receiver (same legal entity as the Customer/Buyer in this use case)
Assumptions	The Seller has previously sent a catalogue to the Buyer which has been accepted. The Seller and the Buyer have ended their contract
The flow	The Seller identifies the current active catalogue to be deleted The Provider creates a Catalogue message The Provider sends the message to the Receiver The Buyer verifies the content in the message and accepts the catalogue. The Buyer sends a Catalogue response with accept. The Buyer, in his ERP system, deactivates the items identified in the catalogue message.
Result	The Buyer can no longer make en order to the supplier from this catalogue.
XML example file	See Appendix A for sample Catalogue and catalogue response files illustrating Use Case 4.

Use Case No

Use Case Name

Catalogue deletion.

Use Case Description

The provider sends a catalogue deletion to the receiver.

The catalogue deletes the previous accepted catalogue.

After receiving the catalogue deletion, the buyer accepts the catalogue using a response message.

Parties involved

Catalogue Provider (same legal entity as the Supplier/Seller in this use case)

Catalogue Receiver (same legal entity as the Customer/Buyer in this use case)

Assumptions

The Seller has previously sent a catalogue to the Buyer which has been accepted.
The Seller and the Buyer have ended their contract

The flow

The Seller identifies the current active catalogue to be deleted
The Provider creates a Catalogue message
The Provider sends the message to the Receiver
The Buyer verifies the content in the message and accepts the catalogue.
The Buyer sends a Catalogue response with accept.
The Buyer, in his ERP system, deactivates the items identified in the catalogue message.

Result

The Buyer can no longer make en order to the supplier from this catalogue.

XML example file

See Appendix A for sample Catalogue and catalogue response files illustrating Use Case 4.

3.6. Use case 5 – Catalogue with all possible information and positive response

This is an Update of a previous sent catalogue and not based on any of the other uses cases. The catalogue includes all possible information in a BIS catalogue. Some information may not be relevant, but is in the catalogue for giving an example.

Use Case No	5
Use Case Name	Catalogue with all information.
Use Case Description	The provider sends a catalogue deletion to the receiver.
Parties involved	Catalogue Provider Supplier/Seller Catalogue Receiver Customer/Buyer
Assumptions	The Seller has previously sent a catalogue to the Buyer which has been accepted. The Seller needs to send a new article to update the previous catalogue. One of the rows handle deposit.
The flow	The Seller identifies the article to be added The Provider creates a Catalogue message The Provider sends the message to the Receiver The Buyer verifies the content in the message and considers the catalogue acceptable. The Buyer sends a Catalogue response with accept. The Buyer inserts/updates the information from the catalogue message in the local ERP-system..
Result	The Buyer have the articles and the contracted prices in the ERP-system and may start ordering Please note that the ordering prosess is not part of this BIS. For ordering, please see Peppol BIS 3A.
XML example file	See Appendix A for sample Catalogue and catalogue response files illustrating Use Case 5.

Use Case No

Use Case Name

Catalogue with all information.

Use Case Description

The provider sends a catalogue deletion to the receiver.

Parties involved

Catalogue Provider

Supplier/Seller

Catalogue Receiver

Customer/Buyer

Assumptions

The Seller has previously sent a catalogue to the Buyer which has been accepted.
The Seller needs to send a new article to update the previous catalogue.
One of the rows handle deposit.

The flow

The Seller identifies the article to be added
The Provider creates a Catalogue message
The Provider sends the message to the Receiver
The Buyer verifies the content in the message and considers the catalogue acceptable.
The Buyer sends a Catalogue response with accept.
The Buyer inserts/updates the information from the catalogue message in the local ERP-system..

Result

The Buyer have the articles and the contracted prices in the ERP-system and may start ordering

Please note that the ordering prosess is not part of this BIS. For ordering, please see Peppol BIS 3A.

XML example file

See Appendix A for sample Catalogue and catalogue response files illustrating Use Case 5.

4. Semantic datatypes

Semantic data types are used to bridge the gap between the semantic concepts expressed by the information elements and the technical implementation. The semantic data types define the allowed value domain for the content, and any additional information components (attributes) needed in order to ensure its precise interpretation.

4.1. Primitive types

Semantic data type content may be of the following primitive types. These primitive types were taken from ISO 15000-5:2014, Annex A.

Primitive type	Definition
Binary	A set of finite-length sequences of binary digits.
Date	Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar ISO 8601:2004.
Decimal	A subset of the real numbers, which can be represented by decimal numerals.
String	A finite sequence of characters.

Primitive type

Definition

Binary

A set of finite-length sequences of binary digits.

Date

Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar ISO 8601:2004.

Decimal

A subset of the real numbers, which can be represented by decimal numerals.

String

A finite sequence of characters.

4.2. Semantic data types

The different semantic data types are described in the tables below, where various features such as attributes, format, and decimals as well as the basic type are defined for each semantic data type. They are based on ISO 15000-5:2014.

When used in an instance document, each data element will contain data. In the below tables this is identified as the “content”. Whenever a business term is used this term shall always have content and therefore the content is always mandatory.

4.2.1. Amount

An amount states a numerical monetary value. The currency of the amount is defined as a separate business term.

Amount is floating up to two fraction digits.

Component	Use	Primitive Type	Example
Content	Mandatory	Decimal	10000.25

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

10000.25

4.2.2. Price Amount

A price amount states a numerical monetary amount value for data elements that contain item prices that may be multiplied by item quantities. The currency of the amount is defined as a separate business term.

Unit price amount does not set restrictions on number of decimals, as contrast to the Amount type

Component	Use	Primitive Type	Example
Content	Mandatory	Decimal	10000.1234

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

10000.1234

4.2.3. Percentage

Percentages are given as fractions of a hundred (per cent) e.g. the value 34,78 % in percentage terms is given as 34,78.

No restriction on number of decimals for percentages.

Component	Use	Primitive Type	Example
Content	Mandatory	Decimal	34.7812

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

34.7812

4.2.4. Quantity

Quantities are used to state a number of units such as for items. The code for the Unit of Measure is defined as a separate business term.

No restriction on number of decimals for quantities.

Component	Use	Primitive Type	Example
Content	Mandatory	Decimal	10000.1234

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

10000.1234

4.2.5. Code

Codes are used to specify allowed values in elements as well as for lists of options. Code is different from Identifier in that allowed values have standardized meanings that can be known by the recipient.

Codes shall be entered exactly as shown in the selected code list

Component	Use	Primitive Type	Example
Content	Mandatory	String	Abc123

Component

Use

Primitive Type

Example

Content

Mandatory

String

Abc123

4.2.6. Identifier

Identifiers (IDs) are keys that are issued by the sender or recipient of a document or by a third party.

The use of the attributes is specified for each information element.

Component

Use

Primitive Type

Example

Content

Mandatory

String

abc:123-DEF

Scheme identifier

Conditional

String

0088

Scheme version identifier

Conditional

String

1.0

4.2.7. Date

Dates shall be in accordance to the “Calendar date complete representation” as specified by ISO 8601:2004, format YYYY-MM-DD.

Dates shall not include timezone information.

Table 1. EN 16931_ Date. Type
Component	Use	Primitive Type	Example
Content	Mandatory	Date	2017-12-01

4.2.8. Time

Time shall be in accordance to the “Extended time format” as specified by ISO 8601:2004,
- format without time zone [hh]:[mm]:[ss]
- format with UTC timezone [hh]:[mm]:[ss]Z
- format for other zones [hh]:[mm]:[ss]±[hh:mm] with zone is given as difference from UTC.

Time may include timezone information.
Decimal fraction on seconds SHALL not be used.

Table 2. EN 16931_ Date. Type
Component	Use	Primitive Type	Example
Content	Mandatory	Date	09:30:12

4.2.9. Document Reference

Document Reference Types are identifiers that were assigned to a document or document line.

Table 3. Document Reference. Type
Component	Use	Primitive Type	Example
Content	Mandatory	String	abc:123-DEF

4.2.10. Text

Text is the actual wording of anything written or printed. Line breaks in the text may be present, and any line breaks should be preserved and respected by the receiver’s system

Component	Use	Primitive Type	Example
Content	Mandatory	String	5% allowance when paid within 30 days

Component

Use

Primitive Type

Example

Content

Mandatory

String

5% allowance when paid within 30 days

4.2.11. Binary objects

Binary objects can be used to describe files which are transmitted together with the business document. Attachments shall be transmitted together with the business document. The binary object has two supplementary components: a Mime Code, which specifies the Mime type of the attachment and a Filename that is provided by (or on behalf of) the sender of the business document.

Component	Use	Primitive Type	Example
Content	Mandatory	Binary	QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==
Mime Code	Mandatory	String	image/jpeg
Filename	Mandatory	String	drawing5.jpg

Component

Use

Primitive Type

Example

Content

Mandatory

Binary

QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==

Mime Code

Mandatory

String

image/jpeg

Filename

Mandatory

String

drawing5.jpg

4.2.12. Boolean

Boolean indicators are used to specify the two allowed values, true or false. All elements of datatype Boolean, must have either true or false as their value.

Component	Use	Primitive Type	Example
Content	Mandatory	Boolean	true

Component

Use

Primitive Type

Example

Content

Mandatory

Boolean

true

5. Code lists

5.1. Code lists for coded elements

Any element with the semantic data type = code, can mandate the use of a specific code list (or a fixed value). The applicable code lists can be found in the Code list section. In this section, you can find the valid codes, their names and description, and also links to where the same code list is used elsewhere in the transaction, or in other Peppol BIS v3. documents.

5.2. Code list for identifiers

5.2.1. Party identifiers and party legal registration identifier scheme

All party identifiers (cac:PartyIdentification/cbc:ID) and party legal registration identifier (cac:PartyLegalEntity/cbc:CompanyID) has an optional scheme identifier attribute (@schemeID). If used, the value shall be chosen from the code list ICD codes

Examples of usage in cac:PartyIdentification

<cac:PartyIdentification>
        <cbc:ID schemeID="0088">5790000435968</cbc:ID> (1)
</cac:PartyIdentification>

1	schemeID attribute is optional, but when used, the codes must be from ICD codes

5.2.2. Electronic address identifier scheme identifier

All electronic address identifiers (cbc:EndpointID/@schemeID) use the Electronic Address Scheme code list (EAS), maintained by CEF (CEF Code lists).

Valid values are found here: EAS codes.

Examples of usage in cbc:EndpointID

<cbc:EndpointID schemeID="0184">DK87654321</cbc:EndpointID> (1)

1	schemeID attribute is mandatory

6. Description of selected parts of the catalogue message

6.1. Parties

The following parties/roles may be specified in the message:

6.1.1. Catalogue Provider (ProviderParty)

The party that is responsible for the preparation and transfer of the Catalogue to the Catalogue receiver. Can be the Supplier itself or a third party providing this service.

Example:

<cac:ProviderParty>
        <cbc:EndpointID schemeID="0192">987654325</cbc:EndpointID>
        <cac:PartyIdentification>
                <cbc:ID schemeID="0088">5790000435951</cbc:ID>
        </cac:PartyIdentification>
        <cac:PartyLegalEntity>
                <cbc:RegistrationName>Suuplier AS</cbc:RegistrationName>
        </cac:PartyLegalEntity>
</cac:ProviderParty>

6.1.2. Catalogue Receiver (ReceiverParty)

The party that is responsible for the reception and control of the Catalogue. Can be the Customer itself or a third party providing this service to the Customer.

Example:

<cac:ReceiverParty>
        <cbc:EndpointID schemeID="0192">123456785</cbc:EndpointID>
        <cac:PartyIdentification>
                <cbc:ID schemeID="0088">5790000435944</cbc:ID>
        </cac:PartyIdentification>
        <cac:PartyLegalEntity>
                <cbc:RegistrationName>DEF Customer Ltd.</cbc:RegistrationName>
        </cac:PartyLegalEntity>
</cac:ReceiverParty>

6.1.3. Supplier (SellerSupplierParty)

The party that is responsible for the delivery of products or services specified in the Catalogue.

Example:

<cac:SellerSupplierParty>
        <cac:Party>
                <cac:PartyName>
                        <cbc:Name>Office AS</cbc:Name>
                </cac:PartyName>
                <cac:PostalAddress>
                        <cbc:StreetName>Office street 12</cbc:StreetName>
                        <cbc:CityName>oslo</cbc:CityName>
                        <cbc:PostalZone>1163</cbc:PostalZone>
                        <cbc:CountrySubentity>Oslo</cbc:CountrySubentity>
                        <cac:Country>
                                <cbc:IdentificationCode>NO</cbc:IdentificationCode>
                        </cac:Country>
                </cac:PostalAddress>
                <cac:Contact>
                        <cbc:ElectronicMail>kontor@online.no</cbc:ElectronicMail>
                </cac:Contact>
        </cac:Party>
</cac:SellerSupplierParty>

6.1.4. Buyer (ContractorCustomerParty)

The party buying products or services from the Catalogue.

Example:

<cac:ContractorCustomerParty>
        <cac:Party>
                <cbc:EndpointID schemeID="0184">DK16356706</cbc:EndpointID>
                <cac:PartyIdentification>
                        <cbc:ID schemeID="0184">DK16356706</cbc:ID>
                </cac:PartyIdentification>
                <cac:PartyName>
                        <cbc:Name>DIGST</cbc:Name>
                </cac:PartyName>
                <cac:Contact>
                        <cbc:ElectronicMail>postmottak@digst.dk</cbc:ElectronicMail>
                </cac:Contact>
        </cac:Party>
</cac:ContractorCustomerParty>

6.1.5. Manufacturer (ManufacturerParty)

The name of the Manufacturer.

Example:

<cac:ManufacturerParty>
        <cac:PartyName>
                <cbc:Name>The PC Manufacturing Party</cbc:Name>
        </cac:PartyName>
</cac:ManufacturerParty>

6.2. Action code

The Action code holds instructions about the treatment of the Catalogue by the recipients system. The Action code can be stated either on header or line level. Please be aware that the below mentioned are codes, and hence the correct use of upper and lower case must be used. Example: Replace is valid, REPLACE is not valid.

Legal codes on Catalogue header level:

Add – Used when a catalogue is sent for the first time to the Catalogue Receiver referring to the contract in the header of the catalogue.
Replace – Replaces the entire catalogue referring to the contract. This is the default action.
Update – Updates a current catalogue.
Delete – deletes the entire catalogue
Example:
```
<cbc:ActionCode>Replace</cbc:ActionCode>
```

Legal codes on Catalogue Line level:

Add – Used to add items to the catalogue.
Update – Used to update an item. The entire Catalogue Line is updated. Only used if Action code on header level is Update
Delete – Used to delete an entire Catalogue line. Only used if Action code on header level is Update.

It is important to note that when updating or deleting on line level, the key identifier is the item ID (sellers item identification or standard item identification, see chapter 10.2.2.), not the line ID. If CatalogueLineReference is used in the corresponding order message (outside scope of this BIS), the numbering of Line ID must be consistent in all versions of the catalogue.

Example:

<cbc:ActionCode>Update</cbc:ActionCode>

6.3. Item identification

Item identification must be sent using the identifiers described below.

Sellers item identification
Standard item identification, e.g. GTIN
Manufacturers item identification which is necessary when the same product is bought from several suppliers.
Buyers item identification

At least one of Sellers item identification or Standard item identification must be sent. Which identifier to use depends on what is known at the time of catalogue exchange or what is commonly used in the relevant business sector.

Example 1, Seller item identification

<cac:SellersItemIdentification>
        <cbc:ID>MNTR01</cbc:ID>
</cac:SellersItemIdentification>

Example 2, Standard item identification

<cac:StandardItemIdentification>
        <cbc:ID schemeID="0160">1234567890124</cbc:ID>
</cac:StandardItemIdentification>

6.4. Hazardous item

If an item is classified as Hazardous item, a reference to the relevant UNDG-code must be stated and further specification must be provided in an attached document or on a web-site (URI).

Example:

<cac:HazardousItem>
        <cbc:UNDGCode>ADR</cbc:UNDGCode>
</cac:HazardousItem>

6.5. Item name and description

The Item name shall be sent in tag cac:Item/cbc:Name on line level. It is the short description of an item commonly used in ERP-systems. An item name should make it possible for the user to distinguish between similar items. The Item name is often sent in the order from buyer to seller. The field length could be an agreement between parties, to make sure the supporting systems can handle the length.

cac:Item/cbc:Description is used to provide additional relevant description of the item, in free text.

Example:

<cac:Item>
        <cbc:Description> Ballpoint pen, comes in different colours and tip
                sizes</cbc:Description>
        <cbc:PackQuantity unitCode="XCT">10</cbc:PackQuantity>
        <cbc:Name> Ballpoint pen. Blue colour 0.7 mm</cbc:Name>
        <cac:SellersItemIdentification>
                <cbc:ID>34234-324</cbc:ID>
        </cac:SellersItemIdentification>
</cac:Item>

6.6. Classification

An item may be classified according to UNSPSC being the mandatory public classification schemes in some countries/sectors. The code "TST" (The UNSPSC commodity classification system) from codelist UNCL7143 is used. Products can also be classified according to regulatory schemes or classification schemes used in certain business sectors.

Example:

<cac:CommodityClassification>
        <cbc:ItemClassificationCode listID="TST" listVersionID="20.0601"
                >14111511</cbc:ItemClassificationCode>
</cac:CommodityClassification>

6.7. Keyword

Keywords are sent to let the Buyer search for an item without knowing the item identification or name. Keywords tag can be repeated (0..n), but the number should be limited to ensure correct handling in the receiving system.

It is also possible to send several keywords in the same tag, by using a separator between the different keywords. Which separator that should be used, must be agreed between the parties. Example of a separator can be the %-sign, as this is not used anywhere else.

Example of several keywords by using several <KeyWord>-tags:

<cac:Item>
        <cbc:Description>Day cream</cbc:Description>
        <cbc:PackQuantity unitCode="EA">50</cbc:PackQuantity>
        <cbc:Name>Ultimate Day cream, 250 ml</cbc:Name>
        <cbc:Keyword>Moisturizer</cbc:Keyword>
        <cbc:Keyword>Balm</cbc:Keyword>
        <cbc:Keyword>Lotion</cbc:Keyword>
        <cac:SellersItemIdentification>
                <cbc:ID>654321</cbc:ID>
        </cac:SellersItemIdentification>
</cac:Item>

Example of several keywords using “%” as separator:

<cbc:Keyword>write equipment%felt pen</cbc:Keyword>

6.8. Quantities and units

The table below lists quantities and units in the catalogue transaction. All quantities must be based on a Unit Of Measure (UOM) according UNECE Recommendation 20 and Recommendation 21 for UOM. For xml-examples for quantities and units, we refer to Appendix A on the main page.

Following are two examples showing the use of different elements.

Example 1: Bottles that contain 250m of shampoo are packed in cases, 6 bottles in each case. The cases are stacked 18 on each pallet. The minimum order quantity is always one unit.

Example 2: Printing paper is sold in packs of 500 sheets. 6 packs of paper are packed in cases and 18 cases are stacked on a pallet. Minimum order quantity is one unit.

	1 bottle	Case of 6 bottles	Pallet of 18 cases
Line identifier (tir19-032)	4	5	6
Seller Item identifier (tir19-091)	1111	111	11
Item Name (tir19-078)	Shampoo 250 ml	6x250 ml Shampoo	Shampoo
Orderable unit (tir19-035)	EA	CS	PF

Packaging level (tir19-102)	CU	TU	DU
Packed quantity (tir19-066)		6	18
-Packed units		EA	CS

Consumable unit quantity (tir19-036)	1	6	108

ItemNetQuantity (tir19-061)	250	1500	27000
-Unit	MLT	MLT	MLT

MinimumOrderQuantity (tir19-038)	1	1	1
-Unit	EA	EA	EA

Component related item Identifier (tir19-045)		1111	111
Component related item quantity (tir19-046)		6	18

	Pack of 500 sheets paper	Case of 5 packs paper	Pallet of 18 cases copypaper
Line identifier (tir19-032)	7	8	9
Seller Item identifier (tir19-091)	A	AA	AAA
Item Name (tir19-078)	500 copy paper	5*500 Copy paper	Pallet of paper
Orderable unit (tir19-035)	EA	CS	PX

Packaging level (tir19-102)	CU	TU	DU
Packed quantity (tir19-066)		5	18
-Packed units		EA	EA

Consumable unit quantity (tir19-036)	1	5	90

ItemNetQuantity (tir19-061)	500	2500	45000
-Unit	EA	EA	EA

MinimumOrderQuantity (tir19-038)	1	1	1
-Unit	EA	EA	EA

Component related item Identifier (tir19-045)		A	AA
Component related item quantity (tir19-046)		5	18

Pack of 500 sheets paper

Case of 5 packs paper

Pallet of 18 cases copypaper

Line identifier (tir19-032)

Seller Item identifier (tir19-091)

AAA

Item Name (tir19-078)

500 copy paper

5*500 Copy paper

Pallet of paper

Orderable unit (tir19-035)

Packaging level (tir19-102)

Packed quantity (tir19-066)

-Packed units

Consumable unit quantity (tir19-036)

ItemNetQuantity (tir19-061)

500

2500

45000

-Unit

MinimumOrderQuantity (tir19-038)

-Unit

Component related item Identifier (tir19-045)

Component related item quantity (tir19-046)

Following table shows the definition of the business terms shown in the example as well as their syntax binding.

Id	Description	Element /xPath
tir19-032	Each line must have an identifier that is unique within the document to make it possible to positively reference the line. For example, from other documents.	/cac:CatalogueLine/cbc:ID
tir19-091	An identifier, assigned by the seller, for the item. Associates the item with its identification according to the seller’s system.	/cac:CatalogueLine/cac:Item/cac:SellersItemIdentification/cbc:ID
tir19-078	A short name for an item.	/cac:CatalogueLine/cac:Item/cbc:Name
tir19-035	The unit in which the item described in this catalogue line can be ordered. The same item can be described in more than one catalogue line with different orderble units. E.g. catalogue line 1 describes item X that can be ordered in boxes at a given price. Line 2 may describe the same item X as orderable in pallets where the price is lower.	/cac:CatalogueLine/cbc:OrderableUnit
tir19-102	The packing level of the catalogue line.	cac:CatalogueLine/cbc:PackLevelCode
tir19-066	The number of packed units that are in the orderable unit. E.g. if the orderable unit is a pallet that contains 30 boxes then the packed units are BOX and the packed quantity is 30.	/cac:CatalogueLine/cac:Item/cbc:PackQuantity
UOM	The prepacking the article is available in inside the orderable unit (next lower level packing), and which contains the number of unit described in PackSizeNumeric. Unit desciption to PackQuantity. The value shoud be a valid UOM code like XCS for case.	/cac:CatalogueLine/cac:Item/cbc:PackQuantity/@unitCode
tir19-036	Specifies the number of consumable units that are in each orderable unit.	/cac:CatalogueLine/cac:Item/cbc:PackSizeNumeric
tir19-061	The net quantity of the item that is contained in each consumable unit, excluding any packaging materials.	/cac:CatalogueLine/cbc:ContentUnitQuantity
UOM	The unit of measure that applies to the item net quantity	cac:CatalogueLine cbc:ContentUnitQuantity @unitCode
tir19-038	The minimum number of orderable units that can be ordered according to details provided in the catalogue line, such as price.	/cac:CatalogueLine/cbc:MinimumOrderQuantity
UOM	The unit of measure that applies to the minimum order quantity	/cac:CatalogueLine/cbc:MinimumOrderQuantity/@unitCode
tir19-045	The sellers identifier for the related item.	cac:CatalogueLine/cac:ComponentRelatedItem/cbc:ID
tir19-046	The quantity that applies to the relationship.	cac:CatalogueLine/cac:ComponentRelatedItem/cbc:Quantity

Description

Element /xPath

tir19-032

Each line must have an identifier that is unique within the document to make it possible to positively reference the line. For example, from other documents.

/cac:CatalogueLine/cbc:ID

tir19-091

An identifier, assigned by the seller, for the item. Associates the item with its identification according to the seller’s system.

/cac:CatalogueLine/cac:Item/cac:SellersItemIdentification/cbc:ID

tir19-078

A short name for an item.

/cac:CatalogueLine/cac:Item/cbc:Name

tir19-035

The unit in which the item described in this catalogue line can be ordered. The same item can be described in more than one catalogue line with different orderble units. E.g. catalogue line 1 describes item X that can be ordered in boxes at a given price. Line 2 may describe the same item X as orderable in pallets where the price is lower.

/cac:CatalogueLine/cbc:OrderableUnit

tir19-102

The packing level of the catalogue line.

cac:CatalogueLine/cbc:PackLevelCode

tir19-066

The number of packed units that are in the orderable unit. E.g. if the orderable unit is a pallet that contains 30 boxes then the packed units are BOX and the packed quantity is 30.

/cac:CatalogueLine/cac:Item/cbc:PackQuantity

UOM

The prepacking the article is available in inside the orderable unit (next lower level packing), and which contains the number of unit described in PackSizeNumeric. Unit desciption to PackQuantity. The value shoud be a valid UOM code like XCS for case.

/cac:CatalogueLine/cac:Item/cbc:PackQuantity/@unitCode

tir19-036

Specifies the number of consumable units that are in each orderable unit.

/cac:CatalogueLine/cac:Item/cbc:PackSizeNumeric

tir19-061

The net quantity of the item that is contained in each consumable unit, excluding any packaging materials.

/cac:CatalogueLine/cbc:ContentUnitQuantity

UOM

The unit of measure that applies to the item net quantity

cac:CatalogueLine cbc:ContentUnitQuantity @unitCode

tir19-038

The minimum number of orderable units that can be ordered according to details provided in the catalogue line, such as price.

/cac:CatalogueLine/cbc:MinimumOrderQuantity

UOM

The unit of measure that applies to the minimum order quantity

/cac:CatalogueLine/cbc:MinimumOrderQuantity/@unitCode

tir19-045

The sellers identifier for the related item.

cac:CatalogueLine/cac:ComponentRelatedItem/cbc:ID

tir19-046

The quantity that applies to the relationship.

cac:CatalogueLine/cac:ComponentRelatedItem/cbc:Quantity

6.9. Prices

All prices in the format are related to the article or service within this Catalogue identified by an item identification. The following prices can be stated:

Net price including all discounts and charges but excluded TAX.
Item comparison price defining price for a certain quantity. Used for comparing prices for different articles with various quantities.
Conditional price related to a specific location, validity period or ordered quantity.
Approximate price. The current price will be set on the order date. Commonly used for fruit, vegetables, fresh fish etc.

Example:

<cac:RequiredItemLocationQuantity>
        <cbc:LeadTimeMeasure unitCode="DAY">2</cbc:LeadTimeMeasure>
        <cac:Price>
                <cbc:PriceAmount currencyID="NOK">20.0000</cbc:PriceAmount>
        </cac:Price>
</cac:RequiredItemLocationQuantity>

6.10. Item labelling

Information about the items environmental, social, ethical and quality type of labelling.

Example:

<cac:Certificate>
        <cbc:ID>EU Ecolabel</cbc:ID>
        <cbc:CertificateTypeCode>NA</cbc:CertificateTypeCode>
        <cbc:CertificateType>Environmental</cbc:CertificateType>
        <cac:IssuerParty>
                <cac:PartyName>
                        <cbc:Name>NA</cbc:Name>
                </cac:PartyName>
        </cac:IssuerParty>
</cac:Certificate>

Items can be related to each other for ordering or logistic purposes. All related items must also be sent as separate Catalogue lines. Sellers article number is the only permitted type of article number and there for it is important that the Sellers article numbers is provided in catalogue line with the related item.
Types of relations:

Products that are bundled and ordered/invoiced together, e.g. bottles and deposits.
Products that are connected in a product line or a logistics structure, e.g. consumer units and trading units of the same article.
Accessories that might be sold together with a product, e.g. disk station to a laptop.

Example, The current item consists of 6 of Sellers article number 7690211, and 5 of article 523467:

<cac:ComponentRelatedItem>
        <cbc:ID>7690211</cbc:ID>
        <cbc:Quantity unitCode="XCT">6</cbc:Quantity>
</cac:ComponentRelatedItem>
<cac:ComponentRelatedItem>
        <cbc:ID>523467</cbc:ID>
        <cbc:Quantity unitCode="XCT">5</cbc:Quantity>
</cac:ComponentRelatedItem>

6.12. Logistics information

The Logistics elements can be used to specify different pack levels for the same item:

Each pack level is regarded as a unique item and must be sent as a separate Catalogue line and identified with a unique identification such as GTIN.
Information about pack level is done in the element PackLevelCode on line level. The Pack level codes are based on the Edifact/Eancom-standard and the following codes are available:
- DU = Dispatch Unit
- HN = Handling Unit (level between TU and DU).
- TU = Traded Unit
- CU = Consumer Unit
It should be stated if the pack level is orderable.
The relation between pack levels should be specified by using Component Related Item, e.g. that a Dispatch unit contains Traded units. For the higher level Packed Quantity should be used.
Example:
```
<cbc:PackLevelCode>TU</cbc:PackLevelCode>
```

6.13. Dimension

Physical properties are important for logistics. The following values can be stated:

Height (HT)
Width (WD)
Length (LN)
Weight (WT)
Net Volume (AAX)

For some items it is important to inform about storage regulations. The following values can be stated:

Temperature
Humidity

Example:

<cac:Dimension>
        <cbc:AttributeID>HT</cbc:AttributeID>
        <cbc:Measure unitCode="CMT">270</cbc:Measure>
</cac:Dimension>
<cac:Dimension>
        <cbc:AttributeID>LN</cbc:AttributeID>
        <cbc:Measure unitCode="CMT">300</cbc:Measure>
</cac:Dimension>

6.14. Additional properties

Additional properties are meant for product properties that cannot be sent in any of the defined elements in this Peppol BIS. Additional properties consist of the Name of the property and the actual Value.
Example of additional properties:

Color
Allergens.
Legal values: YES, NO, UNKNOWN, FREE.
Nutrition.
Stated with amount per 100 g/ml.
Genetically modified.
Legal values: True, False

Example simple:

<cac:AdditionalItemProperty>
        <cbc:Name>Color</cbc:Name>
        <cbc:Value>Red</cbc:Value>
        <cbc:ValueQualifier>Color</cbc:ValueQualifier>
</cac:AdditionalItemProperty>

Example showing code properties:

<cac:AdditionalItemProperty>
        <cbc:Name>Allergens</cbc:Name>
        <cbc:NameCode listID="CodeListID">Allergens</cbc:NameCode>
        <cbc:Value>Item contains 5% hazelnuts by volume.</cbc:Value>
        <cbc:ValueQuantity unitCode="60">5</cbc:ValueQuantity>
        <cbc:ValueQualifier>HAZELNUTS</cbc:ValueQualifier>
</cac:AdditionalItemProperty>

6.15. Replaced item

Replaced item is used to identify an existing item being replaced by an item in this Catalogue.

Example:

<cac:ReplacedRelatedItem>
        <cbc:ID>12345</cbc:ID>
        <cbc:Quantity unitCode="EA">5</cbc:Quantity>
</cac:ReplacedRelatedItem>

6.16. Line TAX Category

TAX information on line level is provided in the class cac:ClassifiedTaxCategory.

Each line may have the item TAX information including category code and percentage.

UBL example of line TAX category, when TAX is VAT

<cac:ClassifiedTaxCategory>
    <cbc:ID>S</cbc:ID> (1)
    <cbc:Percent>18</cbc:Percent>(2)
    <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>(3)
    </cac:TaxScheme>
</cac:ClassifiedTaxCategory>

1	TAX category according to codelist Code list UNCL5305
2	The TAX percentage rate that applies to the item unless specific trade reasons apply such as exemptions.
3	Value must identify the correct tax type. For example VAT, GST or sales tax.

7. Peppol Identifiers

Peppol has defined a Peppol Policy for identifiers, policy 8 that specifies how to use identifiers in both its transport infrastructure and within the documents exchanged across that infrastructure. It also introduces principles for any identifiers used in the Peppol environment. The policies that apply to this BIS are the following:

7.1. Profiles and messages

All messages contains ProfileID and CustomizationID. ProfileID identifies what business process a given message is part of, and CustomizationID identifies the kind of message and the rules applied.

Profiles are connected to one business process, and may contain multiple document types. Valid document instances shall contain corresponding ProfileID and CustomizationID.

CustomizationID is a string without spaces. The list below contains spaces in CustomizationID to make them easier to read. Make sure to remove any spaces before use.

7.2. Customization and Profile identifiers

In the table below you will find the values to be used as the specification identifier and the business process type for this profile

Type Element cbc:CustomizationID Element cbc:ProfileID

Type	Element `cbc:CustomizationID`	Element `cbc:ProfileID`
Catalogue (Trdm19)	urn:fdc:peppol.eu:poacc:trns:catalogue:3	urn:fdc:peppol.eu:poacc:bis:catalogue_only:3
Catalogue response (Trdm58)	urn:fdc:peppol.eu:poacc:trns:catalogue_response:3

Catalogue (Trdm19)

urn:fdc:peppol.eu:poacc:trns:catalogue:3

urn:fdc:peppol.eu:poacc:bis:catalogue_only:3

Catalogue response (Trdm58)

urn:fdc:peppol.eu:poacc:trns:catalogue_response:3

7.3. Namespaces

The catalogue data model is bound to UBL 2.1 document type UBL Catalogue 2.1.

The target namespace for the catalogue is: urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2

The catalogue response data model is bound to UBL 2.1 document type UBL Application Response 2.1.

The target namespace for the catalogue response is: urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2

Peppol BIS Catalogue With Response 3.1

Link to main site of documentation

1. Introduction to openPeppol and BIS

1.1. Audience

2. Principles and prerequisites

2.1. Business Process in scope

2.2. Peppol BIS 1A - Benefits

2.2.1. Parties and roles

2.3. Interoperability

3. Process and typical scenarios

3.1. Process chart

3.2. Use case 1 – New Catalogue and positive Catalogue Response

3.3. Use case 2 – Catalogue update and negative response

3.4. Use case 3 – Replace of catalogue and positive response

3.5. Use case 4 – Catalogue deletion and positive response

3.6. Use case 5 – Catalogue with all possible information and positive response

4. Semantic datatypes

4.1. Primitive types

4.2. Semantic data types

4.2.1. Amount

4.2.2. Price Amount

4.2.3. Percentage

4.2.4. Quantity

4.2.5. Code

4.2.6. Identifier

4.2.7. Date

4.2.8. Time

4.2.9. Document Reference

4.2.10. Text

4.2.11. Binary objects

4.2.12. Boolean

5. Code lists

5.1. Code lists for coded elements

5.2. Code list for identifiers

5.2.1. Party identifiers and party legal registration identifier scheme

5.2.2. Electronic address identifier scheme identifier

6. Description of selected parts of the catalogue message

6.1. Parties

6.1.1. Catalogue Provider (ProviderParty)

6.1.2. Catalogue Receiver (ReceiverParty)

6.1.3. Supplier (SellerSupplierParty)

6.1.4. Buyer (ContractorCustomerParty)

6.1.5. Manufacturer (ManufacturerParty)

6.2. Action code

6.3. Item identification

6.4. Hazardous item

6.5. Item name and description

6.6. Classification

6.7. Keyword

6.8. Quantities and units

6.9. Prices

6.10. Item labelling

6.11. Related items

6.12. Logistics information

6.13. Dimension

6.14. Additional properties

6.15. Replaced item

6.16. Line TAX Category

7. Peppol Identifiers

7.1. Profiles and messages

7.2. Customization and Profile identifiers

7.3. Namespaces