Party Synchronisation v. 2.0.2

XML Standards	>	Party Synchronisation Messages

Message Description

PARTY SYNCHRONISATION v. 2.0.2

Problem Statement

Substantial effort has been made to develop a Global Data Synchronisation process because master data sharing between partners is both complex and fundamental to all supply chain processes. Integrity and timeliness of master data is critical to the flow of goods, services and information throughout the chain. Sharing data effectively and efficiently relies on access to common data definitions, data accuracy and agreement on the processes used to exchange data. This process is termed Master Data Synchronisation.
The salient points for synchronisation are:

synchronisation is a process
it is auditable
the process must utilize EAN·UCC industry standards
the data exchanged must be compliant with these standards
the recipient must acknowledge the integration of the data
continuous updates must be applied

Party information is a part of Master Data. Trading Partner’s involved with the Global Data Synchronisation Network (GDSN) require data regarding party (GLN) information to determine the unique identification, the role definition, the business process capability and the message capability required to function in the network defined to achieve Master Data Synchronisation.
The process requirements for synchronisation of Party information within the Global Data Synchronisation Network should include:

Manage a Data Pool Profile
Load and Update Party Data within a Data Pool
Load and Update Party Data within the Global Registry
Manage Party Data in the Global Registry
Manage Party Distribution Criteria
Distribute Data Recipient Requests
Distribute Party Data

The data requirements for synchronisation of Party information within the Global Data Synchronisation Network should include:

The attributes defined in the most current version of the Party data model defined through EAN.UCC’s GSMP
GLN as mandatory choice for Party Identification
At least one role of Party as mandatory, allowing additional roles
At least one Business Process identification and one Message Identification used to define the capability of the party
Subscription criteria available by:

GLN
Role
Process Capability
Trade Item Classification

Objective

To supply the detail design of a Global Data Synchronisation Network business transaction needed to meet the requirements of the referenced BRAD(s).

Audience

The audience of this standard is any participant in the global supply chain. This includes retailers, manufacturers, service providers and other third parties.

Business Context

Industry: All
Geopolitical: All
Product: All
Process: Align
System Capabilities: EAN.UCC
Official Constraints: None

Business Process View

Background

Unlike the Catalogue Item Data Synchronisation definition phase of the Global Data Synchronisation Network, with the experience of UCCnet users and the GCI Data Synchronisation documents, the path to Party Data Synchronisation was uncharted.
There were many discussions ranging from the most simple to the most complex methods of synchronising Party information:

The easiest method was simply synchronising the GLN information (name, address, etc.) as shown above on the left.
The most complex method was to build and maintain GLN defined organizational hierarchies keyed with GLN and assigning:

A role
A hierarchical/organizational/relationship type
A containment or linking capability

When discussing the functionality and relationship of roles and hierarchies for a GLN, it became clear that even with a definition of a role, e.g. Store - a physical entity that sells trade items to a consumer, it was complicated to determine a specific organization hierarchical level to identify a business process for the role. Party Roles relate to a general concept, but do not clarify the identification of the business process. For example: when Role = Store, then we must ask:

can this store receive goods?
can it receive DSD goods?
can it pay for those goods?
can it order goods?

Party Synchronisation Resolution

Initially, the focus within this Party Data Synchronisation (BRD) business requirements document is on the process of Item Data Synchronisation. To accomplish the synchronisation of item data, party data synchronisation can be accomplished with two additional classes of data (Process Capability and Message Capability) included in the synchronisation messages required within the Global Data Synchronisation Network.
The team discussed a framework to support future maturity beyond the process of Item Data Synchronisation to accommodate the different business processes such as Pricing, Ordering, Delivery, and etcetera. These maturities are not included in this first publication of party data synchronisation. However, the team has defined a framework for future enhancements to this party synchronisation process.
The initial Party Data Synchronisation solution is to synchronise party (GLN) information for the process of item and party synchronisation, and build a framework to allow for future maturity levels.

Most importantly, the solution will NOT require modifications to the Party BRD, Version 7.1, but can be accomplished with 2 classes of data (Process Capability and Message Capability) included with the synchronisation messages required within the Global Data Synchronisation Network.
The solution is scalable for future process requirements, eliminates the need for strict, globally defined organization hierarchical levels, and meets the ebXML context category methodology.
The enhanced maturity levels for future consideration are pictured below:

Guiding Principles for Party Synchronisation Requirements

The GS1 Data Synchronisation project team recommends the following guiding principles for the Party Synchronisation Requirements:

All change requests that impact the existing GS1 standards and Industry sector guidelines endorsed by GS1 must go through the GS1 GSMP.
The criteria for Party Synchronisation (attributes that are determined to be synchronised within the process) will be defined and consistent for all participants in the GDSN
The Party Synchronisation Requirements will include criteria maintained at the Global Registry. The requirements assume that the data required by the Global Registry for this process is provided by the datapools and the Trading Partners in its entirety and is standards compliant.
The Party Synchronisation definition adheres to the guiding principles documented in the BRD of the Catalogue Item Synchronisation.
The Global Registry shall encompass the physical infrastructure to facilitate the Party Synchronisation functionality.
The Party Synchronisation functionality will be made available to any member or potential member of the Global Data Synchronisation Network, facilitated through the datapools; or any entity connected with the process in any way. This is to allow Data Sources, Data Recipients and others the ability to synchronise party information within the GDSN.
Party Synchronisation Requirements will be managed through the GS1 GSMP process. This will be the mechanism for all change management associated with Party Synchronisation.
Party Synchronisation may produce new attributes to be included in the GS1 Data Model. If this is to be the case, a Change Request must be submitted to formally address these Requirements.
Hierarchical content and Process Capabilities will be addressed in these Party Synchronisation Requirements.
Each Acknowledgment is returned as part of the party synchronisation process. If errors exist, every error must have a unique error code. Each error code will be accompanied by a text field (initially error text will be in Oxford English). Datapools may translate as a value add.
The choreography for Datapool to Datapool interaction must be defined. The process flow includes the Registration of the Party information. The process flow also includes the ability for Datapools to interoperate in the GDSN.
The concept of requesting information from a Data Source is essential for party synchronisation functionality to fit into the overall GDSN functionality.

Business Transaction View

Use Case Overview

Figure 3 - Party Synchronisation Use Case Overview Use Case Diagram

Use Cases Triggering Other Use Cases

Depending on additional factors, a Use Case may trigger the initiation of another Use Case. An example of this is when a Party is added to a Data Pool which initiates the Registration of that party in the Global Registry and, depending on existing Publications and Subscriptions, may initiate the distribution of that Party data to the Data Recipient.The following spreadsheet shows which subsequent Use Cases each Use Case has the potential to trigger. The preconditions of the triggered Use Case must be satisfied for the Use Case to actually be initiated.

Use Case Overview - High Level

The following figure depicts a high level view of the Global Data Synchronisation Network, it’s participants and the major data flows that support Party Data Synchronisation.

Figure 4 - The Global Data Synchronisation Network and Party Synchronisation

Use Case Scenarios Synchronise Party Data

Figure 4 - Synchronise Party Data Use Case Diagram

