For those who are familiar with our demo and posting that discusses how to drill from a report into a page (blog posting here), you may or may not notice a limitation in what was presented. The example showed drilling from a financial report to the journal entry where the number came from. Unfortunately, drilling to the journal is just not granular enough to tell you exactly where the number came from (journals can have hundreds of lines, and a number in a financial report is governed by the chartfield values that are used).
This means that what you really want to do is to drill to items that are at scroll level 1 or greater in the page. Because the standard URLs to PeopleSoft pages are driven by the search records for those pages, you need to be able to (1) pass parameters to identify what values you want to navigate to, and (2) write code to do the navigation.
Sounds interesting, so how do you do it?
Well, the first part was answered in this posting on how to add parameters to your PeopleSoft pages.
The second part can be acoomplished in multiple ways (depending on the following):
Using the SetCursorPos PeopleCode Function
The first approach we will discuss is using the SetCursorPos function. This works by iterating through the data in the component buffer until you find the row you want to be on, and setting the focus (or cursor position) to a field on that row. Because you can’t navigate to fields that are grayed out (or are read only), this only works when that occurs. Also, since you are navigating through what’s already in the component buffer, if the only loads a subset of the data at a time into the component buffer, then you may be navigating through a small part of the data you want to search. Navigating to a posted journal entry in PeopleTools is a perfect example of where both of these conditions would prevent this from occurring.
Here is an example of code you would use for a page with updatable data where the component buffer contains the full data set you want to search
Local Rowset &rsJrnlLines = GetLevel0().GetRow(1).GetRowset(Scroll.JRNL_LN);
Local number &j;
For &j = 1 To &rsJrnlLines.ActiveRowCount
Local Row &rowTest = &rsJrnlLines.GetRow(&j);End-If;
If &rowTest.GetRecord(Record.JRNL_LN).GetField(Field.ACCOUNT).Value = &sAcctNum Then
Adding a navigation element to the grid
If all the items in the scroll are read-only (or grayed out), then another option is to put a push button or other element in the grid that isn’t grayed out to set focus to. It’s actually as simple as that. You add the item, and then set the cursor position to it. Of course, this gets into customizing the page itself, which can be an issue at upgrade time.
Leverage selection code written into the page
This approach can be used very effectively in inquiry pages or even pages where there search logic is used written by application developers to populate the scroll. The journal line page is a great example of this. There’s a link in the Financials 8.9 journal entry page that allows you to enter search criteria for your journal lines. This page actually displays fields in the JRNL_PANELS_WRK record, which is in the componenet buffer for the page. By merrely setting the values of chartifelds in this work record and calling the adjust_line_scroll function, you can use parameters to restrict the set of journal lines displayed in the page (ultimately drilling to those values).
Here is the code to do that.
Declare Function adjust_line_scroll PeopleCode FUNCLIB_GL.JOURNAL_LINE FieldFormula;
/* Code to drill to row with account number passed in as a parameter */
Local string &sAcctNum = %Request.GetParameter("ACCOUNT");
If All(&sAcctNum) Then
If JRNL_HEADER.JRNL_HDR_STATUS = "D" Or
One last item of note: if there is already Page Activate PeopleCode, you will probably want to put yours at the end for the navigation (this ensures that all other logic has already been executed). The JOURNAL_ENTRY2_IE page is an example of this.