MRP run appears to be “Unfirming” current jobs that have current Labor and Material transactions.
When we manually “Firm” the jobs - the old job is Deleted (as in not found) and all costs are transferred to a new job - however no details. i.e. actual labor or material details. The labor and Material costs show up in the job Totals.
Has anyone seen this happen before? is it something we are doing?
Any advice appreciated.
DaveO 651-246-3281
Something sounds fishy. Firming jobs is a way one way street. Once firmed it cannot be unfirmed.
Also unclear on what the “old” job is? When firming a job it is expected behavior that the MRP job # changes to a new firm job number. There should never be any costs or transactions against an unfirm job.
Mr. Zach: i think i found the issue.
I have an UBAQ that allows users to add comments to JobHead.Character05.
I added the JobHead.JobFirm field so they could filter by that field. The JobHead.JobFirm is NOT updatable the only updatable is the JobHead.Character05.
However, it appears that whenever someone adds or updates the JobHead.Character05 the JobFirm is being turned off 
That should NEVER happen. when a job is firm - thats it.
When we open the job to “Firm it” the original job is deleted (or re-written) as a new Fxxxxxx job that contains all the cost of the original job - but none of the details.
Really wierd stuff.
I am not sure why the updatable BAQ is writing to the JobHead.JobFirm OR why Epicor even allows changing that field even if the job has Labor and/or material transactions.
I put in a support ticket to look at it. Support wants me to mock it up in Pilot so it can be replicated. Aaaaarg!
That’s super weird. What happens if you exclude the JobFirm field from your BAQ?
If support can’t figure out what’s wonky, or it can’t be avoided, you could try a workaround
by doing a custom update in the BAQ using the Db Context.
If you decide to go with that and need help, holler at me.
Mr. Kevin: for the UBAQ i am using the JobStatus method and not the JobEntry.
My guess is when someone updates the JobHead.Character05 field the BPM (auto generated) does not change the JobFirm meaning it is off and for some reason it is writing that value to the job. Total guess on my part.
I just re-worked the BAQ to use a Calculated string and i called it Calculated_JobFirm so i am not including the JobHead.JobFirm field in the dataset at all. I tested and it seems to working fine. At least the jobs are not being “unfirmed” anymore.
What a mess
I am tempted to go into Pilot to test this out and offer support a repeatable scenario. However, since i have worked around it - i do not see any benefit to me.
I created a mess in our Live system becuase of an Epicor “Bug”. Epicor is not going to fix our mess - we will just have to deal with the 17 jobs that got unfirmed.
I added this info hear to warn any future users of the JobStatus method - DO NOT include the JobHead.JobFirm field in your dataset - create a calculted field instead.
DaveO
I can see that. Sorry for your troubles!
I’m glad that worked. I haven’t looked at Base Update in a while, I would have assumed if the
field was not marked updatable that it wouldn’t touch it, but that does not seem to be the case.
Now I’m going to have to be on the lookout for gotchas like this. 
Best guess is that JobStatus.Update has built in requirements that expects the status to change in some way when called. Since you’re just changing a UD field, the panic mode default must be to toggle the first status file it finds in the data set.
I believe this has happened to me before also. Different table, different BO, etc., but I have a hunch that I have seen it before as well.
Very frustrating.