You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem:
The splitting of BTs in BT-XY-Lot and BT-XY-Part greatly inflates the SDK and its artifacts, although parts are only used in very few notices. (Currently, subtypes 4-6 account for only 11.451 out of 394.667 notices at TED.)
The technical distinction between lots and parts leads to a duplication of rules and fields (ids) and is often a source of
errors for SDK updates and/or national tailoring of an SDK.
Background:
Lots and Parts are using the same XML Structures. The technical differentiation is made by an attribute of the cbc:id
element. This differentiation results in dublicated field definitions and the associated efx expressions as well as the
schematron rules generated from them. The rules between lot and part negate each other. That makes it more complex to understand and maintain.
I would therefore like to suggest examining whether the distinction is really necessary.
I know that lots and parts are not the same business object, but the distinction can also be made using notice subtypes
such as 4 or 16. For example, a subtype 4 can only contain parts and a subtype 16 can only contain lots.
So rules can be made based on the subtype, rather than on xPath.
The descriptions of the fields are usually identical. A distinction can nevertheless be made using the notice subtypes.
Benefit through proposed solution:
Rules only need to be defined in one place, taking subtypes into account. This leads to easier traceability of
changes and simpler maintenance effort. The domain specificity between lot and part can be differentiated via the subtypes.
The ruleset does not negate each other, as all rules are hold in one element. Less of forbidden rules are needed. As they represent same field in xml structure.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Problem:
The splitting of BTs in BT-XY-Lot and BT-XY-Part greatly inflates the SDK and its artifacts, although parts are only used in very few notices. (Currently, subtypes 4-6 account for only 11.451 out of 394.667 notices at TED.)
The technical distinction between lots and parts leads to a duplication of rules and fields (ids) and is often a source of
errors for SDK updates and/or national tailoring of an SDK.
Background:
Lots and Parts are using the same XML Structures. The technical differentiation is made by an attribute of the cbc:id
element. This differentiation results in dublicated field definitions and the associated efx expressions as well as the
schematron rules generated from them. The rules between lot and part negate each other. That makes it more complex to understand and maintain.
I would therefore like to suggest examining whether the distinction is really necessary.
I know that lots and parts are not the same business object, but the distinction can also be made using notice subtypes
such as 4 or 16. For example, a subtype 4 can only contain parts and a subtype 16 can only contain lots.
So rules can be made based on the subtype, rather than on xPath.
The descriptions of the fields are usually identical. A distinction can nevertheless be made using the notice subtypes.
Benefit through proposed solution:
Rules only need to be defined in one place, taking subtypes into account. This leads to easier traceability of
changes and simpler maintenance effort. The domain specificity between lot and part can be differentiated via the subtypes.
The ruleset does not negate each other, as all rules are hold in one element. Less of forbidden rules are needed. As they represent same field in xml structure.
Beta Was this translation helpful? Give feedback.
All reactions