oracle aps: customizing audit reports - home - value...

Oracle APS: Customizing Audit Reports An Oracle APS White Paper January 2004

Oracle APS: Customizing Audit Reports

INTRODUCTION

Oracle Advanced Planning and Scheduling Product Suite provides a set of seeded reports that are useful to analyze the validity of information collected from the source/legacy instance as well as the APS setup information in the source instance as well as the destination APS instance. The reports that are seeded with the APS are:

• ASCP: Audit Collections Setup Data • ASCP: Audit Planning Data • ASCP UI: Audit UI Data • DP: Audit All Fact Data • DP: Audit Level Values • IO: Audit Inventory Optimization Data • ATP: Audit ATP Data

The Architecture of APS Audit Reports is extensible – i.e, customers/users can add more validations to either an existing audit report or create their own Audit reports. This white paper will take you through the Generic Architecture of the Audit Reports and explain how the user could modify an existing Audit Report or create a new Audit Report.

Figure1 – Pre-Seeded APS Audit Reports

Architecture of Audit Reports The Audit reports functionality in APS is basically a validation SQL repository, which provides the following capabilities:

• To seed Audit Statements which are nothing but simple or complex SQL Statements

• To combine a group of above mentioned Audit Statements to an Audit Report

• To report Customizable Error Messages with the Audit Statements

• To report either at a detailed Row-by-Row level or provide a table or business entity level summary error report.

• To execute the one or more such seeded as well as custom reports with all the above-mentioned options.

• The ability to enable or disable a set of Audit Statements attached to a Report.

• To generate reports that are visually differentiated – i.e., errors could be color-coded and made in bold.

As Audit Reports is a validation SQL repository, this feature provides primarily the capability to store the SELECT, FROM and the WHERE clauses of the Validation SQL Statement. Further, this feature also gives the user the capability to associate a custom Message to these Audit Statements. A typical Audit Statement would have the WHERE clause evaluate TRUE for a faulty condition. The Audit statements could be very simple – i.e, the SQL statements are based on the attributes of an underlying table. Sometimes these statements could complex – For instance they may contain a function call in the SELECT clause or they may be based on a complex view. Similar to the SQL Statements, the Messages associated to the Audit Statements could be Simple or could be complex with number of Tokens that are set at the execution time. The main validation SQL repository is the MSD_AUDIT_SQL_STATEMENTS table. Each one of the audit statements is stored as a single record in this table. Each record in this table stores the SELECT, FROM and WHERE clauses of the Audit Statement. Further, the relationship of the Audit Statements to its Report, the Oracle Application to which this Statement belongs, and the Error Messages that are associated to the Audit reports are all held as attributes of each record. The detailed description of this table is given in Table1.

Column Name Description

STATEMENT_ID System Generated Statement ID

STATEMENT_NAME User Defined Statement Name

STATEMENT_DESCRIPTION User Defined Statement Description

APPLICATION_CODE Oracle Application to which the Statement is associated

FUNCTION Audit Report to which the Statement is associated

TRANSLATE Not used currently

COLUMN1 First Attribute to be reported

COLUMN2 Second Attribute to be reported

COLUMN3 Third Attribute to be reported

COLUMN4 Fourth Attribute to be reported

COLUMN5 Fifth Attribute to be reported

COLUMN6 Sixth Attribute to be reported

COLUMN7 Seventh Attribute to be reported

COLUMN8 Eigth Attribute to be reported

COLUMN9 Ninth Attribute to be reported

COLUMN10 Tenth Attribute to be reported

COLUMN11 Eleventh Attribute to be reported

DESCRIPTION1 User Friendly Description of the first attribute to be reported

DESCRIPTION2 User Friendly Description of the second attribute to be reported

DESCRIPTION3 User Friendly Description of the third attribute to be reported

DESCRIPTION4 User Friendly Description of the fourth attribute to be reported

DESCRIPTION5 User Friendly Description of the fifth attribute to be reported

DESCRIPTION6 User Friendly Description of the sixth attribute to be reported

DESCRIPTION7 User Friendly Description of the seventh attribute to be reported

DESCRIPTION8 User Friendly Description of the eigth attribute to be reported

DESCRIPTION9 User Friendly Description of the ninth attribute to be reported

DESCRIPTION10 User Friendly Description of the tenth attribute to be reported

DESCRIPTION11 User Friendly Description of the eleventh attribute to be reported

FROM_CLAUSE The FROM clause of the audit statement

WHERE_CLAUSE The WHERE clause of the audit statement

ERROR_MESSAGE Error Message associated to the Audit Statement

SUMMARY_MESSAGE_ONLY Lookup to Enable whether a Audit Statement will report only in the Summary Mode

SUMMARY_MESSAGE The Summary Message Associated to the Audit Statement

SUMMARY_TOKEN1 The First Token in the Summary Message

SUMMARY_TOKEN2 The SecondToken in the Summary Message

SUMMARY_TOKEN3 The Third Token in the Summary Message

SUMMARY_TOKEN1_VALUE The Actual Value for the First Token in the Summary Message

SUMMARY_TOKEN2_VALUE The Actual Value for the second Token in the Summary Message

SUMMARY_TOKEN3_VALUE The Actual Value for the Third Token in the Summary Message

ENABLED Lookup to Enable or Disable a Audit Statement Table 1: MSD_AUDIT_SQL_STATEMENTS table description

The Audit Engine, which executes the Audited Statements stored in the above-mentioned repository, is launched as Concurrent Program - “Audit Statements Report”. The details of how to launch this concurrent program and the meaning of this concurrent program’s parameters are detailed later in the Launching the Audit Reports section. The detailed logic of the Audit Engine is shown Figure 2.

