Print Approval User on PO Report 1

[PTina]

I need to print the Approval user on the PO. However the table that holds the Approval ID is in the PO Enhancement Dictionary and there seems to be no way to link tables from other dictionaries with tables in the Dynamics dictionary.

I'm trying to see if the rw_TableHeaderString function will at least give me the approver ID in a calculated field but this does not seem to work.

FUNCTION_SCRIPT(rw_TableHeaderString 2277 "POA_Approvals_Detail_Zoom" POP_PO.PO NUMBER 0 2)

Has anyone else been able to print the Approval User on the PO report? What should have been a pretty simple modification (my initial thoughts) is turning out to be somewhat of a nightmare and I'm running out of time.

Help!

 

[PTina]

Has anyone else tried to print approval details on the PO report? I'm open to any suggestions.

 

[jazgeek]

you'll need to add the relationship to approval table to the existing modified report. open the report in report writer, select tables, select purchase order work and hit new. Then hit open to get the table definition screen. Hit the relationship button then new and find the secondary table that includes the approval information (I don't know what the table is so this is as far as I can take you) then select the primary table to secondary table relationship and bob's your uncle.

you'll then be able to insert the info into your report as you would any other field that's selectable.




-----------
and they wonder why they call it Great Pains!

jaz

 

[PTina]

Thanks for you reply Jaz.

However I can't add a relationship because the table POA_Ctrl (POA40003) is not in the Dynamics Dictionary. It is in another dictionary called Purchase Order Enhancements - I guess the Approval function is not fully integrated yet.

That is why I was trying to use the rw_TableHeaderString function which is supposed to pull fields from other dictionaries unto a Dynamics report.

I just can't seem to get it to work no matter what changes I make to the function. I don't get an error but nothing prints even though I can see the approval information in the table and on screen.

 

[jazgeek]

ahhh... yes the infamous not in the same dictionary report problem...... been there numerous times. I wouldn't hold my breath... just look at the advance lookup dictionary, it's been seperate since version 5.

well knowing how much you hate crystal reports, I won't bother saying that is the way that I would do it



-----------
and they wonder why they call it Great Pains!

jaz

 

[jazgeek]

now that being said, I have thought of something you could do on the back end.

you could make a trigger on insert into the approvals table to put the username into a user defined or unused field on the purchase order header. You could then put that field into your report and call it the approval user.

just a suggestion....


-----------
and they wonder why they call it Great Pains!

jaz

 

[PTina]

Thanks. Great Idea Jaz,

I tried it on our test server and it seems to work beautifully.

I used the Confirm1 field in the POP10100 table as it seems not to be used (in our case at least).

Do you know what the field CONFIRM1 in the Puchase Order Work table is used for? I need to investigate it some more to make sure that we won't ever need this field. Maybe it's updated by a module that we don't have or something like that.

This issue with separate dictionaries just grates on my nerves. You have to wonder if Microsoft will ever clean this up: ver 9 still has various dictionaries.

 

[jazgeek]

it might be from autoPO generation or it may just be a throwback to when it was advance PO from previous to version 5. Most likely it's not used by anything else as it's resource description shows it is only used on Purchase order history, temp and purchase order work.



-----------
and they wonder why they call it Great Pains!

jaz

 

[winthropdc]

To obtain information from any table and place it onto a report is easy achieveable using VBA. Are you registered for VBA/Modifier or Customisation Site License?

Dexterity is not capable of combining all the modules into a single dictionary. It can only address up to 22,000 of any type of resource in the core Dynamics.dic dictionary and if HR, Manufacturing, Project, Field Service and all the other small addons from MBS were combined into the core dictionary, Dexterity would exceed that limit.

Also, the separate dictionary architecture is what has allowed developers and partners to create Dexterity addons for vertical markets and horizontal customisations. It is this expandability that has help Dynamics GP become the success it is.

Finally, the rw_TableHeaderString() function is a placeholder function which can be used by a Dexterity developer to return data from their dictionary back into Dynamics core dictionary reports. The developer must have added a trigger for this to work. See KB 888884 for more info.

https://mbs.microsoft.com/knowledgebase/KBDisplay.aspx?scid=kb;en-us;888884

David Musgrave [MSFT]
Senior Development Consultant
Escalation Engineer - Great Plains
Microsoft Dynamics Support - Asia Pacific

Microsoft Dynamics (formerly Microsoft Business Solutions)

http://www.microsoft.com/Dynamics

mailto:dmusgrav@online.microsoft.com

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.