Change StorageLocation element from StorageHierarchyScopeType to ResourceLocationType in MaterialLotType and MaterialSubLotType

[racheliurui]

MESAInternational/B2MML-BatchML#30

Background and Solution

to align with updated 950002 Operational Location Model in Material Model, the following changes are required.

complexType name = "MaterialLotType", element name ="StorageLocation";
CHANGE: type = "StorageHierarchyScopeType" to "ResourceLocationType"

complexType name = "MaterialSubLotType", element name ="StorageLocation";
CHANGE: type = "StorageHierarchyScopeType" to "ResourceLocationType"

Impacted Types

Material.xsd

• MaterialLotType
• MaterialSubLotType

Supporting Document

950002 JWG5 CDV01 version (2019 12)
Clause 5.7.6 Material lot, Table 69 – Material lot attributes
Clause 5.7.8 Material sublot, Table 73 – Material sublot attributes

[racheliurui]

During today's discussion, there seems to need more consideration for this change. Let's revisit this.

[racheliurui]

This is related to open issue with B2MML
MESAInternational/B2MML-BatchML#30

Current model containing StorageLocation

ComplexType Name	Element Name	Element Type	Schema
OpMaterialActualType	StorageLocation	ResourceLocationType	OperationsPerformanceTypes
OpMaterialCapabilityType	StorageLocation	ResourceLocationType	Common
OpMaterialRequirementType	StorageLocation	ResourceLocationType	Common
MaterialLotType	StorageLocation	StorageHierarchyScopeType	Material
MaterialSubLotType	StorageLocation	StorageHierarchyScopeType	Material

Proposed change

ComplexType Name	Element Name	Element Type
MaterialLotType	StorageLocation	ResourceLocationType
MaterialSubLotType	StorageLocation	ResourceLocationType

Payload Comparison

• MaterialLot payload sample using the current standard

<p:MaterialLot>
	<p:ID>BlastholeID001935</p:ID>
	<p:StorageLocation>LabA</p:StorageLocation>
</p:MaterialLot>

• MaterialLot payload proposed

<p:MaterialLot>
	<p:ID>BlastholeID001935</p:ID>
	<p:StorageLocation>
		<p:Location>LabA</p:Location>
		<p:LocationType>Operational Location</p:LocationType>
	</p:StorageLocation>
</p:MaterialLot>

Agreed with this change.

[racheliurui]

@CharlieG021163 has mentioned there would be more types being impacted by this change. Thus leave it at "discussed" stage

[CharlieG021163]

Additional Changes:

ComplexType Name	Element Name	Element Type	Schema
OpMaterialSpecificationType	StorageLocation	ResourceLocationType	Common
OpPhysicalAssetSpecificationType	PhysicalLocation	ResourceLocationType	Common
OpEquipmentSpecificationType	OperationalLocation	ResourceLocationType	Common
OpPersonnelSpecificationType	OperationalLocation	ResourceLocationType	Common

ACTION
Changes applied to Draft branch

[CharlieG021163]

@gerardmoloneyetpartners
@terryrankine
Since the changes to MaterialLot and MateialSubLot were submitted to MESA, I have moved the ADD OperationalLocation element to the OpXXXSpecificationTypes in Common.xsd to #96 as a separate issue.

[gerardmoloneyetpartners]

MESA have a large alternative proposal for us to review and provide feedback.

The proposal is to:
Move the OperationalLocationType to the B2MML_Common file.

Remove StorageHierarchyScopeType and replace with ResourceLocationType

Add a in ResourceLocationType to allow selection of either:
a) A Location ID, which is a reference to an OperationalLocation that is previously defined.
b) A Location of type OperationaLocationType, so that an entire OperationalLocation can be included in the ResourceLocationType
c) Add the following two codetypes to ResourceLocationType1Type: OperationalLocation ID and Person (to allow a resource to be associated with a person, such as a tool's location is with a specific person).

<xsd:complexType name="ResourceLocationType1Type">
xsd:simpleContent
<xsd:restriction base="CodeType">
<xsd:enumeration value="Operational Location ID"/>
<xsd:enumeration value="Operational Location"/>
<xsd:enumeration value="Person"/>
<xsd:enumeration value="Equipment"/>
<xsd:enumeration value="Physical Asset"/>
<xsd:enumeration value="Description"/>
<xsd:enumeration value="Other"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>

<xsd:complexType name="ResourceLocationTypeType">
xsd:annotation
xsd:documentation
Indicates whether the storage location attribute refers to an operational location, equipment
or physical asset object, or contains a description of the storage location.
Mandatory where a storage location is specified.
Defined values are

Operational Location ID: storage location attribute references an operational location (OperationalLocationID);
Operational Location: storage location attribute defines an operational location (OperationalLocationType);
Person: location attribute references a Person (PersonID) (eg: material or equipment is with a person);
Equipment: storage location attribute references an equipment object (EquipmentID);
Physical Asset: storage location attribute references a physical asset (PhysicalAssetID); and
Description: storage location attribute contains a description of the storage location, such as a street address.
</xsd:documentation>
</xsd:annotation>
xsd:simpleContent
<xsd:extension base="ResourceLocationType1Type">
<xsd:attribute name="OtherValue" type="xsd:string"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType> <xsd:complexType name="ResourceLocationType">
xsd:sequence
xsd:choice
<xsd:element name = "LocationID" type = "TextType" />
<xsd:element name = "Location" type = "OperationalLocationType" />
</xsd:choice>
<xsd:element name = "LocationType" type = "ResourceLocationTypeType" />
</xsd:sequence>
</xsd:complexType>

[CharlieG021163]

@gerardmoloneyetpartners @terryrankine
I agree with proposal except OperationalLocation.xsd should NOT be move to Common.xsd since it is a first order object that is exchanged as master data.
I will make change once discussed

[Dennis-Brandl]

I agree with the change (except to move of the OperationalLocation.xsd to common.)