Get the Report Name, Instance, Plan and Output Type Parameters from the ConcurrentProgram.

Setup the Output Report Format [ Log File]

Set all the Universal filters based on the Concurrent Program Input Parameterlike Instance and Plan

Fetch all the Enabled Audit Statement for the Audit Report

for each audit statement

Construct the Dynamic SQL using the SELECT, FROM and WHERE Clausesmentioned in the

SQL Repository - MSD_AUDIT_SQL_STATEMENTS

Output the results of the Previous query in the Output Format initialized

Execute the Dynamic SQL Statement constructed in the Previous Step

Figure2 – APS Audit Execution Engine Program Flow

User Procedure to Create, Launch & Analyse Audit Reports: The user procedure to create an Audit Report is detailed in the Flow diagram below:

APS Audit Reports Functionality:

Aud

it R

epor

tA

naly

sis

Aud

it R

epor

tsE

xecu

tion

Audi

t Sta

tem

ent

Def

initi

on Define the AuditReport

[Lookup]

DefineSELECT clause

of theAudit Statement

for the Report

DefineFROM & WHERE

clause of theAudit Statement

for the Report

Create Audit Statements for the Report. This is a cyclical process that involves each one of the following steps.

DefineHeader Messageand associate it

to theAudit Statement

DefineError Messageand associate it


DefineSummary Message

& Tokensand associate them


Executethe Audit Reportfrom SRS Form

UsersAnalyze the

Audit Reportresults in either aHTML or simple

text format

1

2

3

4

2a 2c2b 2d 2e

Figure 3 – User Procedure to create, and Launch Audit Reports

In the next section, the white paper will take you through the creation of a Simple Audit-Statement as well as a complex Audit-Statement that are Pre-Seeded.

Detailed User Procedure to Create a Simple Audit-Statement: Inconsistent DB Link for ATP This Audit Statement is one of the Pre-Seeded Audit Statements that is shipped in the “Audit ATP Data” Report as a part of Global Order Promising Application. The logic for this Validation is as follow:

If the A2M_DBLINK attribute of the MRP_AP_APPS_INSTANCES table in the source instance is not equal to the “MRP: ATP Database Link” Profile in the source Instance then raise an Error displaying the following details:

• A2M_DBLINK attribute in MRP_AP_APPS_INSTANCES • The “MRP: ATP Database Link” Profile Value

The following SQL Statement accomplishes the audit logic mentioned in the previous page:

SELECT

A2M_DBLINK, FND_PROFILE.VALUE (‘MRP_ATP_DATABASE_LINK’), ‘ERROR’

FROM MRP_AP_APPS_INSTANCES@M2A_DBLINK

WHERE INSTANCE_ID = @INSTANCE_ID AND A2M_DBLINK <> FND_PROFILE.VALUE (‘MRP_ATP_DATABASE_LINK’)

The detailed user procedure required to seed the above-mentioned Audit Statement is as follows:

• Enter a New Record in the Audit Statements Form. • Under the Audit Report Section, Choose the “Audit ATP Data” as the

Report Name and “Oracle Advanced Supply Chain Planning” as the Application.

• Create the Messages that will be used as the Header, Error as well as

Summary Information messages. For this report, we will create the following messages:

o MSC_ATP_DB_LINK_PRE: Checking consistency of Database Link Information between the value of Profile Option MRP: ATP Database Link and the mrp_ap_apps_instances table value.

o MSC_ATP_DB_LINK_ERR: ERROR- The database link information is not the same in the two columns above. Set the Source Instance Profile MRP: ATP Database Link to match the Source to APS Database link specified in the Setup > Instance form on the Destination.

Refer to Figure 4a and 4b.

mailto:MRP_AP_APPS_INSTANCES@M2A_DBLINK

• Under the Audit Statement Section, create the new Audit Statement – INCONSISTENT_ATP_DB_LINK and associate the Header Level Message for this Audit Statement - MSC_ATP_DB_LINK_PRE as well as the Error Message to be reported – MSC_ATP_DB_LINK_ERR. Check the Enabled check box to enable the Audit Statement. Refer to Figure 4 in the next page.

• Under the Columns Sub tab, create the various attributes that needs to be

reported - i.e. mention all the columns in the SELECT clause of the Validation:

o A2M_DBLINK o FND_PROFILE.VALUE (‘MRP_ATP_DATABASE_LINK’) o ‘ERROR’

In order to describe the attributes reported in a more user-friendly fashion, each of the above reported attributes are given the following descriptions:

o DB_LINK_TABLE (A2M_DBLINK) o DB_LINK_PROFILE (‘MRP_ATP_DATABASE_LINK’) o TYPE

Refer to Figure 4 in the next page.

• Under the Query Clause Sub Tab enter the FROM and WHERE clauses of the Audit Statement. All the rows that evaluate TRUE in the WHERE clause will have its attributes (as specified in the columns sub tab) reported. For this Audit Statement the FROM and WHERE clauses are mentioned below:

o FROM CLAUSE: MRP_AP_APPS_INSTANCES@M2A_DBLINK

o WHERECLAUSE:

INSTANCE_ID = @INSTANCE_ID AND a2m_dblink <> FND_PROFILE.VALUE ('MRP_ATP_DATABASE_LINK')

Refer toFigure 5.

• In the Summary Message Sub Tabs associate the Summary Messages as well as the values that will be substituted for the tokens in the messages. For this simple Audit Statement, we will associate the same Header Message MSC_ATP_DB_LINK_PRE as the Summary Message as well. Refer to Figure 6.

mailto:MRP_AP_APPS_INSTANCES@M2A_DBLINK

Figure 4 – Creating the Audit Statement and entering its Report Columns

