Navigation: TagNet Extension Framework (EF) > Background Jobs >

Delayed Inventory Move Rules

Still need help? Create a Support Ticket with Stratum Support

Send comments on this topic.

← Previous Next →

 

Delayed Inventory Move Rules

 

This feature enables a solution to mitigate false positives of movement when maintaining inventory state where the consistency of tag readability varies when using the (RFDFULL) Binding. When using this binding the following logic occurs: tagged item arrives in a read zone and it is moved to that target location... when it leaves (is no longer seen on the next read event cycle) it is moved to another location such as 'issued', 'in-transit' or 'complete'.  So as long as the tag is read on every read cycle, whether for hours, days or weeks, it generates a single transaction on the entry to the read zone and another when it physically leaves. Where this logic can cause issue is explained below:

Manufacturing Scenario #1:  Tagged WIP is physically moved into a Work Center read zone, it registers in that location and sits there for ~3 hours while being worked on. If the tag is blocked or is providing a weak signal that causes it not to respond for a given read event cycle (e.g. 1 min), then it will be construed as 'gone' and moves to its next location based on the TagNet IMOVE rules. When the tag is then seen on the next or subsequent read cycles, the tag is moved back into that W/C location causing another reversal transaction. This 'ping ponging' of inventory state sends redundant in/out transactions to customer subscribing systems. The System-of-Record doesn't know when it actually physically leaves until the last 'out' transaction is received. 

Parts Inventory Scenario #2:  Tagged Item is physically moved into an RFID enabled read zone, parts cabinet or parts trailer. It registers in that location and sits there until such time it is physically taken out of the area. If the tag is blocked or is providing a weak signal that causes it not to respond for a given read event cycle (e.g. 2 min), then it will be construed as 'gone' and moves to its issued/consumed/check-out location. When the tag is then seen on the next or subsequent read cycles, the tag is moved back into that location causing another reversal transaction. Again, this 'ping-ponging' of inventory state sends redundant in/out transactions indicating false positives of both consumption as well as receipts to customer subscribing systems.

Considerations

Simply increasing the read cycle time will also achieve the same result, however it then delays the accuracy of the time the tag arrives at the dwelling location. For example; if 2 mins is not enough and it is changed to say 10 minutes, this will also suppress redundant in/out transactions however it can then take up to 10 minutes for the tag to register to that location initially.

This logic is not meant to overcome bad readability, if the read zone is not engineered correctly it needs to be by reassessed by adding/repositioning antennas and/or modifying attenuation.

Resolution using Delayed Rules

A temporary location is setup such as 'Pending' and inserted into your location hierarchy. Tags not seen are moved to that ‘PENDING’ location, when they are seen again they move back to the source location (e.g. W/C, cabinet, etc.).

Only when the Tags in the PENDING holding location exceed a given threshold (e.g. 30 mins) are they construed as 'no longer there' and only then moved to formal ‘ISSUE’ location which will been seen as a valid transaction. This logic is managed via a special Job that polls the PENDING location and moves to ISSUE (or whatever the final state is). Note this logic favors the 'in' time accuracy and buffers on the 'out'.

These back and forth transactions (Ping Ponging) are suppressed so you simply will not see them (as they are just noise). Note: This suppression is customized in the Outbound Queue Trigger 

 

 

Create New

This button enables creating a new Delay Move Rule

 

Sequence

The user defined sequence of the rule, they are processed in that order

 

Rule Name

The rule name as defined by the user

 

Delay Time (minutes)

The delay time before the rule is executed based on how long a given tag has been consistently sitting in the source inventory Location.

 

Action Links

These hyperlinks perform the following functions:

 

Edit

Enables change mode of the Delay Rule

Details

Enables inquiry mode only of the Delay Rule

Delete

Enables delete mode of the Delay Rule

 

 


Copyright © 2024 Stratum Global, Inc.