Split Inventory on a Run
Discover the functionality of splitting WIP through an issue ticket. This helps with splitting inventory on a run when an issue with some parts is detected.
Use Case:
During the receiving process, your looking at 10 parts provided by a supplier. After conducting an inspection, you note that 3 of those 10 parts contain visual defects that deviate from the expected condition.
How do you address the issue with those 3 parts without holding up the progression of the other 7 through your process?
In ION you can create an issue ticket to handle just those three parts, assign a location to them such as an MRB cage, and continue running the remaining seven.
For information specific to issues check out this page with more details.
The video bellow shows you how to execute this functionality in the run execution window.
Case Study: Create 5 "New York Cheesecakes" and Split Off 2 Mid-Process
This is a more complicated case were the parent inventory item has multiple child components required to build it, these are the aBOM build requirements.
Steps followed in the video:
Establish the run to produce those five cheesecakes.
Once the run has been created you will see these in inventory as WIP. They will also be assigned a location of your choosing, in this case the "Great Place".
The build requirements (aBOM) for a singular cheese cake is setup to be 3 Sugar, 2 Cream Cheese, and 1 Egg. This will be important when we create an split WIP issue with partially installed quantities.
Total Build requirements for the five cheesecakes is thus: 10 cream cheese, 15 sugar, 5 eggs.
During the procedure you have installed 2 sugar and 1 cream cheese when you notice there is an issue with two of the cheesecakes. The location of the installed goods at this point is in the "Great Place" where the cheesecakes were originally destined for.
You create an issue ticket to split those two cheesecakes off the run and put them in a location called "Bad Place".
From the inventory page page, you will now see that those two split cheesecakes are available now in the "Bad Place". If "Bad Place" was an "Unavailable" inventory location, users could use it as a way to make split-off inventory "Unavailable" for use elsewhere.
Likewise the current logic is that all components installed into the split-off inventory will also move to the new location "Bad Place".
Looking at the aBOM now for this run you will see a couple additional pieces of information.
For build requirements that had some inventory installed before the split, they will now show a UI indication that they are shared between the two parent part inventories. In the video's example, it shows the build requirement is linked to inventory ID 12 and 15.
The quantity looks like Qty: 1 of 6 (10). Hovering on the tool tip shows you that 1 inventory is still installed on the build requirement, quantity 6 is the current quantity required by the build requirement of the part, and quantity 10 was the original build requirement quantity. Since it's impossible to exactly know whether the qty 1 was a component of the newly-split off inventory or still in inventory attached to the Run, the previously installed inventory will remain visible on the Run's aBOM even after the split.
6 total sugar are needed for the remaining three cheesecakes down from original 10 demanded.
Logic Diagrams:
These diagrams show how inventory will be divided up based on full installs, partial installs, or no aBOM install scenarios. The final locations of children inventory will be reflective of the locations of the child parts (pink boxes) after the split (on the right side of the arrow).
Scenario 1: This scenario details a case where the parent part related to the run has not had any build requirements installed against it. In this case the split parent parts after the issue has been created will also cleanly split the build requirements.
Scenario 2: When inventory has either been partially or fully installed toward a run's build requirements and then the parent inventory gets split, the following case will take place. Here you can see that due to each build requirement already having inventory installed, there is no easy way to say which installed inventory belongs to which of the two parent inventories. So ION instead will link each build requirement to both parent part inventories. This allows users to at least know that the installed inventory could be in either or both of the parent inventories.
Scenario 3: When some build requirements are fully installed and others w/o installs the build requirements without installs get allocated to their own location. The fully installed inventory follows the same behavior as scenario 2, resulting in the below execution.
Last updated
