EUROPEAN COMMISSION
DIRECTORATE-GENERAL
INFORMATICS
Information systems Directorate
European Commission
e-PRIOR Use Case Specification: Status Request
Date:
27/03/2009
Version:
0.012
Authors:
João Rodrigues Frade
Revised by:
Technical Review:
Quality Review:
Maarten Daniels
Approved by:
Public:
Reference Number:
Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) 299 11 11.
Commission européenne, L-2920 Luxembourg. Telephone: (352) 43 01-1.
TABLE OF CONTENTS
1. USE-CASE DESCRIPTION .................................................................................................................... 1
1.1. Functional Features List ........................................................................................................................... 1
2. FLOW OF EVENTS ................................................................................................................................. 1
2.1. B1: Basic Flow ........................................................................................................................................ 1
2.1.1. User submits message ........................................................................................................................... 1
2.1.2. System checks conformance to the message schema rules.................................................................... 1
2.1.3. System queries the message repository ................................................................................................. 1
2.1.4. System builds the Status Response ....................................................................................................... 2
Variations of Data used in the Basic Flow (Same Behavior is expected) ....................................................... 2
2.2. SubFlows ................................................................................................................................................. 3
2.3. Alternative Flows ..................................................................................................................................... 3
2.3.1. A1: At step 2.1.4 "System builds the Status Response" no document matches the query
criteria ................................................................................................................................................. 3
2.4. Exceptional Flows.................................................................................................................................... 3
2.4.1. E1: At step 2.1.1 "User submits message" the system is down ............................................................. 3
2.4.2. E2: At step 2.1.4 "System builds the Status Response" there is a technical error reported
regarding the connection with the supplier ......................................................................................... 3
2.4.3. E3: At step 2.1.2 "System checks conformance to the message schema rules" XSD
constraints are broken ......................................................................................................................... 3
3. SPECIAL REQUIREMENTS ................................................................................................................. 4
3.1. Interface(s) with other Systems ................................................................................................................ 4
3.2. Security Requirements ............................................................................................................................. 4
3.3. Other Non Functional Features ................................................................................................................ 4
3.4. Constraints ............................................................................................................................................... 4
4. PRECONDITIONS................................................................................................................................... 4
5. POSTCONDITIONS ................................................................................................................................ 4
5.1. Postcondition One .................................................................................................................................... 4
6. ADDITIONAL INFORMATION ............................................................................................................ 4
6.1. e-PRIOR documents hierarchy ................................................................................................................ 4
6.2. Example 1 ................................................................................................................................................ 5
6.3. Example 2 ................................................................................................................................................ 6
e-PRIOR Use Case Specification: Status Request -
Page i
Document History
Version
Date
Comment
Modified Pages
0.001
14/05/2008
Creation
All
0.002
19/05/2008
Implementation of internal comments
As required
0.003
20/05/2008
Examples added
As required
0.004
01/07/2008
The essential parameters of the status request of a
business document are changed to encompass the
Interchange Agreement parameter
Section 2.1.3.
0.005
04/07/2008
The essential parameters of the status request of a Section 2.1.3.
business document are changed to encompass the
Supplier Agreement parameter not the Interchange
Agreement parameter
0.006
15/07/2008
Implementation of comments from pre-Kick off
meeting
As required
0.007
25/08/2008
Update of Use Case following Kick-Off meeting
with George Vaicar
Chapter 6 –
Additional
Information²
0.008
20/10/2008
Update of the document to cater for the possibility
of information being returned for two business
documents sent with the same ID.
As required
Document renamed to "Status Request"
0.009
21/10/2008
Minor improvements
As required
0.010
05/11/2008
The following note has been removed:
Basic Follow
Note: The request message XML Schema Design
may contain additional information, such as the
document Issue Date - this is not a problem however this additional information will not be
used by the system.
0.011
23/11/2008
Minor Corrections
0.012
20/03/2009
Cross-references to SOAP Faults documents
e-PRIOR Use Case Specification: Status Request -
As required
Page ii
1. USE-CASE DESCRIPTION
The system supports the request of a business document status. The business document must
have been submitted via electronic means.
1.1. Functional Features List
Phase: Phase 1
Cross-Functional Support of a technical and/or business response to every request
Cross-Functional Supported response types
Information Query of business documents status
Cross-Functional Control of the data in all requests and responses
Cross-Functional Support of hard and soft business rules
Cross-Functional Accurate rejection notification
Data Code tables support
Security Restricted access to data based on the ownership of the data item
2. FLOW OF EVENTS
The details of each message and SOAP Faults can be found in svn:
https://svn.forge.osor.eu/svn/openeprior/trunk/Analyses and design/Data Model/XML_Data_Dictionary
2.1. B1: Basic Flow
2.1.1. User submits message
 This use case starts when the User submits a message to the Request Status service end-point.
