Existing query parameters for filter on parties and locations are complex. A few errors need to be corrected and they need to be better described to make it easier for developers to understand how to implement it. There are 2 options.
Existing example
- in: query
name: supplierParty.value
schema:
type: string
required: false
description: filter based on `supplierParty.identifiers[].value` and `supplierParty.identifiers[].assignedBy`
- in: query
name: supplierParty.assignedBy
schema:
type: string
required: false
description: filter based on `supplierParty.identifiers[].value` and `supplierParty.identifiers[].assignedBy`
Option 1: Proposed to be change to
- in: query
name: supplierParty.identifiers.value
schema:
type: string
minLength: 1
required: false
description: |
Filter based on `supplierParty.identifiers[].value`. MUST only be used combined with query parameter `supplierParty.identifiers.assignedBy`. Both conditions MUST match the same supplierParty.identifiers array element."
- in: query
name: supplierParty.identifiers.assignedBy
schema:
type: string
enum:
- Supplier
required: false
description: |
Filter based on `supplierParty.identifiers[].assignedBy` (Supplier). MUST only be used combined with query parameter `supplierParty.identifiers.value`. Both conditions MUST match the same supplierParty.identifiers array element.
Option 2: Change identifier construct
Existing construct
identifiers:
type: array
minItems: 1
items:
type: object
unevaluatedProperties: false
required:
- value
- assignedBy
properties:
value:
type: string
minLength: 1
assignedBy:
type: string
enum:
- Supplier
Proposed to be changed to
identifierBySupplier:
type: string
minLength: 1
description: The identifier assigned by the _Supplier_ .
Query parameter
- in: query
name: supplierParty.identifierBySupplier
schema:
type: string
minLength: 1
required: false
description: filter based on `supplierParty.identifierBySupplier`.
Option 2 is less complex using a single property instead of an array with two properties. The filtering on a party or location is also more simple to implement.
If papiNet in the future needs to add an new identifier assigned by e.g. LogisticsSupplier, then in option 1 a new enumeration will be added and in option 2 a new property will be added.
Option 2 is also in line with the design of papiNet master data in version 2.0.0.
Existing query parameters for filter on parties and locations are complex. A few errors need to be corrected and they need to be better described to make it easier for developers to understand how to implement it. There are 2 options.
Existing example
Option 1: Proposed to be change to
Option 2: Change identifier construct
Existing construct
Proposed to be changed to
Query parameter
Option 2 is less complex using a single property instead of an array with two properties. The filtering on a party or location is also more simple to implement.
If papiNet in the future needs to add an new identifier assigned by e.g. LogisticsSupplier, then in option 1 a new enumeration will be added and in option 2 a new property will be added.
Option 2 is also in line with the design of papiNet master data in version 2.0.0.