Figure 4a – Creating the FND Message that is associated to the Audit Statement as the Header.

Figure 4b – Creating the FND Message that is associated to the Audit Statement as the Header.

Figure 5 – Entering the Query Clauses – FROM and WHERE Clauses

Figure 6 – Entering the Summary Information for the Audit Statement

Detailed User Procedure to Create a Complex Audit-Statement: Custom Stream Data Audit This Audit Statement is one of the Complex Pre-Seeded Audit Statements that is shipped in the “Audit Fact Data” Report as a part of Oracle Demand Planning Application. The logic for this Validation is as follow:

If the data in MSD_CS_DATA for custom stream[s] do not have the Foreign Key association for Product, Geography, Time, Organization, Sales Channel and Sales Representative dimensions to the Demand Planning Dimension Repository - MSD_LEVEL_VALUES table [i.e, they are parent less children], then error out those records and highlight just the column[s] in each row that does not have it Foreign Key association to the MSD_LEVEL_VALUES table.

The following SQL Statement accomplishes the audit logic mentioned in the previous page:

SELECT

A.ROWID, A.INSTANCE, DEF.NAME, A.CS_NAME, DECODE (PRD.LEVEL_PK, PRD_LEVEL_VALUE_PK,

PRD_SR_LEVEL_VALUE_PK, ''|| PRD_SR_LEVEL_VALUE_PK || '') ,

DECODE (PRD_PARENT.LEVEL_PK, PRD_PARENT_LEVEL_VALUE_PK, PRD_PARENT_SR_LEVEL_VALUE_PK, ''|| PRD_PARENT_SR_LEVEL_VALUE_PK || ''),

DECODE (ORG.LEVEL_PK, ORG_LEVEL_VALUE_PK, ORG_SR_LEVEL_VALUE_PK, ''|| ORG_SR_LEVEL_VALUE_PK || ''),

DECODE (CHN_LEVEL_VALUE_PK, CHN.LEVEL_PK, CHN_SR_LEVEL_VALUE_PK, ''|| CHN_SR_LEVEL_VALUE_PK || ''),

DECODE (REP.LEVEL_PK, REP_LEVEL_VALUE_PK, REP_SR_LEVEL_VALUE_PK, ''|| REP_SR_LEVEL_VALUE_PK || ''),

DECODE (GEO.LEVEL_PK, GEO_LEVEL_VALUE_PK, GEO_SR_LEVEL_VALUE_PK, ''|| GEO_SR_LEVEL_VALUE_PK || ''),

DECODE (DCS.LEVEL_PK, DCS_LEVEL_VALUE_PK, DCS_SR_LEVEL_VALUE_PK, ''|| DCS_SR_LEVEL_VALUE_PK || '')

FROM MSD_CS_DATA_V1 A, MSD_CS_DEFINITIONS DEF, MSD_LEVEL_VALUES PRD, MSD_LEVEL_VALUES PRD_PARENT, MSD_LEVEL_VALUES ORG, MSD_LEVEL_VALUES GEO, MSD_LEVEL_VALUES CHN, MSD_LEVEL_VALUES REP, MSD_LEVEL_VALUES DCS

WHERE A.CS_DEFINITION_ID = DEF.CS_DEFINITION_ID AND A.PRD_LEVEL_VALUE_PK = PRD.LEVEL_PK (+) AND A.PRD_PARENT_LEVEL_VALUE_PK = PRD_PARENT.LEVEL_PK (+) AND A.GEO_LEVEL_VALUE_PK = GEO.LEVEL_PK (+) AND A.ORG_LEVEL_VALUE_PK = ORG.LEVEL_PK (+) AND A.REP_LEVEL_VALUE_PK = REP.LEVEL_PK (+) AND A.CHN_LEVEL_VALUE_PK = CHN.LEVEL_PK (+) AND A.DCS_LEVEL_VALUE_PK = DCS.LEVEL_PK (+) AND (DECODE (PRD.LEVEL_PK,

A.PRD_LEVEL_VALUE_PK, 0, 1) = 1 OR DECODE (PRD_PARENT.LEVEL_PK,

A.PRD_PARENT_LEVEL_VALUE_PK, 0, 1) = 1

OR DECODE (ORG.LEVEL_PK, A.ORG_LEVEL_VALUE_PK, 0, 1) = 1

OR DECODE (GEO.LEVEL_PK, A.GEO_LEVEL_VALUE_PK, 0, 1) = 1

OR DECODE (CHN.LEVEL_PK, A.CHN_LEVEL_VALUE_PK, 0, 1) = 1

OR DECODE (DCS.LEVEL_PK, A.DCS_LEVEL_VALUE_PK, 0, 1) = 1

OR DECODE (REP.LEVEL_PK, A.REP_LEVEL_VALUE_PK, 0, 1) = 1

)

The detailed user procedure required to seed the above-mentioned Audit Statement is as follows:

• Enter a New Record in the Audit Statements Form. • Under the Audit Report Section, Choose the “Audit All Fact Data” as the

Report Name and “Oracle Demand Planning” as the Application.

• Create the Messages that will be used as the Header, Error as well as Summary Information messages. Further for this Complex Audit statement, in order to provide a more user-friendly description of the columns that are reported, the descriptions of these columns will be messages as well. Hence for this report, we will create the following messages:

o MSD_AUDIT_CS_DATA: ERROR- The database link information is not the same in the two columns above. Set the Source Instance Profile MRP: ATP Database Link to match the Source to APS Database link specified in the Setup > Instance form on the Destination.

o MSD_AUDIT_ ERROR: &COUNT error(s).

o MSD_AUDIT_FACT_COLUMN_ROW: Row Identifier.

