You can try creating a UDF for the QOH and map it to the SO_OpenOrderWrk file.  The source would be IM_ItemWarehouse.

When creating the UDF in SO_OpenOrderWrk I do not find IM_ItemWarehouse as an available data source. It seemed logical that the QuantityOnHand field would using IM_ItemWarehouse as the source?

Doesn't seem like you can source the quantity on hand into the work table and i don't know why the existing field does not populate. If you must have the value, you will either have to add the table with the correct join on the item code and warehouse code (from the detail, not the header) or use a sub report to IM_ItemWarehouse linked on the item code and warehouse code (from the detail, not the header). You can either use the subreport to return the value or you can use a combination of formulas in the subreport and main report that use a single shared variable to get it in the main report, this approach is useful if planning to export in column/row formats but isn't really needed for printing or viewing on screen.

Thanks, I understand exactly what you are saying. Just disappointed that the field I need is there but not populating. 

I agree it is disappointing (...I've had that request to show QoH on picking sheets).

Be careful if you link to IM_ItemWarehouse because misc charges and comments won't have entries in that table.  A sub-report is safer.

Excellent point on link to IM_ItemWarehouse if using the default inner join. If that is the only other table added to the report, you might be able to get away with using the left outer join without a big performance hit.

Excellent point on link to IM_ItemWarehouse if using the default inner join. If that is the only other table added to the report, you might be able to get away with using the left outer join without a big performance hit.

I would use a sub-report.

It isn't just the outer join... if you use a field from the optional table in a formula (like: if QuantityOnHand < QuantityOrdered then...) you have to handle the NULL values or you effectively make it an inner join.

Yes, there are report options to help with NULL... but they have never worked as consistently for me as an ISNULL check in formulas.

Good point, just another gotcha you have to watch out for. I have found that when nulls are a possibility,  you always have to handle them first with the IsNull function in your If or Select evaluations and sometimes it get plain annoying and redundant. My preferred approach is a formula in a section above the sub report that reset the shared variable to either a 0 or blank string. Then have every section in the sub report suppressed with a formula that sets the value for the shared formula added to the detail section. The formula does not have to return a value. Back in the main report, set the sub report to be suppressed if blank, then set the section the sub report is in to also suppress if blank. Then create a formula in the main report to retrieve the value of the shared variable and return it to the formula. This allows you you to keep your columns consisting of formulas so they export properly to column and row formats. You can optionally add a suppression formula to the section the sub report is in to suppres for item types other than 1 or any other condition you might have in mind, this should keep the subreport from being executed when it doesn't need to.

Thanks everyone for the feedback. This is the first question I have posted so somewhat amazed by the depth and timeliness of the responses!

Yeah, I have a number of tricks for sub-reports to prevent extra white space and ensure proper function.

For sub-reports, I always initialize the shared variables before each iteration.

whileprintingrecords;

shared numbervar QtyOnHand := 0;

""

For fields that can be NULL (from an outer join... or UDF) I usually set up a formula field like:

if isnull(UDF_stringfield) then "" else (UDF_stringfield)

if isnull(UDF_numberfield) then 0 else (UDF_numberfield)