Issues to discuss with Patrice

[larsolofsson]

Please see attached file

papiNet API, Issues to discuss with Patrice 2025-11-24.docx

Current develop branch before merging new stuff into develop branch
This branch is 5 commits ahead of and 1 commit behind master.

Is it possible to delete these commits or must we merge it to master branch with a pull request?

[patricekrakow]

I think we SHOULD never delete a commit unless it is necessary to remove sensitive/conferential data.

[patricekrakow]

Let me answer here the questions from your Word document.

1. You are right, I am using the Standalone Pact Stub Server and I am wrongly referring to it as a "mock server". We should correct that and replace the word "mock" by "stub". For the second point, I can indeed add somewhere an explanation of how to install the Standalone Pact Stub Server.
2. The idea was to use a specific port 30[Major][Minor], 3030 for 3.0.0, for each version in order to be able to run stubs of different versions at the same time.
3. Indeed, I do see some inconsistencies.
4. The idea was to keep the content of the folders "[MAJOR].[MINOR].[PATCH]" immutable after their release.
5. That's correct, the "tools" should be independent of the version, which should come as a (dynamic) parameter.
6. I think we, indeed, need to discuss that question...
7. I do not understand anymore what we meant by "minimized", I will check the history...
8. (to be continued)

[patricekrakow]

Regarding the Rule 8, we should update it with the text "Deprecated" (so we do not need to renumber all the subsequent rules).

Approved by CWG on 2026-01-14 (Wed).

[patricekrakow]

Rule 9 should also "Deprecated" for now. We may revisit that topic in the context of #125.

Approved by CWG on the 2026-01-14 (Wed).

[larsolofsson]

Rule 6 - Avoid lookup optimization

When a response contains the reference to something (e.g. a seller-product), it MUST only contain the identifier of that thing and any additional information MUST be retrieved via a subsequent lookup. There should not be any lookup optimization combining the identifier with additional information.
*******************************************************************************************'

How should papiNet change this rule?
When having a reference to an object (e.g. a delivery note), there is often also a need to include in the reference the version of the object in addition to the identifier, and UUID or a number. The version can be identified by the TimeStamp of a digital object.

If the object is not digital, then the version can be identified by a version number or date and time.
In an XML reference construct papiNet has TransactionHistoryNumber, VersionNumber and "date and time".

In the goods receipt endpoint papiNet has a reference to a delivery note with deliveryNoteNumber and deliveryNoteTimeStamp.

Should it using papiNet API be possible to implement only some endpoints in a use case, e.g. to implement goods receipt without having a digital delivery note?

[patricekrakow]

In the future, we might invent for "reference" a generic object which contains several properties in order to deal with the different situations:

• UUID
• XML transaction history
• paper document
• ...

For the moment, @patricekrakow should just adapt the wording of the rule because the word "identifier" MUST NOT be understood as a single property in order to comply with the statement above.

[patricekrakow]

We should cross check if we have cover all issues from the Word document as GitHub issues!

[patricekrakow]

The only remaining issue is the one regarding the papiNet-JSON-Style-Guide.md.