Access Management 

DataFlow

Overview

Technical dataflow : SPRINT - Technical Data Flow.pptx https://drive.google.com/open?id=0BzuKacO6n43ic2tUNjhKelRsWWc

See also SPRINT Dataflow https://drive.google.com/open?id=1G0eplgqwvDwJjtYoziwdE2NPT5YtSjm72fUXXlPcEhM

Technical Rules on Workbench

users

• Purchasing & Supply Chain function
• SBS PtP

each one having a dedicated Menu in WBP with the respective queries.

The Sprint reporting is also including queries based on following projects :

• PUNCH (QM Notification - Task/Activity/Causes/Item)
• SRM7 (Shopping Cards)
  
  SRM7 is used by Rhodia and  by Solvay (SMILES program is rolling out SRM7 for Solvay; first rollout for NAM and LATAM went live on July 1st 2014, next rollouts for APAC and EMEA planned go-live for 2015). The SRM7 system is shared by both legacies and is connected to both ERP systems.

Tool Leader + IT leader of the application:

Reporting Coordinator : Duarte Costa (Lisbon)

Purchasing & Supply Chain Solutions Coordinator : Karin WEIGEL-JUNG (Lyon)

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

Purchasing and Supply Chain Excellence  / Quality Leader : Cécilia Allain (Lyon)

Contact on ECC side for MM => Henri OLLIVIER

Usage information

History

SPRINT is a project launched early 2014.  The roadmap of the project has been sliding in time and at the current date (January 2016) the Purchasing solution has been live for 9 months (first deployment made in March 2015 for APAC users, second deployment made in April 2015 for NAM users, third deployment between May and June 2015 for EMEA users and forth deployment in June 2015 for LAM users); the SBS PtP solution is partially deployed since June 2015.

One of the major objectives of the project is to have and maintain a reporting solution that is kept simple, meaning, that unlike what happened with GSV (where more than 80 queries exist due to multiple copies made for each user request), the aim for SPRINT is to keep the number of queries limited.

Dataflow overview

Technical dataflow : SPRINT - Technical Data Flow.pptx https://drive.google.com/open?id=0BzuKacO6n43ic2tUNjhKelRsWWc

See also SPRINT Dataflow https://drive.google.com/open?id=1G0eplgqwvDwJjtYoziwdE2NPT5YtSjm72fUXXlPcEhM

Reporting documentation drive folder:

https://drive.google.com/drive/folders/0B0qn89R0RGdqYkZZOFZyYXlXVkE

https://drive.google.com/drive/folders/0B83QGvNCt4LGQWtlX3o4VUZMNm8?resourcekey=0--ENxeBSFeII6Uc5nAHyt1Q

Exemple of dataflow overview :

Functional and Technical rules on Workbench + Reporting

Rules & Explanations

Data Mappings

Directory 01. Data Mapping https://drive.google.com/drive/folders/10XYuyUz0xuSsrqG0pQwVNfMDAsaxaNGe

SPRINT - Data Mapping - Master Data

 https://drive.google.com/open?id=1ECdjg6yFQ_v6bTEWbjuUni8NRNbSvGw0EAApb8XA358

SPRINT - Data Mapping - Purchase Schedule Line V2

https://drive.google.com/open?id=1-TqvFdKifRXQU5vwdBFEXcW9rje9PDNs3EMfCpZf7dc

Masterdata RULE1 on Vendors (C_VENDID) / Class attribut (C_VENCLS)

This rule concerns only Solvay vendors (from PF1) P*, which are employees not existing in PRS.

These vendors are partly created in Solvay PF1 and it is then not possible to set Class = 'X' in Solvay PF1.

For those vendors, the class has to be set to 'X' in BW.

The intervall of vendor is managed in Global Filter (C_GLBFILT). Currently P000000000 to PZZZZZZZZZ

Masterdata RULE2 on Realigned Material Group (C_MATPUR2) 

All realigned material group are existing on Solvay, descriptions are then filled from PF1 only. Only english description are required.

Masterdata RULE3 on Terms of Payment (C_PMNTTRM) 

Terms of Payment on SAP side are managed into 2 tables. TVZBT for sales (customers), T052U for purchasing (vendor). 

Payment terms can be common. On BW there is only one object for Payment Terms. T052U has to be loaded first. The description of common terms will be then TVZBT's one.

Note that keys are differents, no matters, the last description is kept.

Payment terms can be find at different level

Different objects are used Sprint vs DPO, but values are the same.

(xxxx) means it comes from ECC table xxxx, othervise it is in the document itself

ReadSoft DataFlow

SPRINT - Data Mapping - Read Soft https://drive.google.com/file/d/1EfgvHmN3JZyWKzI820JJLHXqgEsARdMPCsIkjb8uri8/view

There are some differences between rhodia and solavy data flow.

For exemple, in function module of extractor ZFM_BW_COCKPIT_THDR, in WP1 (Rhodia), the date of rejection (ZWDATE_REJECT) is recovered in table /cockpit/thdr.

It's not the case in PF1 (Sokvay), here ZWDATE_REJECT  get the date in /COCKPIT/THDR-CH_TIMESTAMP when STATUS = 13 (this rule will may be applied in Rhodia in the future).

In bw, in transformation between dso DP_RDSF and DB_RDSF, some fields like accounting doc number, posting date, controlling area... come from FIAP.

For Rhodia side, we used DSO DBFIAP01 to take data. For Solvay we used two dso: DPFIAP02 and DB_FIAP2.

