Backflushing BOs, Trace Logging, and BPMs

Epicor ERP 10
1

We have parts that are set to not allow negative quantities. We are also backflushing these parts, and I understand backflushing is one of those things in Epicor that ignores this setting, and we are winding up with negative quantities, but this is just how it works.

I want to create a BPM that analyzes the issue material transaction, and based on criteria, modify the quantity that is being issued, so we wind up with 0 in the BIN, rather than a negative. I am having trouble using tracing to even identify the BO that is used for the backflush transaction. I thought I understood how trace logging worked, but I guess I don’t.

Can anyone help me configure my tracing correctly, or even just point me to the BO in question?

2

The backflush BO is a black box. You won’t really be able to get any control of it. (I’ve tried in the past and have been unsuccessful)

I also could go on and on why not allowing negatives isn’t really a good idea, but I’ll just leave it at that.

3

Thanks. Knowing that that is a dead end is a bummer but very helpful.

I will, however, happily discuss your thoughts on allowing negatives.

4

So, and ERP inventory is tracking what’s happening in reality. If you have 100 on the shelf, you say you have 100 in ERP inventory. You use 25 on the shelf, you take 25 out of erp. You now have 75 on the shelf and 75 in ERP. This is the ideal matching of how it’s “Supposed” to work. In this case, you can’t ever have negative of something in real life, so you wouldn’t have negative of something in ERP land.

Now bring some real life transaction hygene into the mix and play with the timings.

You have 10 on the shelf. Erp says that you have 10. You have a job that needs 100. That morning you get a shipment of 500, but the receiving people are busy and don’t get that recorded right away, because there is a stack of paper to go through is sitting on their desk. This is pretty typical. But they knew that the production guys needed it to keep going or the production guys pilfered the receiving area to see if they were there.

Now the production guys finished there 100 parts. Backflush needs to issue the 100 parts, but ERP thinks you only have 10. If ERP stops at 0, there are 90 parts that don’t get issued that they physically used. Later that day, receiving does there paperwork and receives the 500. Now ERP says that you have 500, but 90 of those were actually used so in reality you really only have 410.

If you allowed negatives, the inventory would have backflushed down to -90. Then the receipt would have happened and you would be back to 410, like it should be.

without negatives
10-100 = 0
0+500 = 500

with negatives
10-100 = -90
-90+500 = 410

So negatives are necessary to allow for some flexibility. In the timing of transactions.

Also, there is basically the same scenario with material locations. If the backflush bin runs to 0, and it can’t go negative, when you move material into that bin in ERP land (mirroring what you did in real life just out of order) the amount will be off.

So , negatives should definitely, absolutely be investigated and fixed (exception dashboards are great for this), but simply not allowing negatives simply covers up and creates more problems than is solves.

Even if you aren’t backflushing, this will cause the same problems, because if you have not allow negatives on, and someone is trying to physically move/issue parts that they can see, but the system says “This will result in a negative”, they should investigate and go to receiving and say “Hey receive this so I can do my crap”… But do they? :wink:

The reason Backflushing allows negatives, even when you are set up to not, is that when you are making a manual transaction, and the system stops you, a person is getting that message and has to (is supposed to anyway) do something about it. With backflushing, there is no one to send the message to, and it would lead to this error where epicor says you have more than you do.

Anyways, that’s my soap box for the day.

1 Like
5

I think how flexible you are in the timing of transactions is something people can have wildly different opinions on. I am extremely (admittedly too) rigid here. I would never want to be in a situation where a shipment was delivered, and then physically moved into stock without first being properly received in the system and moved into it’s destination BIN. As close to real time as possible is what I am striving for.

I do understand and agree with everything you are saying though. I am constantly told I have unrealistic expectations, and I constantly reply I believe what I want is achievable. Ultimately I think it boils down to how committed we are to ensuring everyone does their job as directed, and weather or not doing things ‘perfectly’ is worth it.

The issues that arrive from these type of decisions, and the proper way to resolve them, is not what I am actually trying to solve here.

