Hi
I am using Epicor 10, at the time of job close system issue all backflush parts but stock goes negative what can i do to stop negative transactions.
It is on the Part Class Maintenance, where you can decide what to do with Negative quantity.
Thanks you,
Yes its on Part Class , but in case of Backflush parts feature not working.
This is not a bug⌠the Backflush process actually ignores that setting be design. There is no out-of-the-box way to make it not do that⌠best practice is to develop a process so that either: (1) the person initiating the Backflush checks stock before the Backflush takes place; or (2) someone gets notified that a bin is negative and takes an appropriate action to correct it after the fact.
2 Likes
Hi Thanks,
Yes you are right, but user wants to get notification from system whenever primary bin have not sufficient stock that is not in a Epicor Base system.
For that we need to design BPM, unfortunately i am not found proper trigger to write BPM code.
It would be after the fact, but you could put a data directive on parttran to email the user whenever there is a transaction that brings the bin quantity negative.
1 Like
Thanks,
Yes it can be a temporary solution but not a permanent solution.
Because user wants a notification at time of transactions ,and i think his point is valid because lot of transactions within single day. itâs not easy to track all those.
You can try to use Kanban and Kanban Bin Monitor to have a birdâs eye view of inventory levels
OK⌠so my question always is: âHow did they make it if they didnt have the stock?â⌠seems like allowing it to go negative, and THEN having a dashboard to find all the negatives every day would help you find all your issues⌠The REASON that it went negative could be one of the following reasons:
- the BOM is incorrectly pulling too many pieces on KanBan
- the person in the shop manufactured the part with the incorrect parts
- the inventory count was wrong to begin with.
In each of these scenarios, an investigation can determine the root cause, and can correct it IF they know that there is a problem. The Dashboard is a simple fix in a backflushed world.
4 Likes
Correct me if Iâm wrong @timshuwy , but I believe also once something has backflushed it wonât come back if you reduce production qty. So say you have 1 backflushed part per finished part. You report 10 complete and 10 of the backflushed are issued. You realize you only have 9 complete and adjust the reported qty the backflushed will not adjust with it. That is how I remember seeing that work IRL but itâs been a while since Iâve looked at backflushed stuff so I could be wrong. If Iâm not that is also something to take into consideration.
I think that reducing the qty in production will un-issue, but I am not positive.
1 Like
If you reduce production qty backflushed components will return. Backflushing is both a good/bad thing in Epicor, I wish they made backflushing notifications. If you instead issue materials manually or by using DMT, these transactions will tell when issuing results in a negative and ask for confirmation. Backflushing and average costed parts are a pain since any negative qty cause average costed part to go back to 0 cost. Backflushing is a tool as long as BOM and receiving are inline with job entries.
2 Likes
One challenge is that not all backflushing happens in real time⌠for example:
- Operation 10 is marked as backflushed⌠It has a bunch of materials that are ârelatedâ to op 10 that are also backflushed.
- Operation 20 is marked as Quantity Only. It also has a bunch of materials
I believe that when you complete a quantity against operation 20, it will immediately charge the labor and issue the materials for operation 20, but operation 10 is deferred
Operation 10 will be done in the background later, and all the materials there will be issued once op 10 is marked as complete.
Also note, that in a perfectly simple world, it might be ok to notify the user about a backflushed material⌠but in a more complex world where you have 1000 backflushed materials, you do not want the user to sit around waiting for that to complete, nor do you want 50 warning messages for them to have to click âAcceptâ or ârejectâ against. If you are in a backflushed world, you have already âacceptedâ the fact that some transactions are going to be wonky. If you want perfect transactions, then a user needs to do them one-at-a-time.
I like the word wonky, perfect description of a production world, hard to expect the software to read our minds
1 Like
I think your proper trigger would be âPreCloseJobâ and use a Pre-Processing Directive.
So that would be Method: Erp.BO.JobClosing.PreCloseJob
From there you should be able to check the JobClosing.Backflush to see if itâs true and then run Queriesâ to check your on hand/availability against the Mtl Lines that have open mtl requirements.
@raj05
You can use the base functionality of send the email notification to specific user using global alert.
If the part goes
- Part on-hand is below minimum.
- Part on-hand is below safety.
This may be checker before initiating backflush
@timshuwy and @swilliasc111 described it perfectly⌠and itâs something I say with nauseating regularity: the more you automate something, the less flexibility you retain. If you want ultimate flexibility, then youâre going to do ALL the work. If you want to just push a button and have everything happen by itself, then youâd sure better have programmed it right!
2 Likes
Then you better be willing to follow the rules that you put in place.
The programming is the easy part. Computers do what you say. Humans, not so much.
1 Like
Emailed alerts are ok if this is a rare occurrence⌠but if the people are getting multiple per day, then I find the users add filters to automatically throw away the emails. It would be far better to create a dashboard that people need to look at daily to find all the parts with negatives for them to handle. THEN also make this part of their official job duties (performance review tied to this as a goal). Drive behavior with metrics.
1 Like
I canât really disagree with you @Banderson, but the issue is more making sure youâve accounted for ALL the unintended consequences and twice-a-year-or-less odd scenarios and what-if-the-person-that-pushes-the-button-is-on-vacation and things like that.