Master Data Identification: Add new Version elements and Change all Version elements to IdentifierType to align with updated 950002 and 950004

[racheliurui]

Background ERDi, MESA: Related #9 When the updated 950002 and 950004 first order objects are used to exchange the various forms of MOM Master Data, a version element in the B2MML Types shall be used for master data instances as required. In some use cases where there are multiple versions of a Master Data instance (ISA-95 1st order object) simultaneously used across a supply chain, the version attribute requires additional identification header information to differentiate each version as MD identification.
In the ISA95 October 2019 Meeting, one of the approved C. Gifford comments added 1) new text to the updated 950002 Clause 4.5.5. Object identification and 2) the Version attribute to 1st order objects.
The updated text states that additional identification attributes/elements shall be used with Version attribute as required by the implementation. The recommended master data identification attribute set is ID, Version, Published Date, Effective Start Date and Effective End Date or similar. This attribute set is typical for Master Data of MOM process and resource definitions used by planning and job order execution. Versioned Master Data is time constrained in applications without changing the ID to maintain change history.

Solution This issue and associated commits are to ADD the "Version" element to following Resource and Definition Types to support the updating of a master data instance as its properties and/or attributes are changed. Some B2MML types already have a version element. Issue #9 and its associated commits are to ADD the PublishedDate, EffectiveStartDate, and EffectiveEndDate or use exisitng similar elements. This issue for version element and master data dates (#9) are updated per approved comment at ISA-95 Meeting.

Additional Issue Addressed in This Solution In Common.xsd, VersionType simply calls IdentiferType.
ETP recommend to MESA to simply the B2MML implementation by deleting Version Type and changing all Version elements to IdentifierType. Current Common.xsd

_EXAMPLE SOLUTION_ complexType name = "MaterialClassType" element name = "Version" type = "IdentifierType" minOccurs = "0"/> **Impacted Types:** WorkflowSpecification, WorkflowSpecificationNodeType, WorkflowSpecificationConnectionType Equipment.xsd: _EquipmentClassType_ DONE _EquipmentType_ DONE Material.xsd: _MaterialClassType_ DONE _MaterialDefinitionType_ DONE _MaterialLotType_ DONE _MaterialSublotType_ DONE PhysicalAsset.xsd: _PhysicalAssetClassType_ DONE _PhysicalAssetType_ DONE Personnel.xsd: _PersonnelClassType_ DONE _PersonType_ DONE MasterDataProfile.xsd: MasterDataProfileHeaderType DONE OperationalLocation.xsd: _OperationalLocationClassType_ DONE _OperationalLocationType_ DONE OperationsEvent.xsd: _OperationsEventClassType_ DONE _OperationsEventDefinitionType_ DONE _OperationsEventType_ DONE ProcessSegment.xsd: _ProcessSegmentType_ DONE OperationsDefinition.xsd: _OperationsDefinitionType_ DONE _OperationsSegmentType_ DONE _OperationsMaterialBillType_ DONE _OperationsMaterialBillItemType_ DONE OperationsSchedule.xsd: _OperationsScheduleType_ DONE _OperationsRequestType_ DONE _OpSegmentRequirementType_ DONE OperationsPerformance.xsd: _OperationsPerformanceType_ DONE _OperationsResponseType_ DONE OperationsCapability.xsd: _OperationsCapabilityType_ DONE _OpProcessSegmentCapabilityType_ DONE _OpOperationsSegmentCapabilityType_ DONE WorkDefinition.xsd _WorkDefinitionType_ DONE WorkflowSpecification.xsd: _WorkflowSpecificationType_ DONE _WorkflowSpecificationNodeTypeType_ DONE _WorkflowSpecificationConnectionTypeType_ DONE ResourceRelationshipNetwork.xsd _ResourceRelationshipNetworkType_ DONE _ResourceNetworkConnectionTypeType_ DONE WorkSchedule..xsd _WorkScheduleType_ DONE _WorkRequestType_ DONE _JobListType_ DONE _JobOrderType_ DONE WorkPerformance.xsd _WorkPerformanceType_ DONE _WorkResponseType_ DONE _JobResponse_ DONE _JobResponseListType_ DONE WorkCapability.xsd _WorkCapabilityType_ DONE _WorkMasterCapabilityType_ DONE WorkAlert.xsd _WorkAlertDefinitionType_ DONE _WorkAlertType_ DONE WorkCalendar.xsd _WorkCalendarDefinitionType_ DONE _WorkCalendarDefinitionEntryType_ DONE _WorkCalendarType_ DONE Common.xsd: _OperationsRecordSpecTemplateType_ DONE _OperationsRecordTemplateType_ DONE _OperationsRecordEntryTemplateType_ DONE _TestResultType_ DONE BatchML-BatchInformation.xsd _ApprovalHistoryType_ DONE _ControlRecipeType_ DONE _ListHeaderType_ DONE _MasterRecipeType_ DONE _RecipeElementType_ DONE -- Commonly used elements -- DONE

[racheliurui]

I see this will help with "master data update". I have made the same suggestion to Dataware house design to have a version column to represent a whole group of master data which is missing in our DW implementation. We can make use of the Version field to easily identify the version of master data and do the bulk switch/cutover when master data changes.

[racheliurui]

Confirmed in today's meeting that the version will help with batch update the master data. If the publishing failed and need a rollback or we want to disable a whole version, a version label will help with that.

Agreed.

[CharlieG021163]

@gerardmoloneyetpartners @terryrankine Possible Issue In Common.xsd, VersionType simply calls IdentiferType.
Does ETP recommend to MESA to simply implementation by deleting Version Type and changing all Version elements to IdentifierType?

[CharlieG021163]

@gerardmoloneyetpartners @terryrankine Need to rediscuss and decide about type for version.

[terryrankine]

A double abstraction thing->version->identifier->text a single abstraction thing->identifier->text should be all that is needed

Terry

[Dennis-Brandl]

I agree with the change.