Frequently Asked Questions (FAQs)

What’s the difference between Pending and Running status? What does it mean when my report gets “stuck” in one of these two statuses?
What do I do if my reports have been in pending or running status longer than expected?
I can’t access CREW. I’m getting a “Page not found” type error.
Why don’t my Balance Forward amounts appear when I run reports for the new Current Fiscal Year?
My PDF reports are not opening! I get a dialogue box that reads ‘File does not begin with %PDF’.
I'm converting a query from the HDWPROD view DWGL_POSTED_ACTUAL_LINES to the HDWUTS/DWCENPRD view DW_TRANSACTION_DETAILS_F_SV and I'm getting budget journals. Why would that be?
I see a record in HDWPROD'S DWGL_PERIOD_CHILD_BALANCES VIEW for my code combination for each period in this fiscal year, but when I run a query for the same code combination in DWCENPRD's DW_PERIOD_BALANCES_F_SV view, I only see one record for the current month. All of the balances for the code combination equal zero. Why don't I get the same number of rows?

What’s the difference between Pending and Running status? What does it mean when my report gets “stuck” in one of these two statuses?

Pending Status: The pending status is the system’s way of telling you that it has received your report request, but is currently busy processing other requests.

The reporting environment is set up so that only a certain number of reports can run simultaneously. An Oracle product called the Concurrent Manager is employed to manage the simultaneous requests. In order to conserve system resources and to make sure that users’ requests are handled in an organized, equitable manner, the HDW team has set up a set number of reports “queues” within the Concurrent Manager.

One or more reports are associated with a particular queue. For each queue, there are a fixed number of slots. Each slot represents an opportunity to run a report simultaneously. As multiple requests for a particular report – the Detail Listing, for example - are submitted, they are assigned to one of the available slots associated with the report’s queue. As soon as a report is assigned a slot, Oracle starts to run it. Any report requests received after all its queue’s slots are filled will remain in pending status until a slot becomes available. The longer the reports in the queue take to run, the longer the waiting requests will remain in pending status.

A good analogy for this is a group of customers waiting in line for their turn at a bank teller window. Let’s say that a group of customers are waiting for only two bank tellers. Teller #1 is handling a customer who is cashing a check. In less than 2 minutes they’re on their way and the next person in line gets right to the window. Teller #2, on the other hand, has a customer who is getting a money order in foreign currency and paying for it with loose change. Teller #2 won’t be helping any other customers for a while. The Teller #2 customer is equivalent to a “long-running” report. Too many customers like that and the queue of customers waiting for the next available teller begins to wind out the door and around the corner!

Again, you can avoid the crowds by doing your banking – er, reporting! – at night. While Harvard sleeps, the reports you’ve scheduled to run overnight chug along to completion and are waiting for you when you come in in the morning.

Running Status: The running status indicates that your report request has been received by the Concurrent Manager (see above), assigned an open slot in the queue, and is querying the data, applying security and formatting it for review. Running times for reports can vary based on a couple of factors:

The number of reports competing for the same data – Just like your PC, the servers which host the reporting applications have constraints around how many simultaneous processes they can handle at a time. Unlike your PC, though, HDW’s servers are extremely powerful machines with loads of memory and high clock speeds. But even the Charles Atlas of servers could only go after the same tables of data a finite number of times. When multiple Detail Listings go after data in the journal lines table, contention arises between them and the length of time it takes the server to process all of them degrades.
The sheer volume of data – Many of the reports run at year-end are summarizing data for the entire fiscal year. As the number of transactions and periods increases, the servers have to work harder and longer to compile all the data; therefore, the same report run for a single period at the beginning of the FY will often take longer when it is run for 12 periods at year-end.
Parameters that are too broad – Certain broad parameters (ALL for every segment for example) can cause the system to have to go out to the system for large quantities of data, only to have to filter those results against a user’s security before the output is displayed. The effort to filter this data takes longer than it would have just to return and filter the smaller data set.

Check out our Reporting Performance During Year-End content for more ways you can reduce your wait times for reports.

What do I do if my reports been in pending or running status longer than expected?

