ContextID

Discussions related to ReadyDoc development.
Post Reply
MJA-99
Posts: 33
Joined: Fri Apr 08, 2011 2:41 pm

ContextID

Post by MJA-99 »

Hi,

This may also be Crystal Reports board question, yet since the report was imported under ReadyDoc tree, I am posting here.

I am outside contractor helping Title Guarantee with some custom reports. Another contractor has created an existing custom Crystal .rpt called Timeline Report. The report has one Parameter called OrderNumber (String) for main report, and it is based on a Stored Procedure which uses Orders, OrdersContact, and OrderContactPerson tables for the SELECT data. The report is opened from the Order --> Documents Tab in SoftPro (After an existing Order is opened).

In an opened Order, as it is now, the user is always prompted to enter an Order Number once the Document is in sected over to ReadyDoc list on right side of Documents Tab and ran.

The client would prefer the OrderNumber to be automatically populated based on the current order they are interacting with in SoftPro.

Here are my initial conclusions so far based on looking at another .rpt (Buyer HUD-1, Attachment (Letter)) which they said is doing a similiar thing already:

1. There is a text field in model report in Report Header that has the following for text value: Primary Context {{Order.Hud}}? How does this factor in to Parameters?

2. I also notice a formula called SetVariables that has the following value (not sure this is needed for real report based on what they want to do):

Shared Numbervar Page;
Shared Numbervar PageSize;
Shared Numbervar StatementType;
Shared BooleanVar Final;

//1st page of HUD, Page=1
//2nd page of HUD, Page=2
//Attachment page of HUD, Page=3
//Legal size, PageSize=1
//Letter size, PageSize=2
//Buyer's HUD, StatementType=1
//Seller's HUD, StatementType=2
//HUD, StatementType=3
//Final Hud, Final=True
//Estimated Hud, Final=False

Page:=3;
PageSize:=2;
StatementType:=1;
Final:=True;

3. There are only two parameter fields in model report that does similiar thing called ContextID and USERID

4. When the report is imported, there is a Context button. Is there a particular item from this we should select?

In summary, the client has a custom report working, however it prompts the SoftPro user who then has to key in Order Number. They would prefer to have this happen in background based on the Order report was opened from.

Thanks,

Michael
Lisa Ennis
Posts: 84
Joined: Thu Sep 11, 2008 1:57 pm

Re: ContextID

Post by Lisa Ennis »

There are several parameters that are passed from our program to the Crystal Report that are coded from our program to not display the parameter when it is rendered. ContextID and UserID are two of those parameters.

I believe you can accomplish what you are wanting to in your custom readydoc report by renaming the OrderNumber parameter to ContextID. You can do this in either your report or at the stored procedure level. For the purposes of your development and testing, it is probably easiest to rename the parameter in the report. Changing names of parameters in the stored procedure and verifying the database afterwards can sometimes cause issues, especially if you have changed the parameter order to be different from parameter order of the stored procedure.

Once you have changed the parameter name to ContextID, then you would probably need to change the selection criteria in the report to be "sprocname.OrderID=?ContextID" or the selection criteria of your stored procedure to be OrderID=@ContextID. When you are testing the readydoc report in Crystal, you will need to enter the OrderID GUID, enclosed in brackets, like this: {F2A6C9C0-81B2-DE11-AB19-0019B9619C4C}

The ContextID then has to be set for the readydoc when you add it to the document tree. It sounds like from the tables that you mentioned in the stored procedure that your primary context would be {{Order}} since the report currently is prompting your for the order number. The most common context types for readydoc reports are {{Order}} or {{Order.Hud}}.

Almost all of our standard readydoc reports, and those copied from our standard ones, are going to have a "SetVariables" formula field. Many of our reports are written using subreports. The subreports utilize shared variables that are set in the main report, and passed to the subreport. So you may not see where it appears the "SetVariables" formula field in the main report is used other than to either exist in the formula fields or is placed on the report and then suppressed. We do this so that we have as few subreports as we can to maintain, and keep as much code in one place as possible. I would caution you to be careful if you remove the set variables formula fields, as they may not appear to have any use in the main report, but the subreports may actuallly utilize that.
Lisa Ennis
Senior Report Developer
SoftPro
MJA-99
Posts: 33
Joined: Fri Apr 08, 2011 2:41 pm

Re: ContextID

Post by MJA-99 »

I did get it to work. I was already doing what you mentioned in your post, yet there was also a Subreport which had OrderNumber Parameter that also needed to be changed to ContextID. Once I changed OrderNumber Parameter Name in Subreport to be ContextID as well, it worked. I did not use the Order.ID due to the fact that everything was already being driven by Order.Number in existing report.

Thanks again for your help.

Michael
Post Reply