Process Use Case Name	Synchronise Party Data
Use Case Identifier (Traceability)	UC-50
Use Case Description	The process of continuous harmonisation of Party information between all trading partners within the supply chain through the use of Align Data standards. The salient points for synchronisation are: synchronisation is a process it is auditable must utilise EAN·UCC industry standards the data exchanged must be compliant with these standards the recipient must acknowledge the integration of the data continuous updates must be applied The Summary and Detail Use Cases of this process are further defined and identified below.
Summary Use Cases	UC-51: Load and Update Party Data to Data Pool UC-59: Manage Party Data in Global Registry UC-53: Manage Party Distribution Criteria UC-70: Distribute Requests for Party Data UC-71: Distribute Party Data
Detail Use Cases	See Summary Use Cases for identified Detail Use Cases
Actors	Data Source (DS) Source Data Pool (SDP) Global Registry (GR) Recipient Data Pool (RDP) Data Recipient (DR)
Performance Goals	Data Source: To have Party Data available to Data Recipients. Source Data Pool: To ensure Data Source provided Party Data is searchable and available to Recipient Data Pools. Recipient Data Pool: To find Party Data that matches the Data Recipient’s search or subscription criteria. Data Recipient: To obtain Party Item Data of their trading partners. Global Registry: To ensure that Party Data can be found by Recipient Data Pools.
Preconditions	Actors are participants of the Global Data Synchronisation Network.
Postconditions	Party Data is available to participants of the Global Data Synchronisation Network.
Scenario	See Figure in Section 2.7 “The Global Data Synchronisation Network (GDSN) for Party Synchronisation”
Alternative Scenario	None
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	See Business Requirement table for Party Synchronisation

Load and Update Party Data to Data Pool (UC-51)

Figure 5 - Load and Update Party Data to Data Pool Use Case Diagram

Summary Use Case Name	Load and Update Party Data to Data Pool
Use Case Identifier (Traceability)	UC-51
Use Case Description	The process of continuous harmonisation of Party information between a Data Source and his Data Pool. A Data Source is required to notify his Data Pool of the state of the Party Data with the following values: Canceled – A term describing a maintenance function used to communicate that a Party GLN was not introduced into the complete GDSN, allowing for reuse of the GLN in accordance with the EAN.UCC GLN Allocation rules. Discontinued – A term describing a maintenance function used to communicate the permanent removal of a Party GLN and data from the GDSN, beginning the trigger to track the EAN.UCC retention period for GLN reuse. In_Process – A term describing a maintenance function used to communicate the intent of registering a Party GLN and data to the Global Registry. New – A term describing a maintenance function used to communicate the first time use of the Party GLN and data. As a Summary Use Case, specific processes are further defined in the Detail Use Cases identified below.
Process Use Case	UC-50 Synchronise Party Data
Detail Use Cases	UC-56: Add Party Data to Data Pool UC-57: Change Party Data in Data Pool UC-58: Remove Party Data from Data Pool
Actors	Data Source (DS) Data Pool (DP)
Performance Goals	Data Source: To have Party Data available to Data Recipients. Data Pool: To ensure Data Source provided Party Data is searchable and available to Data Recipients.
Preconditions	The Data Source and Data Pool must have entered into a working relationship. The Data Pool must be certified within the Global Data Synchronisation Network (GDSN).
Postconditions	Party Data is captured and maintained within the Data Pool for the Data Source. In the case of a removal, the Party Data is removed from the Data Pool and no longer available to Data Recipients.
Scenario	Begins when, the Data Source sends, to their Data Pool, either Party data to be added or changed, or an indication of which Party data to remove. 1. The DP validates that the message was received from a valid DS 2. The DP acknowledges receipt of the DS’s Party data 3. The DP validates the Party data 4. The DP updates their copy of the DS’s data 5. The DP notifies the DS that the Party data was processed successfully 6. The DS receives the DP’s notification 7. The DS acknowledges receipt of notification to the DP Ends when, the Data Pool receives the Data Source’s acknowledgement
Alternative Scenario	ad 1. Message not sent by valid DS: 1.1. DP does not process the message ad 3. Validation fails: 3.1. DP sends an error message to the DS Ends when, the Data Source receives the error message ad 4. Update fails: 4.1. DP sends an error message to the DS Ends when, the Data Source receives the error message ad 6. DS does not receive Success Notification from DP: 6.1. DS may choose to send the Party data again 6.2. DS must contact the DP regarding the status of the Party Data Ends when, the Data Source and Data Pool resolve the status of the original Party data ad 7. Data Pool does not receive acknowledgement of success notification: 7.1. DP may choose to notify the DS again 7.2. DP must contact the DS regarding the status of the notification Ends when, the Data Pool and Data Source resolve the status of the original Party Data
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	See Detail Use Cases #56, 57, 58 for Business Requirements identification

Figure 5 - Load and Update Party Data to Data Pool Sequence Diagram

Add Party Data to Data Pool (UC-56)

Figure 6 - Add Party Data to Data Pool Use Case Diagram

Detail Use Case Name	Add Party Data to Data Pool
Use Case Identifier (Traceability)	UC-56
Use Case Description	The Add Party Data use case describes what activities need to happen to validate and register Party data. After the Party data is validated and registered, it can then reside in the Source Data Pool for distribution.
Actors	Data Source (DS) Source Data Pool (SDP) Global Registry (GR)
Summary Use Case	UC-51 Load and Update Party Data to Data Pool
Detail Use Cases	None
Performance Goals	Data Source: To have validated, registered Party data in their Source Data Pool. Source Data Pool: To have validated, registered Party data. Global Registry: To ensure valid, unique Party data is registered.
Preconditions	Data Source has defined Party data.
Postconditions	Data Source knows that Party data has been validated and registered.
Scenario	Begins when, the Data Source sends, to the Source Data Pool, Party data. 1. The SDP receives the Party data 2. The SDP acknowledges receipt of Party data 3. The SDP validates the Party data 4. The SDP loads the Party data 5. The SDP sends the Registry Party data of Party data to the GR for registration 6. The GR receives the Registry Party data 7. The GR validates the Registry Party data for uniqueness 8. The GR registers the Registry Party data 9. The GR sends a registration response to the SDP 10. The SDP receives the registration response 11. The SDP stores the registration response information 12. The SDP sends a success notification to the DS 13. The DS acknowledges receipt of success notification Ends when, the Source Data Pool receives acknowledgement receipt of success notification.
Alternative Scenario	ad 2. Validation fails. 2.1. SDP sends an error message to the DS Ends when, the Data Source receives the error message ad 7. Validation fails at the GR 7.1. GR sends an error message to the SDP 7.2. The SDP receives the error message 7.3. The SDP sends an error message to the DS Ends when, the Data Source receives the error message ** SDP may not send Party data to GR for uniqueness check w/o Registration request.
Special Requirements	Data Source is using a (source) data pool.
Extension Points	N/A
Requirements Covered	Business Requirement # 199, 206, 208, 209, 210, 211, 220, 221, 222, 223, 226, 227, 230, 231, 232, 258

Figure 7 - Add Party Data to Data Pool Sequence Diagram

Change Party Data in Data Pool (UC-57)