The parts in question here are rolls of thin laminate that are stored in feet. By nature, our inventory in Epicor for these parts, and what exists in real-life, do not jive. We have some very accurate ways to measure footage during production, but once these rolls make their way to inventory and start getting consumed, how much we used, and how much we have left is very much an approximation. The only way to know exactly how many feet we have left would be to roll them out on a machine to count it, which we are never going to do. So we have templates our people use to approximate how many feet are left, to the nearest 100. Whatever number they determine here is the number that winds up in Epicor, which, we already acknowledge, is not perfect, but this is as close as we are willing to get without putting in more effort.

Because of this, when a roll is fully consumed, and also issued in Epicor, we find ourselves with negative quantities, ranging mostly from -99 to -1, left in the from BIN. This is usually from unexpected scrap, or over production (separate issue). Obviously I have the 5XX feet on the roll, or they wouldn’t be able to produce that quantity, but because of my estimation, I only had 500 in Epicor, not 5XX.

We have already decided we are punting on the remainder from the nearest hundred, and do not care about capturing that anywhere, so my idea was to alter the amount Epicor was actually issuing to the job. One of many ways to end up with an empty spool, and 0 in the system.

6

We have an app that we wrote that does something similar to what you are trying to do. We have customer owned material, where they send in a pallet of stuff. The counts on those pallets may or may not be accurate. When they receive them, they receive them at the quantity that’s on the paper work. When they are done with a job, they could have some leftover. They don’t really care that much about the quantity issued to the job, because the cost is zero, but they would like an accurate count of what’s left on that partial pallet.

So there is a function that takes the part number, and job (and some other things that we pass in with a search to find the requisite pieces) and asks for a final quantity on the pallet. Then the function figures out if it needs to issue material, or return material from the job to get the pallet in inventory to the correct quantity and does it all for them. There’s a bunch of nasty code with the issuereturn BO (which is a cluster) but at the end of the day it does work quite nicely.

You could do something like that for the end of rolls. Someone would still have to do something, but you could automated it so that when a roll is done, someone pushes a button, and you could handle a lot of the assumptions.

This works for us because we use PCID’s for each pallet, so we have separate part bin records. If you have more than 1 roll in a bin, and you are adding up the quantity, you are kind of hosed on trying to guess what the quantity is supposed to be.

Cycle counting is your real answer here.

1 Like
7

No PCIDs here. I once broached the idea of lot controlling these rolls but was laughed out of the building.

I understand why though, and have since changed my mind, so nothing resembling serial tracking on these parts.

Maybe a BPM that monitors BINs for negative quantity, looks for specific criteria, and does an adjustment to get it back up to 0.

8

You could schedule a function

I just saw your version. Upgrade so you can schedule functions!

It’s probably easiest to use a UBAQ to do this. The benefit would be you can get the rows, then on a post processing BPM (in the baq itself) you can do your logic.

9

Ok. Is this strictly better than a Data Directive on PartBin. After I posted that it seemed like a bad idea.

10

Well, putting things in data directives hammers your app server because it’s gonna fire all of the time, especially when you are doing lookups and making transactions. It also locks transactions, so it will cause slowdown. Here we generally avoid data directive and only use as a last resort.

If you put it on a UBAQ you would simply run it to clean up negatives as a process occasionally. Personally, I think someone should have an eye on negatives to make sure there isn’t something weird going on besides just the valid scenario that you listed. But if someone runs this once a day, or a couple of times a week, I would think that should be good enough. If after a while you trust the automation enough, you could schedule the UBAQ to run so you don’t have to manually push the button.

1 Like
11

Yes, we do have someone monitoring these regularly, letting negative quantities languish here can easily result in MRP writing a job or purchase suggestion to make or buy something we don’t need. I was just trying limit the negatives to valid issues that need to be investigated/corrected.

Multiple ways to skin that cat I suppose.

12

Remember though, that it’s not just negative quantities that do this. The reality is if you have 0 and ERP says you have -100, that’s the same as if you have 500 but ERP says you have 400. You’re still have 100 more than ERP says you have. But 0 is easier to cycle count than 500. So those things that show up negative should trigger in immediate cycle count, with the easiest count you could possibly do, and now your inventory is correct.