Update linkage for existing BPNs

[StWeisshaar]

Description

As sharing member of BPDM,
I must be able to update how existing BPNs are linked,
so that non-conflicting site information shared by the owner can be applied to the BPDM Pool.

Acceptance Criteria

• Linkage of existing BPNs can be updated based on provided referenceValues (BPN or requestIdentifier)
• LegalAddress can be updated to a LegalAndSiteMainAddress while maintaining the BPNA for a new BPNS
• AdditionalAddress can be updated to a SiteMainAddress while maintaing the BPNA for a new BPNS
• Site information for an existing AdditionalAddress can be updated
• Handling for out of scope cases is decided (error or silent update of content)
• Updates on existing BPNs is communicated to the Gates

Additional Information

In the face of the BP Explorer we will see cases where already issued BPNs must be updated.

Example: A big automotive manufacturer provides a generic address for one of its suppliers. The address gets assigned a BPNA and is attached to the BPNL of the supplier. Afterwards the supplier onboards and provides exactly the same address together with the correct linkage and address type.

Current behavior: The Pool is able to update the BPN content based on the provided referenceValue (BPN or requestIdentifier), but the linkage of the BPNs will not get updated.

Cases to be considered:

• LegalAddress -> LegalAndSiteMainAddress
  • Existing BPNA must be maintained as LegalAddress
  • Existing BPNA is additionally flagged with SiteMainAddress
  • A new BPNS must be issued
• AdditionalAddress -> SiteMainAddress
  • Existing BPNA is flagged with SiteMainAddress
  • A new BPNS must be issued
• Adding site information for an existing AdditionalAddress
  • Update site information for existing BPNAs (i.e. which site is a given BPNA assigned to)

Out of scope

• Resolving conflicts between information shared by different parties
• Changes that would move a BPNA between two distinct BPNLs
• Changes that would affect which BPNA is considered the SiteMainAddress for BPNS
• Changes that would affect which BPNA is considered the LegalAddress for a BPNL

To be discussed how the out of scope changes should be handled. I do see two options:

1. We continue to silently update the content based the provided referenceValue.
2. The pool rejects those undefined update requests.

[StWeisshaar]

@nicoprow @kunyao-cofinity-x We will also need to consider how these updates will be communicated to the Gates. In the given a case a BPN could have been returned to a Gate. This information also must be updated.

[StWeisshaar]

Could possibly be split into two issues:

1. Updating the Pool based on provided information
2. Communication between Gate and Pool to fetch the updated information

[StWeisshaar]

Question: Should it be possible to link a BPNA that represents the LegalAddress into a site? The BPNA would be attached to the BPNS, but would be distinct from the SiteMainAddress.

[nicoprow]

Question: Should it be possible to link a BPNA that represents the LegalAddress into a site? The BPNA would be attached to the BPNS, but would be distinct from the SiteMainAddress.

At the moment it is not possible but to my knowledge there is no clear requirement either way. I would like to get a feeback on that question from the association.

@zygokaktus

The question boils down to: Is a legal address that resides at a site automatically the site main address? Or can such a site that hosts the legal address also have a different site main address?

[StWeisshaar]

@zygokaktus @Sebastian-Wurm @maximilianong @nicoprow As discussed updated the ticket to focus on enabling the sharing members to make updates to the BPDM Pool. This should be seen in the context of non-conflicting site information shared by the owner to allow updates to existing BPNAs that were created as a generic AdditionalAddress. Please review and let me know if you see any need for further refinement.

I would also appreciate your input on the following two points:

1. Maintaining the existing BPNA when non-conflicting site information is provided for an already existing address.
2. How should the Pool handle requests which do not fulfill the above mentioned conditions and fall under the "out of scope" section? Example: You could provide BPNL001 together with BPNA002 that is already linked to BPNL002.

[Sebastian-Wurm]

Just some thoughts:

1. Thanks for updating the user story. Now it's clearer that the issue (not being a conflicting situation) arises on the side of the sharing member / Catena-X member. This means the fix must also be triggered from sharing member / Catena-X member side by either input through the sharing member gate or through the portal UI / portal gate. It's just a logical consequence that the pool must support changing the address type and references of an address, as it gets the requests from the gate through the orchestrator. However, the request always must arise from a gate. No client / service (etc.) should change the pool directly.
2. We really struggle with "BP Explorer" as the name for the portal UI for changing own business partner data. "Explore" does not have the meaning of "change" and "BP" is too generic, as we only change own business partners. Can we please find a better name? Currently the UI view is under "My company". Suggestions: "My Company Master Data {XYZ}", "My Organization Master Data {XYZ}", "My Corporate Structure Master Data {XYZ}", with {XYZ] being "Management", "Setup", "Configuration".
3. Regarding data model: From yesterday's discussion I am unsure if it's clear to everybody, that an address always has a legal entity assigned and additionally can have a site assigned.
4. @StWeisshaar: As for the two questions, I guess it's best to discuss them in the BPDM Expert Group, please feel invited. It's Monday, Wednesday and Thursday at 14:00 CET.

[jkirschn308]

The transformation from a ‘LegalAddress’ to a ‘LegalAndSiteMainAddress’ is currently not reflected when searching for the initial externalId of the ‘LegalAddress’ initially added. The address type is still ‘LegalAddress’. The update of the legal entity in the pool is not transmitted to the gate.

Example: externalId LA_09.12. vs LSMA_10.12.

[StWeisshaar]

Finalization of open questions with BPDM Expert Group (@zygokaktus, @Sebastian-Wurm, ...):

1. Maintaining the existing BPNA when non-conflicting site information is provided for an already existing address.

• Existing BPNAs must be maintained if site information is updated by the owner
• Updating which BPNA is the SiteMainAddress for given a site is out of scope

2. How should the Pool handle requests which do not fulfill the above mentioned conditions and fall under the "out of scope" section? Example: You could provide BPNL001 together with BPNA002 that is already linked to BPNL002.

• Discussion to be continued as part of a separate issue.
• BPDM Expert Group already has a matrix/ table.

[Sebastian-Wurm]

• Updating which BPNA is the SiteMainAddress for given a site is out of scope

According to the current standard, we must provide a site main address to create a site - in the worst case it's the first address assigned to a site. Does that mean that I can set the SiteMainAddress once, but I cannot change it afterwards? If so, why is that out of scope?

[StWeisshaar]

@Sebastian-Wurm Updating the SiteMainAddress was put out of scope to provide an initial scope that covers the creation of new sites and attaching sites to existing addresses while keeping the complexity as low as possible. As discussed we will need a follow up on the out of scope content.

Out of scope

• Resolving conflicts between information shared by different parties
• Changes that would move a BPNA between two distinct BPNLs
• Changes that would affect which BPNA is considered the SiteMainAddress for BPNS
• Changes that would affect which BPNA is considered the LegalAddress for a BPNL

Each site is expected to have exactly one SiteMainAddress. We therefore expect the owner to provide a SiteMainAddress or LegalAndSiteMainAddress to issue a BPNS. The alternative would be that a BPNS is issued based on a provided siteName. As suggested the main address could be inferred by the operator by choosing the first address. Based on my understanding the standard mandates the owner to clearly define their sites. The SiteMainAddress is therefore not inferred based on ordering.

The current Pool implementation does support an update operation on which BPNA is considered the SiteMainAddress (@nicoprow May I ask you to correct me here if needed?). One could update the underlying BPNA and therefore the SiteMainAddress, but I assume this is not the desired behavior. The unanswered question is: What is meant to happen to the BPNA which was previously considered the SiteMainAddress?

@jupakajo @albireo411 @zygokaktus fyi

Additional note: I am aware that there were discussions to get rid of the SiteMainAddress, but in the current data model the SiteMainAddress is an integral part. The only way for a sharing member to indicate the desire to create a new site and therefore a BPNS, is by setting the addressType to either SiteMainAddress or LegalAndSiteMainAddress and/or by providing a siteName. There are no other input fields related to a site. Excluding siteBpn since there is no BPNS issued yet.