We are currently setting up a company that inventories their steel products in lbs but sells them in pcs. The company does not want to use jobs. So to get the system to work somewhat for their needs, I was thinking that I could add 2 fields to the OrderDtl table called Pieces_c and Length_c. What I need help with is getting the system to update the Order Qty field based on the Pieces_c and Length_c and Part.NetWeight fields. The Order Qty field will reflect the total lbs.
example: Customer orders 4 pcs of PartX at 7", the unit net weight is 0.2225.
Calculation should be 4 * 7 * .2225 = 6.23 lbs
I am not sure of the best way to go about this, and my C# knowledge is nonexistent.
I was thinking SalesOrder.Update based on the condition that the Pieces_c and Length_c fields have been changed from any to another. I don’t know if that is the best way though
That’s a tricky one. I keep finding areas where we did things like that and then find ourselves unable to use some Epicor feature as a result. Is there no way to use something out-of-the-box?
We stock aluminum extrusion in “Lengths” and consume it in inches, and the conversion is handled in Part UOM Conversion Maintenance; is it possibly similar?
You might find that doing this would be tricky but more sustainable.
Another thing that helps us, is that just cutting stuff up being a repetitive job that takes <1min, we used Kanban Receipt jobs to actually execute. For order-related there’s some automation involved, but for cutting pieces to stock its just handled by the supervisor.
I know I didn’t really answer your question but hopefully that’s useful…
I was looking into that, but one day a CustomerA could order 4 pcs of PartX at 7" lengths and then CustomerB could order 7 pcs of PartX at 9.4" lengths. The lengths are all over the place and don’t want to have to create several UOM’s.
If they are always ordering by the number of inches, then you’d create an “Inch” Part-Specific UOM on the Weight UOM Class, and the be able to specify that on the sales order as a Selling UOM. Each inch of PartX weighs 0.2225 pounds. They order 7 inches, Epicor does the math. They order 9.4", Epicor does the math. Quantity in the Sales Order Detail form is the number of inches they purchase.
That makes sense to me, but then how does the system know that we are selling 4 pcs of 7" steel bars? I understand the conversion part I am confused when you start factoring in the number of pieces.
Say we purchase steel at 12’ lengths, we will receive it in as lbs. Then a Customer orders 4 pcs of that steel and they would like it cut down to 2" each. I can put 2" into the Order Qty but where does the 4 pcs fit in.
I need to be able to show the pcs, lengths, and lbs for reporting purposes as well
So… in that case I’d combine the two options. Looking at your “4 7-inch pieces” example…
The value in the “Order quantity” box on the Sales Order Line form is the amount that pricing is based on, and the amount that will be transacted out of inventory… so THAT number (in this example) needs to be 28 inches… which needs (a) a price per inch; and (b) a conversion to however many pounds. This problem gets solved with an “inch” Sales UOM.
However, the customer needs to see how many inches and how many pieces were purchased. This can be solved with the UD fields you described in the original post.
Finally, so that the sales people don’t need to do that math, you could create a BPM to multiply your Pieces and Length values to populate the Order quantity field. Since these are UD fields and can be populated at any time after the “New Line” is created, I’d have as my process to fill these fields in FIRST (BEFORE entering the part number), and then put the Method Directive BPM on the SalesOrder.ChangePartNumMaster BO. Once the part number is entered, the calculation runs and populates the Order Quantity field.
Since the order default pricing is per inch, you will probably want to create another UD field for “PiecePrice”, which would be the Inch price * Length.
Finally, you’d need to modify the Sales Order Acknowledgement, Pack Slip, and AR Invoice forms so that they’d show the customer what they expect to see.
This is a sort of convoluted subterfuge, but it doesn’t mess with any Epicor processes.
And yes, there are probably holes in this, but testing would probably find them.
What if the pricing is based on pieces or lbs and not inches. That is why I was thinking the Order Qty needed to reflect lbs and not inches. I just don’t know how to get the unit net weight from the Part table into the calculation.
Unless the pricing can be based on a UOM that is defined in your system, then you need to build an entire process that will somehow keep your quantities and pricing in line with each other. If that is how your business has no choice but to go, then you have a LOT of work ahead of you. By simplifying it so that Epicor can use the processes it already has, it will be tedious but not necessarily difficult.
It sounds like this is a good fit for Epicor Advanced UOM Management Module.
I had a client @bboes that was trying to do exactly what you are suggesting (I think), had it sorta working and then instead implemented the Advanced UOM Managment and it’s worked out much better.
The trouble with what you are proposing is the downstream implications, you will probably find yourself then needing to add UD fields to other tables changing various reports, and it quicky becomes very difficult to manage.
@Rick_Bird makes an excellent point… in addition to just the SO Acknowledgement, Pack Slip, and AR Invoice forms, you’ll need to add these UD fields to any number of trackers and dashboards, which may well entail more UD fields in more tables.
We have the same scenario in the metal service industry and we are implementing the Advance UOM module to handle this. Also we worked with the Encompass partner and they have implemented several metal service companies on Epicor, so they understand the needs. When a part is created we have a custom UOM class grid loaded automatically that enables all the conversions from feet to pounds to metric to inches, etc.
Between the custom UOM conversions and the Advance UOM module we have our needs covered. Two features for us with the Adv UOM module are critical. Dual UOM is one of them. So tracking of total lot footage by bin with a Pieces tracked also. The second feature is allow different inventory lengths for the same part number. this allows us to cut a part into 20 footers, 10 footers, 5 footers and track the inventory that way.
You need to send work instructions to someone to cut the bar’s to the correct length
The material needs to be pulled from stock.
And, someone did some work to produce the parts.
Using a job template you can make to order without creating new part numbers each time.
The quantity to be issued to the job will be in pounds.
Job Traveler is printed to the floor to cut the material and sent with the parts to shipping.
Could you use the Sales Kit functionality where you have part numbers for inches or lengths that are a sales kit part, with one kit component being the inventoried part in lbs. Stores will get a picking list in lbs while customer gets an invoice in inches or lengths; and no job number.
