Where to view job costing?

I don’t generally deal with the costs of a job (material, labor, etc) but I am having to prove to my corporate team that backflushing and issuing give them same results - aka it wont ‘break’ things.

I intend to duplicate a job that has already run from LIVE into my test environment. I will ensure all of the job details are the same (part num, parts produced, etc). I plan to turn OFF backflush and use the BOM to calculcate exactly how much material is needed and issue it manually.

Presumably. the results of the job costing should be identical. I am concerned a little that some underlying properties may be different (resource labor rates, etc) in my test environment.

I have a few things to consider. First, I can’t depend on my corporate accounting team to validate the tests because they may be unwilling to give ‘accurate’ results since they are deadset against making these changes. Also, I have very limited access to LIVE to validate settings and get the required information to ensure a solid control case. I do have access to BAQ so may there’s an option if I know what to query.

What is the best way to perform a good test to use a proof of concept?

Print Production Detail from Job? Should have the costs.

2 Likes

The JobAsmbl table holds the costs for jobs.

Start your BAQ there.

1 Like

If you do not to write a query or run the Production Detail report Job Tracker also shows cost per Assembly – Job Details -> Assemblies -> Costs. There is a Detail button that shows each Material Cost for the Assembly

1 Like

Up to this point I’ve only associated backflush with material. Is labor also backflushed? Is there anything I will change in that regard by changing whether a material is backflush or issued?

We currently do not log labor. It is assumed when we enter production through Time & Expense

Yes, you can backflush labor.

I’m a little confused. Are you backflushing today?

Everything is backflushed. I am making the case to go to issuing so we can get more accurate material usage.

So, my assumption is that you find huge discrepancies in your inventory levels when you cycle count/year-end inventory?

Switching to issuing will be more work for the business.

We don’t have much choice. It will take more work for the business to fix any of our issues (missing alternate materials and operations).

The biggest issue has been the use of an alternate material - sometimes we use it, sometimes we don’t. Sometimes we use a little, and sometimes we use a lot. Another issue is people not properly reporting scrap.

As far as the issuing goes, I plan to make it seamless for the user. See this snippet below:

The way I have almost decided to handle this is using a combination of issuing and backflush logic – I think I’ll call it back-issuing ™ because it sounds cool. In essence, all material moved into a job will be weighed. BEFORE the job is closed, any remaining physical material will be weighed and moved out of the job. At this point the only material that is electronically still tied to the job will be the actual consumed material. I will write the code to automatically issue that remaining electronic material to job - this means the exact physical quantities consumed will be assigned to be consumed electronically. This also accounts for unreported scrap because since we weighed material into and out of the job, the discrepancies would be from misreported scrap (in most cases). This is a much better solution than constantly adjusting the inventory. It will easier to manage on the floor plus it has the added benefit that accounting sees more accurate numbers, less adjustments, and has the ability to detect when scrap is not being properly entered. In case anyone notices, this is almost the same as simply issuing – so why not do that? The reason I decided to use a hybrid was to keep the steps (and required understanding of the user) to a minimum. With the issuing in our case, there were a couple instances of “if this, then that” which required different steps for different situations. My hybrid should avoid that and still get the same results. One of the other major advantages is that no one has to learn new concepts of issuing and returning – they continue to use the familiar inventory transfers.

If people are complaining about inaccurate scrap in backflush, they do not understand what backflush is. You cannot report scrap in a backflush environment. Either the scrap is factored into the method or it’s not. Either way, accounting will have to do an adjustment at some point for the variance in inventory.

Is the alternate material functionality being used in the system? I’ve only looked at it and have never used it.