Acuity Report - Consolidated data
- Sophie Rotrou (Deactivated)
- Emmanuel Dotte
Voic aussi les pages suivantes, qui décrivent les algorithmes du LFM
https://acuity-cloud.atlassian.net/wiki/spaces/N/pages/303202395
et les paramètres du LFM
https://acuity-cloud.atlassian.net/wiki/spaces/ACUITY/pages/917930073
Word document explaining the LFM agregation rules at the laundry
Consolidated vs Raw reports – LFM Rules
consolidated reports include a smart treatment layer in order to improve the consistency of the data and get rid of some operational anomalies
Consolidated receiving at Laundry
| Quantity in RAW EVENT report | Quantity in CONSOLIDATED RECEIVING report | Comments |
Item received that was previously shipped to a customer (nominal case) | X | X | If receiving occurs >8h after shipment |
Item received that was shipped very short time ago | X |
| LFM Setting HOURS_LIMIT: delay after shipping to take into account a receiving. By default set to 8h. Useful if the exit door of the laundry is closed to the entrance where the soiled linen is scanned S’applique sur l’algo1 savoir si on archive ou pas le tag s’applique uniquement si on est en mode HFM il compare les dates de last seen et event time de l’event courant. S’applique tout le temps HOURS_LIMIT n’est pas pris en compte dans ACUITY Laundry, suelement en HFM Je fais une lecture : je vérifie algo1 à partir du moment ou le précédent bizstep est un customer shipping et pas vu depuis HOURS_LIMIT, alors on va réinitialiser le cycle et incrémenter le cycle de lavage si le dernier bizstep est différent d’un customer receiving et que l’on fait un customer receiving, alors là aussi
si on enchaine 2 customer shippings à plus de HOURS_LIMIT d’intervalle, alors là aussi on incrémente le cycle
le bizstep clé dans ce cas est le customer shipping : sans customer shipping on considère que le tag reste à l’hpotel.
DAYS_LIMIT s’applique au cas d’ACUITY Laundry compare à la délivery date DAYS_LIMIT configuré à 0 dans ce cas on va chercher la delivery date
je shippe maintenant j’ai configuré delivery day = tomorrow j’ai configuré days limit = 1
Cas 1 : je fais un receiving dans 10 minutes pas pris en copmpte par le lfm
Cas 2 : je fais un receiving demain
Cas 3 : je fais un receiving après demain à 1h du matin il est bien pris en compte et apparaît à la fois dans le raw events et
|
Item missed at portal (receiving) but scanned on soiled conveyors (launching) |
X (launching process) |
X | Benefit of multiplying the successive reading points in soiled reception |
Item received successively twice | X
(2 records) | X
(first reception only) | The second event is ignored in consolidated receiving report, whatever the delay between the 2 receptions. |
Item that was previously shipped (delivery day reached) and that is scanned in the laundry (washing, packing, shipping, condemning etc.) |
| X | Receiving event is created a posteriori (at timestamp of the scan in the laundry) |
Rejecting at laundry | X (rejecting) | X
| Receiving event is created in // for each reject (no need to scan the rejected items through a receiving station) |
Exemple of communication with a customer (JOHNSONS LEEDS) concerning the consolidated receiving data
I have checked precisely how ACUITY handles the items going through the following sequence (ie 2 successive receptions without any shipping nor packing process in between) :
RECEIVING (portals)
LAUNCHING (soiled conveyors, sling)
WASHING (clean conveyors)
RECEIVING (portals)
LAUNCHING (soiled conveyors, sling)
WASHING (clean conveyors)
Etc.
This corner case (that seems to be frequent at Leeds) clearly affects the integrity / accuracy of the data :
The second reception (portal, soiled conveyor, or sling) is not counted in consolidated RECEIVED figures whatever the delay after the first one, because the item is already considered at the laundry.
This is logical and enable to keep integrity between laundry stock figures vs received & shipped figures.
In ACUITY an item is considered out of the laundry if it has been packed or shipped for a customer + delivery day reached, and/or if it is scanned at customer.
So finally due to this corner case the consolidated RECEIVED figures are underestimated at Leeds because any linen that comes back but was not shipped is not counted.
This explains why we have the same order of magnitude between RECEIVED and SHIPPED figures.
We would strongly recommend to stick to the process and not skip the critical shipping step in order to get accurate and actionable figures in ACUITY.
NB : I have also amended the paragraph I wrote below :
Conditions for ignoring a scan in reception (portals, conveyors, sling) in consolidated RECEIVED data:
Items already considered at the laundry (for which the last event is a receiving, launching, or even washing)
Typically : the corner case that we observe at Leeds, where some items delivered physically to customers without being shipped with cabins
Items for which the last event is a shipping to customers, that occurred less than 8 hours ago
Typically : a cage of clean linen that is moved too close to the soiled station before being loaded into the truck
Consolidated shipping at Laundry
| Quantity in RAW EVENT | Quantity in CONSOLIDATED SHIPPING | Comments |
Items shipped to a customer (nominal case) | X | X |
|
Item shipped successively twice to the same customer (with delivery day + day_limit not reached) | X
(the 2 successive shipments) | X
(second shipment only) | The first event is ignored in consolidated shipping report
Delivery day : set on the smart reader for the shipping (ex : today, tomorrow…)
Day limit : ACUITY duration parameter.
Exemples :
day_limit set to 1 and Delivery day = today à the first shipment (Date D) will be ignored in consolidated shipping if the second one occurs before D+1 at 00H00
day_limit set to 1 and Delivery day = tomorrow à the first shipment (Date D) will be ignored in consolidated shipping if the second one occurs before D+2 at 00H00 |
Item shipped successively twice to 2 different customers (delivery day + day_limit not reached) | X
(the 2 successive shipments) | X
(second shipment only) | Same as just above |
Item inventoried at Customer site whereas it was considered at the laundry (or never seen yet) |
| X | Shipping event created a posteriori (at inventory timestamp minus 1h) |
Item inventoried at Customer B whereas it was previously shipped to customer A |
|
| No effect on consolidated shipping report, but Delivery customer (in tag state table) is updated. Shipping event remain the first shipment to Customer A |
Consolidated Checkout at the hotel (Hotel in LFM Extended)
| Quantity in RAW EVENT | Quantity in CONSOLIDATED SHIPPING | Comments |
Items checked out and then the next step is a checkin or any scan at the hotel | X | X then 0 | After the checkout the items are added to the consolidated checkout, but if the items are then scanned at the hotel WITHOUT ANY SCAN AT THE LAUNDRY then the LFM considers that these items have remained at the hotel and removes the corresponding quantity from the consolidated checkout report So finally you can have a consolidated checkout showing 100 items on day D juste after the checkout, and showing 96 items on day D when looking at the report a few days later
|