O MSD_AUDIT_FACT_COLUMN_INSTANCE: Instance

O MSD_AUDIT_DEFN_NAME: Custom Stream Name

O MSD_AUDIT_DEFN_DESIG: Stream Designator

O MSD_AUDIT_FACT_COLUMN_ITEM: Item Identifier

O MSD_AUDIT_FACT_COLUMN_P_ITEM: Parent Item Identifier

O MSD_AUDIT_FACT_COLUMN_ORG: Organization Identifier

O MSD_AUDIT_FACT_COLUMN_CHN: Channel Identifier

o MSD_AUDIT_FACT_COLUMN_REP: Sales Rep Identifier

o MSD_AUDIT_FACT_COLUMN_LOC: Location Identifier

o MSD_AUDIT_FACT_COLUMN_DCS Demand Class Identifier

Refer to Figure 7a, 7b and 7c.

• Under the Audit Statement Section, create the new Audit Statement – Custom Stream Data Audit and associate the Header Level Message for this Audit Statement - MSD_AUDIT_CS_DATA as well as the Error Message to be reported – MSD_AUDIT_ERROR. Check the Enabled check box to enable the Audit Statement. Refer to Figure 7 in the next page.

• Under the Columns Sub tab, create the various attributes that needs to be

reported - i.e. mention all the columns in the SELECT clause of the Validation:

O A.ROWID O A.INSTANCE O DEF.NAME O A.CS_NAME O DECODE (PRD.LEVEL_PK, PRD_LEVEL_VALUE_PK,

PRD_SR_LEVEL_VALUE_PK, ''|| PRD_SR_LEVEL_VALUE_PK || '')

O DECODE (PRD_PARENT.LEVEL_PK, PRD_PARENT_LEVEL_VALUE_PK, PRD_PARENT_SR_LEVEL_VALUE_PK, ''|| PRD_PARENT_SR_LEVEL_VALUE_PK || '')

O DECODE (ORG.LEVEL_PK, ORG_LEVEL_VALUE_PK, ORG_SR_LEVEL_VALUE_PK, ''|| ORG_SR_LEVEL_VALUE_PK || '')

O DECODE (CHN_LEVEL_VALUE_PK, CHN.LEVEL_PK, CHN_SR_LEVEL_VALUE_PK, ''|| CHN_SR_LEVEL_VALUE_PK || '')

o DECODE (REP.LEVEL_PK, REP_LEVEL_VALUE_PK, REP_SR_LEVEL_VALUE_PK, ''|| REP_SR_LEVEL_VALUE_PK || '')

o DECODE (GEO.LEVEL_PK, GEO_LEVEL_VALUE_PK, GEO_SR_LEVEL_VALUE_PK, ''|| GEO_SR_LEVEL_VALUE_PK || '')

o DECODE (DCS.LEVEL_PK, DCS_LEVEL_VALUE_PK, DCS_SR_LEVEL_VALUE_PK, ''|| DCS_SR_LEVEL_VALUE_PK || '')

In order to describe the attributes reported in a more user-friendly fashion, each of the above reported attributes are associated with the following messages:

O MSD_AUDIT_FACT_COLUMN_ROW O MSD_AUDIT_FACT_COLUMN_INSTANCE O MSD_AUDIT_DEFN_NAME O MSD_AUDIT_DEFN_DESIG O MSD_AUDIT_FACT_COLUMN_ITEM O MSD_AUDIT_FACT_COLUMN_P_ITEM O MSD_AUDIT_FACT_COLUMN_ORG O MSD_AUDIT_FACT_COLUMN_CHN o MSD_AUDIT_FACT_COLUMN_REP o MSD_AUDIT_FACT_COLUMN_LOC o MSD_AUDIT_FACT_COLUMN_DCS

Refer to Figure 7.

• Under the Query Clause Sub Tab enter the FROM and WHERE clauses of the Audit Statement. All the rows that evaluate TRUE in the WHERE clause will have its attributes (as specified in the columns sub tab) reported. For this Audit Statement the FROM and WHERE clauses are mentioned below:

o FROM CLAUSE: MSD_CS_DATA_V1 A, MSD_CS_DEFINITIONS DEF, MSD_LEVEL_VALUES PRD, MSD_LEVEL_VALUES PRD_PARENT, MSD_LEVEL_VALUES ORG, MSD_LEVEL_VALUES GEO, MSD_LEVEL_VALUES CHN, MSD_LEVEL_VALUES REP, MSD_LEVEL_VALUES DCS

o WHERECLAUSE:

A.CS_DEFINITION_ID = DEF.CS_DEFINITION_ID AND A.PRD_LEVEL_VALUE_PK = PRD.LEVEL_PK (+) AND A.PRD_PARENT_LEVEL_VALUE_PK = PRD_PARENT.LEVEL_PK (+) AND A.GEO_LEVEL_VALUE_PK = GEO.LEVEL_PK (+) AND A.ORG_LEVEL_VALUE_PK = ORG.LEVEL_PK (+) AND A.REP_LEVEL_VALUE_PK = REP.LEVEL_PK (+) AND A.CHN_LEVEL_VALUE_PK = CHN.LEVEL_PK (+) AND A.DCS_LEVEL_VALUE_PK = DCS.LEVEL_PK (+) AND (DECODE (PRD.LEVEL_PK,

A.PRD_LEVEL_VALUE_PK, 0, 1) = 1 OR DECODE (PRD_PARENT.LEVEL_PK,

A.PRD_PARENT_LEVEL_VALUE_PK, 0, 1) = 1

OR DECODE (ORG.LEVEL_PK, A.ORG_LEVEL_VALUE_PK, 0, 1) = 1

OR DECODE (GEO.LEVEL_PK, A.GEO_LEVEL_VALUE_PK, 0, 1) = 1

OR DECODE (CHN.LEVEL_PK, A.CHN_LEVEL_VALUE_PK, 0, 1) = 1

OR DECODE (DCS.LEVEL_PK, A.DCS_LEVEL_VALUE_PK, 0, 1) = 1

OR DECODE (REP.LEVEL_PK, A.REP_LEVEL_VALUE_PK, 0, 1) = 1

)