This opens an https connection between the User and the system.
 Include Use Case “User Access” to authenticate and authorize access to the User.
Note: The request message contains the request for a single business document.
2.1.2. System checks conformance to the message schema rules
 The system validates the message against the Request Status XML Schema Design rules (i.e.
data types, mandatory/ optional data elements and attributes, data elements multiplicity).
2.1.3. System queries the message repository
 The essential parameters for the system to perform the status request of a business document
are provided below:
 The Supplier Agreement (parameter derived from the UserID
- provided at
authentication - and the SupplierID of the Requester – provided in the message header)
 The Document ID (parameter found in the request message)
 The Document Type Code (parameter found in the request message)
The system queries for documents:
 With a specific Supplier Agreement and
 Of a specific Document Type Code (e.g. 380 for Commercial Invoice) and with
e-PRIOR Use Case Specification: Status Request -
Page 1 / 6
 A specific Document ID
2.1.4. System builds the Status Response
 Based on the result of the previously mentioned query, the system builds the Status Response.
For documents matching the previously mentioned criteria, the following information is
returned on the status response:
 The ID of the (matching) document
 The Document Type Code of the (matching) document
 The Status Code of the (matching) document
 The Issue Date of the (matching) document
 The Response Code (applicable for a response message only)
Note: There could be one or more matching documents. When several matching documents exist
then only one of them has a Status Code different than "REJECTED". However, all of them may
be in "Rejected" status. When the Status Request is made right after the documents submission,
it may happen that these documents are still in the state "RECEIVED".
 If existing, information on the document or documents related to the matching document
is also returned:
 The ID of the (related) document
 The Document Type Code of the (related) document
 The Status Code of the (related) document
 The Issue Date of the (related) document
 The Response Code (applicable for a response message only)
Note: The matching document may have zero or more documents related to it. When the
matching document is in the state "REJECTED" or "PROCESSED", it should at least have one
related document (i.e. the Application Response).
For a given matching document, several related documents of the same type may exist. The
typical example is Attached Document messages.
For a given matching document, several related documents of the same type and the same ID
may exist. If this happens then only one of them has a Status Code different than "REJECTED".
However, all of them may be in "REJECTED" status. When the Status Request is made right
after the documents submission, it may happen that these documents are still in the state
"RECEIVED".
For a given matching document, the list of related documents only displays the documents that
contain a direct reference to the matching document (i.e. the level below of the hierarchy). For
additional information on the document's hierarchy, the reader should have a look at chapter 6
Additional Information.
 System responds with a Status Response to the Request.
 This closes the https connection between the User and the system.
 Use Case Ends.
Variations of Data used in the Basic Flow (Same Behavior is expected)
B2
Matching document with no related documents.
e-PRIOR Use Case Specification: Status Request -
Page 2 / 6
B3
When the matching document is in the state "REJECTED" or "PROCESSED", it should at
least have one related document (i.e. the Application Response).
B4
For a given matching document, several related documents of the same type may exist.
B5
For a given matching document, several related documents of the same type and the same
ID may exist. If this happens then only one of them has a Status Code different than
"REJECTED".
B6
There could be one or more matching documents. When several matching documents exist
then only one of them has a Status Code different than "REJECTED".
B7
For a given matching document, the list of related documents only displays the documents
that contain a direct reference to the matching document (i.e. the level below of the
hierarchy).
2.2. SubFlows
 Not identified.
2.3. Alternative Flows
2.3.1. A1: At step 2.1.4 "System builds the Status Response" no document matches the
query criteria
 No document is found in the message repository matching the previously mentioned criteria.
When no document matches the previously mentioned criteria, the following information is
returned on the status response:
 A note stating that "No matches were found"
 System responds with a Status Response to the Request.
 This closes the https connection between the User and the system.
 The Use Case Ends.
Note: This may also happen should the Status Request for Invoice ID "009" contain ID "9".
2.4. Exceptional Flows
2.4.1. E1: At step 2.1.1 "User submits message" the system is down
 The User receives a 503 Service Unavailable
 The Use Case Ends.
2.4.2. E2: At step 2.1.4 "System builds the Status Response" there is a technical error
reported regarding the connection with the supplier
 The system detects when a supplier closes its connection. In this case the system cannot
