The new wiki link for this data flow is here:

Technical Documentation - Procurement - SPRINT report 

Please update the new doc there and no longer here.

General presentation

Objective of the application

This report / application is to track the Purchase Info Record price change information by change date

Before this report, the business was retrieving information on Purchasing Info Record (PIR) price changes from the following back end reports (the reports have a different name per back end report in PF1 and WP1 but are basically the same):

The above reports provide differences in Price only when the calculations based on the Condition records assigned to the PB** conditions set at PIR (Changes to the PIR’s price condition, which are saved in table CDHDR with OBJECTCLAS = COND_A.). But, there are several other factors that impacts the PIR price information changes. This application is to handle all the relevant factors that affect the PIR price changes.

Tool Leader + IT leader of the application: 

Reporting Coordinator : Duarte Costa (Lisbon)

Purchasing Data and P-t-P Interface Manager : Sylvie Severini (Brussels)

Usage information

D&A and buyers are the key users of this report

History

Business requested a BW report that can provide a structure similar to the above mentioned reports in PF1 and WP1 and that is able to provide the price changes per material Base Unit of Measure and also per last condition record unit of measure considering changes done not only to the condition records but the Price Unit information and its quantity conversions.

Requestor: Luis Dias

Roles & Access

Roles and access

List of application role + menu role  and explanation if we have several applications role with specials rules.

Authorization objects

List of authorization objects mandatory for the application.

Dataflow overview

Extraction:

The key logic was built in extractor. The extraction logic was built in such a way that the relevant field's (that affect the price changes) old value and new value should be captured in the extraction.

But, the key challenge is we always have the latest values in the tables. Previous values can only be captured using the change documents (CDHDR & CDPOS).

Example: 

If Purchase order unit of measure (EINA-MEINS) changed from KG to TO...

We will have the value "TO" in the table EINA. But to get the previous value (KG), we need to scan through all the change documents for that PIR.

Extraction logic:

Only the below list of 12 fields are relevant for price differences.

Using the function module "CHANGEDOCUMENT_READ", the extractor picks the change documents of the given date range. Only by keeping the above 12 field's changes, remaining changed were discarded.

In that selected documents, for each change document and its PIR, the subsequent document will be verified in the same list that was selected. If the subsequent document found in the selected list, we will read that document to capture both old & new values. Old values are considered from old change document number and the new value considers from the next available subsequent change document for the same PIR.

If the subsequent document is not found in the initially selected documents, the program again scans for the next available change document of the PIR number. This way of scanning continues for all the relevant 12 fields changes are found. Using both the change documents, it captures both old values & new values of each change document. If subsequent change document is not found for any of the PIR, it means; that particular PIR is not changed after. It means, the existing value for that PIR is the new value for that field.

After capturing the both old & new values of each PIR & change document, the extractor gets the outcome in below format.

Each record represents the above said 12 fields old and new values at change document level.

The extractor is available in both the Solvay & Rhodia systems (WP1 & PF1)

BW Data model:

Just for the sake of quick understanding here is the field mapping details between data source fields & BW info objects

C_O*→ Old Value

C_N*→ New Value

Extractor brings the data in to BW with both old & new values of the PIR at change document level.

The extraction data mapped to the propagation layer DSO, as it is.

The business logic and calculations are built in between propagation layer & business layer DSO's. This include the currency conversions also. Since the conversion is based on the document change date, the currency conversion calculations are done at the transformation level using the conversion rate "CAR1".

Reporting documentation drive folder:

https://drive.google.com/drive/folders/1ztdFqaCBEoDcpm_2156MYKsqTrAbLcyV

In the above folder (Link), FSD, TSD & Data source core logic details are available.

Functional and Technical rules on Workbench + Reporting

Rules & Explanations

All the KPI calculations are explained in this section

All the below calculations are performed in below two transformation's end routine.

ODSO DP_PIRC2 -> ODSO DB_PIRC2

ODSO DP_PIRC1 -> ODSO DB_PIRC1

1. Old Price in Order Price Unit in Info record currency = Old Net Price / Old Price Unit

2. New Price in Order Price Unit in Info record currency = New Net Price / New Price Unit

3. Delta % in point 1 & 2 = (1 - 2) / 1

4. Delta in point 1 & 2 = (1 - 2) 

5. Old price in base UoM in info record currency 

6. New price in base UoM in info record currency

7. Delta % of Old price in base UoM in info record currency & New price in base UoM in info record currency

8. Delta in Old price in base UoM in info record currency & New price in base UoM in info record currency

9. Old Price in Order Price Unit in Vendor Currency

Convert the NETPRICE to vendor currency using FM "Convert_To_Foreign_Currency"

10. New Price in Order Price Unit in Vendor Currency

Convert the NET_PRICE to vendor currency using FM "Convert_To_Foreign_Currency"

11. Delta % of old & New order price Unit in vendor currency

Convert the K_DELPUP to vendor currency using FM "Convert_To_Foreign_Currency"

12. Delta of old & New order price Unit in vendor currency

Convert the K_DELCUP to vendor currency using FM "Convert_To_Foreign_Currency"

13. Old price in base UoM in Vendor currency

Convert the K_IRBUOP to vendor currency using FM "Convert_To_Foreign_Currency"

14. New price in base UoM in Vendor currency

Convert the K_IRBUNP to vendor currency using FM "Convert_To_Foreign_Currency"

15. Delta % of Old price in base UoM in Vendor currency & New price in base UoM in Vendor currency

Convert the K_IRBUOP to vendor currency using FM "Convert_To_Foreign_Currency"

16. Delta in Old price in base UoM in Vendor currency & New price in base UoM in Vendor currency

Convert the K_IRBUNP to vendor currency using FM "Convert_To_Foreign_Currency"

Dependencies with other applications

This is an independent data model.

Data loadings

Info providers and objects loaded

Process Chain: PC_SPRINT_PIRC1

Loading frequency

Daily loads (except week end) using pseudo delta with current day - 4 days logic

Average performance

if possible, give some information on average process chain duration, amount of data loaded and total data volume example: daily process chain loaded in 30 min, weekly chain loaded in 1h15, with around 2k to 10k lines in DELTA mode for a total of 10M lines in cube. The purpose is to give a general overview of the volume of data managed y the application

Record Keeping

Data loaded from 2015 - till date

Reporting

Queries End User Documentation

Query end user documentation should be created in the public "Customer Support Wiki" space under the corresponding BW application page : BW - Application. Technical query query documentation, if necessary should be added as a sub-page of this documentation using the BW Technical Query Documentation template.

Main queries

The core Query: 

BW_QRY_MV_PIRC1_0001 - SPRINT - PUR : PIR Price Analysis (Core Query)

Filters:

Rows:

Columns:

All the key figures are displayed without dimensions (units) as requested by business

Exceptions:

As per the business requirement, there are two exceptions in the query to show in different color where...

Delta variance is greater than 5%

Variance greater than 200

Selection Screen:

Report Output:

Exception example:

Main functionalities

Give detail on all complex functionalities: list most important and/or complex KPI, query jump, alerts

Broadcast

Indicate if there are broadcasts and give some details on the broadcast settings.

Maintenance

Known bugs

Give the list and explanation on the known, not-solved, bugs.

Recurring procedure

List recurring procedures

Planned Evolution

Detail planned major evolution if already known. Example: complete decommissioning of application is planned in 2017 / Extension to solvay perimeter planned in 2nd semester of 2016