Refer toFigure 8.

• In the Summary Message Sub Tabs we will not associate any messages, as the Report in itself is a summary one. Refer to Figure 9.

Figure 7 – Creating the Complex Audit Statement and entering its Report

Columns.

Figure 7a – Creating the FND Message that is associated to the Audit Statement as the Header.

Figure 7b – Creating the FND Message that is associated to the Audit Statement as the Error.

Figure 7c – Creating the FND Message that is used as the Column Descriptions for the Attributes of the Audit Statement.

Figure 8 – Entering the Query Clauses – FROM and WHERE Clauses of the

Complex Audit Statement

Figure 9 – Entering the Summary Information for the Complex Audit

Statement

Launching the Audit Reports The users can launch the Audit reports by submitting the “Audit Statements Report”. This program takes the following attributes:

• Application: This is the Oracle Application to which the Audit Report is associated with.

• Report: This is the name of the Audit Report that will be launched. Based on the report chosen, different sets of Audit Statements will be executed.

• Plan: This is the name of the plan for which the Audit Statements will be run. For the set of reports for which the plan name does not make sense, the plan name will default to “Collection”. A typical Example for this would be running the “Audit All Fact Data” report for Oracle Demand Planning.

• Instance: This parameter is used to restrict the records that are audited to only the rows that are collected from this instance

• Report Type: This determines the output of the Report. The output report could either be a Row-by-Row detailed report or a High level Summary report. The following four Kinds of reports are supported:

o Summary Report o Detailed Report – Complete o Detailed Report – Errors o Detailed Report – Errors and Warnings

This following section takes you through launching an Audit Report – “Audit All Fact Data” report of Demand Planning. Go to the Submit Request (SRS) Form and enter “Audit Statements Report” as shown in Figure 10.

Figure 10 – Launching Audit Statements Report

In the Parameter section of the SRS Form, enter the relevant information:

• For the Application parameter, choose Demand Planning. This is a required parameter.

• For the Report parameter, choose Audit All Fact Data report. For this

parameter only the relevant audit reports that are seeded for a particular Oracle product will be brought in – i.e., this parameter is dependent on he application parameter field. This is a required field.

• For the Plan parameter. Choose the respective plan for which this audit

report needs to be run. For the reports to which this parameter does not make sense, this will be defaulted to Collection – i.e, this parameter is a dependent field on the Report parameter. For the report we are running, it is defaulted as Collection.

• For the Instance Parameter, choose the instance whose collected rows

need to be audited. This is not a required field, so if the user does not specify any instance all rows that are collected from all the instances will be validated. In this specific case we will launch the audit report against records from the tps instance.

• For the Output Type: the user can choose one of the 4 report types

previously mentioned. Refer to Figure 12. In this specific case we choose “Detailed Report – Complete”

Refer to Figure 11 for the screenshot of these parameters.

Figure 11 – The Parameters of Audit Statements Report

Figure 12 – The Different Types of Reports Supported

Analyzing the Audit Reports The users can then view the generated Audit Report by clicking on the View Output button of the FND Requests Form. The screen shots of the outputs of two sample reports are given to show the difference between a Summary Audit Report [Refer to Figure 13a] and a Detailed Audit Report [Refer to Figure 13b]. In the Detailed Audit output that is displayed, do note that all the column values that do not have its Parent Key (Foreign Key violation) are highlighted in red. The data analyst or the programmer can look at such reports and take the corrective action to make sure that the data in APS datamodel is clean and error free.

Figure 13a – Sample Summary Audit Report

Figure 13b – Sample Summary Audit Report

Customizing Audit Reports This white paper so far has discussed the Architecture as well as the User Procedure to create Audit Statements. This particular section deals mainly with customizing existing reports or creating a new custom Report. Typically customers would like to put in their own custom validation logic on top of the pre-seeded validations that are shipped out of the box by APS. Customers can accomplish the above-mentioned goals in one of three ways:

• Create a new Audit Report: This is the recommended and commonly used way to develop a custom report. In this method the user will create his own validation SQL statements, test them initially using SQL Plus, and then seed these SQL statements as new Audit Statements and associate them with a newly created Report.

• Include a new Audit Statement in a existing Audit Report: This is the next commonly used way to develop a custom validation. This method is recommended as well. In this method the user creates his own validation SQL statement, test it initially using SQL Plus, and then seed these SQL statements as new Audit Statements and associate them with an already existing Report.

• Modify an existing Pre-Seeded Audit Statement: This method is not recommended and is the least common way to develop a custom validation. In this method the user modifies an existing Pre-Seeded Audit Statement.

Create a new Audit Report: The following section will walk the user through the steps required to create a new Audit report as mentioned in Figure 3. The intention of this exercise is to create:

o A new custom Audit Report – “ATP Profiles Custom Audit” o This report will include two audit statements which will report

the “Inv: Capable to Promise” at both the Destination and the source instance. The SQLs and the names for these audit statements are given below:

INV: Capable To Promise Dest. Profile :

SELECT 'INV: Capable to Promise', MEANING FROM MFG_LOOKUPS WHERE

LOOKUP_TYPE = 'MRP_ATP_TYPE' AND LOOKUP_CODE = FND_PROFILE.VALUE('INV_CTP')

