Hey Guys,
So we are trying to set up some sort of system to handle back ordered parts. Our business has extremely large assemblies (as many as ten truck loads) as a single line item on an order. These are engineered to order so naturally we sometimes will be short some items that are long lead time that need to go on the job, but we want to ship the rest of the stuff when it’s done. We also want to be able to ship the job and close it with the correct cost on it so that the revenue is recognized when the order ships. (as a side note, if anyone can explain what happens when you add cost onto a job after it’s shipped that would be very helpful to me, not being an accountant I’m having a hard time tracing GL transactions through the system). As far as we can tell, Epicor is not designed to be able to back order parts of line items on an order, which I can understand as this is a somewhat unique situation.
We have thought about changing order lines to move the parts out of the original line onto a new line, but that raises issues with the original customers P.O. not matching the order and for large corporations that we sometimes deal with, causes huge headaches. It also creates problems with pricing because when you split stuff out like that, markups for parts sales and whole goods it different and so we don’t want to open that can of worms.
So what I have so far for job materials purchased directly to the job that haven’t arrived yet (one subsection of possible back order stuff) is a simple dashboard that reads the RcvHead table and pulls in anything with comments on it. It’s tied to the RcvDtl and PODetail to get the other pertinent information. So anything with a comment shows on the list, and if they put “Comments” (for non-back order related comments) or “Shipped” (no longer on back order) at the beginning of the comment it removes it from the list. They use the comments to explain that these parts were received before they physically got here. Then there is a running list for what is on back order so that customer service knows when dealing with customers, for when shipping gets stuff in that is from a closed P.O., and what do to with the parts (how to ship them out), since E-10 thinks they actually got here and left with the original job. Not the most elegant solution but it works OK and was simple to create.
So that works with that situation and fixes our materials costing issues so that the end of the month margin reports are accurate, and helps with some of the back order parts issues.
Now what I am trying to do is come up with a solution that works for stuff coming from inventory, which would just drive the inventory to negative until the parts arrived (so no job cost issues), or if there is an assembly on the job that can’t ship with the rest of it for some reason (I need to think about what happens with labor after the job shipped). Since they aren’t tied to a receipt entry, I can’t use the other solution, and I need somewhere else to denote that the parts are back ordered, add comments for instructions, as well as be able to remove them from back order.
My first thought was to use the comments from the JobAsm and JobMtl tables to basically do the same thing as I did with the other parts. The problem that I have with that solution is the people who would be putting in the comments won’t have access to job entry (and for good reason). Also my use of the comments boxes to trigger important things like this is clearly a very amateur way to do things. I could add an updateable dashboard to give them access to those fields, so that is one possibility. We don’t use the comments for anything else right now so it could work.
So my next though was using UD fields which is probably the right way to do things. The question is, is it better to simply add an extended fields to the current tables (JobAsm and JobMtl) or is it better to create/use a new UDTable that copies the pertinent information from either table so it can be tied back to those tables without the possibility of messing the original tables up. Both of those solutions would require the use of an updatable dashboard to put the back order information into the system. (Or I suppose a customization into the job tracker may be possible?) Is there problems running an updatable on two different tables if I use extended UD fields? Or should it be two different dashboards for that situation? This is why I’m wondering if it’s better to have a separate table altogether for the back ordered things only so that the dashboard would only affect that new table.
If you have any thoughts, ideas, best practices, or if you have a solution working for this very thing, I would love to hear about it. My plan is to try some things in our test database and get a good scope/plan together and then probably hire a consultant to write the final version so that it will work correctly all of the time as my skills are limited.