respond to the subsequent request.
 The Use Case Ends.
2.4.3. E3: At step 2.1.2 "System checks conformance to the message schema rules" XSD
constraints are broken
 When broken XSD constraints are reported (1 or more), the following information is
returned:
 System submits a SOAP Fault [6]
e-PRIOR Use Case Specification: Status Request -
Page 3 / 6
 This closes the https connection between the User and the system.
 The Use Case Ends.
 The Use Case Ends.
3. SPECIAL REQUIREMENTS
3.1. Interface(s) with other Systems
 Suppliers' system
3.2. Security Requirements
The reader should refer to chapter 1.1 Functional Features List of subtype "Security"
3.3. Other Non Functional Features
Phase 1
Non Functional: Usability Exposure of an applications interface for data communications
Non Functional: Usability Exchanged data in pre-agreed structure and format
Phase 2b
Non Functional: Reliability Use of SLAs
3.4. Constraints
Phase 1
Constraint: Implementation Open standards support
Phase 2a
Constraint: Interface Support of Unicode Encoding
Phase 2b
Functional, Constraint: Regulation Retention period of data storage
4. PRECONDITIONS
There are currently no preconditions defined.
5. POSTCONDITIONS
5.1. Postcondition One
Following the basic flow the system responds to the Status Request with a Status Response.
6. ADDITIONAL INFORMATION
6.1. e-PRIOR documents hierarchy
The e-PRIOR document hierarchy is depicted below.
e-PRIOR Use Case Specification: Status Request -
Page 4 / 6
ePrior Documents Hierarchy
Request
Level 0
Order
1
Order
Cancellation
0...1
Order
Response
OrderProposed
Change
0...1
0...1
0...n
Order
Confimation
0...n
0...1
Order
Response
Simple
Order
Change
Level 1
1
1
0...1
0...1
Order
Response
Order
Response
0...1
Order
Response
Simple
0...n
Invoice
1
Level 2
0...n
0...1
Attached
Doc
0...n
Application
Response
0...1
Credit
Note
1
1
Level 3
0...1
0...1
0...n
Attached
Doc
Application
Response
Application
Response
Level 4
1
0...1
Application
Response
Level 5
The documents coloured in yellow are the outbound documents of the e-Invoicing and eOrdering Project. The reader should note that the Application Response must be present when
the matching document is in a state such as "Rejected" or "Processed". A few examples are
provided in the next sections, the examples are run-time examples which intend to clarify the
behaviour of this service.
6.2. Example 1
Having the above in mind, the table below provides an example of a status response produced on
16/05/2009 for Invoice ID 5000:
ID
Document Type Code
Status Code
Issue Date
Response Code*
5000
380 for Invoice
2 for Processed
25/04/2009
Not applicable
Issue Date
Response Code*
These are the related documents to this document:
ID
Document Type Code
e-PRIOR Use Case Specification: Status Request -
Status Code
Page 5 / 6
200
916 for Related Document
(a.k.a Attachment)
2 for Processed
01/05/2009
Not applicable
3000
301 Application Response
2 for Processed
09/05/2009
380:2 for Invoice
Disputed
1500
81 for Credit Note related
to goods or services
2 for Processed
10/05/2009
Not applicable
It should be noted that the Application Response for the Credit Note is not listed above. This is
the correct behaviour; this information will only be provided in the Status Request/Response
related to this Credit Note. The table below provides an example of a status response produced
on 16/05/2009 for Credit Note ID 1500:
ID
Document Type Code
Status Code
Issue Date
Response Code*
1500
81 for Credit Note related
to goods or services
2 for Processed
25/04/2009
Not applicable
These are the related documents to this document:
ID
Document Type Code
Status Code
Issue Date
Response Code*
3020
301 Application Response
2 for Processed
14/05/2009
81:1 for Credit
Note approved
6.3. Example 2
The table below provides an example of a status response produced on 17/05/2009 for Invoice
ID 5020:
ID
Document Type Code
Status Code
Issue Date
Response Code*
5020
380 for Invoice
1 for Received
17/05/2009
Not applicable
These are the related documents to this document:
ID
Document Type Code
Status Code
Issue Date
Response Code*
9
916 for Related
Document (a.k.a
Attachment)
1 for Received
17/05/2009
Not applicable
10
916 for Related
Document (a.k.a
Attachment)
1 for Received
17/05/2009
Not applicable
* Response Code indicates the Response Code in the Application Response.
e-PRIOR Use Case Specification: Status Request -
Page 6 / 6