INV: Capable To Promise Profile : SELECT 'INV: Capable to Promise', MEANING FROM MFG_LOOKUPS@M2A_DBLINK WHERE

LOOKUP_TYPE = 'MRP_ATP_TYPE' AND LOOKUP_CODE = FND_PROFILE.VALUE('INV_CTP')

o Test the above mentioned SQLs in SQL Plus as shown in Figure

14a and 14b.

o Create the new Audit Report as another entry – “ATP Profiles Custom Audit” in the Audit Report Lookup Type as shown in Figure 15.

o Seed the Header as well as Summary Messages that will be used

in the above mentioned Audit Statements:

MSC_MRP_INV_CTP_PRE: Checking the value of Profile Option INV:Capable To Promise. Refer to Figure 16a.

MRP_INV_CTP_PRE : Checking the value of Profile Option INV: Capable to Promise. 'INV: Capable to Promise'. Refer to Figure 16b.

o Create a new Audit Statement “INV: Capable To Promise Dest.

Profile” for the “ATP Profiles Custom Report” custom report. Associate the Audit Report to “Oracle Advanced Supply Chain Planning”. Enter the Audit Statement’s Columns, Query Clause based on the SQL mentioned above, enable it and associate MSC_MRP_INV_CTP_PRE as its Header as well as Summary Message as shown in Figure 17a, 17b, and 17c.

o Create a new Audit Statement “INV: Capable To Promise

Profile” for the “ATP Profiles Custom Report” custom report. Associate the Audit Report to “Oracle Advanced Supply Chain Planning”. Enter the Audit Statements Columns, Query Clause based on the SQL mentioned above, enable it and associate MRP_INV_CTP_PRE as its Header as well as Summary Message as shown in Figure 18a, 18b, and 18c.

o Launch the the newly created Audit Report - “ATP Profiles

Custom Report”. Refer to Figure 19.

o Analyze the output of the Audit Report. Refer to Figure 20.

Figure 14a – Testing the SQL for “INV: Capable To Promise Dest. Profile”

Audit Statement.

Figure 14b – Testing the SQL for “INV: Capable To Promise Profile” Audit

Statement.

Figure 15 – Creating the New Audit Report “ATP Profiles Custom Audit”

Figure 16a – Creating the Summary Message for “INV: Capable To Promise

Dest. Profile” Audit Statement

Figure 16b – Creating the Summary Message for “INV: Capable To Promise

Profile” Audit Statement

Figure 17a – Creating the “INV: Capable To Promise Dest. Profile” Audit

Statement

Figure 17b – Creating the “INV: Capable To Promise Dest. Profile” Audit

Statement

Figure 17c – Creating the “INV: Capable To Promise Dest. Profile” Audit

Statement

Figure 18a – Creating the “INV: Capable To Promise Profile” Audit Statement

Figure 18b – Creating the “INV: Capable To Promise Profile” Audit Statement

Figure 18c – Creating the “INV: Capable To Promise Profile” Audit Statement

Figure 19 – Launch the Custom Audit Report - “ATP Profiles Custom Audit”

Figure 20 – Detailed output of the Custom Audit Report - “ATP Profiles

Custom Audit”

Figure 21 – Summary output of the Custom Audit Report - “ATP Profiles

Custom Audit”

Include a new Audit Statement in an existing Audit Report:

In this method the user creates his own validation SQL statement, test it initially using SQL Plus, and then seed these SQL statements as new Audit Statements and associate them with an already existing Report. The detailed user procedure for this is a sub-set of the user procedure mentioned in the previous section for creating a new Audit Report - starting from the bullet on creating new Audit Statements.

Modify an existing Pre-Seeded Audit Statement:

As previously mentioned, this method is not recommended and is the least common way to develop a custom validation. In this method the user modifies an existing Pre-Seeded Audit Statement. The user procedure usually involves testing the modified SQL statement initially in SQL Plus and then making the modifications to the already existing Audit Statement. The user then can launch the Audit Reports and analyze the results.

Appendix A – Seeded Audit Reports & Statements The Audit Reports that are seeded for the various APS products are:

Product Report Code Report Name Purpose ASCP COLL_DATA Audit Collections

Setup Data Audit report that checks whether all the ASCP collection related configurations are setup properly.

ASCP PLN_DATA Audit Planning Data

Audit report that checks for errors in the ASCP planning data.

ASCP UI_DATA Audit UI Data Audit report that checks whether all the ASCP UI related configurations are setup properly.

DP FACT_DATA Audit All Fact Data

Audit report that checks for errors in the DP Fact data.

DP LEVEL_VALUES Audit Level Values

Audit report that checks for errors in the DP Level Values data.

IO IO_DATA Audit Inventory Optimization Data

Audit report that checks for errors in the Inventory Planning data.

ATP ATP_DATA Audit ATP Data Audit report that checks whether all the ATP related configurations are setup properly.

The various audit SQL statements that belong to each one of the above mentioned report; their meanings and purposes are described in the following sections.

Product: Advanced Supply Chain Planning

Report Name: Audit Collections Setup Data This report has audit statements that checks the collections objects and configurations. The list of the statements and their descriptions are listed below:

Statement Name Statement Desription

Partitioned PctIncrease and Nextextent Checking to see if any of the Non Partitioned MSC Indexes in Destination have either PCT Increase > 0 or Next Extent > 10 Mbytes.

Destination msc_apps_instances Check Validating Instance Setup information in the Destination.

Source Collections Package Check Checking for Packages in the Destination instance.

Partitioned PctIncrease and Nextextent Checking to see if any of the Partitioned MSC Indexes in Destination have either PCT Increase > 0 or Next Extent > 10 Mbytes.

