1 Extra DataItem just to link?

I’m building a report that is based on 2 Header tables. DataItem ‘Sales Shipment Header’ DataItem ‘Posted Whse. Activity Header’ (NSC) There’s no field to make a DataItemLink between these tables [:(]. Should I insert a DataItem ‘Sales Shipment Line’ that contains fields that can link to both DataItems mentioned above (I know there can be 1 to n lines). DataItem ‘Sales Shipment Header’ DataItem ‘Sales Shipment Line’ DataItem ‘Posted Whse. Activity Header’ (NSC) If so, what elegant way should I prevent the ‘Posted Whse. Activity Header’ Body from repeating as many times as there are ‘Sales Shipment Line’ records. I already tried the following, but since I’m new to this I ask myself is this the correct way: - make a Global boolean x - OnAftergetRecord ‘Sales Shipment Header’ x:=TRUE - OnPostDataItem ‘Posted Whse. Activity Header’ x:=FALSE - In the ‘Posted Whse. Activity Header’ BodyCurrReport.SHOWOUTPUT(x)

Firstly take a step back and look at the logic. You are trying to find a Warehouse activity document based on a Shipment header. Well there is not link, so it can’t be done. A warehouse activity header could combine multiple shipments, manufacturing transfers etc. By the same token, one shipment could be processed over many warehouse documents. The same logic applies to the classic End User question, “I need the Shipping Number printed on the Invoice” (End user questions do not need to be interrogative[:(]) I am assuming that you have a client that needs a report that shows certain Warehouse detail on a shipping note. Unfortunately this is an issue of training and BPR, part of the process of every Navision implementation. Try to work with your customer, find out what they are trying to achieve, and then offer options on resolving the issue, rather than just programming a solution.

David, thank you for your reply. Now taking a step back, I realise that you’re right. In our case the data I need from ‘Posted Whse. Activity Header’ maybe should be in ‘Sales Shipment Header’ in the first place. To be precise: the units and pallets shipped. We (ignorant of standard Navision [:I]) gave our NSC a functional design to create a ‘single button’ function for 1 employee to post simultaneously: - Sales order - Whse. Activity - Stock Document (NSC specific) adding all relevant shipping data (after a physical check of the goods). Provided 1 Shipment leads to 1 Whse. Activity. We received a solution to start this function from the Whse. Activity Form, adding unit- and palletfields to ‘Posted Whse. Activity Header’ table. No recommendations otherwise. A report to generate unit/pallet labels was included, based on ‘Sales Shipment Header’ & ‘Posted Whse. Activity Header’ linked by an enormous amount of (unclear) code, leading to an incorrect number of labels in backorder situations. I simply created a new report myself (with minimal code) to correct this error and add functionality, but do you think I should re-design the proces?

What to say, and how to say it? [:(] Your NSC should have pointed out where this was headed, BEFORE they programmed it. Is it too late to go back and start again? I can not answer that. You need to look at the long term plans you have for this functionality. Can you work with it this way, and what is the cost compared to the cost to correct it? Something deap in me says “re-design it to solve the problem correctly”, my practical side says “If it ain’t broke don’t fix it”. Is it broken?

It’s not broken anymore [:)]. I will see this as a valuable lesson for other functional issues still to solve with our NSC.

My phylosophy with Navision, is if you are going to make mistakes (and everyone will), then make them as soon as possible, whilst they are still small, cause the least damage ($), and learn from them. The lesson pays for it self many times over. [:)]