Infopackages for datasources, are in delta mode. THe delata is based on change date (the change date is also implemented when it's a creation of cockpit document).

WBS determination reading Settlement Rules 

This rule concerns only RCS & Solvay FIAP data (transformation between DBFIAP01/2 et DB_FIAP1/2). Acetow is not concerned.

The Settlement rules (table COBRB) are loaded every days by another application (RCS : Dso  DSRCOBRB / Solvay : Dso  DSSCOBRB).

Reuse of rule between ODS_PMEN to DBFICS02. 

Case  WBS element is already determined for the FIAP record => keep it, no further determination.

Case WBS element is empty and CO order is filled => read settlement rules

         First check is a previous determination has been done (lookup on Dso)

=> If yes, take the WBS element stored

=> if no, read settlement rules

The check is done to avoid dupplicates as the WBS element is part of the key, and settlment rules can be changed even for the past.

NB: the check can be skip for performance purpose essentielly (case of an initialization for example) => Flag in Global Filter SPRINT/ DB_FIAP1 or  DB_FIAP2/ put Y in low value and Y. Do not forget to put it back to N afterwards. 

NB : In case of a reload of the DSO, the first WBS Element determination is lost, as the DSO is previously is empted. The WBS Element will be the one correcponding to the current settlement rules

To see Settlement rules on ECC side :

-> use transaction KO03 with Co Order 000010528547 (for WP1)

-> button 'Settlement rule'

How COBRB table is read

=> Read only line Category WBS

=> Use firstly Settlement Type 'PER', then, if not found or out of  validity, use 'GES'
=> Use firstly the higher %  Settlement percentage rate

Segmentation Segment/Domain/Cost Sub Package/Cost Package/Cost Macro Package

Since 2020, with projects S3 and co$ta, the Segmentation rule was changed.

Until then it was based on Vendor Segmentation: Domain and Segment come from 1. domain/segment of the Vendor if assigned; if not, 2. domain/segment of the Creditor if assigned; if not, 3. domain/segment of the PO Material Group; Exceptions: if the domain of the Creditor is "LO - Logistic (8)" and domain of the Vendor is different, take domain/segment of the Creditor.

With S3 and co$ta it was changed to focus on Material Group Segmentation.

There are two kind of rules, simplified and complete.

The simplified rules, based on the rules below, determine only the Segment and the Domain.

The simplified rules are determined in the following transformations:

• TRSF: DPMMCY01 -> DBMMCY01 (PC_FILE)
• TRSF : DP_PUCS1 -> DB_PUCS1 (Rhodia)
• TRSF : DP_PUCS2 -> DB_PUCS2 (Solvay)
• TRSF : DB_PUDC1 -> DB_PUDC1 (Rhodia - Domain/Segt/GBU)
• TRSF : DB_PUDC2 -> DB_PUDC2 (Solvay - Domain/Segt/GBU)
• TRSF : DB_PUHD1 -> DB_PUHD1 (Rhodia - Domain/Segt/GBU)
• TRSF : DB_PUHD2 -> DB_PUHD2 (Solvay - Domain/Segt/GBU)
• TRSF : DP_PUSL1 -> DB_PUSL1 (Rhodia)
• TRSF : DP_PUSL2 -> DB_PUSL2 (Solvay)
• TRSF : DB_PUSL1 -> DB_PUSL1 (Rhodia - Domain/Segt/GBU)
• TRSF : DB_PUSL2 -> DB_PUSL2 (Solvay - Domain/Segt/GBU)

The complete rules, based on the rules below, determine the Segment, the Domain, the Cost Sub-Package, the Cost Package and the Cost Macro Package.

The complete rules are determined in the following transformations:

• TRSF : DBFIAP01 -> DB_FIAP1 (Rhodia)
• TRSF : DB_FIAP1 -> DB_FIAP1 (Rhodia - Domain/Segment)
• TRSF : DBFIAP02 -> DB_FIAP2 (Solvay)
• TRSF : DB_FIAP2 -> DB_FIAP2 (Solvay - Domain/Segment)

Loadings

There is a daily loading for the following transformations that works in delta mode:

• TRSF: DPMMCY01 -> DBMMCY01 (PC_FILE)
• TRSF : DP_PUCS1 -> DB_PUCS1 (Rhodia)
• TRSF : DP_PUCS2 -> DB_PUCS2 (Solvay)
• TRSF : DP_PUSL1 -> DB_PUSL1 (Rhodia)
• TRSF : DP_PUSL2 -> DB_PUSL2 (Solvay)
• TRSF : DBFIAP01 -> DB_FIAP1 (Rhodia)
• TRSF : DBFIAP02 -> DB_FIAP2 (Solvay)

The segmentation is redetermined every Sunday. There is a weekly loading for the following transformations that works in full mode with two abap filters in the data transfer process that determine the source system and the period that is current year and previous three years (see global filter C_GLBFILT / SPRINT / SEGMENTAT):

• TRSF: DPMMCY01 -> DBMMCY01 (PC_FILE)
• TRSF : DB_PUDC1 -> DB_PUDC1 (Rhodia - Domain/Segt/GBU)
• TRSF : DB_PUDC2 -> DB_PUDC2 (Solvay - Domain/Segt/GBU)
• TRSF : DB_PUHD1 -> DB_PUHD1 (Rhodia - Domain/Segt/GBU)
• TRSF : DB_PUHD2 -> DB_PUHD2 (Solvay - Domain/Segt/GBU)
• TRSF : DB_PUSL1 -> DB_PUSL1 (Rhodia - Domain/Segt/GBU)
• TRSF : DB_PUSL2 -> DB_PUSL2 (Solvay - Domain/Segt/GBU)
• TRSF : DB_FIAP1 -> DB_FIAP1 (Rhodia - Domain/Segment)
• TRSF : DB_FIAP2 -> DB_FIAP2 (Solvay - Domain/Segment)

Cost Package mapping

C_MAT_GRP (Material Group) through WEBDYNPRO ZWD_FILE_C_MAT_GRP_SEGT.

The webdynpro ZWD_FILE_C_MAT_GRP_SEGT loads into C_MAT_GRP the following master data fields:

• LOGSYS (Source System)
• C_MAT_GRP (Material group)
• C_MAT_PUR (Material Group Purchasing (Obsolete))
• C_SEGT (Segment code)
• C_CTMCPKG (Costs Macro-Package)
• C_CTPKG (Costs Package)
• C_CTSBPKG (Costs Sub-Package)

The source system of the above webdynpro is an excel file that is moved into the folder “/usr/sap/tmp/C_MAT_GRP_SEG.csv” of the transaction AL11 and from there into C_MAT_GRP.

Segment

There are two daily loadings, from Monday to Friday:

1. loads data based on the data source DTS_BW_ZZRSEGT_ATTR from PRS_020
2. loads data from C_SEGT to C_SEGT and takes result of C_CTPKG (Costs Package) and C_CTSBPKG (Costs Sub-Package) from C_MAT_GRP (Material Group) if not fed from DTS_BW_ZZRSEGT_ATTR

Organization (P)

Organization (P), C_ORG attribute of 2 Function, C_FUNCT_2.

C_ORG is a non-navigation attribute of C_FUNCT_2.

and such Master Data is used in order to determine C_ORG into the two DSOs DB_FIAP1 and DB_FIAP2.

That Master Data is loaded through PC_FILE Data Source on a Business request and triggered by the Process Chain PC_SPEND_S3_01.

The description of C_ORG comes from two different Data Sources, from WP1_400 for the GBU description and from PC_FILE for the Organization (P).

The schedule of the loading from WP1_400 is 7 times per day excluded the weekend and it is triggered by the Process Chain FREQUENTLY_LOAD_MD.

The schedule of the loading from the PC_FILE is on a Business request and triggered by the Process Chain PC_SPEND_S3_01.

C_ORG is used into the following objects.

Into the two following Transformations

it is mapped in the Rule Routine

based on the following Business Rules:

If C_SUBACT2__CPFCTR1_2 <> “CB” - -> C_ORG = C_SUBACT2__CPFCTR1_2

Else

If C_SUBACT2__CPFCTR1_2 = “CB” And C_CALRCC__C_FUNCT_2 Is Empty - -> C_ORG = C_SUBACT2__CPFCTR1_2

Else

If C_SUBACT2__CPFCTR1_2 = “CB” And C_CALRCC__C_FUNCT_2 Is Not Empty --> C_ORG = C_FUNCT_2__C_ORG

Into the two following Transformations

it is mapped one by one.

 In the Multiprovider MV_SPD01 it is identified with the two cubes CR_PUAP1 and CR_PUAP2.

The loading of the Master Data of C_FCUNCT_2 and of the Description of C_ORG, based on a Business request, is triggered by the Process Chain PC_SPEND_S3_01.

Specific procedure for the historical re-loading of the Organization (P).

After having run the Process Chain PC_SPEND_S3_01 it needs to re-determine C_ORG into SPRINT flow, meaning into DB_FIAP1 à CR_PUAP1 and into DB_FIAP2 à CR_PUAP2.

The complete procedure to re-load all is the following.

When receiving the Freshdesk ticket from the Business, you have to save the two files (one for C_FUNCT_2 attributes and one for C_ORG descriptions) in your local computer.

The two files have to have the following layout:

C_FUNCT_2 attributes

C_ORG text

Then into the two following InfoPackages

catch the two files saved during the previous step.

Then, run manually the Process Chain PC_SPEND_S3_01.

Once the Process Chain is finished, perform the following manual steps:

For SPRINT Rhodia

• Delete data manually  in DB_FIAP1 for the period asked in the Freshdesk ticket

• Run manually a FULL loading from DBFIAP01 to DB_FIAP1 filtered for the period deleted at point 1 and activate data

• Run manually a FULL loading from DBFIAP05 to DB_FIAP1, through IFS_DBFIAP05__DB_FIAP1, filtered for the period deleted at point 1 and activate data

• Run manually a DELTA loading from DB_FIAP1 to DB_FIAP1, through  IFS_DB_FIAP1_DB_FIAP1 and activate data

• Delete data manually in CR_PUAP1 for the period asked in the Freshdesk ticket

• Run manually a DELTA loading from DB_FIAP1 to CR_PUAP1

For SPRINT Solvay

• Delete data manually  in DB_FIAP2 for the period asked in the Freshdesk ticket

• Run manually a FULL loading from DBFIAP02 to DB_FIAP2 filtered for the period deleted at point 1 and activate data

• Run manually a FULL loading from DBFIAP06 to DB_FIAP2, through IFS_DBFIAP06__DB_FIAP2, filtered for the period deleted at point 1 and activate data

• Run manually a DELTA loading from DB_FIAP2 to DB_FIAP2, through  IFS_DB_FIAP2_DB_FIAP2 and activate data

• Delete data manually in CR_PUAP2 for the period asked in the Freshdesk ticket

• Run manually a DELTA loading from DB_FIAP2 to CR_PUAP2

LeadTime

Lead Time https://drive.google.com/open?id=0By6hfdCwPGY_a09sQWJ4NHlWcnc

Calculation of compliance delta and flag for FIAP dso

In end routine of transformations for DSOs "FIAP for SPRINT" Rhodia and Solvay (DB_FIAP1 & DB_FIAP2) from splitted DSOs, there is abap code to calculate the compliance flag and eventually the delta value between payment term reference and payment term.

There is also specific transformations to reload only the compliance flag, compliance value and terms of payment key reference. These transformations can be used for historical reloading.

To understand the rules and abap code, see this diagram:

Link: https://drive.google.com/open?id=0By6hfdCwPGY_aDYxUlNjYmw2c1E

Material Group (C_MAT_GRP)

The material group can be found at different places:

• masterdata C_MATNR2 : loaded via datasource 0MATERIAL_ATTR.
• masterdata C_PO_ITM : loaded via datasource DTS_BW_PO_ITM.
                                        Special rule "Logistic tables" for Item Category 9 "Service" (EKPO-PSTYP) or empty material group (EKPO-MAKTL) moved from ECC to BW side (Transformation C_PO_ITM → C_PO_ITM).
                                        Also there is a Material Group "Restatement" process via custom extractor DTS_BW_GPS_EKPOREST.

• Schedule line Dsos/Cubes : load via 2LIS_02_SCL, extended. Caution same special rule, but Abap coded slightly differently => DO NOT use it, material group is not always correct.
• FIAP Dsos/Cubes : a lookup is done on Business level of Schedule line => DO NOT use it, material group is not always correct.

Caution: In case of C_PO_ITM manual data reloading via DTS_BW_PO_ITM, you MUST run also the Logistic Table and Restatement loadings.

1) Reloaded data via DTS_BW_PO_ITM;