Figure 8 - Change Party Data in Data Pool Use Case Diagram

Detail Use Case Name	Change Party Data in Data Pool
Use Case Identifier (Traceability)	UC-57
Use Case Description	The Change Party Data use case describes what activities need to happen to change existing Party data within a Source Data Pool, whether the Party has been registered or not.
Summary Use Case	UC-51: Load and Update Party Data to Data Pool
Detail Use Cases	None
Actors	Data Source (DS) Source Data Pool (SDP) Global Registry (GR)
Performance Goals	Data Source: To change Party data in their Source Data Pool. Source Data Pool: To have validated, registered updated Party data. Global Registry: To ensure valid, unique Party data is registered.
Preconditions	Data Source has defined the changes to existing Party data within a Source Data Pool.
Postconditions	Data Source knows that updated Party data has been validated and registered.
Scenario	Begins when, the Data Source sends, to the Source Data Pool, Party data to be changed. 1. The SDP receives Party data to be changed 2. The SDP validates Party data to be changed 3. The SDP loads the changed Party data 4. The SDP sends the Registry Party data (to be changed) to the GR 5. The GR receives the Registry Party data to be changed 6. The GR validates the Registry Party data 7. The GR registers the changed Registry Party data 8. The GR sends a registration response to the SDP 9. The SDP receives the registration response 10. The SDP stores the registration response information 11. The SDP sends a success notification to the DS 12. The DS acknowledges receipt of success notification Ends when, the Source Data Pool receives the acknowledgement from Data Source
Alternative Scenario	ad 2. Validation fails: Party data not loaded 2.1. SDP sends an error message to the DS Ends when, the Data Source receives the error message ad 6. Validation fails at the GR: Registry Party data not registered 6.1. GR sends an error message to the SDP 6.2. The SDP receives the error message 7.3. The SDP sends an error message to the DS Ends when, the Data Source receives the error message ** SDP may not send Party data to GR for uniqueness check w/o Registration request.
Special Requirements	Data Source is using a (source) data pool.
Extension Points	N/A
Requirements Covered	Business Requirement # 200, 220, 221, 223, 258

Figure 9- Change Party Data in Data Pool Sequence Diagram

Remove Party Data from Data Pool (UC-58)

Figure 10- Remove Party Data from Data Pool Use Case Diagram

Detail Use Case Name	Remove Party Data from Data Pool
Use CaseIdentifier (Traceability)	UC-58
Use Case Description	This use case describes the process that should be considered to remove Party Data from the Global Data Synchronisation Network. This process (UC-58) is triggered from UC-57, Change Party Data in Data Pool, with the Party Notification State defined as Discontinued and a value in discontinueDate.
Summary Use Case	UC-51: Load and Update Party Data to Data Pool
Detail Use Cases	None
Actors	Data Source (DS) Source Data Pool (SDP) Global Registry (GR)
Performance Goals	Data Source: To be able to remove Party Data from the Source Data Pool and from the Global Registry. Source Data Pool: To remove Party Data upon request of the Data Source. Global Registry: To remove Party Data upon request of a Source Data Pool.
Preconditions	The Data Source has identified the Party Data to be removed.
Postconditions	The Data Source Party Data has been removed from the network.
Scenario	Begins when, the Data Source notifies Source Data Pool of the Party Data to be removed ,via the process defined in UC-57, Change Party Data in Data Pool with the Party Notification State defined as Discontinued and a value in discontinuedDate. 1. The GR removes the Registry Party data based on discontinuedDate (see UC-62). 2. The GR sends a registration response to the SDP 3. The SDP receives the registration response 4. The SDP validates the discontinuedDate 5. The SDP removes the Party Data 6. The SDP notifies the DS that the Party Data has been removed 7. The DS acknowledges receipt of notification from SDP 8. The SDP receives acknowledgement of receipt Ends when, the Source Data Pool receives the receipt acknowledgement from the Data Source
Alternative Scenario	None
Special Requirements	A deletion cannot be reversed
Extension Points	N/A
Requirements Covered	Business Requirement # 220, 221, 223, 258

Figure 11 - Remove Party Data from Data Pool Sequence Diagram

Manage Party Data in Global Registry (UC-59)

Figure 12 - Manage Party Data in Global Registry Use Case Diagram

Summary Use Case Name	Manage Party Data in Global Registry
Use Case Identifier (Traceability)	UC-59
Use Case Description	This use case describes the processes that need to take place for Party Data to be registered and managed in the Global Registry. A Data Source is required to notify his Data Pool of the state of the Party Data with the following values: Canceled – A term describing a maintenance function used to communicate that a Party GLN was not introduced into the complete GDSN, allowing for reuse of the GLN in accordance with the EAN.UCC GLN Allocation rules. Discontinued – A term describing a maintenance function used to communicate the permanent removal of a Party GLN and data from the GDSN, beginning the trigger to track the EAN.UCC retention period for GLN reuse. New – A term describing a maintenance function used to communicate the first time use of the Party GLN and data. Registered – A term describing a maintenance function used to communicate that a Party GLN and data has met the validation requirements for acceptance to the Global Registry. As a Summary Use Case, specific processes will be further defined in the Detail Use Cases identified below.
Process Use Case	UC-50: Synchronise Party Data
Detail Use Cases	UC-60: Register Party UC-61: Change Registered Party UC-62: Remove Registered Party ***************************** The 2 Use Cases below will be defined in the Validation Process Definition at a future date: UC-32: Validate Data Pool UC-64: Validate Party Data for Registry
Actors	Source Data Pool (SDP) Global Registry (GR)
Performance Goals	Source Data Pool: To have validated, registered Party data. Global Registry: To ensure valid, unique Party data is registered.
Preconditions	The Source Data Pool has access to the Data Source Party Data
Postconditions	Party data is registered and the Source Data Pool receives a registration notification.
Scenario	Begins when, the Source Data Pool intends to register Party data received from the Data Source. 1. The SDP sends the Registry Party data to the GR 2. The GR validates the Registry Party data 3. The GR sends a registration response to the SDP Ends when, the Source Data Pool receives the registration response
Alternative Scenario	ad 2. Registry Validation fails: 2.1. GR sends an error message to the SDP 2.2 The SDP receives the error message Ends when, the Source Data Pool receives the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	See Detail Use Case #’s 60, 61, 62, 32* & 64* for Business Requirement Identification Note: Use Case 32 & 64 will be incorporated into the Validation Process BRD.

Figure 13 - Manage Party data in Global Registry Sequence Diagram

Figure 14 - Register Party Use case diagram

