UNILIN-UNIMAT: Garments

Creates or updates a garment in the resolved customer scope. For personal garments the row is connected to a wearer; for generic garments the row is connected to an item pool.

New garments and existing garments that should be kept in sync with the source file.

The garment identity is resolved from chip number. The customer scope comes from the device. The article code is resolved in that same customer scope, and if the article does not yet exist it is created there as part of the garment handling.

The existing garment is updated to match the row. If nothing changed, the row becomes a no-op.

The garment is created.

The garment is assigned to the resolved wearer in that customer scope.

The garment is assigned to an item pool in the resolved customer scope.

If an explicit pool identity is configured, that pool is used. If one deterministic pool exists, that pool is used. If no pool exists, a new one may be created. If several possible pools exist and no deterministic match can be made, the row is invalid.

The garment row is interpreted in source order. Earlier valid rows in the same payload can create the wearer, article, or item pool needed by later rows. Personal garments are handled against the wearer state available at that point in the payload. Generic garments are handled against the item-pool state available at that point in the payload.

Changes garment information in the resolved customer scope. Depending on what changed, the row can update garment data, article data, or both.

Existing garments/articles with unique identity.

The garment is resolved by chip number.

The garment data is updated. Depending on the changed fields, this may update garment-specific data, article-type data, or both.

The current interface creates the garment from the row data instead of rejecting the row. That keeps the result aligned with the source file even when the sender uses T.F as a correction for a garment that is missing in Q-Cloud 2.

This page keeps the legacy distinction: changes to article code and size affect the garment, while article name and slot/compartment changes may affect the broader article definition in customer scope.

The change is interpreted after all earlier rows in the same payload. It is not allowed to overtake earlier create, assign, load, return, or delete mutations for the same garment.

Replaces the article code for an existing article in the resolved customer scope.

Existing article identities in customer scope.

The old article code and the target article code are looked up in customer scope.

The article code is renamed from old value to new value.

The mutation is invalid.

The row is invalid because the target identity is already in use.

The rename is interpreted in sequence. Later rows in the same payload are evaluated against the renamed article identity only after the rename row has been handled.

Marks the garment/article as returned to the laundry path without deleting the garment information.

Garments/articles with unique identity.

The garment is resolved by chip number in the customer scope derived from the device.

The garment is marked as returned.

The row is invalid.

No business change is made.

The return-marking mutation remains distinct from delete and load mutations. It is interpreted in its own place in the ordered journal, and it updates the garment state without removing the garment itself.

Deletes the garment record from the current customer scope.

Garments/articles with unique identity.

The garment is resolved by chip number in the customer scope derived from the device.

The garment record is deleted.

No business change is made.

The current interface treats a missing garment as a no-op rather than a hard failure.

Delete is interpreted in source order. Earlier rows for the same garment still apply before the delete, and later rows are not allowed to behave as if the delete happened earlier than stated in the file.

Marks which garments/articles should be sent as an outscan for loading into the device.

Garments/articles with unique identity.

The garment is resolved by chip number first. The current item state is then checked to decide whether the outscan should be sent.

If the garment has no current location in Q-Cloud 2, the outscan is always sent.

The interface compares the current item state with the file’s loading date and only sends the outscan when that state is still considered current enough. If the item looks newer than the file by too much, the row is skipped instead of sending a stale outscan.

The mutation is invalid.

The device operation uses the garment identity that Q-Cloud 2 treats as the external garment id. In this interface that is the garment chip number. When no row-specific date is present elsewhere, the surrounding control block timestamp remains the default business time for the load decision.

Records a garment-delivered-to-wearer event in the source stream. The current interface recognises the row, but it does not apply a business state change.

Garments/articles with unique identity.

The garment is resolved by chip number in the customer scope derived from the device. The current interface accepts the row as a recognised mutation, logs it as warning-only, and does not change garment state.

No business change is applied.

The row is still recognised, but no delivery state is applied.

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

As in the old source document, this is a delivery-state mutation rather than a garment-definition mutation. In the current Q-Cloud 2 implementation, it is kept as a recognised input type without a business action.

Adds a signal to the garment/article, for example a repair or adjustment signal. In the current UNILIN-UNIMAT implementation the row is recognised, but it does not trigger a business change.

Garments/articles with unique identity.

The mutation is recognised by the interface, but no garment or article state change is applied.

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