UNILIN-UNIMAT: Rules And Error Conditions

Rules That Must Be Followed

The sending system must make sure that:

records are in chronological and dependency-safe order
each control block starts with a valid control record
all required fields contain relevant data
device numbers resolve to existing devices
each row is interpreted in the customer scope resolved from the device

The current interface accepts the recommended initialization order 1,2,A,C for a file that introduces wearers, garments, uniforms, and uniform articles in one pass.

In the current interface, customer values in the source row are descriptive only. Device ownership decides customer scope.

Processing Guarantees

When the payload is valid, the interface guarantees that:

row order is preserved
dependency order is preserved
each row is evaluated in the customer scope resolved from that row’s device
later rows in the same payload are interpreted after earlier rows
control blocks are respected as record boundaries

When several rows refer to the same identities, the later row is always interpreted after the earlier row. The interface does not change the business sequence described by the sender.

Technical optimisation may reduce repeated lookups or combine compatible technical operations, but it must not change business order.

Conditions Per Record Type

Code Record type Conditions

Code	Record type	Conditions
`1`	New wearer	Wearer rows are interpreted in the resolved customer scope. If the wearer does not already exist, a new wearer is created. If the wearer already exists, the row is a no-op. If the row carries a non-empty and non-zero uniform number, that row records an intended wearer-to-uniform assignment that can be resolved immediately if the uniform already exists or deferred until a later `A` row in the same file creates it. If no matching uniform exists by the end of the file, the row is treated as an error.
`2`	Assign garment to wearer	Personal garments require a valid wearer. Generic garments require deterministic item-pool resolution. The garment is created when new and updated when it already exists in the resolved customer scope. The article code is resolved in the same customer scope and may be created there if needed.
`3`	Bring garment back from device	Garment must exist. If it is already marked as returned, the row becomes a no-op.
`4`	Delete garment from device	If the garment exists, it is deleted from the resolved customer scope. If the garment cannot be found, the row becomes a no-op. The delete is still order-sensitive and cannot overtake earlier rows for the same garment.
`5`	Change wearer information	Row must resolve to the intended wearer identity in device-derived customer scope. The current interface treats this as a wearer upsert. If the row carries a non-empty and non-zero uniform number, the updated wearer-to-uniform assignment follows the same resolve-or-defer rule as mutation `1`. If no matching uniform exists by the end of the file, the row is treated as an error.
`6`	Add signal to garment	Garment must exist. The current interface recognises the row, logs it, and keeps it distinct from malformed input, but it does not apply a business change in the current release.
`7`	Delete wearer	If the wearer does not exist, the delete is a no-op. If the wearer exists, it must not have garments remaining in use.
`8`	Garment for loading / outscan	Garment must exist. The interface resolves the item first, then sends an outscan only when the current item state still fits the file’s loading date. If the item has no location, the outscan is always sent. If the item looks newer than the file by too much, the row becomes a no-op instead of forcing a stale load.
`9`	Garment delivered to wearer	The row is recognised by the interface, logged, and accepted as part of the file format, but no business change is applied in the current release.
`A`	Add new uniform	Uniform must be resolvable in the intended customer scope and created before dependent uniform-article rows. A later `A` row may satisfy wearer references already seen earlier in the same file.
`B`	Delete uniform	If the uniform exists, it is deleted from customer scope. If it does not exist, the row becomes a no-op.
`C`	Add article to uniform	Uniform must exist. Article must already exist in customer scope. If the link already exists, the row becomes a no-op.
`D`	Delete article from uniform	Uniform must exist. Article must exist in customer scope. If the link does not exist, the row becomes a no-op.
`E`	Message to wearer / general message	The row is recognised by the interface, logged, and accepted as part of the file format, but no business change is applied in the current release.
`F`	Change garment information	The current interface applies the row as a garment/article synchronization in customer scope. Existing garments are updated; missing garments are created from the row data.
`G`	Change article code	Old article code must exist. The target article code must not already exist in the same customer scope.
`H`	Reserved	The row is recognised as reserved, logged, and accepted as part of the file format, but no business change is applied in the current release.

1

New wearer

Wearer rows are interpreted in the resolved customer scope. If the wearer does not already exist, a new wearer is created. If the wearer already exists, the row is a no-op. If the row carries a non-empty and non-zero uniform number, that row records an intended wearer-to-uniform assignment that can be resolved immediately if the uniform already exists or deferred until a later A row in the same file creates it. If no matching uniform exists by the end of the file, the row is treated as an error.