Detail Use Case Name	Register Party
Use Case Identifier (Traceability)	UC-60
Use Case Description	All Parties must be registered in the Global Registry. Prior to registration, the Party data must pass a validation at the Source Data Pool and a uniqueness check at the Registry. The Global Registry ensures that valid, unique Party data is available within the Global Data Synchronisation Network. This Use Case describes the Registration process that is performed by the Global Registry.
SummaryUse Case	UC-59: Manage Party Data in Global Registry
Detail Use Case	None
Actors	Source Data Pool (SDP) Global Registry (GR)
Performance Goals	Source Data Pool: To have validated, registered Party data. Global Registry: To ensure valid, unique Party data is registered.
Preconditions	The Source Data Pool is a certified Data Pool. The Source Data Pool has a profile that resides in the registry. The Source Data Pool has validated Party data received from a Data Source.
Postconditions	The Party data has been registered and retained by the Global Registry.
Scenario	Begins when, the Global Registry receives validated Party Data from a Source Data Pool. 1. The GR ensures that the SDP is certified. 2. The GR validates the Validation Certificate (from validation engine) sent with the Party data. 3. The GR verifies the uniqueness of the GLN. 4. The GR stores the Party data. Ends when, The Global Registry sends a registration response to the Source Data Pool
Alternative Scenario	ad 1. Data Pool not certified: 1.1. The GR sends an error message to the SDP Ends when, the Source Data Pool receives the error message ad 2. Validation certificate does not pass validation: 2.1. The GR sends an error message to the SDP Ends when, the Source Data Pool receives the error message ad 3. The Party already exists in the GR: 3.1. GR sends an error message to the SDP 3.2. The SDP receives the error message Ends when, the Source Data Pool receives the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 199, 201, 203, 206, 208, 209, 210, 211, 218, 219, 220, 221, 222, 223, 226, 231, 232, 233, 234, 235, 236, 258

Figure 15 - Register Party Sequence Diagram

Change Registered Party (UC-61)

Figure 16 - Change Registered Party Use Case Diagram

Detail Use Case Name	Change Registered Party
Use Case Identifier (Traceability)	UC-61
Use Case Description	In the event that Party data changes (see UC-57, Change Party Data in Data Pool Use Case) in a Source Data Pool, the changes must be reflected in the Global Registry.
Summary Use Case	UC-59: Manage Party Data in Global Registry
Detail Use Cases	None
Actors	Source Data Pool (SDP) Global Registry (GR)
Performance Goals	Source Data Pool: To have validated, registered Party data. Global Registry: To ensure valid, unique Party data is registered.
Preconditions	The Source Data Pool is a certified Data Pool. The Source Data Pool has a profile that resides in the registry. The Source Data Pool has received a “Change Registered Party” message from the Data Source. The Source Data Pool has validated Party data received from a Data Source and has sent that Party data and a Validation Certificate to the Global Registry. The Party data has been previously registered.
Postconditions	The Party data changes have been applied and retained in the Global Registry.
Scenario	Begins when, the Global Registry receives a validated Change Registered Party message from a Source Data Pool. 1. The GR ensures that the SDP is certified. 2. The GR validates the Validation Certificate (from validation engine) sent with the Party data from the SDP. 3. The GR ensures that the Party data already exists in the Registry. 4. The GR stores the Party data. Ends when, The Global Registry sends a registration response to the Source Data Pool
Alternative Scenario	ad 1. Data Pool not certified: 1.1. The GR sends an error message to the SDP Ends when, the Source Data Pool receives the error message ad 2. Validation certificate does not pass validation: 2.1. The GR sends an error message to the SDP Ends when, the Source Data Pool receives the error message ad 3. The Party data does not exist in the GR: 3.1. GR sends an error message to the SDP 3.2. The SDP receives the error message Ends when, the Source Data Pool receives the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 200, 219, 220, 221, 223, 237, 258

Figure 17 - Change Registered Party Sequence Diagram

Remove Registered Party (UC-62)

Figure 18 - Remove Registered Party Use Case Diagram

Detail Use Case Name	Remove Registered Party
Use Case Identifier (Traceability)	UC-62
Use Case Description	This use case describes the process to remove Party data from the Global Registry. This process takes place in the Global Registry and is triggered via UC-57, Change Party Data in Data Pool, with the Party Notification State defined as Discontinued and a value in discontinueDate and UC-58, Remove Party Data from Data Pool. The coordination of removing Party data from the Global Data Synchronisation Network is the responsibility of the Source Data Pool (triggered from a request of the Data Source) and the Global Registry. Recipient Data Pools and Data Recipients must have been notified via UC-73, Distribute Party Data and pre-defined synchronisation lists.
Summary Use Case	UC-59: Manage Party Data in Global Registry
Detail Use Cases	None
Actors	Source Data Pool (SDP) Global Registry (GR)
Performance Goals	Source Data Pool: To maintain validated, registered Party data. Global Registry: To ensure registered Party data is maintained.
Preconditions	The Party data has been previously registered. The Source Data Pool has received a request to remove Registered Party Data (UC-57) from the Data Source. The Source Data Pool has notified the Global Registry with “Change Registered Party” (UC-61).
Postconditions	The Party data has been removed from the Global Registry.
Scenario	Begins when, the discontinuedDate received from a previous notification has arrived. The GR validates the discontinuedDate of the Party data The GR removes the Party data The GR notifies the Source Data Pool that the Party data has been removed based on the discontinuedDate Ends when, the Source Data Pool receives notification from the Global Registry
Alternative Scenario	ad 1. The Party does not exist in the Registry: 1.1. GR sends an error message to the SDP 1.2. The SDP receives the error message Ends when, the Source Data Pool receives the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 219, 220, 221, 223, 238, 258

Figure 19 - Remove Registered Party Sequence Diagram

Manage Party Data Distribution Criteria (UC-53)

Figure 20 - Manage Party Data Distribution Criteria Use Case Diagram

Summary Use Case Name	Manage Party Data Distribution Criteria
Use Case Identifier (Traceability)	UC-53
Use Case Description	This Use Case describes the processes that need to take place for Party Publications, Subscriptions and Confirmations to be moved throughout the Global Data Synchronisation Network. As a Summary Use Case, specific processes will be further defined in the Detail Use Cases identified below.
Process Use Case	UC-50: Synchronise Party Data
Detail Use Cases	UC-65: Publish Party Data UC-66: Stop Publishing Party Data UC-67: Subscribe to Party Data UC-68: Remove Party Subscription UC-69: Confirm Party Data UC-72: Request Party Data UC-78: Create Party Schnronisation List
Actors	Data Source (DS) Source Data Pool (SDP) Global Registry (GR) Recipient Data Pool (RDP) Data Recipient (DR)
Performance Goals	Data Source: To have Party publications available to the Source Data Pool for matching with Subscriptions. Source Data Pool: To have the proper criteria (Publications, Subscriptions and Confirmations) to allow distribution of Party data to Data Recipients (via their Recipient Data Pool). Global Registry: To allow for the distribution of Party Subscriptions to the proper Source Data Pools. Recipient Data Pool: To ensure Party Subscriptions match the data that is being sent by Source Data Pools and requested by the Data Recipient. Data Recipients: To control the type and volume of Party Data received.
Preconditions	The Data Source has sent Party data to the Source Data Pool, and that data has been validated and Registered in the Global Registry
Postconditions	Party Data is available to subscription criteria
Scenario	Begins when, a Data Source creates a Publication and/or a Data Recipient creates a Subscription. SDP builds Synchronisation List based on distribution criteria RDP builds Synchronisation List based on distribution criteria Ends when, a Data Pool has built a Synchronisation List to accommodate Data Recipient criteria.
Alternative Scenario	N/A
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	See Detail Use Case #’s 65, 66, 67, 68, 69 & 78 for Business Requirement Identification.