Partitioned PctIncrease and Nextextent Checking to see if any of the Partitioned MSC Tables in the Destination have either PCT Increase > 0 or Next Extent > 10Mbytes.

Source Planning Profile Options Check Checking for Profile Option Values in the Destination instance.

MSC Tables PctIncrease and Nextextent Checking to see if any of the Non Partitioned MSC Tables in the Destination have either PCT Increase > 0 or Next Extent > 10 Mbytes.

Destination Partitioned Index Check Checking to see if the Indexes on the MSC Partitioned Tables are USABLE in Destination.

Source Planning Flexfields Check Checking for Planning flexfields information in the Source instance.

Source mrp_ap_apps_instances_all Check

Checking to see if the Instance information matches between the tables MRP_AP_APPS_INSTANCES in SOURCE and MSC_APPS_INSTANCES in DESTINATION.

Source mrp_ap_apps_instances_all Check - 1 I - Validating Instance Setup information in the Source.

Source mrp_ap_apps_instances_all Check - 2 II - Validating Instance Setup information in the Source.

Source Collections Package Check Checking for Packages in the Source instance.

Source Planning Profile Options Check Checking for Profile Option values corresponding to the Planning flexfields in the Source instance.

Source Responsibility Check Checking if the Responsibility exists on the Source Instance.

Source Snapshot Check Checking for Snapshots in the Source instance.

Source Snapshot Check Checking to see if all the necessary tables have corresponding snapshots.

Source Trigger Check Checking for Triggers in the Source instance.

Source User Check

Checking if the User exists on the Source Instance. Please note that all the users planning to run Collections should run this report.

Source Views Check Checking for Views in the Source instance.

Partitioned PctIncrease and Nextextent Checking to see if any of the Non Partitioned MSC Indexes in Destination have either PCT Increase > 0 or Next Extent > 10 Mbytes.

MSC Tables PctIncrease and Nextextent Checking to see if any of the Non Partitioned MSC Tables in the Destination have either PCT Increase > 0 or Next Extent > 10 Mbytes.

Report Name: Audit Planning Data This report has audit statements that checks the Planning Data – mainly the ODS data. This audit statement is usually launched after the information has been collected from the source into the planning server, before a Plan run is launched. The list of the statements and their descriptions are listed below:

Statement Name Statement Description

Efficiency Utilization Check Checking to see if Efficiency or Utilization is < 50%.

Fixed LT Check Validating to check if Fixed Lead time > 100 days.

From Unit Number Check Validating FROM Unit Number.

HLS Principal Flag check Principal flag validation When there is more than one resource per activity, check if more than one resource has principal flag set to Yes.

HLS Aggregate Resource Validating that the Routings do not use Aggregated resources.

Intransit LT Check Validating to check if Intransit Lead Time > 100 days.

Msc_item_supplier LT Check Validating to check if Item Supplier Lead Time > 100 days.

Validation of usage_rate_or_amount > 100 Validating to check if Resource Usage Rate > 100 hours/unit.

More than one operation and no principal flag Checking for Routings with More than one Resource and No Principal Flag checked.

Check for more than one standard operations Validating to check if every operation has at least one resource (for OSFM routings only).

Check for profile option MSC: Share Partitions Validating the value of Profile Option MSC: Share Plan Partitions.

Check for Share Partitions set to Yes Validating the Plan partitions information-I.

Check for Share Partitions set to Yes Validating the Plan partitions information-II.

To Unit Number Check Validating TO Unit Number.

VARIABLE LT Check Validating to check if Variable Lead Time > 100 days.

Volume_uom Check Checking for Invalid Volume UOM.

WEIGHTUOM Check Checking for Invalid Weight UOM.

Checking alternate sources Checking if items at an alternate source is cheaper than the primary source.

Assembly carrying cost structure check Checking if there are assemblies whose carrying cost is less than the sum of the carrying cost of the individual components.

Assembly cost structure check Checking if there are assemblies whose standard cost is less than the sum of the standard cost of the individual components.

Destination org carrying cost structure check Checking if the carrying cost of items in the destination organization is less than that in the source organization.

Check for items with incorrect safety stock method Checking if there are items with incorrect safety stock methods.

Check for items with zero carrying cost Checking if there are items with zero carrying cost.

Check for items with zero cost Checking if there are items with zero standard cost.

Substitute items check Checking if there are substitute components, cheaper than the primary component.

Check for items with zero lead time Checking if there are items whose lead time is zero.

Report Name: Audit UI Data This report has audit statements that checks the configurations required for the ASCP UI to function properly. The list of the statements and their descriptions are listed below:


UI Profile Options Check Checking the Profile Options used by UI

KPIs Materialized View Invalid status Check Checking to see the status of materialized views for KPIs

Product: Demand Planning

Report Name: Audit Level Values

This report has audit statements that check the Demand Planning Level Values Data. This audit statement is usually launched after the Level Values has been collected from the source into the planning server, before a Demand Plan build is launched. The list of the statements and their descriptions are listed below:


Parentless Level Values Checking for parentless level values...

Composite Calendar Values with Multiple Parents Checking Composite Calendar Values with Multiple Parents...

Missing Calendars referenced by Organizations Fiscal Calendar Values with Multiple Parent Checking Fiscal Calendar Values with Multiple Parents...

Childless Level Values Checking for level values at aggregate levels that have no children...

Manufacturing Calendar Values with Multiple Parent Checking Manufacturing Calendar Values with Multiple Parents....

Top Levels with more than one row Checking for multiple level values at the topmost level of a dimension...