If you think that your reports are in Pending status too long, or reports are taking an inordinate amount of time to run (compared to how long similar reports run during the year), take a look at the “messages” dialogue box on the Financial Reporting Support Year End home page. We will post any known issues there. If you don’t see a message indicating any known issues, feel free to call the Help Desk at 496-2001. They in turn will alert us and we can look into it for you.

back to top^

I can’t access CREW. I’m getting a “Page not found” type error.

Are you using a previously saved bookmark to access the site?. Use the vpf web page to launch financial applications (http://vpf-web.harvard.du/applications/).

back to top^

Why don’t my Balance Forward amounts appear when I run FY06 (Current Fiscal Year) reports?

Balance Forward amounts will not appear on FY07 reports until after the June period is finally closed and the balance forward program runs on the weekend of August 5/6. Any July and August reports run between July 1 and August 7 will not contain balance forward data; however, reports completing on August 8 and beyond will.

My PDF reports are not opening! I get a dialogue box that reads ‘File does not begin with %PDF’.

Please refer to the “Using IE with Oracle Financials” troubleshooting guide for a listing of known issues using IE and how to resolve them.

I'm converting a query from the HDWPROD view DWGL_POSTED_ACTUAL_LINES to the HDWUTS/DWCENPRD view DW_TRANSACTION_DETAILS_F_SV and I'm getting budget journals. Why would that be?

In HDWPROD, we have 3 different views for each type of journal, Actual (DWGL_POSTED_ACTUAL_LINES), Budget (DWGL_POSTED_BUDGET_LINES), and Encumbrance (DWGL_POSTED_ENCUMBRANCE_LINES), as well as one view that combines all 3 (DWGL_POSTED_JE_LINES). For this initial release of journal detail to DWCENPRD, we have only provided a single view, DW_TRANSACTION_DETAILS_F_SV, which is comparable to HDWPROD's DWGL_POSTED_JE_LINES view. To eliminate budget journals from your DW_TRANSACTION_DETAILS_F_SV query, pull in the DW_AMOUNT_TYPES_D_V dimension, join the amount_type_keys between the two views, and add a limit on column DW_AMOUNT_TYPES_D_V.amount_type_cd="A".

I see a record in HDWPROD'S DWGL_PERIOD_CHILD_BALANCES VIEW for my code combination for each period in this fiscal year, but when I run a query for the same code combination in DWCENPRD's DW_PERIOD_BALANCES_F_SV view, I only see one record for the current month. All of the balances for the code combination equal zero. Why don't I get the same number of rows?

The FinStar loads specifically exclude rows where the fact values in all columns equal zero. HDWPROD, because it is really the Oracle transaction system base table, reflects the way Oracle handles the balances, which allows all balances in a row to be zero.

How, you might be wondering, do there come to be records in the Oracle GL_BALANCES source table where all the balances could be zero? Usually it happens because of a transaction that hits and is reversed within the same period such that the net effect is $0. At the time the first journal posts, Oracle creates a record for the code combination in GL_BALANCES where the period net is equal to the amount of the first journal. When the reversing transaction posts, it sets the period net for the code combination to $0. Once the GL_BALANCES record is created though, Oracle treats it the way it treats all other balance records; it continues to carry the $0 balances through for each subsequent period forever.

In order to save database space, the DW_PERIOD_BALANCES_F table in FinStar does not carry records with all zero balances except during the time a period is open. There is a load job that at the start of the month takes all the balances for the new period from OLTP. While the period is open, the FinStar balances are updated as part of the nightly load based on the last_update_date on the record in the GL_BALANCES table in OLTP. Once the period closes, however, there is another job that basically deletes all of the records associated with the closed period and rebuilds them from OLTP. The third job specifically excludes any GL_BALANCES rows where all balances equal $0.

If you look at the DW_PERIOD_BALANCES_F_SV in DWCENPRD today, you will see only one record for your code combination. It's for the FEB-06 period. Assuming that no transactions post to the code combination in FEB-06, when the MAR-06 period opens on March 1, that night's load will create a second balance transaction for MAR-06. Both will be visible until the FEB-06 period closes, when the FEB-06 period balances for the code combination will not be included because all the facts equal $0.