Figure 21 - Manage Party Data Distribution Criteria Sequence Diagram

Publish Party Data (UC-65)

Figure 22 - Publish Party Data Use Case Diagram

Detail Use Case Name	Publish Party Data
Use Case Identifier (Traceability)	UC-65
Use Case Description	The Publish Party Data Use Case describes how a Data Source provides the Source Data Pool with the criteria under which their Party Data may be distributed to Data Recipients.
Summary Use Case	UC-53: Manage Party Data Distribution Criteria
Detail Use Cases	None
Actors	Data Source (DS) Source Data Pool (SDP)
Performance Goals	Data Source: To inform the Source Data Pool of the criteria under which their Party Data may be distributed to Data Recipients. Source Data Pool: To possess the necessary information that will allow the distribution of Party Data to the appropriate Recipient Data Pool.
Preconditions	The Party data has been loaded to the Source Data Pool and Registered in the Global Registry.
Postconditions	Publication criteria is stored in the Source Data Pool.
Scenario	Begins when, the Source Data Pool receives a Publication message from a Data Source. The SDP validates the Publication criteria The SDP creates or updates the Synchronisation List Ends when, the Synchronisation List is created or updated.
Alternative Scenario	ad 1. Data Source has sent invalid data: 1.1. The SDP sends an error message to the DS specifying what was invalid. Ends when, the Data Source receives the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 194, 201, 203, 204, 205, 207, 212, 213, 220, 221, 223, 233, 243, 244, 245, 258

Figure 23 - Publish Party Data Sequence Diagram

Stop Publishing Party Data (UC-66)

Figure 24 - Stop Publishing Party Data Use Case Diagram

Detail Use Case Name	Stop Publishing Party Data
Use Case Identifier (Traceability)	UC-66
Use Case Description	The Stop Publishing Party Data Use Case describes how a Data Source informs the Source Data Pool to delete the criteria under which their Party Data may be distributed to Data Recipients.
Summary Use Case	UC-53: Manage Party Data Distribution Criteria
Detail Use Cases	None
Actors	Data Source (DS) Source Data Pool (SDP)
Performance Goals	Data Source: To inform the Source Data Pool to delete Publication criteria and stop distributing Party Data. Source Data Pool: To possess the necessary information that will allow the Source Data Pool to eliminate distribution of Party Data from the synchronisation list.
Preconditions	The Publication exists in the Source Data Pool.
Postconditions	The Source Data Pool has stopped distributing the Party Data that was specified in the deleted Publication criteria.
Scenario	Begins when, the Source Data Pool receives a request to stop Publication from a Data Source. 1. The SDP validates that the Publication exists 2. The SDP updates the Synchronisation List 3. The SDP deletes the Publication. 4. The SDP sends a Publication stopped notification to the Data Source. Ends when, the Data Source receives the Publication stopped notification
Alternative Scenario	ad 1. The Publication does not exist at the Source Data Pool: 1.1. The SDP sends an error message to the DS specifying that the Publication does not exist. Ends when, the Data Source receives the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 220, 221, 223, 246, 258

Figure 25 - Stop Publishing Party Data Sequence Diagram

Subscribe to Party Data (UC-67)

Figure 26 - Subscribe to Party Data Use Case Diagram

Detail Use Case Name	Subscribe to Party Data
Use Case Identifier (Traceability)	UC-67
Use Case Description	The Subscribe to Party Data Use Case describes how a Data Recipient informs the Recipient Data Pool with the criteria under which Party Data may be distributed to the Data Recipient. Once the Subscription is created, the Recipient Data Pool will forward it to the Global Registry which, in turn, will forward it to appropriate Source Data Pools (see UC-73 Distribute Party Subscription Data).
Summary Use Case	UC-53: Manage Party Distribution Criteria
Detail Use Cases	None
Actors	Data Recipient (DR) Recipient Data Pool (RDP)
Performance Goals	Data Recipient: To inform the Recipient Data Pool of the criteria by which Party Data may be forwarded to the Data Recipient. Recipient Data Pool: To possess the necessary information that will allow the Recipient Data Pool to send subscriptions to the Global Registry.
Preconditions	The Party data requested exists in the Global Registry
Postconditions	The Recipient Data Pool has a Subscription that can be shared with the Global Registry.
Scenario	Begins when, the Recipient Data Pool receives a Party Subscription request from a Data Recipient. 1. The RDP sends an acknowledgement of receipt to the DR 2. The RDP validates the Subscription criteria. 3. The RDP sends a notification of Subscription verified to the DR Ends when, the Data Recipient acknowledges the Subscription verification notification.
Alternative Scenario	ad 2A. The Subscription already exists: 2A.1. The RDP sends an error message to the DR specifying that the Subscription exists. Ends when, the Data Recipient receives the error message ad 2B. The validation fails: 2B.1. The RDP sends an error message to the DR specifying the criteria in error Ends when, the Data Recipient receives the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 195, 201, 202, 203, 205, 207, 208, 215, 216, 219, 220, 221, 223, 225, 233, 247, 248, 249, 258

Figure 27 - Subscribe to Party Data Sequence Diagram

Remove Party Subscription (UC-68)

Figure 28 - Remove Party Subscription Use Case Diagram

Detail Use Case Name	Remove Party Subscription
Use Case Identifier (Traceability)	UC-68
Use Case Description	The Remove Party Subscription Use Case describes how a Data Recipient informs the Recipient Data Pool to delete a subscription for Party Data. Once the Subscription is removed, the Recipient Data Pool will forward the removal information to the Global Registry which, in turn, will forward it to appropriate Source Data Pools (see UC-73 Distribute Party Subscription Data). The Source Data Pools will remove the subscription. Thereafter, the Source Data Pools will not send Party data to the Data Recipient (via their Recipient Data Pool). The removal of a subscription does not affect the Synchronisation list held by the Source Data pool. The Data Recipient will continue to receive changes, corrections and deletions based on the Synchronisation List for existing Party data. (See UC-69 Confirm Party Data for rejection of existing Party data).
Summary Use Case	UC-53: Manage Party Data Distribution Criteria
Detail Use Cases	None
Actors	Data Recipient (DR) Recipient Data Pool (RDP)
Performance Goals	Data Recipient: To inform the Recipient Data Pool of the removal of a subscription. Eventually (via the Distribute Party Data Use Case 73) stopping Party data from being forwarded. Recipient Data Pool: To possess the necessary information that will allow the Recipient Data Pool and appropriate Source Data Pools to stop distributing Party Data to the Data Recipient.
Preconditions	The Data recipient has a Subscription held by the Recipient Data Pool.
Postconditions	The Subscription no longer exists in the Recipient Data Pool, the Registry, or Source Data Pool.
Scenario	Begins when, the Recipient Data Pool receives a request from the Data Recipient to remove a Party Subscription. 1. The RDP acknowledges receipt of request to the DR 2. The RDP validates that the Subscription exists. 3. The RDP sends notification of removed subscription to the DR Ends when, the Data Recipient acknowledges the Subscription removed notification.
Alternative Scenario	ad 2. The Subscription does not exist: 2.1. The RDP sends an error message to the DR specifying that the Subscription does not exist. Ends when, the Data Recipient receives the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 219, 220, 221, 223, 250, 258