2) Logistic Tables: Run C_PO_ITM → C_PO_ITM for the same documents reloaded in the STEP 1;

3) Restatement: Extract the full PSA from DTS_BW_GPS_EKPOREST and load RSDS DTS_BW_GPS_EKPOREST (Source System) -> IOBJ C_PO_ITM.

Usage of ECC tables:

Logistic Tables

• Z1M_BW_MAT_GRP for Solvay PF1
• ZWPUT042 for RCS WP1 and Acetow RHO

https://drive.google.com/file/d/109PzNJAbgJ8D5hhHShVqXg7Boi35R4-4zuXH3NNN3fw/view

Restatement Tables

• ZZM_GPS_EKPOREST for Rhodia WP1 and Solvay PF1

https://drive.google.com/file/d/1PVIYYmNy7D8IiQ8BmKvYZ3QKc-EnBWI8CUTUAx5KqQ8/view

Important : The Material Group in schedule line and FIAP Dsos & Cubes is partly false.

Currently Core & QV queries is using C_MAT_GRP from FIAP or Schedule lines. It has to be changed with C_PO_ITM attribut when Business validates it.

• Solvay cases (the list might be not exhausted)
  • Issue for S1.2009
    Example PO 4511000082/1340 => Document date 31.03.2009 => FI document 6311201583/5835/2015
    Only one part of PO for S1.2009, having a schedule line over 2013 have been loaded into BW. On may 2015 initialization, the PSA was not well loaded, and no action have been done to correct it, so part of S1.2009 is missing. No correction have yet been done as Business DSO for schedule line is using ratio in addition, and a whole re-initialization would take several weeks.
  • PO with schedule line previous to 2013 but in actual FI documents
    Example PO 3100441596 => document date 09.07.2012 => Good Receipt / MM Invoice en 2012 => FI document 6311603854 / 5782 / 2015. These PO have not been loaded into BW. The FI documents do not have PO information.
  • Deleted PO items
    Example PO 3100578083/20 => 2 FI documents created (6311642636/0292/2014 and 6311644101/0292/2015) before the PO item deletion the 22.12.2015.
    The deleted PO items are not kept into BW (0PROCESSKEY non kept between Propa & Business DSOs). The FI documents have been reloaded several times in 2016. As the PO item is not existing anymore in the business DSO, the FIAP document can not be filled with PO information
  • Shipment Cost Number archived or other for service PO
    Example PO 4502271249
    PO 4502271249 => entry sheet 1005459308 => Shipment Cost 2164736
    This PO has had a determined material group 0433 when the Shipment Cost was existing on WP1 (table VFKP)
    Today the shipment 2164736 can not be displayed anymore in WP1, so is not existing anymore in table VFKP. Are the shipment costs archived at anytime? et just deleted some how?
    The material group can not be determind any more when the PO schedule line was loaded again when the invoices  were created the 02/05/2016
    
    The material group is also available in masterdata C_PO_ITM.
    For this PO  4502271249, the material group is 0433. No modifications on the PO have been detected, so no additional loading even when the invoices were created. The material group remains 0433. Caution , if the masterdata C_PO_ITM is reloaded today, the material group would be reset to empty!
  • Missing combination in table ZWPUT042
    Example 4502642333. Empty also in masterdata C_PO_ITM as no corresponding value for  9008/12/0003 is existing in table ZWPUT042
    Caution , if the combination is added in table ZWPUT042, previous PO will not be updated, and masterdata C_PO_ITM can not be fully reloaded because Shipment Costs Number are archived or deleted. Rhodia cases (the list might be not exhausted)

