Posting Rule and/or Function governing Job Subcontract POs

Good morning (or applicable!)

I’m a bit in over my depth with financials and we don’t have anyone in-house on the Epicor/IT side with more experience in the Posting Engine, so I figured I’d ask about the scope of this problem.
We’re using the standard posting ruleset, and as far as we can tell, all Job Subcontract-type PO Line Releases post to 1120-01-000, WIP Work in Process.

For “normal” job subcontract lines, this has been okay (though it might make more sense for those to go to 1130-01-000 WIP Subcontract?) but now we’d like to track some job-related details about a Definitely-Not-WIP job.

For some short context, one of the processes we do in-house is sheet-metal powder-coating. Parts need to be hung on hooks as they go through the powder-coating line’s spray booth and curing oven, and these hooks accumulate buildup of the powder-coat as time goes on. While these hooks aren’t tremendously expensive, it’s cheaper to send these outside to get them sandblasted than it is to buy entirely new hooks when they lose their conductivity, so we’d like to make a small Job, with a misc operation for our Powdercoat dept, Pack, Outside Process, and Inspection on receipt. This way we can record quantities and financials against the job, and we’d like to use this data for process improvement as well.

These hooks aren’t going to be sold to a customer, but they’re going to post to WIP just the same, and so we’d like to change what account segment Job Subcon PO Releases pull from to instead be based on either the Part Class, or potentially a UD field on the Job itself.

The transaction type these post under is PUR-SUB; Looking at the posting rules for PUR-SUB transactions, the only thing I see that might have something to do with this is below. I haven’t actually changed anything on this rule, I just created a new Revision to be able to see how the controls for it work.

Looking at the posting rules in general though, I’m out of my element. Is this something we should hand off to a consultant? I’ve taken a look at the transaction hierarchy guides, but I don’t think I’ve got enough accounting context to be able to configure these myself without learning a fair bit more.
For all I know, the posting rule itself is fine and we’re missing a GL Control specified somewhere else.

Anyone do anything like this? How’d you do it?

Hi Julie,

Do you happen to have the Maintenance Module? The hooks would be considered equipment, and the maintenance job would track costs and expense them to the appropriate expense account.

We use the maintenance module; We looked into considering them an Equipment, but chose not to because Maintenance Subcontract operations don’t record part quantities and the resulting PO ends up looking strange.
We also don’t get to use our PDRs to handle the shipment/receipt steps, which was a bonus of trying to do it the “normal Job” way.

This also applies to things like getting a fixture waterjetted, or similar. Not every Job we run with a subcon operation is producing a sold part, and internal stuff is taxed differently, I think? Long-term we need to be able to use different GL Codes on normal Job Subcon ops.

I’m the only one who’s tested this here, but it also seems like Maintenance SubContract operations still get coded as WIP, though again I might have something set up incorrectly.

In your Company Configuration | GL Control, what account do you have in your INV, COS and WIP GL Contro?

Happy Monday!
We’ve got nothing listed under Maintenance Expense.
The only two non-required Account Contexts we have specified are Inspection and Actual Cost Allocation Burden

I’m guessing this is the ‘Context’ that the posting functions refer to in places like Get Segment For XYZ?

My guess is that Maintenance Expense is the COGS charged when the Maintenance Job is closed. I didn’t have time to check this. The Maintenance Expense also exists on Equipment Type and that will override the Maintenance Expense account.

But like you, I didn’t see a way to set the Product Group to change the WIP account for a piece of equipment. You CAN link Equipment to a Part number but that only seemed to pick up UOM information.

However, you might be able to use Job Type with Equipment Type to override the WIP account number for PUR-SUB in the Posting Engine. :thinking:

Anywho, are the hooks have a unique identifier? That would be necessary for the Maintenance module and you would have a job for each one. :frowning: I’ve never tried batching with subcontracting operations…

Separately, I’m having trouble getting my head around charging “the production job” for maintenance expense. The hooks might be sent out a small job but the bulk of the build-up on the hooks may be done to a previous job - unless one customer ties up that whole process.

Ultimately the reasoning for wanting to use a production job is all internal processes.
We don’t use Inspection Processing, or any of the Workbench apps other than Engineering, and our shop floor employees do the vast majority of their tasks by working off a PDR that an internal app renders by scanning the ResourceTimeUsed tables, rather than any kind of task lists or Kinetic-native processes.

If I want our Pack dept to see that they need to do this, the only clean way to do that is to add an Operation to it, and I’m trying to avoid a whole subset of Maintenance Operations for doing things like packing hooks into a box. If I want them to count them on the way back in the shipping door, they need a Receipt (thankfully not an operation) and ideally an Inspect operation as well.

Because so much of our processes are ‘tuned’ around our normal Jobs processes, I was hoping we could piggyback those to get this somewhat-weird maintenance task done. We’d run into some GL issues with Subcon Maintenance in the past already so it seemed like two birds with one stone if I can dip my toes into this and start to understand what’s going on under the hood.

Blockquote
However, you might be able to use Job Type with Equipment Type to override the WIP account number for PUR-SUB in the Posting Engine. :thinking:

This is where I was hoping to go, but I don’t think I’m familiar enough with all the moving pieces yet.

EDIT:
The hooks aren’t individually-addressed, there’s about 100 of them mounted on a dragchain around our Powdercoat room; I’m not sure how many in total there are. The Equipment record would probably be either “Powdercoat Line” for the whole thing, or “Powdercoat Hooks” for the dragline itself if we went that route, but an individual Equip record for each of a hundred+ hooks is untenable.

We aren’t trying to get the Customer to pay for de-coating them, either, we just want to be able to record information about doing so without needing to jam it all in the Comments/Labor Note and unpack it later. Which job caused them to get coated is irrelevant, thankfully. Cost-wise, this is all accounted for already within our Burden rates for the equipment.

I get it. But every time I try to co-opt a field or process for something else, I get burned. Every. Single. Time. I try to optimize for one department and someone downstream now has to track things manually, which kind of defeats the purpose of being in one system. :wink:

In the end, we have to make the determination if the juice is worth the squeeze. We could avoid all this by buying extra hooks and when the box is full of untreated ones, we send them out on a miscellaneous PO. There’s no tracking like there is with the Subcontract one, but maybe the effort isn’t worth it. That’s a decision for your team.

You might be able to create groups of hooks as equipment and send them out as sets? :thinking: