| APPPLICATION RECEIPT ACKNOWLEDGEMENT v
2.0.2 |
|
|
|
| Problem
Statement |
|
To ensure a
reliable flow of
information between companies, Business Managers must be assured that
their trading partners receive GS1 Messages and are able to process
them without error. The GS1 Simple-eb specification calls for
the full choreography of messages to support business processes.
For example, the Order process calls for an Initiator to create an
Order document and a need to know it was received prior to back end
processingby the Responder’s business application.
This is what
we mean by The Responder will create an Application Receipt
Acknowledgement And Or ErrorApplication Receipt Acknowledgement
document for the Initiator to confirm that the Responder received the
Order document. This BRD does not deal with the additional separate
need for a business level Response (Acceptance, Modi-fication, or
Rejection) to an Order. So, for example, the Application Receipt
Acknowl-edgement (ARA) for an Order would not indicate that the
Responder plans to fulfill the order exactly as requested by the
Initiator e.g. with respect to quantity, price, etc. Rather the ARA
indicates receipt of the order document and optionally detection of
errors or warnings.
This choreography or, conversation ensures that trading partners are
aware that the process is progressing in a predictable
fashion. A
proper automated choreography allows trading partners to reduce
expensive safeguards and manual checks, to recognize data receipt and
errors quickly, and therefore smooth the flow of goods and services
through the supply chain.
|
|
| Objective |
|
To supply the
detail design of the
Application Acknowledgement Receipt Acknowledgement business
transaction needed to meet the requirements of the referenced BRAD(s).
|
|
| Audience |
|
Initiator
– organization responsible
for generating and sending an GS1 Business Message.
Responder – organization that receives and processes an GS1
Business Message. This organization is also responsible for
creating an XML Application Receipt Acknowledgment And Or
ErrorApplication Receipt Acknowledgement in reply to the received GS1
Business Message when applicable. A Responder may
out-source to an Agent to act on their behalf.
|
|
Business
Context
|
|
Industry:
All
Geopolitical:
All
Product:
All
Process: All
System
Capabilities:
EAN.UCC
Official
Constraints: None
|
|
Business
Transaction View
|
|
This Business Requirement Document
outlines the requirements and supporting processes for a business
application level acknowledgement of the receipt of a GS1 XML
message and optional indication of detected validation errors or
warnings.
|
|
| TOP |
|
| Business
Transaction Use Case
Diagrams |
|
 |
|
Application
Receipt
Acknowledgement Use Case Diagram
|
|
 |
|
Relations
to General Business Model
|
|
| TOP |
|
Use
Case
Description
|
|
| Use
Case Name: |
Initiator sending
directly to a
Responder |
| Use
Case Description: |
The Initiator
sends the intended
XML Instance Document (business message) within the context of a
Business Process and potentially and a multi-step
Collaboration.
The Responder upon receiving the XML Instance Document acknowledges
receipt (and optionally detects errors/warnings) at the SBDH,
Transaction, Command and/or Document hierarchical levels and responds
to the message Initiator. |
| Actors
(Goal): |
Initiator,
Responder |
| Performance
Goals: |
None
|
| Preconditions:
|
The Responder
receives message. |
| Postconditions: |
The message Initiator receives
the Application Receipt Acknowledgement, including optional
error/warning message(s). |
| Scenario: |
Begins when
1. The
Responder’s Back End application receives an XML Instance
Document (business message)
| Step
# |
Actor
|
Activity
Step |
| 2
|
|
The Responder continues by fully detecting all
possible errors/warnings in the business document.
|
| 3
|
|
The Responder determines how they will uniquely
identify the business document(s) for which errors/warnings were
detected back to the Initiator. |
Ends
when
4. The
Responder generates and sends the Application Receipt
Acknowledgement message back to the Initiator
|
Alternative
Scenario:
|
N/A
|
Related
Requirements:
|
N/A
|
Related
Rules:
|
N/A
|
| Use
Case Name: |
Agreement to use
the Application
Receipt Acknowledgement |
| Use
Case Description: |
When
Trading partners agree to
use the Application Receipt Acknowledgement message, they must agree
what actions will be taken should Acknowledgements not be received
within the normal course of business. The Trading Partners
must
decide whether they will enforce a
‘Time To
Acknowledge Receipt’ and if so, what actions
will be taken if
the lead time lapses before an Acknowledgement is received by the
Initiator. The Trading Partners must also decide whether they
will enforce the optional ‘Is
Application Error
Response Requested’ choreography. |
| Actors
(Goal): |
Responder:
To be assured that
both parties understand the full process being im-plemented and what
actions are to be taken if the expected outcome is not achieved
Initiator: To be assured that both parties understand the full process
being imple-mented and what actions are to be taken if the expected
outcome is not achieved |
| Performance
Goals: |
None,
this is a business
agreement between trading partners |
| Preconditions:
|
Responder
and Initiator must
agree to use the Application Receipt Acknowledgement. |
| Postconditions: |
The
Responder and Initiator
agree on a full process that includes the Application Receipt
Acknowledgement and all potential outcomes. |
| Scenario: |
Begins when
1. The Responder and Initiator agree to use the Application
Receipt Acknowledge-ment message.
Continues
with...
Step
|
Actor
|
Activity Step
|
2
|
Initiator
& Responder
|
Agree
on the duration of the Acknowledgement Receipt Lead Time period.
|
3
|
Initiator
& Responder |
Agree
whether to use the ‘Is
Application Error Response Requested’ choreography.
|
4
|
Initiator
& Responder |
If
a Time To Acknowledge
Receipt is to be enforced, they agree on the steps to be taken if an
Application Receipt Acknowledgement is not received within
the
agreed time period.
|
5
|
Initiator
& Responder |
Agree
on the steps to be
taken if an Application Receipt Acknowledgement is not received.
|
6
|
Initiator
& Responder |
Agree
on the steps to be
taken if Errors or Warnings are detected
|
Ends
when
7. Responder and Initiator have full agreement on their
process.
|
|
Alternative
Scenario:
|
N/A
|
Related
Requirements:
|
When a
message is sent, the
Initiator requires an answer from the Responder that the Business
Message has been received. |
Related
Rules:
|
- Acknowledgement
Receipt Lead Time existence: The Initiator and Responder
must
agree on an Acknowledgement Lead Time.
- Acknowledgement
Receipt Lead Time rule: Prior to the lapse of
the Time to
Acknowledge Receipt Lead Time, the Initiator must have received the
Application Receipt Acknowledgement.
- The
Initiator and Responder must
agree whether the Application Receipt
Acknowledgement will be used in their individual collaborations.
- The
Initiator and Responder may
agree on specific processes to be performed
should an Acknowledgement not be received within the agreed
Acknowledgement Lead time.
|
|
|
|
| TOP |
|
| Business
Transaction Activity Diagram |
|
|
|
TOP
|
|
| Business
Transaction Sequence Diagram |
|
| Not available |
|
| |
|
| Implementation
Considerations |
|
| Example - Business Document |
|
