Job Pick Lists

Hello folks,

I’m writing a BAQ to get all the items attached to a Job Pick List. I’ve used the Report Data Definition to help me assemble the entities, but I’m getting what appears to be too many rows.

I assume there are fields that I can help narrow the data down (eg. OpenOrder = true, VoidOrder = false, etc.) at the order level, but can I also determine what pick lists are still “open” ?

Thanks!

image

@Jeff_Owens JobMtl has issued complete, Jobcomplete and (RequiredQty - IssuedQty) to show if open.

Greg

Using all inner joins will certainly lead to some records being missed.

If your job is for stock, and has no linked order, you’ll get nothing returned.

Any Buy to Job materials that aren’t in your system will be missed too. Same goes for any material that is not tied to an operation.

Thanks guys – that’s good info. :+1: I’m not an Epicor functional person, so really appreciate that you’re not laughing and pointing. :yum:

Followup question on this.

We have MANY “open” jobs in the system. Cell leaders operate by a custom schedule (based on certain business rules) to determine when a job will start production. They indicate which ones (in the entire open job lists) that they are ready to begin production on. Making this request, in the past, indicates to someone to produce/print a Job Pick List.

We’re moving away from paper, so we’ve developed a web-interface that pulls the same picklists and displays on our Intranet – thus this custom BAQ.

The job pick list data from the BAQ shown above is queried for each of the jobs they are ready to receive. BTW, this entity relationship diagram is based on the RDD that the Epicor Job Pick List report uses.

Since we “mark” the jobs the cell leaders want by setting a Boolean UD field in the JobHead table, I’d like to narrow the above BAQ results to only show those (where the UD is true) but I’m not sure how JobHead relates to the tables in this BAQ.

Any thoughts? And thanks in advance! :+1:

@Jeff_Owens Join JobHead to JobProd with all matching rows from both and on JobHead set the condition of the UD to be a specified constant of 1. I would probably add a condition for JobComplete = 0 so you don’t show jobs they checked the flag on after they are done.

Don’t be fooled by the structure of an RDD. Those table names might not even be references to the actual tables. The built-in RDD’s can have code behind them to generate data that you can’t get from the simple relationships between tables. In these cases, those “tables” shown in the RD aren’t the same as the DB’s tables. This is why you sometimes find an RDD with a “table” in it that doesn’t exist in the DB. Or an RDD that seems to have fields from tables that aren’t listed in the RDD.