Skip to content

Commit

Permalink
Merge pull request #67 from OpenPEPPOL/2022-fall-advanced-ordering
Browse files Browse the repository at this point in the history
2022 fall advanced ordering
  • Loading branch information
jerouris authored Jan 20, 2023
2 parents 98772b3 + 0688f39 commit 79ba36a
Show file tree
Hide file tree
Showing 183 changed files with 13,879 additions and 59 deletions.
40 changes: 0 additions & 40 deletions .travis.yml

This file was deleted.

Empty file.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
21 changes: 21 additions & 0 deletions guides/profiles/65-advanced-ordering/introduction/index.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@

= Introduction to OpenPeppol and BIS

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

This 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 BIS is based on the CEN WS/BII Profile {bii-ordering} and is extended to include order change and order cancellation.
This business processes in this BIS are specified in collaboration with CEN TC-440/WG6.

*The purpose* of this document is to describe formats for the Order, Order Change, Order Cancellation and Order Response Advanced message, and to facilitate an efficient implementation and increased use of electronic collaboration regarding the advanced ordering process based on these formats.

//.Relationship between BII profiles and Peppol BIS
//image::../../shared/images/BII_relationship.png[]

:leveloffset: +1

include::../../../shared/files/audience.adoc[]

:leveloffset: -1
62 changes: 62 additions & 0 deletions guides/profiles/65-advanced-ordering/main.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
include::../../shared/links.adoc[]
:doctype: book
:icons: font
:stem:
:toc: left
:toclevels: 2
:source-highlighter: coderay
:source-language: xml
:sectanchors:
:sectnums:
:title-logo-image: ../../shared/images/peppol.png
:order: ../../transactions/01-order
:order-resp: ../../transactions/116-order-response-advanced
:order-change: ../../transactions/114-order-change
:order-cancellation: ../../transactions/115-order-cancellation
:snippet-dir: ../../../../rules/snippets/order
:snippet-response-dir: ../../../../rules/snippets/order-response-advanced
:snippet-change-dir: ../../../../rules/snippets/order-change
:snippet-cancellation-dir: ../../../../rules/snippets/order-cancellation
:ubl21: http://docs.oasis-open.org/ubl/UBL-2.1.html[UBL 2.1]
:ubl23: http://docs.oasis-open.org/ubl/UBL-2.3.html[UBL 2.3]

= image:../../shared/images/peppol.png[float="right"]BIS Advanced Ordering 3.0
{author}


{description}

include::../../shared/copyright.adoc[]


= Link to main site of documentation

{main-site}


:leveloffset: +1

include::introduction/index.adoc[]

include::principles/index.adoc[]

include::process/index.adoc[]

//include::requirements/index.adoc[]

include::../../shared/datatypes/index.adoc[]

include::../../shared/codes/index.adoc[]

include::{order}/description/index.adoc[]

include::{order-resp}/description/index.adoc[]

include::{order-change}/description/index.adoc[]

include::{order-cancellation}/description/index.adoc[]

include::profile/index.adoc[]


:leveloffset: -1
21 changes: 21 additions & 0 deletions guides/profiles/65-advanced-ordering/principles/benefit.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
[[benefit]]
== Benefit

Based on success with automation of invoicing, there is a growing interest in automation of ordering also.
This approach has two dimensions: Support further automation of invoicing and using structured catalogues as basis for ordering.
Implementing this BIS is an important step for many companies and government agencies towards full procurement automation.

For the sellers, the approval, picking and invoicing can be automated significantly.

For the procuring agency, approval and accounting of invoices can be automated and ordering can be structured by use of catalogues.

Other potential benefits of using this BIS are, among others:

* Can be used by procuring agencies as step towards automation of procurement. The flexibility of the specifications allows the buyers to gradually automate and structure ordering, based on a cost/benefit approach.
* SME can offer their trading partners the option of exchanging standardized documents in a uniform way and thereby move all orders into electronic form.
* Large companies can implement this BIS as standardized documents for general operations and implement custom designed bi-lateral connections for large trading partners.
* Can be used as basis for restructuring of in-house processes of orders and invoices.
* Significant saving can be realized by the procuring agency by automating and streamlining in-house processing.
* Significant saving can be realized by the sellers by automating and streamlining in-house processing.
Linking to picking and invoicing can be improved significantly based on increased order quality, restructuring of invoice dispute resolution and shorter payment cycles.
* For the procuring agency, invoice automation and ordering can be structured.
16 changes: 16 additions & 0 deletions guides/profiles/65-advanced-ordering/principles/index.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
[[principles-and-prerequisites]]
= Principles and prerequisites

This chapter describes the principles and assumptions that underlie the use of Peppol Advanced Ordering.

:leveloffset: +1

include::scope.adoc[]

include::parties.adoc[]

include::benefit.adoc[]

include::interoperability.adoc[]

:leveloffset: -1
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
[[interoperability]]
= Interoperability