Figure 29 - Remove Party Subscription Sequence Diagram

Confirm Party Data (UC-69)

Figure 30 - Confirm Party Data Use Case Diagram

Detail Use Case Name	Confirm Party Data
Use Case Identifier (Traceability)	UC-69
Use Case Description	The Confirm Party Data Use Case describes how a Data Recipient informs the Recipient Data Pool of its intentions regarding the Party Data. This communication from the Data Recipient to the Recipient Data Pool indicates what action has been taken on the party data. The confirmation process occurs in the recipient’s data pool. Confirmation is not mandatory. When used, it provides for the following outcomes: Synchronised: data is integrated, in synch and added to the synchronisation list. Accepted: data is added to the synchronisation list and will be in synch. Rejected: data will not longer be synchronised or updates will no longer be provided. Review: a request to the data source to “review” their data because the data recipient has received discrepant data which they cannot synchronise. If the data was previously synchronised, it will be removed from the synchronisation list. In the absence of a confirmation, the Recipient Data Pool will continue to receive updates intended with the publication process. In addition, this communication from the Data Recipient to the Recipient Data Pool must include the Global Location Number of: Data Recipient: The GLN of the Data Recipient prepared to synchronise the Party data. Confirmed Party GLN: The GLN of the specific Party data that will be synchronized. And may include: Data Source: The GLN of the Data Source who has registered the Party data. Refer to UC-74, Distribute Party Confirmation Data for additional process definition within the Global Data Synchronisation Network.
Summary Use Case	UC-53: Manage Party Data Distribution Criteria
Detail Use Cases	None
Actors	Data Recipient (DR) Recipient Data Pool (RDP)
Performance Goals	Data Recipient: To inform the Recipient Data Pool of its intentions regarding the Party Data. This Use Case triggers UC-74, Distribute Party Confirmation Data with additional process definition within the GDSN. Recipient Data Pool: To possess the necessary information that will allow the Recipient Data Pool and appropriate Source Data Pools to distribute Party Data to the Recipient.
Preconditions	The Data recipient has received Party data.
Postconditions	The Recipient Data Pool is aware of the Data Recipient’s intentions regarding specific Party Data. UC-74, Distribute Party Confirmation Data, is triggered by this awareness.
Scenario	Begins when, the Data Recipient sends a Party Data Confirmation to the Recipient Data Pool. 1. The RDP sends acknowledgement of receipt to the DR 2. The RDP validates the Confirmation message. 3. The RDP notifies DR of validation of the Confirmation message. Ends when, the Data Recipient receives the validation notification from Recipient Data Pool.
Alternative Scenario	ad 2. The Confirmation message is invalid: 2.1. The RDP sends an error message to the DR Ends when, the Data Recipient receives the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 207, 214, 217, 220, 221, 223, 239, 240, 241, 242, 258

Figure 31 - Confirm Party Data Sequence Diagram

Request Party Data (UC-72)

Figure 32 - Request Party Data Use Case DiagramSequence Diagram

Detail Use Case Name	Request Party Data
Use Case Identifier (Traceability)	UC-72
Use Case Description	The Request Party Data Use Case describes the process a Data Recipient and it’s Recipient Data Pool follows to receive previously sent Party data based on subscription criteria. This Use Case makes use of the Request for Party Notification message and triggers UC-77. This request is similar to a subscription with the difference being that the Global Registry need not retain the request once all relevant Source Data Pools receive the message, and is defined in UC-77, Distribute Party Data. The Party Notification, in response to this request, MUST have the attribute “isReload” equal to TRUE.
Summary Use Case	UC-53: Manage Party Data Distribution Criteria
Detail Use Cases	None
Actors	Data Recipient (DR) Recipient Data Pool (RDP)
Performance Goals	Data Recipient: To inform the Recipient Data Pool that it would like specific Party data to be resent. Recipient Data Pool: To possess the necessary information that will allow the Recipient Data Pool and appropriate Source Data Pools to re-distribute Party Data to the Recipient.
Preconditions	The Data Recipient has received Party data.
Postconditions	The Recipient Data Pool is aware that specific Party data is to be re-distributed to the Data Recipient.
Scenario	Begins when, the Data Recipient sends a Request For Party Notification to the Recipient Data Pool. The RDP sends an acknowledgement of receipt to the DR The RDP validates the request message. The RDP notifies DR of validation of the request Ends when, the Data Recipient receives the validation notification.
Alternative Scenario	ad 2. The request message is invalid: 2.1. The RDP sends an error message to the DR specifying the errors. Ends when, the Data Recipient receives the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 220, 221, 223, 251, 252, 258

Figure 33 - Request Party Data Sequence Diagram

Create Party Synchronisation List (UC-78)

Figure 34 - Create Party Synchronisation List Use Case Diagram

Detail Use Case Name	Create Party Synchronisation List
Use Case Identifier (Traceability)	UC-78
Use Case Description	The Synchronisation list is the means by which a Source Data Pool determines the Party Data that is to be sent to a Data Recipient (via the Recipient’s Recipient Data Pool). The Synchronisation list is created based on Publications, Subscriptions and Confirmations. Each one of these actions identifies the criteria used by the “Distribute Party Data from SDP to RDP” (UC-75) and “Distribute Party Data from RDP to Data Recipient” (UC-76) Use Cases.
Summary Use Case	UC-53: Manage Party Data Distribution Criteria
Detail Use Cases	None
Actors	Source Data Pool (SDP)
Performance Goals	Source Data Pool: To determine which Recipient should be sent what Party data.
Preconditions	Publications, Subscriptions and Confirmations exist in the Source Data Pool.
Postconditions	The Synchronisation List is created and used to direct the Source Data Pool in moving appropriate Party data to Recipient Data Pools.
Scenario	Begins when, the Source Data Pool identifies all criteria from Publications, Subscriptions, Confirmations, and changes or corrections to Party Data. 1. The SDP is responsible for identifying source GLN’s, RDP GLN’s, and DR GLN’s from the criteria in Publications, Subscriptions, Confirmations, and changes or corrections to Party Data. 2. The SDP creates the synchronisation list based on the criteria. Ends when, the Synchronisation List is complete.
Alternative Scenario	None
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 220, 221, 223, 253, 258

Distribute Request for Party Data (UC-70)

Figure 35 - Distribute Requests for Party Data Use Case Diagram

