I was today years old when I learned if you close a job before the MTO lines for it are shipped the invoice get’s 0 job cost and sales gross margin goes sideways. Always knew you had to ship before closing a MTO job, but apparently you need to wait until after the final invoice for that MTO job is shipped. Anyone have a good workflow for ensuring that order of operations happens. In my mind partial shipments as a job is being worked on is the big hole for us.
Oh, interesting. And AR invoices in weekly batches over here. Finance, however, closes jobs daily.
EDIT
@jgiese.wci , according to Finance, we close jobs automatically every night and usually invoice a couple of days later. Job costs are apparently accurate. We’ve audited them and never thought to differentiate based on jobs closed pre or post invoicing. We certainly never partial ship though; is that what’s making it happen for you?
The job costs would be fine but run Sales Gross Margin and see what that looks like. Also if you’re not running Make To Order this doesn’t apply.
1 Like
@jgiese.wci @SteveFossey We also compete and close automatically as many as possible and use the job completion or job closing exception trackers to complete and close the stragglers. I don’t recall issues with smaller jobs that don’t have partial shipments.
Partials on the other hand are a mess, but not inaccurate. The first few pieces get stuck with almost all of the cost and sometimes the last few will get a few pennies or no cost at all. Throw in scrap and rework and can be hard to track, but I have always been able to work back to what Epicor calculated.
In our case what I saw was that when the job closed it took the costs and distributed them across the multiple invoices accordingly. One invoice or many it really didn’t matter we don’t get costs then we do get costs based on job closing timing. If we close the job before invoicing we get nothing. I have confirmed this in the database as well running this guy before and after opening/closing a job that has already been invoiced out of order
SELECT InvoiceNum, PartNum, JCMtlUnitCost, JCLbrUnitCost, JCBurUnitCost, JCSubUnitCost, JCMtlBurUnitCost, ChangedBy, ChangeDate, ChangeTime FROM Erp.InvcDtl WHERE InvoiceNum = 126562
Sales Gross Margin showing 100%
I will now open and close the job, which was closed before these invoices were sent.
Run Sales Gross Margin again same exact way (didn’t even close the screen). HEY look costs! 28% seems more reasonable than 100% that’s for sure.
This is one of many examples of this we have. I could go job by job open and close it and fix our SGM report. I just did this as I built this email to demonstrate.
Yes, that’s what we audited, I think, but I’ll check.
Edit yes, our numbers all check out from Sales Gross Margin. Maybe your system just hates you?
Yeah, that’s what we’re doing, almost all MTO. About 80% of our jobs have demand links to sales orders. Ergo, we’re shipping from WIP on those and as far as I can tell all the job costs are in WIP.
“And that, Kids, is how Standard Costing was born…”
2 Likes
Funny thing is, it doesn’t matter if it’s standard or not in this case. We run standard cost and if we close the job before invoicing it still shows 0. You would assume it would show the standard since that is what it is, but it does not. So in my scenario above you close the job and run SGM you get the costs at standard, then if you run the report with Adjusted checked you get the actuals from the MTO job.
1 Like
Maybe? But it’s 100% reproducible. Maybe it’s actually a bug on my version?
very strange. I do know we religiously avoid partial anything, even to duplicate SOs rather than multiple releases.
Jobs have BPMs that blocked reporting partial qty, as do shipments. But that works for our model.
Maybe our insistence on this is saving us 
@jgiese.wci Bug or quirk with other settings and timing. I have an SGM that is a one line excel so sales can monitor GP too high or too low. I did a quick look and out of 3100+ invoices since 1/1 I only have 4 that are 100%. Two MTO and two ship from stock.
They look like we just hosed up the process like shipping from a job that has no materials issued, no operations completed but we got 1 piece out the door 
I am sure there is story behind that one.
Now back to the original question. Depending on how often it happened and even if it was frequent I would probably use your query in an updatable baq and have them reopened and closed. The guy who does our manual closing will paste update hundreds of jobs when he is closing them so it is quick. If you wanted to automate it nightly to just fix them all and it would be just like they never happened. 
@SteveFossey I had a single line sales order/line/release with 57 shipments over 90 days. I asked why and they said the system allowed it so it must have been fine. 
oh, of course
I only skimmed this thread …
But are you using an accrual account?
Shipping will credit WIP, debit AR Accrual
Invoicing credits AR Accrual, debits COS
If you close the job before shipping the WIP goes to a variance account. Then when you ship there’s no costs in WIP to be used as the COS.
One other thing that messed us up was partial shipments (and receipts to inventory) of a job prod qty. This might be limited to just AVG cost methods. But if the prod qty was for 10, and you ship 5, they have a zero COS. If you ship 3 more, they too have zero cost. When the last of the prod qty is shipped, all the remaing costs in WIP (which are enough for the prod qty of 10) go to COS (or to inventory). In my example, those last 2 have a cost of 5x for each. It all works out in the end, as you made 8 for zero cost and 2 for the cost of 10.
so executing the final operation gets the job flagged “candidate” right?
Then auto job completion and auto job closing take any candidate jobs, complete and close them?
But this would mean that any job that doesn’t ship the day it’s executed would be sending wip to variance? Or does auto job closing only act on shipped jobs when they’re MTO?
head spinning with possible implications
If you run MRP, you don’t want to close MTO jobs before they ship - at least in all versions of Epicor I’ve been in (currently 10.2.500.7). If a make direct job is closed before shipping, MRP treats it as not being able to ship and creates a new job.
We run auto complete and auto close - those processes are smart enough to not close the jobs if they haven’t been received to stock or shipped from the job.
We also run the Sales Gross Margin nightly in batch since many of our jobs are average (actual) cost. That way invoice costs get updated all the way until the jobs are closed.
Once the jobs are closed, variance just posts to manufacturing variance and not the specific jobs. If something happens that you want to “account” for in the job - say a considerable difference on a subcontract PO versus invoice, you can reopen the job to get the variance to the job.
There is a reason why costing (part, job) are the extra long classes in boot camp 
Jenn
Partial or not doesn’t really matter the same behaviour is exhibited
We don’t allow closing before shipping. It’s blocked with a BPM. The issue lies in closing the job before invoicing. When I open and re-close a job I can follow the costs applying to all of the associated invoice detail lines.
1 Like
Make to order throws out all the costing rules. It’s “special” when it’s make to order, so it has nothing to do with your already established standards.
Not to side line the original topic, but how exactly does Standard costing work with On-The-Fly parts?
When do the costs (for both the parent of a job and its OTF children) get set to a “standard”?