Original Material Group (C_OMATGRP)

Field to store the Material Group value before the Logistic Tables and Restatement processes.

During the Logistic Tables logic (Transformation TRSF : C_PO_ITM -> C_PO_ITM) if the Material Group (C_MAT_GRP) has a new value defined, the Original Material Group will receive the previous Material Group (C_MAT_GRP) value.

The same occurs during the Restatement processing (Transformations: RSDS DTS_BW_GPS_EKPOREST (Source System)) -> IOBJ C_PO_ITM).

Conversion rate used in reports

The conversion rate used in reports is CAR3.

Routine CTK_CAR3

Documentation for Document/MasterData Modifications extractors 

It concerns DSOs DB_MAGR1/2/3 for Agreements, DB_MMAT1/2/3 for Materials, DB_MVEN1/2/3/4 for Vendors

DataSources are based on Infosets

Example DTS_CHANGEDOCUMENT_ART => documentation https://drive.google.com/open?id=0BwM8zQWmqesDYWlOVGV1bThfTk0

There is data flow to retreive changes on Purchasing Info Record:

Here is the documentation:

https://drive.google.com/open?id=0B6PYA70dIrclamRxbFlnTll4RXc

Master Data Attributes & Texts loaded via Web Dynpro

Web Dynpro are used for integration of some masterdata informations :