2

Assign garment to wearer

Personal garments require a valid wearer. Generic garments require deterministic item-pool resolution. The garment is created when new and updated when it already exists in the resolved customer scope. The article code is resolved in the same customer scope and may be created there if needed.

3

Bring garment back from device

Garment must exist. If it is already marked as returned, the row becomes a no-op.

4

Delete garment from device

If the garment exists, it is deleted from the resolved customer scope. If the garment cannot be found, the row becomes a no-op. The delete is still order-sensitive and cannot overtake earlier rows for the same garment.

5

Change wearer information

Row must resolve to the intended wearer identity in device-derived customer scope. The current interface treats this as a wearer upsert. If the row carries a non-empty and non-zero uniform number, the updated wearer-to-uniform assignment follows the same resolve-or-defer rule as mutation 1. If no matching uniform exists by the end of the file, the row is treated as an error.

6

Add signal to garment

Garment must exist. The current interface recognises the row, logs it, and keeps it distinct from malformed input, but it does not apply a business change in the current release.

7

Delete wearer

If the wearer does not exist, the delete is a no-op. If the wearer exists, it must not have garments remaining in use.

8

Garment for loading / outscan

Garment must exist. The interface resolves the item first, then sends an outscan only when the current item state still fits the file’s loading date. If the item has no location, the outscan is always sent. If the item looks newer than the file by too much, the row becomes a no-op instead of forcing a stale load.

9

Garment delivered to wearer

The row is recognised by the interface, logged, and accepted as part of the file format, but no business change is applied in the current release.

A

Add new uniform

Uniform must be resolvable in the intended customer scope and created before dependent uniform-article rows. A later A row may satisfy wearer references already seen earlier in the same file.

B

Delete uniform

If the uniform exists, it is deleted from customer scope. If it does not exist, the row becomes a no-op.

C

Add article to uniform

Uniform must exist. Article must already exist in customer scope. If the link already exists, the row becomes a no-op.

D

Delete article from uniform

Uniform must exist. Article must exist in customer scope. If the link does not exist, the row becomes a no-op.

E

Message to wearer / general message

The row is recognised by the interface, logged, and accepted as part of the file format, but no business change is applied in the current release.

F

Change garment information

The current interface applies the row as a garment/article synchronization in customer scope. Existing garments are updated; missing garments are created from the row data.

G

Change article code

Old article code must exist. The target article code must not already exist in the same customer scope.

H

Reserved

The row is recognised as reserved, logged, and accepted as part of the file format, but no business change is applied in the current release.

Common Errors In The Laundry File

Common error situations include:

assign garment to wearer without first creating the wearer
send garment-for-loading even though the garment does not exist
send garment-for-loading for an item whose current state is too new for the file date to be trusted
send customer values that do not match the device-derived customer scope
send generic-garment rows where item-pool resolution is ambiguous
delete wearer while garments are still in use on that wearer
reference a uniform from wearer rows 1 or 5 when that uniform never exists and is not created later in the same file
rename an article code to a target code that already exists in the same customer scope

If the customer number in the row differs from the customer derived from the device, the device-derived customer remains authoritative.

Serious Error Conditions

If a wearer is deleted while garments are still connected to that wearer, those garments can lose their wearer connection and must be repaired through return, delete, recreate, and reload steps.

Recommended Order For Full Initialization

If a device needs initial load or data resynchronization, the safest order remains:

Code Record type Reason

Code	Record type	Reason
`1`	New wearer	Wearer information is required before personal garments can be assigned.
`2`	Assign garment to wearer	Introduces garment data and may introduce article identity used later by uniform rows.
`A`	Add new uniform	Uniform must exist before articles can be connected to it. This row may also satisfy earlier wearer references to the same uniform number.
`C`	Add article to uniform	Finalizes the allowed article set for the uniform.

1

New wearer

Wearer information is required before personal garments can be assigned.

2

Assign garment to wearer

Introduces garment data and may introduce article identity used later by uniform rows.

A

Add new uniform

Uniform must exist before articles can be connected to it. This row may also satisfy earlier wearer references to the same uniform number.

C

Add article to uniform

Finalizes the allowed article set for the uniform.