Better document the relationship between the mapping and build stages

[yolile]

Some aspects of the mapping process could inform the build stage of the OCDS implementation. For example, during the mapping process, you should map:

• The release.date and release.id fields. If these fields are not part of the source system, which is normally the case, then you need to think about how you are going to generate them, and that decision could invoice deciding if you are going to implement easy releases, full history, etc.
• Similarly, some modeling suggestions involve using different releases to track changes, e..g amendments. So, during the mapping you should know already if you are implementing the full change history or not, to determine how to model and track changes.
• Listing fields and data sources is one step of the mapping, but another important part is to document how to link all the different listed data sources, if possible. We should document or suggest thinking about that as part of the mapping.

@fppenna @allakulov @ndrhzn please add more learnings or insights we should document and I might missed, thanks!

[fppenna]

In some cases, a single local field can map to multiple OCDS fields, particularly when the publication covers various procurement methods, modeled differently in the OCDS data. Although the standard documentation suggests splitting the mapping based on the procurementMethod, if this approach is not followed, it is crucial to document the relationship between the local field and the multiple OCDS fields, as well as how they should be included in the publication for each modeled procurementMethod

[jpmckinney]

@fppenna Can you give a specific example?

[fppenna]

In Portland, a report listing the details of Purchase Orders is one of the data sources. From this report, the tool uses the field "Gross Order Value" to indicate "contracts/value/amount" in processes where "procurementMethod" is "direct". It also uses this field to indicate "contracts/items/unit/value/amount" in processes where "procurementMethod" is "open" or "limited".

Purchase Orders serve as direct contracts when the request does not exceed a certain threshold. They are also used as an internal tool to encumber funds in open or selective procurement processes, incorporating details about the requested items.
All this information is provided in the same report, so the use of "Gross Order Value" varies depending on the procurement method used.

In this implementation, the mapping is segmented by procurementMethod, simplifying the interpretation of this field and its use when creating OCDS releases.