• Change immediately information before updates are done in PRS, and afterwards loaded into BW
• Manage information which are not managed in other systems

Users are then autonomous to update BW masterdata (creation of flat file / check of the flat file / upload of the flat file / status of the execution of the associated process chain)

Web dynpro documentation is available in following directory: https://drive.google.com/drive/folders/0B6fsFFWhLf2yZmF2c1VWS21WVXc

• • user documentation
  • technical documentation

The flat files to load have to follow rules to be uploaded into BW. See https://drive.google.com/open?id=18XlNTM59f7igPNakSwZk_CDZHJ6rnN2RaC28YLiZE5Y

The user interface is available in Solia portal.

See user documentation https://drive.google.com/open?id=1-D47yQianFEbtegyJZxYYV0fafQ-snHVjtDhV6HbNwg

Currently, only Sylvie Sévérini has the access. The technical team do not have access. Tests have to be done via SE80.

Contact person for  any issue on Portal / Sprint menu : Reiner Hellstern (person who has replaced José Cervera)

Documentation to make transport in java portal: How to release/transport Webdynpro on the Java portals

Good to know: For Sprint, in java portal, the name of web dynpro are changed, there are the prefix "SPRINT -" before the name.

To change the name in java portal, it's on propriety of Iview and Workset (it's the same manipulation for both):

Then, go clic on "All" to have all proprieties and search propreity called "Name".

Or search directly the propriety with the research bar.

When you are in the propriety, you can add the prefix.

Loadings are managed via process chains, launched on event (See Process Chain paragraph)

Example: PC_C_VENDID_SEG / event PC_C_VENDID_SEG

When web dynpro ZWD_FILE_C_VENDID_SEGT is used, in transformation TRSF : DTS_C_VENDID_SEG -> C_VENDID (WebDynpro), in start routine there is a verification:

If the vendor has a correpondance in master data vendor PRS, no update is possible and attributes have to manage in PRS. So the records isn't updated.

To get the url corresponding to the WebDynpro...

SE80 

KeyFigures in "summation" mode

Caution Few  KeyFigure are in "Summation" mode in transformations : for PO Schedule lines DSOs (DB_PUSL1/2/3), for PO History DSOs (DB_PUHD1/2/3)

Cytec data flow & procedures

Cyetc FI data flow

Cytec MM data flow

BOZAR data flow & procedures (VBF)

PO2 change

In the cope of Power of 2 project, the VBF data flow and program was duplicated, a new data flow and transaction for SCO were created, the original data flow / transaction (above) are for ECO data.

We applied a physical segregation in some transformations.

To activate the segregation, in master data global filter a variable need to be activated:

If in global filter field C_LOW = YES,

• during the loading in ECO data flow, if the segregation is activated, the data with C_AUTHMA = SCO will be excluded. The exclusion is done in start routine of transformations:
• TRSF: ODSO DB_BOCON -> ODSO DB_BOCAL
• TRSF: ODSO DBPUPE01 -> ODSO DBPUPE02
• during the loading in SCO data flow, if the segregation is activated, the data C_AUTHMA = ECO will be excluded. The exclusion is done in start routine of transformations:
• TRSF: ODSO DB_BOCON -> AB_BOCAL
• TRSF: DBPUPE01 -> ABPUPE02

SPRINT New Data Flows with Advanced DSOs

The following objects have been developed:

A high-level overview of the Data Flows is provided in the diagram depicted below:

Composite Provider CPPURSPD01

The Composite Provider “SPRINT – PO/Spend Analysis” is fed from five newly developed Advanced DSOs which provide information regarding Consignments, PO Historical Data and CYTEC MM:

aDSO ABMMPUCS1

The aDSO “Consignment Withdrawals (Rhodia)” is loaded from the Propagation Layer DSO DP_PUCS1:

aDSO ABMMPUCS2

The aDSO “Consignment Withdrawals (Solvay)” receives information from the Propagation Layer DSO DP_PUCS2:

aDSO ABMMCY01

The aDSO “MM CYTEC: Material Management (PC_FILE)” is populated from the Propagation Layer DSO DPMMCY01:

aDSO ABPOPUHD1

The aDSO “PO: Historical Data (Rhodia)” is mainly loaded from the Propagation Layer DSO DP_PUHD1.  There is also a self-reflective data flow and a third transformation for loading history data from DB_PUHD1 DSO.

aDSO ABPOPUHD2

The aDSO “PO: Historical Data (Solvay)” is mainly loaded from the Propagation Layer DSO DP_PUHD2.  There is also a self-reflective data flow and a third transformation for loading history data from DB_PUHD2 DSO.

Useful transactions / programs

Reporting

SPRINT training & SPRINT presentation 

https://drive.google.com/a/solvay.com/folderview?id=0B5Ivsv4WTtUbVktFZlNVRkNYU1k&usp=sharing

Dependencies with other applications

Few DSOs are shared with FI :

• FIAP
  • DBFIAP01 - FIAP : Line Item Splitted with Delta - Rhodia Level 2
  • DBFIAP02 - FIAP : Line Item Splitted with Delta - Solvay Level 2
  • DBFIAP04 - FIAP : Line Item Splitted with Delta - Acetow Level 2
• FIGL
  • DBFIGL02 - AP from FIGL: Line Items - Rhodia Level 2
  • DBFIGL05 - AP from FIGL: Line Items - Solvay Level 2
  • DBFIGL11 - AP from FIGL: Line Items - Acetow Level 2

Data Loading

Info Providers and objects loaded 

Detail of process chain, list + link between or special event done for the loading

At present, the newly created Advanced DSOs are being loaded through the following process chains in WBP:

• PC_SPRINT_TR_B7, which runs on a daily basis, at 9:00 CET
• PC_SPRINT_TR_B99, which runs on Sundays, at 12:00 CET