Summary Use Case Name	Distribute Requests for Party Data
Use Case Identifier (Traceability)	UC-70
Use Case Description	This Use Case describes the processes that need to take place for Publications, Subscriptions and Confirmations to be moved throughout the Global Data Synchronisation Network. As a Summary Use Case, specific processes will be further defined in the Detail Use Cases identified below.
Process Use Case	UC-50: Synchronise Party Data
Detail Use Cases	UC-73: Distribute Party Subscription Data UC-74: Distribute Party Confirmation Data UC-77: Distribute Request for Party Notification
Actors	Data Source (DS) Source Data Pool (SDP) Global Registry (GR) Recipient Data Pool (RDP) Data Recipient (DR)
Performance Goals	Data Source: To be informed of all data recipient requests. Source Data Pool: To have the proper criteria (Publications, Subscriptions and Confirmations) to allow distribution of Party data to Data Recipients (via their Recipient Data Pool). Global Registry: To be able to distribute Party Subscriptions to the proper Source Data Pools. Recipient Data Pool: To ensure Party Subscriptions match the data that is being sent by Source Data Pools. Data Recipients: To receive the type and volume of Party data requested.
Preconditions	The Data recipient has either created or removed a Subscription in their Recipient Data Pool or has received Party data.
Postconditions	The Global Registry, Source Data Pool and Data Source have received the request for distribution.
Scenario	Begins when, Data Recipient creates subscription RDP sends Party Subscription to SDP SDP notifies DS of subscription criteria Ends when, Data Source receives Subscription notification. See Detail Use Cases for specific process scenarios.
Alternative Scenario	N/A
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	See Detail Use Case #’s 73, 74 & 77 for Business Requirements

Figure 36 - Distribute Requests for Party Data Sequence Diagram

Distribute Party Subscription Data (UC-73)

Figure 37 - Distribute Party Subscription Data Use Case Diagram

Detail Use Case Name	Distribute Party Subscription Data
Use Case Identifier (Traceability)	UC-73
Use Case Description	The Distribute Party Subscription Data Use Case describes how Subscriptions are disbursed throughout the Global Data Synchronisation Network.
Summary Use Case	UC-70: Distribute Requests for Party Data
Detail Use Cases	None
Actors	Data Recipient (DR) Recipient Data Pool (RDP) Global Registry (GR) Source Data Pool (SDP) Data Source (DS)
Performance Goals	Data Recipient: To share Subscriptions with the appropriate Source Data Pools and Data Sources. Recipient Data Pool: To possess the necessary information that will allow the Recipient Data Pool and appropriate Source Data Pools to distribute Party Data to the Recipient. Global Registry: To disburse Subscriptions to appropriate Data Pools. Source Data Pool: To possess the necessary information that will allow the Source Data Pool to distribute Party Data to the Recipient (via their Recipient Data Pool). Data Source: To retain current and potential customer’s usage of Party Data.
Preconditions	The Data recipient has created a Subscription within their Recipient Data Pool.
Postconditions	The Subscription is disbursed to the Global Registry and relative Source Data Pools and Data Sources.
Scenario	Begins when, the Recipient Data Pool receives a Party Subscription from a Data Recipient and has validated it. 1. The RDP sends the Subscription to the GR. 2. The GR validates the message. 3. The GR matches the subscription to Party data in the GR. 4. The GR sends the Subscription to the relative SDP 5. The SDP notifies the relative DS of the Subscription. Ends when, the Data Source acknowledges the Subscription request.
Alternative Scenario	ad 1. New Party data is added to the Global Registry: 1.1 The GR matches the new Party data against existing Subscriptions. 1.2 The GR sends all matching Subscriptions to the SDP of the new Party data. 1.3 The SDP forwards the Subscription to the DS that added the Party data. Ends when, the Data Source sends an acknowledgement of the Subscription with a Publication ad 2. The Subscription fails validation at the Global Registry: 2.1. The GR sends an error message to the RDP. 2.2. The RDP sends an error message to the DR. Ends when, the Data Recipient receives the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 194, 205, 220, 221, 223, 255, 256, 258

Figure 38 - Distribute Party Subscription Data Sequence Diagram

Distribute Party Confirmation Data (UC-74)

Figure 39 - Distribute Party Confirmation Data Use Case Diagram

Detail Use Case Name	Distribute Party Confirmation Data
Use Case Identifier (Traceability)	UC-74
Use Case Description	The Distribute Party Confirmation Data Use Case describes how the Data Recipient informs the Source Data pool of the status of an individual Party Data synchronisation that was the result of a Publication / Subscription match. The confirmation process occurs in the recipient’s data pool. Confirmation is not mandatory. When used, it provides for the following outcomes: Synchronised: data is integrated, in synch and added to the synchronisation list. Accepted: data is added to the synchronisation list and will be in synch. Rejected: data will not longer be synchronised or updates will no longer be provided. Review: a request to the data source to “review” their data because the data recipient has received discrepant data which they cannot synchronise. If the data was previously synchronised, it will be removed from the synchronisation list. In the absence of a confirmation, the Source Data Pool will continue to send updates to the Recipient Data Pool. Confirmations are passed to the Source Data Pool from the Recipient Data Pool.
Summary Use Case	UC-70: Distribute Requests for Party Data
Detail Use Cases	None
Actors	Recipient Data Pool (RDP) Source Data Pool (SDP) Data Source (DS)
Performance Goals	Recipient Data Pool: To possess the necessary information that will allow the Recipient Data Pool and appropriate Source Data Pools to distribute Party Data to the Recipient. Source Data Pool: To possess the necessary information that will allow the Source Data Pool to distribute Party Data to the Data Recipient (via their Recipient Data Pool). Data Source: To possess the necessary information to identify the intent of the Data Recipient.
Preconditions	The Data recipient has created a Subscription in their Recipient Data Pool and has received Party data.
Postconditions	In the case of a “Rejection”, the Data Recipient no longer receives updates to the specific Party. For all other authorizations, the Source Data Pool is aware of the Data Recipient’s intentions regarding the Party data.
Scenario	Begins when, the Data Recipient sends a Confirmation message to the Recipient Data Pool 1. The RDP sends the Confirmation to the SDP. 2. The SDP validates the message. 3. The SDP matches the Confirmation with the Recipient’s Synchronisation List. 4. The SDP applies the state to the DR Synchronisation List. 5. The SDP notifies the DS of the Confirmation status. 6. The DS acknowledges receipt of the notification 7. The SDP forwards Confirmation Acknowledgement to the RDP. 8. The RDP forwards the acknowledgement of receipt to the DR. Ends when, the Data Recipient acknowledges the Recipient Data Pool’s notification.
Alternative Scenario	ad 2. The Confirmation message does not pass validation: 2.1 The SDP sends an error message to the RDP. 2.2 The RDP notifies the DR of the error message. Ends when, the Data Recipient receives notification of the error message
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 220, 221, 223, 258

Figure 40 - Distribute Party Confirmation Data Sequence Diagram

Distribute Request for Party Notification (UC-77)

Figure 41 - Distribute Request for Party Notification Use Case Diagram

