Copyright (c) 2024, Oracle. All rights reserved. Oracle Confidential.

No Demantra Forecast Generated - Common Issues (Doc ID 848205.1)

In this Document

Purpose
Scope
Details
1) The Forecast Engine actually failed which is why no forecast was generated
2) The Forecast Engine succeeded but it did not create 'future' time buckets in the Sales_Data table.
3) The Forecast Engine succeeded and future time buckets are created but no forecast values are observed in the
Demantra Worksheet.
4) Comments on manually changing parameters like Max_Sales_Date, Last_Date, etc. to compensate for incomplete
client data
5) What to upload to Oracle Support if this note doesn't help you to solve the issue.
References

APPLIES TO:

Oracle Demantra Demand Management - Version 7.0.1 and later

Information in this document applies to any platform.

PURPOSE

This note is intended to talk about scenarios where no Demantra forecast appears to have been generated.

The Oracle Demantra application requires item, location and demand (sales) data. Given the required minimum data, run
the full data load procedures; EBS Full Download, ep_load package, ep_load_main wrapper procedure, etc. The engine
should be able to be executed returning forecast data results. Note that the data load procedures and/or engine
run should set all necessary date parameters like max_fore_sales_date, max_sales_date, last_date, etc. based on the data
being provided and should not require any manual intervention.

Date parameters should not be changed manually and instead the data, if no recent data has been provided,
should be manually changed in the staging tables before it enters Demantra to reflect meaningful dates for
Proof of Concept or Demonstration.

SCOPE

This note is intended for those users responsible for monitoring and/or analyzing the output of the Demantra Analytical
Engine

DETAILS

1) The Forecast Engine actually failed which is why no forecast was generated

Determining if the Engine Failed:

-- run the following sql on the Demantra schema:

select lead, last_date, start_date,last_forecast_date,fore_column_name,

start_forecast_date, init_params_table_name, engine_profiles_id
from forecast_history
What you are looking for is a status = 1 (success) for the latest engine run as indicated by the time_sig or date of engine
run. If it is not equal to 1 then review the engine manager logs as per the Errors with the Demantra Batch or Simulation
Engine section of Note 741464.1 and corrective actions should be implemented.

2) The Forecast Engine succeeded but it did not create 'future' time buckets in the Sales_Data table.

A) The Engine ran and it seemed to complete but when looking at the Engine Logs, see the end of this note for how to find
the Engine logs, you see errors like ORA-01652: unable to extend Temp tablespace. If this occurs then you need to have
your DBA allocate more space and then re-run the engine

B) If the Engine has a status = 1, but you still do not see future rows then once again go back to the forecast_history table
and run the same SQL as in the above section:

select lead, last_date, start_date,last_forecast_date,fore_column_name,

start_forecast_date, init_params_table_name, engine_profiles_id
from forecast_history

The key fields that you should review are:

Lead: The number of future time buckets to forecast out into the horizon

Last_Date: The sales_date value in the sales_data table that represents the last period of 'demand' in the database.
Last date of actual sales, to be used by the Analytical Engine and the proport mechanism. No dates after this are used
towards the forecast or the proport calculation.

Last_Forecast_Date: The sales_date value in the sales_data table that represents the period with the furthest amount
of sales of 'demand' in the database. The value should be the value in the Last_Date column plus the Lead column value.

Now since the client is reporting that there are no forecast buckets so it would be expected that the Last_Forecast_Date
would be equal to the Last_Forecast_Date (or at least that the Last_Forecast_Date is not equal to the Last_Date plus the
Lead value).

What if my Last_Forecast_Date is not some date out into the future?

1) Is your RunInsertUnits parameter (Business Modeler --> Parameters --> System Parameters --> Engine (tab) --> Shell)
set to either 1 or 3?

Insert_Units is the procedure that runs at the beginning of the engine that actually creates the future rows (time buckets)
in the sales_data table based on the Lead parameter and should be set to either 1 (Run Insert Units - default) or 3 (Run
Insert Units without Rolling Profiles)

2) Do you have at least 1 combination that meets the rule for Insert_Units to work on and insert rows into the future:

select count(*) from mdp_matrix where level_id > 0 and prediction_status <> 99 and do_fore <> 0;

More information on how future buckets are created and/or if you find that no combinations are eligible per the results of
the above SQL are found in Note 452817.1 - How To Get Forecasting Buckets Generated For The Entire Horizon When The
Item Location Combination Is Dead.

3) The Forecast Engine succeeded and future time buckets are created but no forecast values are observed
in the Demantra Worksheet.

What this might indicate is that the web server has not been restarted or that you are not looking at the Series that
actually represents where the Engine writes its values.