Furthermore, the following process chains have been modified in WBD, in order to prepare them for future transport:

• PC_SPRINT_TR_B1
• PC_SPRINT_TR_B2
• PC_SPRINT_TR_DS2

Upon business confirmation, these chains may be transported to Production, in conjunction with the decommissioning of the objects of the legacy data flow (i.e. DSOs DB_PUCS1, DB_PUCS2, DBMMCY01, DB_PUHD1 and DB_PUHD2, MultiProvider MV_SPD01, Query BW_QRY_MV_SPD01_0025, etc.).

Sub  Chains

Chains for WebDynpro

Other Chains

Loading frequency

Process Chain PC_SPRINT_DAILY runs daily, Sunday night to thursday night, around 5am.

Process Chain PC_SPRINT_TR_DS1 runs weekly on sundays at 12am

Average performance

Record Keeping

No historisation in place.

For FIAP/FIGL, current year + 3 previous ones are requested

For Po Schedule lines, schedule lines frim 01/01/2013 are available

Data Quality Control

Operational Documentation

Procedures

Variables (TVARV/Global Filters)

Variable (TVARVC)

Global Filters (C_GLBFILT)

FIAP Reloading

FIAP for SPRINT Dsos (CR_PUAP1/2/3), and Cubes (CR_PUAP1/2/3) have been reloaded several times since project golive.

At least Sprint needs: current year + 3 previous ones.

Example 2016 => 2016 + 2013 to 2015

See ModOp SPRINT reloadings https://drive.google.com/open?id=1qSUGEl6v1Iftdc9N1CP7ytFxW2ew2lGO0eEmy4Gvwk0

Caution :

• Cube level takes a long time to reload! Users have to be informed before and after the reload.
• A check Before/After image hasto be done. Only opened periods should be differents.
• A check between FIAP for Sprint & Cubes for Working Capital has to be done also. 
• Don't forget to load data from Factoring DSO (DBFIAP05 + DBFIAP06 + DBFIAP07) to SPRINT DSO (DB_FIAP1 + DB_FIAP2 + DB_FIAP3) after the loading from business dso (DBFIAP01 + DBFIAP02 + DBFIAP04) .
  And after t hat, load DSO on himself to do the lookup with readsoft DSO (transformation TRSF: DB_FIAP2 -> IFS_DB_FIAP2_DB_FIAP2 - ReadSoft (Solvay) or TRSF: IFS_DB_FIAP1_DB_FIAP1 -> DB_FIAP1 - ReadSoft (Rhodia)).
  Example:
  
   

Test Queries to check data Sprint vs WC + common DSOs :

• ZTEST_MV_SPD01_CHECKFIAP_001 / SPRINT - Check FIAP loadings (SPRINT Cubes)
• ZTEST_MVFIWC01_CHECKFIAP_001 / SPRINT - Check FIAP loadings (WC Cubes)
• ZTEST_MVFIWC03_CHECKFIAP_001 / SPRINT - Check FIAP loadings (Common Dsos)

Data can be check a company code level. Make sur all the demand in common split DSO are loaded into Sprint Dsos/Cubes and WC Cubes

FIAP Specifics Rules

On DB_FIAP DSO, during the delta loading  (from DBFIAP* to DB_FIAP*) if the material code (C_MATNR2) is empty, we take the material from master data C_PO_ITEM.

DB_FIAP3 - FIAP for SPRINT (Acetow):

In transformation TRSF : DBFIAP04 -> DB_FIAP3 (Acetow), in start routine with help of master data global filter (C_GLBFILT, Stream SPRINT, Rule DB_FIAP3) we delete data with company code 7315 with posting date before 01.05.2017.

Status of payment

In transformation between ODS DBFIAP* and DB_FIAP* we define the several status of payment. It's a little bit complicated to understand, is why we have one document to resume the rules:

https://docs.google.com/presentation/d/1mCwuG94pq7l7qNaV8NuFBDkWCLoeoRzjN5vuVrIHSq0/edit#slide=id.p13

Link with factoring level (CAMS project).

New sources was added in Sprint FIAP flow: DBFIAP05, DBFIAP06 and DBFIAP07.

The goal of these new sources it's to update if necessary some information like clearing date or clearing doc (take into account clearing from factoring dso and not only fiap dso).

For more detail, check this documentation:

https://drive.google.com/open?id=1O82GWo7S2rpcbuLFwjNv06WBPniuGWObmhuM1Elc3cE

Exclusion of some accounting document number:

This procedure should only be applied if the purchasing data team has requested it (Sylvie Severini or Yi Ting Kuo) by ticket.

There are some exclusions in transformations (start routines) between DSO DBFIAP01 / 02 / 04 to DB_FIAP1 / 2 / 3 (FIAP line Item Splitted -> FIAP for Sprint).

Exclusion is also made in expert routine in transformations from DSO FIAP : Line Item Splitted - Factoring Level 2 and DSO FIAP for Sprint.

The goal is exclude several acounting documents with inconsistent values. For that, abap code will be read master data global filter with attributes:

In field "Low" of master data, values must be entered in format : source system/accounting document number/item number/year/company code

Example:

With that, abap code will remove from source package rows with these informations.

You can find impacts on queries on the file below:

https://drive.google.com/open?id=1pA8l7ERzJ7LiMNvcJytYelO2bz5lrRDOslckvodIxpM

It may be necessary to exclude new documents.

To do that, it's necessary to now the source system / document / item number / year  /  company code and update master data global filter.

Then, make a selective deletion on fiap cube and dso on accounting document / company code / year (it's not possible to delete only accounting document concerned because item number isn't available in cube fiap).

When selective deletion is done, reload data on DSO Sprint with DTP with same filters used for selective deletion.

All data will be recovered, except documents on master data global filter (for some item number).