Report Name: Audit All Fact Data This report has audit statements that check the Demand Planning Fact Data. This audit statement is usually launched after the Fact Data has been collected from the source into the planning server, before a Demand Plan build is launched. The list of the statements and their descriptions are listed below:


Shipment Data Checking for shipment data records that refer to non-existent level values...

List Prices Checking for item list price records that refer to non-existent items...

Time Checking time data...

Price List Audit Checking price list data records that refer to non-existent level values...

Custom Stream Data Audit Checking custom data records that refer to non-existent level values...

UOM Conversions Checking for uom conversion records that refer to non-existent items...

Booking Data Checking for booking data records that refer to non-existent level values...

Manufacturing Forecast Data Checking for manufacturing forecast records that refer to non-existent level values...

Product: Inventory Optimization

Report Name: Audit Inventory Optimization Data This report has audit statements that check the Inventory Planning Data. This audit statement is usually launched after the Inventory Plan is run and is used to mainly check the errors in the PDS for an Inventory Plan. The list of the statements and their descriptions are listed below:


Assembly cost structure check Checking if there are assemblies whose standard cost is less than the sum of the standard cost of the individual components.

Check for items with zero lead time Checking if there are items whose lead time is zero.

Assembly carrying cost structure check Checking if there are assemblies whose carrying cost is less than the sum of the carrying cost of the individual components.

Check for items with zero cost Checking if there are items with zero standard cost.

Check for items with zero carrying cost Checking if there are items with zero carrying cost.

Substitute items check Checking if substitute components are cheaper than the primary component.

Checking alternate sources Checking if items at an alternate source is cheaper than the primary source.

Check for items with incorrect safety stock method Checking if there are items with incorrect safety stock methods.

Destination org carrying cost structure check Checking if the carrying cost of items in the destination organization is less than that in the source organization.

Product: Global Order Promising

Report Name: Audit ATP Data This report has audit statements that checks the ATP configurations. The list of the statements and their descriptions are listed below:


MRP_ATP_INVALID_OBJECTS Checking if any ATP objects or configuration are invalid in the destination.

INCONSISTENT_ATP_DB_LINK

Checking consistency of Database Link Information between the value of Profile Option MRP: ATP Database Link and the mrp_ap_apps_instances table value.

MSC_ATP_INVALID_OBJECTS Checking if any ATP objects or configuration are invalid in the source.

INCORRECT_INV_CTP Checking the value of Profile Option INV: Capable To Promise.

NO_MSC_ATP_SNAPSHOT_MV in Source Checking if the ATP Snapshots/Materialized Views exist in Source.

NO_MSC_ATP_SNAPSHOT_MV in Destination Checking if the ATP Snapshots/Materialized Views exist in Destination.

MSC_ATP_DATABASE_LINK_SUMMARY_ERRChecking if the ATP configuration is distributed and whether Profile Option MSC: Enable ATP Summary Mode is enabled (set to Yes).

MRP: ATP Assignment Set Profile Checking the value of Profile Option MRP: ATP Assignment Set in the Source Instance.

MRP: ATP Database Link Profile Checking the value of Profile Option MRP: ATP Database Link.

MSO: Queue Time Factor Profile Checking the value of Profile Option MSO: Queue Time Factor.

MSC: Enable ATP Summary Mode Profile Checking the value of Profile Option MSC: Enable ATP Summary Mode.

MSC: Enable Allocated WorkFlow Profile Checking the value of Profile Option MSC: Enable ATP Workflow.

MSC: Enable Allocated ATP Profile Checking the value of Profile Option MSC: Enable Allocated ATP.

MSC: Class Hierarchy Profile Checking the value of Profile Option MSC: Class Hierarchy for ATP.

MSC: ATP Assignment Set Profile Checking the value of Profile Option MSC: ATP Assignment Set.

MRP: Include Substitute Components Profile Checking the value of Profile Option MRP: Include Substitute Components in the Destination Instance.

MRP ATP Debug Log Directory Listing the value of Log Directory for ATP.

MRP: Calculate Supply Demand Source Profile Checking the value of Profile Option MRP: Calculate Supply Demand.

MSC_ATP_ALLOCATION_SETUP_CHECK Checking if profile MSC: Class Hierarchy is compatible with profile MSC: ATP Allocation Method.

MSC ATP Debug Log Directory Checking the value of ATP Log File Directory.

MSC: Plan Co-Products Profile Checking the value of Profile Option MSC: Plan Co-Products.

MRP: Calculate Supply Demand Dest. Profile Checking the value of Profile Option MRP: Calculate Supply Demand.

INV: Capable To Promise Dest. Profile Checking Profile Option INV:Capable to Promise setting.

MRP: ATP Database Link Dest. Profile Checking the value of Profile Option MRP: ATP Database Link.

INV: Capable To Promise Profile Checking the value of Profile Option INV: Capable to Promise.

MSC_ATP_COLLECTIONS_STATUS Checking whether Collections have been run successfully for doing ATP.

NO_MSC_ATP_SUMMARY_TBLS Checking whether ATP Summary Tables exist if Profile Option MSC: Enable ATP Summary Mode is enabled.

Oracle Advanced Planning and Scheduling; Customizing Audit Reports January 2004 Author: Daniel A. Soosai Copyright © Oracle Corporation 2004 All Rights Reserved Printed in the U.S.A. This document is provided for informational purposes only and the information herein is subject to change without notice. Please report any errors herein to Oracle Corporation. Oracle Corporation does not provide any warranties covering and specifically disclaims any liability in connection with this document. Oracle is a registered trademark and Enabling the In

formation Age,

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: 415.506.7000 Fax 415.506.7200 Copyright © Oracle Corporation 1995 All Rights Reserved

oracle aps: customizing audit reports - home - value...

Documents