Party construct in version 3.0.0

[larsolofsson]

I don't understand why there are multiple uuid:s possible for a party. Shouldn't papiNet have only one uuid for a party?

What impact would this current party construct have on master data for parties when having two party identifiers assigned by supplier and customer? Should master data be skipped completely for parties in papiNet API, i.e should property id: be removed?

My proposal is two properties id: (optional) and partyIdentifiers (required), if uuid would be kept. (partyIdentifier is required in master data for parties, version 2.0.0) supplierParty: type: object required:

• partyIdentifiers properties: id: type: string format: uuid partyIdentifiers: type: array minItems: 1 items: type: object required: -value -assignedBy properties: value: type: string minLength: 1 assignedBy: type: string enum:
  • Supplier
  • Customer

Later papiNet API should also support globally unique party identifiers. How would these globally unique party identifiers be added to the party construct.

The following globally unique party identifiers are used in papinet XML. These party identifiers don't need an assignedBy, but a type needs to be specified.

[patricekrakow]

This is indeed a mistake: the id should not be a child of of partyIdentifiers[] but a (unique) sibling! I think that both id and partyIdentifiers MUST NOT be required:

• id cannot be required because we want to support use case where there is no master data API endpoints giving the details of a party based on an UUID.
• partyIdentifiers cannot be required because we want to support the ideal (target) situation in which UUIDs are the sole identifiers of master data (the native API use case).

I will correct all the parties as suggested, but without partyIdentifiers being required.

[patricekrakow]

Done, see commit 48cd98c.

[patricekrakow]

We closed this issue with @larsolofsson, @bengtwentus and @MrNordenberg.

WARNING: The commit above does not contain ALL corrections, they have been completed in the context of the issue #106.