When Sprint FIAP DSO is reload, launch delta dtp to reload SPRINT FIAP cube.

For more detail, check this documentation:

https://drive.google.com/open?id=1wWMGaM4RzSdZNTGo4vbp1tXDkQ4z15lWatYMRC7GUkg

FIGL Specifics Rules

Be carreful, there is a rule between propagation DSO and business DSO to exclude lines with FIGL Domain not equal to "AP".

Exclusion of some accounting document number:

This procedure should only be applied if the purchasing data team has requested it (Sylvie Severini or Yi Ting Kuo) by ticket.

There are some exclusions in transformations (start routine) between DSO FIAP : AP from FIGL: Line Items - Level 2 and Cubes: FIGL for SPRINT.

The goal is exclude several acounting documents with inconsistent values. For that, abap code will be read master data global filter with attributes:

In field "Low" of master data, values must be entered in format : source system/accounting document number/item number/year/company code

Example:

With that, abap code will remove from source package rows with these informations.

You can find impacts on queries on the file below:

https://drive.google.com/open?id=1pA8l7ERzJ7LiMNvcJytYelO2bz5lrRDOslckvodIxpM

It may be necessary to exclude new documents.

To do that, it's necessary to now the source system / document / item number / year  /  company code and update master data global filter.

Then, make a selective deletion on fiap cube and dso on company code / year (it's not possible to delete only accounting document concerned because accounting document and item number aren't available in cube FIGL for SPRINT).

When selective deletion is done, reload data on DSO Sprint with DTP with same filters used for selective deletion.

All data will be recovered, except documents on master data global filter (for some item number). 

Be carreful, there is a rule between propagation DSO and business DSO to exclude lines with FIGL Domain not equal to "AP". It could happen some documents with at the origin the FIGL Domain at "AP" and then the domain change. So when we make the selective deletion and after the reloading, these lines aren't loaded.

When Sprint FIGL DSO is reload, launch delta dtp to reload SPRINT FIGL cube.

For more detail, check this documentation:

https://drive.google.com/open?id=1wWMGaM4RzSdZNTGo4vbp1tXDkQ4z15lWatYMRC7GUkg

FIGL Reloading

Caution, take into account special periods 013 to 016, overwise December figures will be wrong.

Special periods 013 to 016 are at last stored on period 012.

See ModOp SPRINT reloadings https://drive.google.com/open?id=1qSUGEl6v1Iftdc9N1CP7ytFxW2ew2lGO0eEmy4Gvwk0

It is important to check image Before/After. Only opened periods could be differents.

ReadSoft Reloading

See ModOp SPRINT reloadings https://drive.google.com/open?id=1qSUGEl6v1Iftdc9N1CP7ytFxW2ew2lGO0eEmy4Gvwk0

For information, at the reloading of readsoft there have been issue during activation of data in DSO DB_RDSF1 & DB_RDSF2.

Somes rows had currency = USA, chinese character in field wc user and "!" in the beginning of field Reference document number.

So there is an exclusion in DTPs when currency = USA and routines to clear stranges characters for wc user and reference document number. 

Manual update

It can happen that some Readsoft Cockpit Documents were manually updated in WP1 and PF1 (to force the Clearing Document and Clearing Date and reset the status).

In this case and for the moment, to update the changes in bw the solution is:

1. Take the list of cockpit document modified in a excel file (1.1).
2. On the first rows, write this:  (2.1 + 3.1)
3. Use excel function:   =CONCATENER($A$2;A7;$A$1) to obtain:
    
4. When we have all rows, we copy the text and paste in abap routine in full infopackage:
   Excel file is usefull only to concatenate the differents elements, don't use excel file in infopackage, just need to copy and paste the text result (rows in yellow).
   
   
   
   
   
   
   Like this, we can filter on several cockpit document in one load from sap to bw, and not one document by on document.

Don't forget to delete the routine in infopackage after the reloading;

Value Creation

Data flow

Source data for Value Creation come from Convergence source system and loaded in bw server with help of webmethods (Transaction AL11 → directory /exploit/BW/BOZAR → filename "ConvergenceToBW.csv").

Normally, webmethods launch event Z_EVT_PC_PUPE to run process chain PC_PUPE_04 and load automatically dso and cube. 

 Interface Value Creation: Salesforce-Webmethods-BW-QV

Power of two update:

With PO2 project, we had to add C_AUTHMA object in Performance data flow.

The issue is we don't have any obect linked (like C_COMPCDE) with C_AUTHMA in source of data (flat file from convergence). It was decided to add a code in convergence side after the GBU.

It means, in flat file we received a field with three characters for the GBU instead two:

And in propagation DSO, the field CPFCTR1_2 is replaced by C_GBUSCOP (with three characters).

Between the propagation and the business DSO in transformation TRSF: ODSO DPPUPE01 -> ODSO DBPUPE01, a lookup with master data global filter is done to retreive the C_AUTHMA associated to the code (0, 1, 2, Z) and split the C_GBUSCOP in CPFCTR1_2 with the two first characters and the C_AUTHMA with the text associated to the code.

It means C_GBUSCOP = CH1 is transformed in CPFCTR1_2 = CH and C_AUTHMA = ECO. All records with "1" in C_GBUSCOP are ECO, with "2" are SCO.

The C_AUTHMA is added in cube and multiprovider, then used in queries with authorization variable.

Master Data:

One master data text (C_BUSLINE) is filled by process chain PC_PUPE_02 (sub chain of PC_PUPE_04). Texts come from datat source DTS_PUPE_01 (same as transactional data of data flow Value Creation).

There is another master data used for Value Creation:

This master data is maintain on demand of purchasing team (Sylvie.Severini or Yi Ting Kuo).

In case of change, for attributes it's necessary to prepare a csv file in this format for example:

Then load the file in master data (change the source file of infopackage before to use the new file). For texts, for the moment, we change directly in text table of master data,.