This BIS structure is based on the European Interoperability Framework 2.0 {EIF}. This 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 BIS supports B2B and B2G.
** This BIS supports cross border, regional and domestic ordering.
** This BIS can function as a component in an EDI agreement within a trading community.
** This 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 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 {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 {ubl21} (for Order transaction)
** Binding to OASIS UBL 2.3, see {ubl23} (for other transactions)
** ISO/IEC 19757-3 Schematron, for automation of document validation, see {schematron}


* Technical Interaction (eSignature Validation):
** Not supported in this BIS.
54 changes: 54 additions & 0 deletions guides/profiles/65-advanced-ordering/principles/parties.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
[[parties-and-roles]]
= Parties and roles

The table below gives the definitions of the parties and roles of the ordering process.

[cols="2,5"]
|====
s|Business partners
s|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, delivery party, debtor, contracting authority, originator.


|Supplier
|The supplier is the legal person or organization who provides a product or service.
Examples of supplier roles: seller, consignor, creditor, economic operator.


s|Role/actor
s|Description

|Buyer +
`cac:BuyerCustomerParty`
|The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services.

|Seller +
`cac:SellerSupplierParty`
|The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the customer.

|Originator +
`cac:OriginatorCustomerParty`
|A person or unit that initiates an order.

|Invoicee +
`cac:AccountingCustomerParty`
|A person or unit that receives the invoice (invoicee) on behalf of the customer.

|Consignee +
`cac:Delivery/cac:DeliveryLocation`
|A person or unit to where the seller, or a despatching party on behalf of the seller, delivers the goods.

|Delivery party +
`cac:Delivery/cac:DeliveryParty`
|A unit to where the consignee forwards the goods. A final delivery point.

|====


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

image::images/advanced-ordering-roles.png[Roles in Advanced ordering]
33 changes: 33 additions & 0 deletions guides/profiles/65-advanced-ordering/principles/scope.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
[[scope]]
= Scope

This BIS describes a process comprising a buyer to issue an electronic order, whereby the seller may accept or reject the order.
In his rejection the seller may indicate reasons, so the buyer may issue a new order that may be acceptable.
The seller may accept the order with changes, only if in a previously concluded contract the scope of such changes was agreed.
After acceptance the buyer may send an order change to the original order and the seller can either accept or reject the change.
The seller may also change the order by sending a response which can be accepted or rejected by the buyer.
Both buyer and seller may also cancel the order.

The order that is agreed upon by final acceptance has the commercial and legal status of a contract and is ready for delivery.

The main activities supported by this profile are

Initial order from buyer::
The initial Order transaction should support the structured ordering of goods or services, using free text or use of identifiers.
The information source of the ordered products may be a (paper or electronic) catalogue.

Change of order from buyer::
The buyer may change the order based on new requirements or other reasons. Changes must be done before the order is prepared for delivery.
The seller can either accept or reject the changes.

Change of order from seller::
The seller may change the previously accepted order due to e.g. changes in delivery dates or replacements.
The buyer can either accept or reject the changes.

Cancellation of order from buyer::
The buyer may cancel the order if this is done before the order is prepared for delivery. The buyer and seller may have agreed upon deadlines
for cancellation. The seller can either accept or reject the cancellation.

Cancellation of order from seller::
The seller may cancel the order because of lack of delivery capacity or other reasons. As stated above the buyer and seller may have agreed
upon deadlines for cancellation. The buyer must confirm the reception of the cancellation.
36 changes: 36 additions & 0 deletions guides/profiles/65-advanced-ordering/process/index.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@

[[process-and-typical-use-cases]]
= Business process and scenarios

The Advanced ordering process includes the sending of an intial order from buyer and subsequent changes to the order from both buyer and seller.
The process also allows for cancellation of the order.

[[process-flow]]
== Process flow

The Ordering process flow is shown in the below figure. Each task comprise a scenario that is described in detail in the following chapters.

image::images/bpmn-advanced-ordering.png[width=1000]

* A buyer submits an initial order to the seller requesting for delivery of goods or services.
** The order may refer to a framework agreement for its terms and conditions; otherwise the buyer’s terms and conditions apply.
** The order may contain items (goods or services) with item identifiers or items with free text description.
* The initial order may be confirmed for delivery without any more changes or it may be cancelled by buyer or seller
* The order may be changed by the buyer sending one or more order changes until a contract is concluded and the order is confirmed for delivery.
* The seller may also change the order by sending a response with proposed changes.
* The buyer may cancel the order by sending an order cancellation which may be accepted or rejected by the seller.
* The seller may cancel the order by sending a negative response with rejection of all lines.

:leveloffset: +1

include::scenario1.adoc[]

include::scenario2.adoc[]

include::scenario3.adoc[]

include::scenario4.adoc[]

include::scenario5.adoc[]

:leveloffset: -1
48 changes: 48 additions & 0 deletions guides/profiles/65-advanced-ordering/process/scenario1.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
[[use-case-1-ordering-of-numbered-itemsarticles]]
= Scenario 1 – Initial order from buyer

The following diagram shows the business process and choreography for Scenario 1.

image::images/bpmn-scenario1.png[width=1100]

[cols="1s,5",options="header"]
|====
|Scenario number
|1

|Name
|Initial order from buyer

|Description
a|
* An order of numbered articles or services.
* The order instructs the seller of the delivery address.
|Parties involved
|Buyer +
Seller

|Assumptions
|Buyer and seller have a commercial agreement with general conditions for ordering of goods or services. +
They may also have exchanged a catalogue with product information and pricing.

|The flow
a|The buyer creates an Order with one or more lines. +
The seller receives the Order and send an Order Response Advanced and either

* Accepts to deliver the order without changes
* Accepts to deliver the order partially or with changes
* Rejects the order

If the seller accepts the order partially or with changes the buyer may either

* Accept the changes by sending an Order Change confirming the changes proposed by seller
* Reject the changes and cancel the order by sending an Order Cancellation

|Alternative results
a|
. The buyer and seller have reached an agreement on delivery of the order
. The order will be cancelled

|XML example file
|See Appendix A for example files for scenario 1
|====
Loading

0 comments on commit 79ba36a

Please sign in to comment.