Detail Use Case Name	Distribute Request for Party Notification
Use Case Identifier (Traceability)	UC-77
Use Case Description	The Distribute Request for Party Notification Use Case describes how the request is passed from Data Recipient through the Global Data Synchronisation Network to the Data Source. This Use Case makes use of the Request For Party Notification message. This message is similar to the Party Subscription with the “isReload” attribute equal to TRUE. The reload flag equal to TRUE is required with the Party Notification message to allow the Data Recipient to process it differently than a normal notification. The Request For Party Notification message is also different from a Party Subscription message in that it is not retained in the Global Registry after the Source Data Pools have received it.
Summary Use Case	UC-70: Distribute Requests for Party Data
Detail Use Cases	None
Actors	Data Recipient (DR) Recipient Data Pool (RDP) Global Registry (GR) Source Data Pool (SDP) Data Source (DS)
Performance Goals	Data Recipient: To request that previously distributed Party data be resent. Recipient Data Pool: To possess the necessary information that will allow the Recipient Data Pool to distribute Party Data to the Recipient. Global Registry: To forward to appropriate Source Data Pools all requests from Data Recipients. Source Data Pool: To possess the necessary information that will allow the Source Data Pool to distribute Party Data to the Recipient (via their Recipient Data Pool). Data Source: To be aware of all usages of supplied data.
Preconditions	The Data recipient has created a Subscription in their Recipient Data Pool and has received Party data.
Postconditions	The request is passed to the Global Registry, appropriate Source Data pools and the Data Source.
Scenario	Begins when, the Data Recipient sends a Request for Party Notification to the Recipient Data Pool 1. The RDP sends the Request For Party Notification to the GR. 2. The GR matches the Request with the relevant SDP. 3. The GR sends the request to the relevant SDP. 4. The SDP notifies DS of the request for Party Notification. Ends when, the Data Source acknowledges receipt of the request.
Alternative Scenario	N/A
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 220, 221, 223, 255, 256, 258

Figure 42 – Distribute Request for Party Notification Sequence Diagram

Distribute Party Data (UC-71)

Figure 43 - Distribute Party Data Use Case Diagram

Summary Use Case Name	Distribute Party Data
Use CaseIdentifier (Traceability)	UC-71
Use Case Description	Using the Distribution Criteria, the Party Data is distributed from SDP to RDP and finally, to the Data Recipient. The Party Notification contains the state of the Party Data with the following values: Canceled – A term describing a maintenance function used to communicate that a Party GLN was not introduced into the complete GDSN, allowing for reuse of the GLN in accordance with the EAN.UCC GLN Allocation rules. Discontinued – A term describing a maintenance function used to communicate the permanent removal of a Party GLN and data from the GDSN, beginning the trigger to track the EAN.UCC retention period for GLN reuse. In_Process – A term describing a maintenance function used to communicate the intent of registering a Party GLN and data to the Global Registry. (Not allowed for use once Party GLN is registered) New – A term describing a maintenance function used to communicate the first time use of the Party GLN and data. As a Summary Use Case, specific processes will be further defined in the Detail Use Cases identified below.
Process Use Case	UC-50: Synchronise Party Data
Detail Use Cases	UC-75: Distribute Party Data from SDP to RDP UC-76: Distribute Party Data from RDP to Data Recipient
Actors	Source Data Pool (SDP) Recipient Data Pool (RDP) Data Recipient (DR)
Performance Goals	Source Data Pool: Distribute Party Data to the Recipient Data Pool based on the Distribution Criteria from Subscription & Publication. Recipient Data Pool: Distribute Party Data to the Recipient based on the Distribution Criteria from Subscription & Publication. Data Recipient: To receive Party Data that complies with Subscriptions and Confirmations.
Preconditions	Publications, Subscriptions and Confirmations (Distribution Criteria) have been defined. The Source Data Pool has a defined synchronisation list for each Party Data request.
Postconditions	Data Recipient has received Party Data that complies with their Subscriptions and Confirmations.
Scenario	Begins when, Source Data Pool receives Publication, Subscription, or Change or Correction to Party Data 1. SDP uses the Synchronisation List to filter the Party Data. 2. SDP sends filtered Party Data to the RDP. 3. RDP use Subscription and Confirmations to filter Party Data. 4. RDP sends filtered Party Data to the DR. 5. RDP sends appropriate Confirmations to the SDP. Ends when Data Recipient has received the Party Data
Alternative Scenario	N/A
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	See Detail Use Case #’s 75 & 76 for Business Requirement Identification

Figure 44 - Distribute Party Data Sequence Diagram

Distribute Party Data from SDP to RDP (UC-75)

Figure 45 - Distribute Party Data from SDP to RDP Use Case Diagram

Detail Use Case Name	Distribute Party Data from SDP to RDP
Use Case Identifier (Traceability)	UC-75
Use Case Description	Using the Distribution Criteria, the Party Data are distributed from SDP to RDP.
Summary Use Case	UC-71: Distribute Party Data
Detail Use Cases	None
Actors	Source Data Pool (SDP) Recipient Data Pool (RDP)
Performance Goals	Source Data Pool: Distribute Party Data to the Recipient Data Pool based on the Distribution Criteria from Publications & Subscriptions. Recipient Data Pool: To receive Party Data that complies with the Distribution Criteria from Publications & Subscriptions.
Preconditions	Publications are available at the Source Data Pool. Subscriptions are communicated to the Source Data Pool. The Source Data Pool has the updated Party Synchronisation list based on the subscriptions and Confirmations received. The Source Data Pool knows which Recipient Data Pool needs to receive Party Data for each Recipient.
Postconditions	Recipient Data Pool has received Party Data that comply with the Distribution Criteria from Subscriptions and Confirmations.
Scenario	Begins when, the Source Data Pool filters the Party Data using the Party Synchronisation list. 1. The SDP sends filtered Party Data to the RDP. 2. The RDP receives the Party Data. Ends when, the Recipient Data Pool uses the Party Subscription and Party Confirmations of the recipient to filter the Party Data to validate Party Data requested.
Alternative Scenario	N/A
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 198, 207, 208, 220, 221, 223, 224, 228, 230, 231, 232, 233, 251, 252, 254, 258

Figure 46 - Distribute Party Data from SDP to RDP Sequence Diagram

Distribute Party Data from RDP to Data Recipient (UC-76)

Figure 47 - Distribute Party Data from RDP to Data Recipient Use Case Diagram

Detail Use Case Name	Distribute Party Data from Recipient Data Pool to Data Recipient
Use Case Identifier (Traceability)	UC-76
Use Case Description	Party Data is distributed from Recipient Data Pool to the Data Recipient.
Summary Use Case	UC-71: Distribute Party Data
Detail Use Cases	None
Actors	Recipient Data Pool (RDP) Data Recipient (DR)
Performance Goals	Recipient Data Pool: Distribute Party Data to the Data Recipient based on the Subscriptions and Confirmations. Data Recipient: To receive Party Data that complies with Subscriptions and Confirmations.
Preconditions	Publications, Subscriptions and Confirmations have been defined. The Party Data is filtered by the Recipient Data Pool (see UC-75).
Postconditions	Data Recipient has received Party Data that complies with Subscriptions and Confirmations.
Scenario	Begins when, the Recipient Data Pool sends the filtered Party Data to the Data recipient. Ends when, the Data Recipient receives the Party Data from its Recipient Data Pool as requested.
Alternative Scenario	N/A
Special Requirements	N/A
Extension Points	N/A
Requirements Covered	Business Requirement # 198, 207, 208, 220, 221, 223, 224, 229, 230, 231, 232, 233, 251, 252, 254, 257, 258

Figure 48 – Distribute Party Data from RDP to Data Recipient Sequence Diagram

TOP

Code lists

Date of Publication: March 2007