Run the following sql:

select computed_title,exp_template from computed_fields where computed_name like 'batch';

The exp_template column, which represents the Server Expression of the series, should have the #FORE# token in it. The
#FORE# token looks at the latest FORE_COLUMN_NAME value from Forecast_History table based on the latest time_sig
column value where the status column = 1 (engine run success)

Note that you may have another series set up that also looks at the #FORE# token but even if you are using a custom
series then the Server Expression does need to have he #FORE# token somewhere in its expression.

What we have observed is that when the engine has run successfully (Status = 1) and that the Run Insert Units parameter
is set correctly that clients and consultants are manually changing parameters like max_fore_sales_date or last_date to
account for clients who may not have current data to give them. If this is the case then see the next Section of this note
for further commentary.

4) Comments on manually changing parameters like Max_Sales_Date, Last_Date, etc. to compensate for
incomplete client data

If you find that the client has not been able to provide you with the latest Demand data for the Proof of Concept or
Demo then parameters, which would normally be set by standard Demantra data loading procedures, should NOT be
adjusted manually. Instead the available data stream should be massaged before they enter Demantra to reflect more
current dates (ex. 2010 data should be changed to 2011) to make the Proof of Concept or Demo more relevant.

Set back the parameters to what they were originally. Load Demantra with the data that you actually have available and
run the Forecast Engine. Verify that you at least get a forecast generated.

5) What to upload to Oracle Support if this note doesn't help you to solve the issue.

Please open up a Service Request and in it upload he results of the following pieces of information. Note that the sqls
should be run on the Demantra schema and uploaded in either Excel or other non-wrapped format.

1) select count(*) from mdp_matrix where level_id > 0 and prediction_status <> 99 and do_fore <> 0;

-- This will tell us that there is at least one eligible combination to be forecasted

2) select max(sales_date) from sales_data;

-- This will tell us that the rows have indeed not been created out into the future

3) select * from forecast_history order by time_sig;

-- This will confirm to us that the engine completed successfully

4) select pname,value_float,value_date from init_params_0 where pname like 'last_date' or pname like 'last_date_backup'
or pname like 'lead' or pname like 'RunInsertUnits';

[Note: Please note that it is now possible in Demantra to have multiple profile for the engine and you might have some
overriding parameters in other init_params_xxx file. Please check your schema to see if you have any additional
init_params_xxx that might have overriding parameters. In your select statement from (3), you will see the engine run
that you completed. Check for the INIT_PARAMS_TABLE_NAME that you are using for the engine run and query the
table. For example, if you have INIT_PARAMS_1 as the data in the INIT_PARAMS_TABLE_NAME for your engine run,
then run the query below

select * from init_params_1;

Check that there are no parameter entries such as 'last_date' , 'last_date_backup', 'lead' or 'RunInsertUnits'. These
parameters will take precedence over the corresponding parameters in init_params_0.]

-- This will confirm to us that the key parameters are set correctly

5) select pname,pval from sys_params where pname like 'max_fore_sales_date' or pname like 'max_sales_date' or pname
like 'min_fore_sales_date' or pname like 'min_sales_date';

-- This will confirm to us that the key parameters are set correctly

6) The engine manager and engine2k logs

When the Engine is running on Windows

The key engine logs are found under the root drive of the machine where the engine is launched. The folder that holds
these logs usually have Engine2k somewhere in the name. Note that there should be at least Engine2k logs (these are
the logs that show the actual splitting and forecasts that the engine does) in this folder. However, to write the primary
EngineManager logs to this folder you need to go to the Engine Administrator (..Demand Planner\Analytical Engines\bin --
> Settings --> Configure) and change the Engine Manager Log tab from STD to FILE.

There is no need to re-register the engine after this change is made

When the Engine Executables are installed on Linux (new option starting in Demantra v73)

Engine and EngineManager logs are placed at the same level as installed BIN and LIB directories. They can be accessed
under $ENGINE_ROOT/engine2k directory. Sub directories are arranged according to schema name, machine name and
run time.

Logs placement can be configured in $ENGINE_ROOT/bin/Settings.xml file, relatively to $ENGINE_ROOT/lib/Engine.exe

location or by supplying full path.

If you did not have Log set to FILE then we would expect you to re-run the engine one more time so that we can get this
additional logging.

REFERENCES
NOTE:452817.1 - How To Get Forecasting Buckets Generated For The Entire Horizon When The Item Location Combination
Is Dead
NOTE:741464.1 - Key Logs When Troubleshooting Demantra Issues - From Installation to Operations

Didn't find what you are looking for?