Technical points to pay attention

Datasource DTS_PUPE_01: please to check data don't use "PSA Maintenance" button but use directly PSA table /BIC/B0011690001. Because of field description with type CHAR length 600 in datasource if we use "PSA Maintenance" we have a dump. It's necessary to have a lentgh of 600 to retreive all information of description (this field will be splited in next transformation).

How monitoring the loading ?

Check process chain PC_PUPE_04 between 1:00:00 am Paris Time (Hours where the flat file is sent from convergence to BW sever) and before 7:00:00 am Pais Time (hour where qlikview run the query to load the dashboard).

If the process chain is not in progress or completed, look on Tcode AL11 and find the flat file (→ directory /exploit/BW/BOZAR → filename "ConvergenceToBW.csv"). 

If the file is the date of the day, there has been an issue when launching the process chain.

If the file has a date of day before, there is an issue to load flat file with webmethod. Please create a Freshdesk ticket or direct contact Support.XML@solvay.com. 

If the process chain is in error, please investigate on the type of issue. In case of invalid value or invalid character please contact Salesforce team (Sylvie.Severini@solvay.com  If she is unavailable, send a mail to  gps.pur@solvay.com ) to know if it's a source problem and if it's possible to correct the issue in Salesforce.

If the value creation data are loaded in cube CRPUPE01 after 7:00:00 am (Paris time), please contact Qlikview team to ask to reload manually the dashbord PPV (Performing Performance Visibility).

Load data manually in case of issue

In all cases, when data are loaded in BW, please contact QlikView team to reloaded Purchasing Performance Visibility dashboard.

There can be three types of errors:

1. Webmethods loaded file in bw server (/exploit/BW/BOZAR) but he was unable to launch the event:
   Use function module Z_TRIGGER_EVENT to trigger event Z_EVT_PC_PUPE to load data in bw. 
   
   
2. Webmethods can't trigger the event and also load data in bw server:
   
   

1. If webMethods team can send the file to load to bw team: 

   BW team need to update infopackage "IP: DTS_PUPE_01 PC_FILE - Full" to use local file and not server file (do not forget to hand over server file after).

   Then, load data on DTS_PUPE_01 and after that run process chain PC_PUPE_03   (Go to transaction SE37, run Function Module RSPC_API_CHAIN_START):
   
   Wait for data to be loaded, then run also PC_PUPE_02 (Texts).

    

2. If webMethods team can't send the file to load to bw team: 

Load data manually from SalesForce

1. Connect to SalesForce. If you do not have access, contact Sylvie Severini to have an account created. If she is unavailable, send a mail to gps.pur@solvay.com
   
   
2. In Dashboards, open Report "CONVERGENCE><SPRINT".
   
   
   
3. Run Report, wait for the page to reload, then Export Details.
   
4. Select UTF-8 and format csv, then click Export.
   
5. Open file in Excel and apply the following changes:
   1. Remove N/A in all fields (Select All, press Ctrl+F, search for N/A leaving "replace by" field blank, Replace All)
   2. Replace comma (,) by dot (.) in numeric columns (Exchange Rate + Last 8 columns) using the same method as above.
   3. Insert a new column after Implementation Date. Copy column Implementation Date in new column Implementation Month.
   4. Update date formats of these two columns and Creation Date - DD.MM.YYYY for Implementation Date and Creation Date, YYYYMM for Implementation Month
   5. Insert new columns Action Recovery and Benefit Recovery
   6. Use model here 
       (Tab: Source Data) to order the fields correctly. 
      If you can't access the file, go to DataSource DTS_PUPE_01 and look up the fields list. 
      Don't forget to add an empty column before Sequence (Monthly Benefit Date, not used as of yet)
   7. Save the file as csv (semi-colon (;) separated)
      
      
6. Connect to WBP. You will likely need FireFighter authorization. Go to DataSource DTS_PUPE_01, open "IP: DTS_PUPE_01 PC_FILE - Full" and change extraction target.
   Adapter = Load Text File from Local Workstation
   File name = Name (and full path) of the extracted csv
   Don't forget to come back here to return to the previous setting after completing your reload!
   Run Extract.
   
   
7. Once data is loaded in PSA, Run Process Chain PC_PUPE_03 (Go to transaction SE37, run Function Module RSPC_API_CHAIN_START)
   

8. Wait for data to be loaded, then run also PC_PUPE_02 (Texts).

Working document

https://docs.google.com/spreadsheets/d/1wEhXdaD9FwEI9PMNvrRbfMWpohjPZ7bQ4VMCTTA2ur4/edit#gid=930941281

Contacts for value creation:

• Webmethod: Freshdesk ticket and direct contact with Support.XML@solvay.com.
• Salesforce: Sylvie.Severini@solvay.com  If she is unavailable, send a mail to  gps.pur@solvay.com
• Qlikview: Freshdesk Ticket.

SPRINT data exported to other applications

Open Hub

Scheduling

<Describe the scheduling in place for the application (eg. existing jobs, trigger time/event based, dependencies)>

Monitoring

<Describe the monitoring checks to confirm the application is performing well (eg. check the overall status, check performance metrics like runtime/data volume/memory/disk/CPU, maintain and react to alerts/notifications)>

Error Handling

<Describe how to handle errors (eg. error codes, description and respective resolution, alert users)>

Known Bugs

<List the existing bugs, its criticality, workarounds and resolution plan.>

Roadmap

These evolutions are currently in progress  (list to be updated)

• Evolution for 0FI_AP_4 / Solvay extractor  to delete rule on Reference field (BKPF-XBLNR) + extension for House bank field (BSEG-HBKID)

First analysis : https://drive.google.com/open?id=1YkibgWKSvk7sqOzu3zEgGJcH0pr9TQfdpq0YKldWcIY