100137 AP355 EFD CO-PA Rebates Posting v0.8

AP355 Extension Functional Design100137_CO-PA - Rebates postings

Version 0.8

Strictly Private and Confidential Prepared by Accenture for the Unilever Group of 35© Accenture 2012. All Rights Reserved AP355 Extension Functional Design

document.doc Version: 0.8

Document Control

Document Preparation Date Version Name Role Comments

10-09-12 0.1 Juan I. MansoCO-PA team

memberInitial version

24-09-12 0.2 Sergio Duran CO-PA team lead Process details05-10-12 0.3 Sergio Duran CO-PA team lead Updated version with Erika’s feedback

05-11-12 0.4 Sergio Duran CO-PA team lead

Updated version with Erika’s feedback:- Include posting rebate correction execution mode- Include purge old data execution mode- Update selection screen

22-11-12 0.5 Sergio Duran CO-PA team lead Include CO-PA posting date validation


memberUpdate process flow with cancelation process, and purge data option.


memberTest conditions

22-01-13 0.8 Sergio Duran CO-PA team lead Review and complete test conditions

Document ReviewDate Version Name Role Comments

04-10-12 0.2 Erika HesseMSO UL Process Office Owner

Comments on open points

01-11-12 0.3 Erika Hesse MSO UL Process Office Owner

Comments on open points. Main ones:- No summarization on rebate posting to material/customer.- Cancellation should be covered- Posting data validation should be included

14-11-12 0.4 Erika Hesse MSO UL Process Office Owner

Ok to purge data execution mode and rebate correction execution mode.

Still pending posting date validation

Document Approval Date Version Name Role Comments



Table of Contents

DOCUMENT CONTROL..............................................................................................2

1. OVERVIEW AND SCOPE......................................................................................5

1.1 FUNCTIONAL DESCRIPTION AND SCOPE.....................................................................................51.2 DEPENDENCIES / CONSTRAINTS...............................................................................................51.3 ASSUMPTIONS......................................................................................................................61.4 EXTENSION USAGE...............................................................................................................6

2. DETAILED FUNCTIONALITY.................................................................................7

2.1 SELECTION SCREEN...............................................................................................................72.2 FUNCTIONAL SPECIFICATION...................................................................................................8

2.2.1 Post rebate re-allocation...........................................................................................92.2.1.1 Collecting data.....................................................................................................................................112.2.1.2 Posting CO-PA document....................................................................................................................142.2.1.3 Saving the execution log......................................................................................................................17

2.2.2 Post rebates correction...........................................................................................172.2.3 Display history table...............................................................................................192.2.4 Display error table..................................................................................................192.2.5 Purge old data........................................................................................................192.2.6 Displaying previous execution logs.........................................................................20

2.3 PROCESS FLOW DIAGRAM....................................................................................................212.4 EXTENSION LAYOUT............................................................................................................222.5 INPUT AND OUTPUT............................................................................................................22

2.5.1 Input Parameters....................................................................................................222.5.2 Method to Retrieve Input Parameters.....................................................................222.5.3 Output Parameters.................................................................................................222.5.4 Method to Release Output Parameters (Output Type)............................................222.5.5 Method to Update Existing Run Parameters with Latest Run Information...............22

2.6 REPORTING.......................................................................................................................222.6.1 History Report.........................................................................................................222.6.2 Error History Report................................................................................................222.6.3 Purge old data........................................................................................................232.6.4 Previous Logs Report..............................................................................................23

2.7 INITIAL DATA SET-UP / CONVERSION REQUIREMENTS................................................................232.7.1 Z0COPA_MAP_OFFIN – CO-PA re-map off invoice conditions...................................232.7.2 Z2REBATESHIST – Rebates CO-PA History table.....................................................232.7.3 Z2REBATESERROR – Rebates CO-PA Error History table.........................................24

2.8 NETWORK INTEGRATION......................................................................................................252.9 EXISTING SAMPLE PROGRAMS...............................................................................................252.10 SECURITY AND AUTHORISATION (THIS IS A MANDATORY SECTION)................................................26

2.10.1 Segregated Access Requirements for Users into Single Roles................................262.10.2 Risk Assessment and Considerations for the Access Required................................262.10.3 Users, Teams, Jobs where access is required..........................................................262.10.4 Objects to be authority-checked.............................................................................262.10.5 Authorization Design:.............................................................................................262.9.6 Security and Authorization for the Accenture AM Team..........................................27

2.11 PROCESSING AND OPERATIONAL CONSIDERATIONS....................................................................272.11.1 Performance...........................................................................................................272.11.2 Batch Requirements...............................................................................................272.11.3 Data Maintenance Requirements............................................................................272.11.4 Re-Use Details........................................................................................................272.11.5 Error Handling.........................................................................................................282.11.6 Log Output..............................................................................................................282.11.7 Purge and Archive Considerations..........................................................................28

2.12 DESIGN ALTERNATIVES........................................................................................................282.13 KEY TEST CONDITIONS AND CONSIDERATIONS.........................................................................29



2.13.1 Selection screen Test Conditions............................................................................292.13.2 Technical Test Conditions.......................................................................................302.13.3 Key Business Test Conditions.................................................................................32



1. Overview and Scope

1.1 Functional Description and Scope

Rebates are used to pay the customers the trade terms negotiated with the contracts. Anticipated cost is posted to P&L accounts. During the validity period of rebate agreement partial settlements can be done- differences in cost are not posted to P&L. When final settlement is made, the cost (the difference between accruals posted and the sum of all the settlements) is brought to P&L. The same applies for manual accruals.

The re-allocation program (part of rebates process) split the amounts accrued manually and the amounts settled to the correct customers and materials. The process will re-allocate accruals and settlements exceeding outstanding accruals to SKU/sold-to level.

The requirement is the creation of an ABAP program which makes postings in CO-PA based on the output of rebates reallocation program, to SKU/sold-to level, including the possibility to revert rebates cancellations, and re-post rebates re-allocations corrections.

Business Benefit

Profitability Analysis (CO-PA) enables UL to evaluate the company's profit or contribution margin for each market segments, which can be classified according to products, customers, orders or any combination of these, or strategic business units, such as sales organizations or business areas. Thus to conduct the Profitability Analysis on market segments, it is necessary to have Rebates posted in CO-PA to the relevant SKU/sold-to level.

1.2 Dependencies / Constraints

Any change in the rebates re-allocation process/program could impact the design of this enhancement.

Changes on CO-PA valuation user exit related to off-invoice discounts value fields The rebate re-allocation posting into Co-PA could result in a big number of entries in CO-PA, with

low amount. Rebates process is under global analysis, looking at extended rebates as it is used in Fusion and

U2K2. The current rebates posting program design could be not valid after rebate extension review, as CO-PA it is also used in those regions and the approach is different.

Data in rebates re-allocation table z2ccmt_1325_02 are only saved when data are sent to BW by extraction program Z0CS_CALL_REBATE_REASS_ABAP. This program is potentially under impact if rebates reallocation will be sent to reporting tool from CO-PA, so only will be needed to update the ‘z’ tables. The changes on reallocation programs are out of the scope of Enabling (retrofit) project.



1.3 Assumptions

The following assumptions have been made in detailing this functional design:

- No MIS reporting tool decision has been taken yet- No go live date decision has been taken yet- Cordillera R2 design is on-going, so possible design changes to align both regions can happen in the

near future- Design deliverables will be created / agreed based on the current available information- Design documentation should be reviewed before build phase start, in line with the final decisions on

reporting tool and go live date - If decision on reporting tool is to report directly form CO-PA, CO-PA design model needs to be

reviewed completely- Rebates re-allocation program are saving reallocations on ‘z’ tables in SAP ECC. No changes on

rebates process are included in the definition of this enhancement. If any change in any rebate program is needed as a consequence of the implementation of CO-PA, it should be design separately from this program.

- The snapshots in this document had been taken from a Sandbox system S9R and only will be considered as a reference.

- The values will be considered in the currency stored in the rebates table Z2CCMT_1325_02 (based on document currency)

1.4 Extension Usage

Extension Usage DescriptionTransaction Volume The total volume is depending on the number of

rebates allocation postings.

Processing Type Batch job daily after billing run (and after rebate reallocation) / Ad hoc



2. Detailed Functionality

2.1 Selection screen

The program selection screen can be similar to the one used in program Z2FICOLLECT_MATCOSTS (trx Z2MATCOSTS) or in program Z2RR_DATA_COLLECTION (trx Z2RRMAT), with different execution modes.

Use the following screenshot as reference:

Name Table field / Check Box / Radio Button

Reference Field

Select-Option(S) or Parameter(P)

Comments Default Value

Company code Table field BUKRS S Mandatory for all execution modes (including post cancellations)

Post rebate re-allocation

Radio button N/A N/A This will create rebates postings in CO-PA

‘X’

Post rebate correction

Radio button N/A N/A This will revert CO-PA document, and post again based on billing doc

Rebate billing document

Table field VBELN S Only entry allowed if post rebate correction is selected.Allow multiple selection

Period / year Table field PERIO S Only entry allowed if post rebate correction is selected.

Test mode Check box N/A N/A Only entry allowed if post rebate correction is selected.

‘X’

Display error table Radio button N/A N/ADisplay history table

Radio button N/A N/A

Purge old data Radio button N/A N/A It should delete data from history and error table, with a reference range of dates.

Display previous logs

Radio button N/A N/A

Execution date(s) Table field Sy-datum Only entry allowed if display previous logs active. In that case will be mandatory and default value system date.



Parameters frame:

In order to allow purge of error and history tables, an option for ‘Purge old data’ has been included in the selection screen. Some parameters has to be used for retention period for each table.

Retention period for history table : when purge old data exectuion mode is selected, all lines older than this parameter should be delete from history table, based on ‘Billing data’ (as saved in the history table). This parameter will reflect months.

Retention period for error table : when purge old data exectuion mode is selected, all lines older than this parameter should be delete from error table, based on ‘Billing date’ (as saved in the error table). This parameter will reflect months.

It should nonetheless be avoided to hardcode these values. Instead, they should be maintained as selection screen parameters. They should be hidden for normal users, unless a user parameter EXP = SIRIUS is maintained in user data. For reference of how selection screen parameters work, please refer to existing Sirius programs, e.g. Z2ADDC or Z2MATCOSTS.

Additionally, a parameter for retaining previous execution logs (extracts) should be included. See point 2.9 as reference from program Z2FICOLLECT_MATCOSTS.

2.2 Functional Specification

Rebates are used to pay the customers the trade terms negotiated with the contracts.

1. Anticipated cost is posted to P&L accounts (from sales documents based on off invoice conditions) - It will be posted to CO-PA.

2. During the validity period of rebate agreement partial settlements can be done (differences in cost are not posted to P&L). - No posting in CO-PA

3. When final settlement is made, the cost (the difference between accruals posted and the sum of all the settlements) is brought to P&L. The same applies for manual accruals. - Posting in CO-PA, which could be cut using the valuation user exit.

When manual accruals or settlements are created (above point 3.), they are done against the customer indicated in the rebate recipient on the rebate agreement and the material for settlement. In order to ensure correct customer/product profitability, the amounts accrued manually and the amounts settled need to be split to the correct customers and materials (SKU/sold-to level).

This is not done automatically in standard SAP. This split is made by the rebates re-allocation program, storing in a ‘z’ table the result of this splitting, allowing the extraction of this info to the reporting tool.

Types of settlements

Partial settl. Final settl.Cancellation of Final settl.

Credit Notes ZNB3 ZNB1 ZNB7

Bill back ZNB6 ZNB5 ZNB8

Accruals ZNB4

Rebate adjustment ZNA1


sergio.duran.ramos, 27/11/12,

Please confirm if the date to be checked for purge tables should be Billing date as saved in each ‘z’ program table.


Confirm if the parameter should be in months.


This re-allocation is not posted in Finance, it is only stored in table Z2CCMT_1325_02 ‘KALIDO Interface for Rebate Re-allocation’.

In order to collect the correct SKU/sold-to level related to the rebates, the rebate re-allocation split should be posted into CO-PA, using a ‘z’ program that use information in table Z2CCMT_1325_02 and using dedicated CO-PA record type ‘1’ Rebate adjustment.

(*) options in this point: There are 2 options related to final settlement posting to CO-PA and process of rebates settlement and re-allocations:

a) Post to CO-PA the final settlement and the manual rebates (billing types ZNB1, ZNB5, ZNB4, ZNB7 and ZNB8); with rebates posting program do a reversion of these postings and with the data on the re-allocation table post the re-allocation into CO-PA.

b) Using the CO-PA valuation user exit to cut the posting of the final settlement and manual rebates to CO-PA (not post them into CO-PA using the sales document type); with the data on the re-allocation table post the re-allocation into CO-PA.

Option a) will post more line items into CO-PA (final settlements and the reversions) and will negative impact the performance of the CO-PA rebates posting program because it needs to select over CO-PA table, which will have millions of items.Option b) will post less line items in CO-PA, but will need an additional step on the valuation user exit that could impact in the performance of the billing process (no big impact as the checking will be based on available field, so no additional selections are needed).

As this process is going to post a big number of line items into CO-PA and the impact on the performance of the billing posting process would be minimum, we recommend option b). This EFD is created based on this option.

2.2.1 Post rebate re-allocation

The trigger for the rebates posting into CO-PA will be the rebate split stored in the table Z2CCMT_1325_02. In this table, the relevant billing types have been already considered by the rebates reallocation program so it is not needed to replicate the process and search again the corresponding documents.In this table the program will select the entries for a specific company code, select the material and the sold-to customer and check the agreement type.

The agreement type, together with the billing doc. type and the prior year indicator, will allow the program to determine which value field should be inform, according to table Z0COPA_MAP_OFFIN CO-PA re-map off invoice conditions, same table used in the valuation user exist to determine the value field for off invoice conditions.



We have changed the initial selection, starting from reallocation table instead of from billing document table by date range.


FD updated. Version V1.1 will be submitted together with this document


CO-PA re-map off invoice conditions (suggested table name included and to be verified with valuation user exit EFD):

Agreement typeKNUMA

Agreement type description

Billing doc type

FKART

Prior year indicatorZZPYCY

OLD value field

New value field

Z601 SCI (BB)SC Improvem. all all VV058 VV014Z601 SCI (BB)SC Improvem. ZNB1 VV014 VV096Z601 SCI (BB)SC Improvem. ZNB1 PY VV014 VV097Z601 SCI (BB)SC Improvem. ZNB4 VV014 VV098Z601 SCI (BB)SC Improvem. ZNB4 PY VV014 VV099Z601 SCI (BB)SC Improvem. ZNB5 VV014 VV096Z601 SCI (BB)SC Improvem. ZNB5 PY VV014 VV097Z601 SCI (BB)SC Improvem. ZNB5 VV014 VV096Z601 SCI (BB)SC Improvem. ZNB5 PY VV014 VV097Z601 SCI (BB)SC Improvem. ZNB7 VV014 VV096Z601 SCI (BB)SC Improvem. ZNB7 PY VV014 VV097Z601 SCI (BB)SC Improvem. ZNB8 VV014 VV096Z601 SCI (BB)SC Improvem. ZNB8 PY VV014 VV097(…)

(*) Sample values

The program needs to retrieve some information from billing document header / item (VBRK/VBRP) and finance posting tables (BKPF/BSEG) to complete the profitability segment together with the info from rebate re-allocation table, to have a complete posting in CO-PA: e.g. sales organization, distribution channel and sector, plant, material and sold-to, posting date.

Characteristic WWREF “Original reference document” will keep the original rebate settlement document (billing doc).

Finally, the successful items processed need to be updated in the history table and error items need to be updated in error history table.

Once the program is executed all the rebate final settlement documents which are not executed and updated in the error history table need to be processed.

The program can only be executed for one sales organization/company code at a time. The option to execute the program for more than one MSO will depend on the program performance.

The program needs to check the History table to make sure the document is not already processed (processing status). If a document number is already processed there would be an entry in the history table against that document/item with status ‘c’ complete posted. In that case an error message needs to be issued to and included in the log.

Based on entered time frame all the documents in the error table should be processed and successfully processed documents should be updated in History table.

If the errors are encountered again the document needs to be updated in the error history table again; however the date and time remains the same as before (this is same proceed than for MSO CoGS posting program).

The Z2REBATESHIST Historical table will include the final settlement billing document and the CO-PA Rebates posting.

Error table Z2REBATESERROR will store the final settlement billing document that has not been processed due to any error. The program should select these documents and process them again. If successfully processed, delete it from the error table, if error again, update the line in the error table.

The program will allow an execution mode to process rebate cancellations, indicating specific billing documents cancelled in the rebate reallocation process, the program should revert the CO-PA posting and process the billing doc. again, deleting the entry in the history table, or indicating a separate status like ‘x’ cancelled, and then updating the history table with the new execution result (‘c’ complete or ‘p’ pending).



2.2.1.1 Collecting data

Data collection should always be accompanied by progress messages displayed to the user at the bottom of the screen. These messages should always be included in the log file of the program.

There are numerous existing programs that could be reviewed as examples on how progress messages can be used, e.g. Z2RRDATA.

a) Progress message: “Selecting rebate re-allocation…”

The table Z2CCMT_1325_02 stores the results of the rebates re-allocation by company code and Rebate settlement billing document, with the agreement type, and the value of the condition, that will give the program the value to be posted in CO-PA.

Z2CCMT_1325_02 selection Selection criteriaTo be selected Field ValueVBELN (rebates settlement billing doc)

BUKRS From selection screen

POSNR (rebates settlement billing doc item)MATNR (Material)KUNNR (Customer number)BOART (Agreement type)KWERT (Condition value)WAERS (Currency)

The Z2CCMT_1325_02 selection is required to read additional fields which will be required later in the processing to populate characteristics fields of the CO-PA document.

All lines should have material, customer number, agreement type, condition value and currency.

If any error in the rebate settlement document selection (any field not filled in), the error table should be informed with the billing doc, and all data available and error type ‘001’.

The program also needs to check if any of the selected documents/items were already successfully processed. Any document/item in the re-allocation table that has status ‘c’ complete posted in the history table should not be reprocessed and an error message included in the message log: “Billing document &1 already processed”.

In the current rebates process, table Z2CCMT_1325_02 is only filled in when the reallocation info is generated by program z0cs_call_rebate_reass_abap (calling function module z_2cmt1325_kalido). This function module deletes all entries related to a company code and inserts the new entries generated with the new calculation. This could impact on the treatment of the Error history documents from previous executions, that is why it is suggested to include in the error table all data selected, including material, sold-to, value field, condition value and currency, in order to have the information for reprocessing the item and post it to CO-PA.

If no values found for the specific company code a message should be included in the message log (e.g. “No entries found in the rebate re-allocation table for company code &xxx”).



b) Progress message: “Selecting Error History Documents…”

In addition to the Rebate settlement billing documents selected from table Z2CCMT_1325_02 the program needs to add all settlement billing docs which were stored in the Error History table Z2REBATESERROR from previous executions of the program. This should ensure that any measure the business might have taken to correct errors is considered by trying to repost the CO-PA document.

The program should take all errors items for the corresponding company code.

Z2REBATESERROR selection Selection criteriaTo be selected Field ValueVBELN (rebates settlement billing doc)

BUKRS From selection screen

POSNR (rebates settlement billing doc item)MATNR (Material)KUNNR (Customer number)BOART (Agreement type)KWERT (Condition value)WAERS (Currency)

Previous executions of the program have stored the successfully posted documents in the history table Z2REBATESHIST. All successfully posted documents should be dropped from error table for further processing.

The program also needs to check if any of the selected documents/items were already successfully processed. Any document/item in the error table that has status ‘c’ complete posted in the history table should not be reprocessed and a message included in the message log.

Lines selected in this point should be added to the lines selected in the previous point.

c) Progress message: “Selecting Rebate settlement billing document header…”

For all lines selected in previous points (rebate re-allocation table and error table), the program should look for additional information in the sales billing table VBRK.

VBRK selection Selection criteriaTo be selected Field ValueVBELN (Billing doc number)

VBELN From Z2REBATESERROR and Z2CCMT_1325_02

ZZPYCY (Referencing requirement rebate)FKART (Billing type)VKORG (Sales Organization)VTWEG (Distribution Channel)SPART (Division)BUKRS (company code)FKDAT (Billing date)

This information will be used to complete the profitability segment and to derive the corresponding value field.

If any error in the selection of billing document header, the error table should be informed with the billing doc, position and all data available, and error type ‘002’ in the billing documents header.



d) Progress message: “Selecting Rebate settlement FI posting date…”

BKPF selection Selection criteriaTo be selected Field ValueBUDAT (Posting date) BUKRS From selection screen

VBELN From VBRK-VBELN

The posting date to be used for CO-PA posting should be aligned to the rebate finance posting document, not to the billing document date, as this could be in a different period.

In the selection on BKPF table (finance docs) the program will select the entries using company code and document number. The document number will be the rebate billing document, same number than FI doc according to UL principals.

If any error in the selection of finance documents, the error table should be informed with the billing doc, position and all data available, and error type ‘003’ in the finance document selection.

e) Progress message: “Selecting Value fields…”

Need to find the corresponding value field related to the combination of agreement type / billing type / Prior year indicator. To do this a selection in custom table Z0COPA_MAP_OFFIN is needed:

Z0COPA_MAP_OFFIN selection Selection criteriaTo be selected Field ValueKNUMA (agreement type) KNUMA From Z2CCMT_1325_02-

BOARTFKART (Billing type) FKART From selection screen

parameters (ZNB1, ZNB5, ZNB4, ZNB7, ZNB8)

ZZPYCY (prior year indicator) ZZPYCY From VBRK-ZZPYCYNEW VALUE FIELD (field code not assigned yet in the ‘z’ table)

If any error in the selection of value fields, the error table should be informed with the billing doc, position and all data available, and error type ‘004’ in the value field mapping.

Option in this point, Summarization of items: in order to reduce the number of line items to be posted into Co-PA there is an option to sum the items with the same Material / Sold-to / Sales organization / Distribution channel combination. In this case the tracking to the final settlement document is lost (in error table when posting to CO-PA, in historical table, and in CO-PA table).This option has been rejected as UL needs to keep the relation between CO-PA document and rebate billing document. This is the only way to reconcile with FI and it is often here we will find issues with the re-allocation amount not adding up to the FI P&L amount. This is important due to the number of incidents with rebate settlements and reconciliation in reporting. Some are incorrect due to master data issues and needs reversal / corrections as well in CO-PA.



2.2.1.2 Posting CO-PA document

The condition values selected from the re-allocation table need to be mapped to the corresponding CO-PA value fields according to the entries in parameter table Z0COPA_MAP_OFFIN.

Based on the table extractions, the profitability segment will be completed following the below table.

a) Progress message: “Completing profitability segment…”

Characteristics table

Characteristics Origin CommentsControlling Area Derivation rule Derived based on company code

Company Code VBRK-BUKRS

Sold-to-Party Z2CCMT_1325_02-KUNNR MSO sold to party so from rebate re-allocation table

Sales Organisation VBRK-VKORG MSO Sales Org. from settlement billing doc

Distribution Channel VBRK-VTWEG MSO Distr. Ch. from settlement billing doc

Division VBRK-SPART MSO division from settlement billing doc

Product Z2CCMT_1325_02-MATNR From rebate re-allocation table

Plant n/a Not relevant in this process

Sales order n/a

Sales order item n/a

Profit Center (not filled) n/a Not used in EU

Billing Type VBRK-FKART

CustomerHier04 Derivation rule



CustomerHier07 n/a This CH level is not used in EU

AcctAssgGr Derivation rule

Material Type Derivation rule

Division Derivation rule

Sub Division 1 Derivation rule

Sub Division 2 Derivation rule

Category Code Derivation rule

Market Code Derivation rule

Sector Code Derivation rule

CPG Code Derivation rule

BFP Code Derivation rule

SPF Code Derivation rule

Brand Derivation rule

Order reason n/a

Segment Sirius Derivation rule



Characteristics Origin CommentsReporting Country Derivation rule

Channel Derivation rule

Plant type from CCtr n/a Not used in MSOs

Business Unit Derivation rule

Original reference document VBRK-VBELN Rebate settlement billing doc

MSO customer n/a Used by USCC only

MSO sales Org. n/a Used by USCC only

MSO distribution Channel n/a Used by USCC only

MSO Division n/a Used by USCC only

(*) this table should be double check with basic setting toolkit to ensure no new one has been included in the Operating Concern.

Characteristics marked as ‘Derivation rule’ will be filled in by CO-PA derivation functionality.

Additional data needed to create the CO-PA line item:

- ‘Posting date’ to be used in the CO-PA posting will be the posting date from FI doc (BKPF-BUDAT), except if the period is already closed for postings. Then should be system day (sy-datum).

- Currency: Based on re-allocation table values (Z2CCMT_1325_02-WAERS).

- The CO-PA document should be saved in company code and Op. Concern currency (2 line items per posting)

- The CO-PA documents posted should use record type ‘1’ “Rebate adjustment”.

b) Progress message: “Deriving CO-PA posting date…”

The principal is that the Posting date for the CO-PA rebate posting should be the same as the rebate settlement posting (CO-PA posting = FI posting date). Especially for the re-process of error table entries, but applicable for all rebates posting, the program needs to check if the period is opened or if it is already closed. CO-PA has not any standard functionality to control this ‘period block’ (OKP1 is not locking CO-PA external postings, only TDD and Cost center assessments to CO-PA), so the program have to check it.

The creation of a dedicated function module is suggested. If we use a function module, we can reuse it in other CO-PA programs like MSO CoGS posting.

Table KAPS (CO Period Locks) keeps the locking periods for CO processes (based on business transactions). To check if the period is locked or not, the program should use Controlling Area, year and period (from the posting date) and a business transaction as reference (suggested one of these: ‘COIN’ CO Through-postings from FI; ‘KSPA’ assessment to CO-PA; ‘KTDA’ COPA: Top-Down: Actuals

Standard function module co_period_blocking_check can be used.



Could you confirm which one?? We suggest COIN to be aligned with FI postings to CO.


Included to control if the period is open for postings.


- GJAHR – year from the posting date

- KOKRS – controlling area (from table TKA02 using BUKRS company code)

TKA02 selection Selection criteriaTo be selected Field ValueKOKRS (Controlling area) BUKRS From selection screen

- PERAB / PERBI - period from the posting date

- VRGNG – business transaction (e.g. COIN)

If the period from FI posting date is blocked, the CO-PA posting date should be set to system date (sy-date).

If there is any change in the posting date from initial Billing date due to period locking, then there must be a reference in the message log, with text “Billing document &1, posting date in a closed period. Posting date changed to system date”.

The period from the system date should also be checked through table KAPS (CO Period Locks). If this period is also blocked, an error table line should be informed with the billing doc, position and all data available, and error type ‘005’ in the posting date derivation. A message in the log also should be included with the text “Billing document &1, posting date derived as system date. System date period blocked for postings”.

c) Progress message: “Posting to CO-PA…”

To post to CO-PA there are 2 options to be evaluated by the technical ABAP team: BAPI or External data transfer (This program should use the same approach than MSO CoGS posting program, if possible use the same function module).

I. Option 1 , BAPI “PostCostingBasedData”:

The data selected above must be organised and transferred to the function modules BAPI_CO-PAACTUALS_POSTCOSTDATA and BAPI_TRANSACTION_COMMIT using the mapping of characteristics as in the table above.

BAPI_CO-PAACTUALS_POSTCOSTDATA replicates standard SAP transaction KE21N. While populating characteristics the derivation needs to be run, so that the missing characteristics are derived.

II. Option 2 , External data transfer:

In costing-based Profitability Analysis, you can import both plan and actual data.

Before the first data transfer, it is needed to define:

- the structure of the external data

- the sender structure: defines the format of the external data that is to be imported to the operating concern

- transfer rules: how the data stored in the format of an external structure will be mapped to the data structures of your operating concern

There is a specific setting for external data transfer already required and defined in the advance setting toolkit for plan data (ZCOPA1000). A specific data structure, sender structure and transfer rules would be needed for this program if that one could not be reused.

If any error in the CO-PA posting, error table should be informed with the billing doc, position and all data available, and error type ‘006’ in the CO-PA posting.



All billing documents/item that were posted to CO-PA should be included in the Z2REBATESHIST table. If the document/item has any error entry in the error table, the line should be saved with status ‘p’ pending errors. If there is not any error in that table, with status ‘c’ completed.

Additionally, for those billing docs/items reprocessed due to previous errors, so already in the history table as status ‘p’ pending errors, it is needed to check if the errors are still in that table. If not, status on history table should be updated to ‘c’ completed.

2.2.1.3 Saving the execution log

At the end of the execution the program must also save the execution log. The log will be saved as an ALV extract so that later can be retrieved and displayed with the Display previous logs function of this program.

In the TEXT field of the extract (40 characters) the program will concatenate the texts Company code(s):’ and the value specified on the selection screen, ‘Exec. date:’ and the execution date value separated by spaces.

In the DATA field of the extract (60 characters) must use the text ‘Execution mode:’ and the execution mode value (e.g. rebates posting, rebates cancellation)’ specified on the selection screen.

For an example of how to use the other fields see routine SAVE_EXTRACT in program Z2FICOLLECT_MATCOSTS. Success or failure messages should also be logged here.

After the log is saved, it should also be automatically displayed.

2.2.2 Post rebates correction

It is an ad hoc execution. The rebates process often has rebate re-allocation mistakes which are due to lack of master data. After the fix the re-allocation program is re-executed and it is needed to re-run as well the CO-PA posting program for the selected rebate billing document.

The program should have a specific execution mode for this correction, based on rebate billing document numbers.

This execution should cancel the CO-PA document already created by the rebate re-allocation, and then create the new one based on the new values in the re-allocation table (Z2CCMT_1325_02).An execution in test mode should be also available.

Process should be like this:

1) Revert previous CO-PA doc:a) Check in the history table that this document has been posted (valid status can be ‘c’ complete posted

and ‘p’ pending):i) If status ‘p’, error lines in the error table should be deleted to avoid double processing. If new

errors appear then new entries in error table will be stored.b) Select from CO-PA table CE11000 the CO-PA documents based on record type ‘2’ / original ref.

document / period-year / sales organization fields. c) Check in CO-PA table (CE11000) that these docs have not been reverted yet (to avoid duplication of

reversions) by checking field “Cancelled document” (STO_BELNR). If there is any other CO-PA doc that has cancelled it, the program should display a message “Document &1 already cancelled by CO-PA document &2”

d) Revert the CO-PA document based on the CO-PA doc (suggested with call transaction on trx. KE4S00).

e) Update history table lines with status ‘x’ cancelled (temporary to keep the tracking just in case the program is terminated before all the process completed).

2) Collecting data:a) Select new rebate re-allocation values from table Z2CCMT_1325_02 (based on SD billing document

from selection screen)b) Select value fields based on mapping table Z0COPA_MAP_OFFIN

3) Post to CO-PAa) Determine CO-PA characteristicsb) create CO-PA doc

Above points 2 and 3 will follow the same logic process as “Post rebate re-allocation” execution mode.



Please review this point, added as requested.


1. Revert previous CO-PA doc

a) Progress message: “Selecting CO-PA Documents…”

Using the billing document in the selection screen, the program should look for it in the CO-PA table (CE11000, field ‘original reference document’) with the record type ‘1’ and the period/year from the selection screen and extract the CO-PA documents created by the rebate program (get sales organization from the selection screen).

CE11000 selection Selection criteriaTo be selected Field ValueBELNR (Document number of line item in Profitability Analysis)

PALEDGER Currency ‘10’ (both are valid, but we just need one of them to find the doc numbers)

BUKRS (company code) VRGAR Record type ‘1’PERIO (period/year indicator)

PERIO Period/year from the selection screen

VKORG Sales org. From selection screen

WWORD Rebate Billing doc from the selection screen

If the rebate billing is not in that field in CO-PA table, a message should be included in the log, with value “Document &1 not in the CO-PA table”.

b) Progress message: “Checking CO-PA Documents…”

Once the rebate billing document has been identified and the corresponding CO-PA documents found, the program should check that these documents have not been already cancelled, checking field “Cancelled document” (CE11000-STO_BELNR).

CE11000 selection Selection criteriaTo be selected Field ValueBELNR (cancellation CO-PA document)

PALEDGER Currency ‘10’ (both are valid, but we just need one of them to find the doc numbers)

STO_BELNR (doc cancelled) VRGAR Record type ‘1’VKORG Sales org. From

selection screen STO_BELNR BELNR From previous

selection

If there is any CO-PA doc that has cancelled it, a message should be included in the log, with value “Document &1 already cancelled by CO-PA document &2”. Those documents should not be cancelled again.



c) Progress message: “Revert CO-PA Documents…”

The reversion should be done with the same characteristics and value fields amounts (opposite values).There is a standard transaction (KE4S00) to revert CO-PA line items. A call transaction can be used (to be decided by the technical designer) in order to use this transaction.

Data needed to run transaction KE4S00: Operating concern – ‘1000’ Record type – ‘1’ Rebate adjustment Company code – BUKRS from CE11000 selection (in point b) above). Document number – BELNR from CE11000 selection (in point b) above). Period/year – PERIO from CE11000 selection (in point b) above). Test run – possibility to run the program in test, according to the main program selection

options in order to simulate the cancellation. Log – mandatory in order to retrieve the log form the standard trx.

A message should be included in the log, with value “#XX CO-PA documents cancelled”. (Explore the possibility to use the output log of the standard transaction ke4s00 for a detail report).

2.2.3 Display history table

Please visit point 2.6.1

2.2.4 Display error table


2.2.5 Purge old data

History and error tables will grow day by day and can reach big volume, so purge process is required for old values.

This process will depend on corresponding parameters that will fix the retention period for each table. Retention period for history table : when purge old data exectuion mode is selected, all lines older than

this parameter should be delete from history table, based on ‘Billing date’ (Z2REBATESHIST-FKDAT). This parameter will reflect months, starting from current month/year.

Retention period for error table : when purge old data exectuion mode is selected, all lines older than this parameter should be delete from error table, based on ‘Billing date’ (Z2REBATESERROR-FKDAT). This parameter will reflect months, starting from current month/year.



Example:If retention period for error table is set as 4 months, and purge execution mode is run on 23-11-2012, the program will delete all lines in the error table that has billing date before 01-08-2012: current period 11/2012, 4 months retention (November, October, September, August).

The functionality should be similar to the purge execution mode used in Z2FICOLLECT_MATCOSTS (trx z2matcosts).

A pop up should be displayed with information related to the values to be deleted from error and history table, with the option of stop the process.

(*) sample picture

If the process is cancelled, the message log should show reflect the cancellation of the process (e.g. “User did not confirm data deletion”).

a) Progress message: “Deleting error table…”The program should check the parameter “Retention period for error table (months)”, and calculate the ‘key date for deletion’. This key day for deletion will be the first day of the key period/year for deletion, calculated as follow:

Period/year from current day (sy-datum) – retention period in months = key Period/year for deletion

All entries in the table before key day for deletion should be deleted from the error table.

b) Progress message: “Deleting history table…”The program should check the parameter “Retention period for history table (months)”, and calculate the ‘key date for deletion’. This key day for deletion will be the first day of the key period/year for deletion, calculated as follow:

Period/year from current day (sy-datum) – retention period in months = key Period/year for deletion

All entries in the table before key day for deletion should be deleted from the history table.

2.2.6 Displaying previous execution logs




2.3 Process Flow Diagram



2.4 Extension Layout

N/A

2.5 Input and Output

N/A

2.5.1 Input Parameters

N/A

2.5.2 Method to Retrieve Input Parameters

N/A

2.5.3 Output Parameters

N/A

2.5.4 Method to Release Output Parameters (Output Type)

N/A

2.5.5 Method to Update Existing Run Parameters with Latest Run Information

N/A

Only track the error logs and the historical data as described in the previous chapters.

2.6 Reporting

If the routines mentioned in chapter 2.2.1.3. are taken over from Z2FICOLLECT_MATCOSTS the reports can be defined as a standard SAP structures.

Reports must be displayed using the ALV functionality with proper top-of-page headers. The relevant selection fields must be displayed in the page header.

2.6.1 History Report

After a processing a rebates settlement billing document successfully, i.e. after posting the CO-PA document, the program must store the invoice and all corresponding information in table Z2REBATESHIST.

On the selection screen the user can select “Display History Table”. This action will display table Z2REBATESHIST, eventually narrowing down the selection according to selection criteria entered on the selection screen.

The report must display all fields of table Z2REBATESHIST as defined in section 2.7.2.

Displaying the History Table should be restricted by company code / Sales Organization authorisations of the user, i.e. a user should not be able to display data of company codes for which he has not authorization.

If no values in history table for the company code selected a message should appear with text:“No entries found in the history table for company code &1”

2.6.2 Error History Report

After processing rebate invoice and any error appears, the program must store the invoice and all corresponding information in table Z2REBATESERROR.

On the selection screen the user can select “Display Error History Table”. This action will display table Z2REBATESERROR, eventually narrowing down the selection according to selection criteria entered on the selection screen.



The report must display all fields of table Z2REBATESERROR as defined in section 2.7.3.2.7.2

Displaying the Error History Table should be restricted by company code / Sales Organization authorisations of the user, i.e. a user should not be able to display data of company codes for which he no authorization.

If no values in error history table for the company code selected a message should appear with text:“No relevant entries found in the error table for company code &1”.

2.6.3 Purge old data

After processing the ‘Purge old data’ execution mode, an execution log should be displayed with the result of the execution, similar to the one used in program Z2FICOLLECT_MATCOSTS.

2.6.4 Previous Logs Report

After each execution of the program, a log will be saved, allowing users to later check the messages generated in the execution.

On the selection screen the user can select “Display Previous Logs”. This action will display the previous logs, eventually narrowing down the selection according to the selected date entered on the selection screen.

This function can be easily implemented with the routines indicated in chapter 2.9 referring to program Z2FICOLLECT_MATCOSTS.

Obsolete extracts should be deleted following the same rules than referred program, Form delete_obsolete_extracts.

It will display a report with existing ALV extracts in descending order of their creation date and time. Double-clicking a line in the report will display the actual log.

2.7 Initial Data Set-Up / Conversion Requirements

2.7.1 Z0COPA_MAP_OFFIN – CO-PA re-map off invoice conditions

This table is already contained and defined in the CO-PA valuation user exit enhancement functional design (100137_AP355_EFD_CO-PA Valuation user exits).

It is needed for the map of agreement type to CO-PA value field (in combination with billing type and prior year indicator).

2.7.2 Z2REBATESHIST – Rebates CO-PA History table

This table will store the successfully processed rebates settlement billing documents, i.e. the ones for which the program creates CO-PA documents without error. It is an application table with Delivery Class = A, display / maintenance should be allowed with restrictions. It must be defined with Data class = APPL1 and Size category = 7 (14.000.000 to 28.000.000).

Field Key Data element Type Length Description OriginMANDT X MANDT CLNT 3 ClientVKORG X VKORG CHAR 4 Sales Organization VBRK-VKORGVTWEG X VTWEG CHAR 2 Distribution Channel VBRK-VTWEGBUKRS X BUKRS CHAR 4 Company Code VBRK-BURKSVBELN X VBELN CHAR 10 Rebates settlement billing document

Number (from VBRK)z2ccmt_1325_02-VBELN

POSNR X POSNR NUMC 6 Item number of the SD document z2ccmt_1325_02-POSNRZyyyy Zyyyy CHART 1 Status of the posting into CO-PA

- ‘c’ completed - ‘p’ errors pending- ‘x’ cancelled (temporary)

Depending on the process



Field Key Data element Type Length Description OriginFKART FKART CHAR 4 Billing type VBRK-FKARTBOART BOART CHAR 4 Agreement type z2ccmt_1325_02-BOARTSPART SPART CHAR 2 Division VBRK-SPARTFKDAT FKDAT DATS 8 Billing Date in the Document VBRK-FKDATERDAT ERDAT DATS 8 Day On Which record was created VBRK-ERDATERZET ERZET TIMS 6 Entry time VBRK-ERZETBUDAT BUDAT DATS 8 FI Posting date BKPF-BUDAT

The table entries will contain a processing status that will indicate if the rebate settlement billing document/item has been processed completely or there is any error pending for any re-allocation split combination (based on error table entries).

The program will update the status of the history table after the execution of the program.

2.7.3 Z2REBATESERROR – Rebates CO-PA Error History table

This table will store the rebates settlement billing documents which could not be processed correctly with specific error type that will indicate when the error has happened. It is an application table with Delivery Class = A, display / maintenance should be allowed with restrictions. It must be defined with Data class = APPL1 and Size category = 5 (3.500.000 to 7.100.000).

Field Key Data element Type Length Description OriginMANDT X MANDT CLNT 3 ClientVKORG X VKORG CHAR 4 Sales Organization VBRK-VKORGVTWEG X VTWEG CHAR 2 Distribution Channel VBRK-VTWEGBUKRS X BUKRS CHAR 4 Company Code VBRK-BURKSVBELN X VBELN CHAR 10 Rebates settlement billing document

Number (from VBRK)z2ccmt_1325_02-VBELN

POSNR X POSNR NUMC 6 Item number of the SD document z2ccmt_1325_02-POSNRKUNAG X KUNAG CHAR 10 Sold-to party z2ccmt_1325_02-KUNAGMATNR X MATNR CHAR 18 Material Number z2ccmt_1325_02-MATNRZxxxx Zxxxx CHAR 3 Error type/point:

- ‘001’ in the rebates re-allocation table- ‘002’ in the billing documents header- ‘003’ in the finance document selection- ‘004’ in the value field mapping- ‘005’ in the posting date derivation- ‘006’ in the CO-PA posting

Depending on the process

BLART BLART CHAR 2 Document Type VBRK-BLARTFKART FKART CHAR 4 Billing type VBRK-FKARTBOART BOART CHAR 4 Agreement type z2ccmt_1325_02-BOARTSPART SPART CHAR 2 Division VBRK-SPARTFKDAT FKDAT DATS 8 Billing Date in the Document VBRK-FKDATERDAT ERDAT DATS 8 Day On Which billing Document was

EnteredVBRK-ERDAT

ERZET ERZET TIMS 6 Time of Entry VBRK-ERZETBUDAT BUDAT DATS 8 Posting date BKPF-BUDATZwwww Zwwww CHAR 6 Value field z0copa_map_offin-new value

fieldKWERT KWERT CHAR 12 Condition value z2ccmt_1325_02-KWERTWAERS WAERS CHAR 3 Currency z2ccmt_1325_02-WAERS

The table entries will contain an error type that will indicate the point where the error was generated. The level of information will depend on the point the error was generated.



In order to reprocess the error, and to avoid impact on refreshing re-allocation table, include all data for Co-PA posting.


Updated with new error types


2.8 Network Integration

N/A

2.9 Existing Sample Programs

Program Z2CMT1325_REALLOCATION already contains a function module formerly used to reverse and post to CO-PA (FORM af_reverse_copa_dox; FORM ai_post_reallocations).

Program Z2FICOLLECT_MATCOSTS already contains similar functionality in several points:

o It is strongly recommended that the subroutines and data structures for handling ALV reports are taken over from program Z2FICOLLECT_MATCOSTS. Some will have to be adjusted to the environment of this program; others can be used as they are. This will considerably shorten the development time while implementing a proven way used in many other programs. The program also contains a full set of subroutines to save, extract and display execution logs. Most of these subroutines are found in the section

************************************************************************ SUBROUTINES RELATED TO ALV REPORTS***********************************************************************Typical examples of the routines that will have to be adapted to the environment of this program are the ALV_COMMENT_BUILD routines, filling information in the page header. The code in MATCOSTS can nevertheless be used as a model, especially when it comes to concatenating individual entries in multiple selection fields.

In the same program there are also subroutines for handling the message log. These routines are in the section

************************************************************************ SUBROUTINES RELATED TO PROCESSING LOG***********************************************************************The majority of the data structures can also be copied.

Program Z2FICOLLECT_MATCOSTS has also an example of how to use FM POPUP_TO_CONFIRM (routine ASK_IF_CONTINUE) as well as an example to restrict the detail multiple selection screen (routine RESTRICT_SELECTIONS).

o To proceed with the history and error tables purge, form purge_data can be taken as based, taken into account the corresponding parameters.

o Obsolete extracts should be deleted following the same rules than form delete_obsolete_extracts



2.10 Security and Authorisation (This is a mandatory section)

To be completed by auth. Team. Pending until CO-PA security approach and design was been completed.

2.10.1 Segregated Access Requirements for Users into Single Roles

[Guidelines: 1) Divide in Access Requirements in small but with same functionality parts (functions); 2) Define Responsible for the Functions: Transaction Owners and Role Owners; 3) Define clear high risk that are desired to be avoided – i.e. 1000 users having access to a Critical Transaction]This program should be named Z2COPAREBATES_POSTING (tbc) and should be assigned to a new transaction Z2COPAREBATES (tbc). The transaction should be assigned to role the corresponding new CO-PA role (not yet defined).

1) transaction will be run by company code, but the users for this transaction will be central team (to be confirmed for cancellations)

2) Responsible for the Functions:

a. Transaction owner:

b. Role owners:

3) The main functionality of the transaction will be done in batch, but the checking of logs, and error and history tables and cancellations, should be done by central user only (to be confirmed if central /central or central by MSO).

2.10.2 Risk Assessment and Considerations for the Access Required

[Guidelines: 1) For each of the different functions and transactions determined which are the corresponding potential risk derived from their functionality: it is key to determine if there is change access or only display, the criticality of the access and the potential Segregation of Duties with other Functions]Processing run Post rebates re-allocations and Post rebates cancellations should allow change access, as they will write CO-PA line items and update ‘z’ tables (error and history tables).

Processing run Display error table, Display History table and Display previous logs will required only display access.

Pending to confirm if a special access is needed for execution mode Purge old data.

2.10.3 Users, Teams, Jobs where access is required

[Guidelines: 1) For each of the different functions identified in previous point determine would should be the users, teams or jobs that will require the specific segregated access; 2) Determine the Composite Roles to be updated according to the user access requirements and responsibilities for the new functions]

2.10.4 Objects to be authority-checked.

[Guidelines: 1) For each transaction determine the relevant authorization objects required according to its functionality; 2) Define the appropriate values for each authorization object depending on the Access Requirements]

2.10.5 Authorization Design:

[Guidelines: PL201 Document with the full requirements for Authorizations based on all previous points]



Special access for purge data processing mode??


Can you provide this information??


UFO task, or for MSO users??


2.9.6 Security and Authorization for the Accenture AM Team

[List all security and authorization or restrictions that must be taken into account when performing the conversion in relation to AM Support team and AM monitoring team access]

2.11 Processing and Operational Considerations

2.11.1 Performance

It is expected that the CO-PA posting function will take considerable time, due to the data volumes it has to select. Therefore it is recommended to execute in the background.

The number of line items to be processed and posted is quite high with small value field amounts, as the re-allocation table stored the split of the rebates settlement for material / sold-to level.

For a rebates settlement billing doc we can find 5.400 re-allocation lines, which will be 5.400 CO-PA line item, just for a settlement document (the rebate re-allocation as well as rebate accrual corrections could create 1M records on one single day for 1 MSO).

2.11.2 Batch Requirements

<Include details required for batch processing in line with the areas below: Submission Scheduling Considerations Run Frequency Start Date Start Time Estimated Volume Per Run Parameters / File Dependencies Job Dependencies Constraints Variant Required

o Field Texto Suggested Valueo Description>

This program will be executed by batch job, daily (batch job daily after billing run and after rebate reallocation) and ad hoc for rebate cancellations.

The functionality to display the history and the error history tables are typically executed online.

Purge tables execution mode can be run either in back job or online. Typically run every month.

2.11.3 Data Maintenance Requirements

N/A

2.11.4 Re-Use Details

N/A



2.11.5 Error Handling

The following messages should be created for this development in message class Z2COGS. The table below also shows the severity with which the message will be displayed in the processing log.

No Severity Message text000 I & & & &001 I &1 &2 - Program started with execution mode &3.002 I &1 &2 – Cancellation process run in test mode.003 I &1 &2 - Execution finished.004 A &1 &2 - Processing terminated.005 I No entries found in the rebate re-allocation table for company code &1006 I &1 re-allocations billing items selected from re-allocation tables.007 I No relevant entries found in the error table for company code &1008 I &1 billing items selected from rebate error table009 E Billing document &1 already processed010 E No value field mapping found for agreement type &1, document type &2011 E **Typically CO-PA posting interface errors (derivation, valuation): Co-PA

document not posted (transferred from CO-PA posting interface)012 E Program execution cancelled by the user.013 E Document &1 not in CO-PA table. No cancellation is possible.014 E Document &1 already cancelled by CO-PA document &2015 I “#XX CO-PA documents cancelled016 A User did not confirm data deletion.017 I User confirmed data deletion018 I Company code &1: Error table successfully deleted019 I Company code &1: History table successfully deleted020 I Company code &1: Error table, no items to be deleted021 I Company code &1: History table, no items to be deleted022 I Billing document &1, posting date in a closed period. Posting date changed

to system date023 E Billing document &1, posting date derived as system date. System date

period blocked for postings.024 I “No entries found in the history table for company code &1”

(…)

This error list is used as an example. It will need to be reviewed once the FD is finalized.

2.11.6 Log Output

See chapter 2.9, existing sample programs.

2.11.7 Purge and Archive Considerations

See chapter 2.2.5 Purge old data.

2.12 Design Alternatives

N/A



2.13 Key Test Conditions and Considerations

2.13.1 Selection screen Test Conditions

ID Condition Expected results Cycle Ref.

1Tests to be performed on the selection screen, without executing the program

2

Selection screen by user that has not user parameter EXP=SIRIUS

It will be displayed Radio button “Post rebate re-allocation”, “Post rebate Correction”, “Rebate billing document”, , “Display error table”, “Display history table”, “Purge old data” and “Display previous logs”. And fields “Period/year”, “Test mode”, “Execution date”

1

3

Selection screen by user that has user parameter EXP=SIRIUS

It will be displayed Radio button “Post rebate re-allocation”, “Post rebate Correction”, “Rebate billing document”, , “Display error table”, “Display history table”, “Purge old data” and “Display previous logs”. And fields “Period/year”, “Test mode” and “Execution date”Besides it will be displayed the fields “Extract ret period(days)”, “Retention period for history table(month)” and “Retention period for error table(month)”, under parameters block.

1

4

Execute the transaction to check fields allocation and default values

Selection screen appears:Company code: defaulted blackPost Rebates re-allocation radio button marked as default execution option.

1

5Company code It will be mandatory for all execution modes

(including post cancellations). By default it will be in blank

1

6 Radio button “Post rebate re-allocation” It will be activated by default. 1

7Radio button “Post rebate correction” Second option in sequence I the selection

screen. By default not activated.1

8Field “Rebate billing document” The entry will be only allowed and mandatory

if post rebate correction is selected. Multiple selection is allowed.

1

9

Field “Period / year” The entry will be only allowed and mandatory if post rebate correction is selected. Multiple selection is not allowed. It will be blank by default.

1

10Checkbox “Test mode” Only entry allowed if post rebate correction is

selected. It will be selected by default in this case.

1

11Radio button “Display error table” This radio button it will be not activated by

default.1

12Radio button “Display history table” This radio button it will be not activated by

default.1

13Radio button “Purge old data” This radio button it will be not activated by

default. 1

14Radio button “Display previous logs” This radio button it will be not activated by

default.1

15Field “Execution date(s)” Only entry allowed if display previous logs

active. It allows a range of dates. It will have by default the system date

1

16 Parameters block 1




17 Field “Extract ret period(days)”Field only displayed if the user has user parameter EXP=SIRIUS. By default has a value of “90”

1

18Field “Retention period for history table(month)”

Field only display for the user that has user parameter EXP=SIRIUS. By default has a value of “4”

1

19Field “Retention period for error table(month)”

Field only display for the user that has user parameter EXP=SIRIUS. By default has a value of “4”

1

2.13.2 Technical Test Conditions


1 “Post rebate re-allocation”This program could be executed in background in this mode

The rebates re-allocation is posted in CO-PA with appropriate value fields and characteristics.The documents which are processed should be updated in history table (header data). The documents which are not processed should be updated in error history table (detail information depending on error source).After processing, an execution log should be displayed with the result of the execution.

2

2 “Post rebate re-allocation”Performance problems??This program could be executed on line in this mode

The rebates re-allocation is posted in CO-PA with appropriate value fields and characteristics.The documents which are processed should be updated in history table (header data). The documents which are not processed should be updated in error history table (detail information depending on error source).After processing, an execution log should be displayed with the result of the execution.

2

3 “Post rebate correction”This program could be executed in background in this mode

The original postings will be removed from CO-PA. If some of those Rebate Billing document corrected would have any entry in the “Rebates Error Table”, those will be removed from that table.Then, the documents will be posted again according to post re-allocation mode, with appropriate value fields and characteristics.The documents processed which are removed and added again should be updated in history table with the correct status (“x” cancelled (temporary) and “c” complete respectively or “p” if any error happens).After processing, an execution log should be displayed with the result of the execution.

2




4 “Post rebate correction”This program could be executed on line in this mode

The original postings will be removed from CO-PA. If some of those Rebate Billing document corrected would have any entry in the “Rebates Error Table”, those will be removed from that table.Then, the documents will be posted again according to post re-allocation mode, with appropriate value fields and characteristics.The documents processed which are removed and added again should be updated in history table with the correct status (“x” cancelled (temporary) and “c” complete respectively or “p” if any error happens).After processing, an execution log should be displayed with the result of the execution.

2

5 “Display error table”This program could be executed on line in this mode

It will be displayed table Z2REBATESERROR for that company code and narrowing down the selection according to other selection criteria entered on the selection screen. The report must display all fields of table Z2REBATESERROR as defined in section 2.7.3.2.7.2

2

6 “Display history table”This program could be executed on line in this mode

It will be displayed table Z2REBATESHIST for that company code and narrowing down the selection according to other selection criteria entered on the selection screen. The report must display all fields of table Z2REBATESHIST as defined in section 2.7.2.

2

7 “Purge old data”This program could be executed on line in this mode.

It will delete the data from the Rebate History and Rebate Error tables according with the parameters indicated in the program: “Retention period for history table (month)” and “Retention period for error table (month)”

After processing, an execution log should be displayed with the result of the execution.

2

8 “Purge old data”This program could be executed in background in this mode.

It will delete the data from the Rebate History and Rebate Error tables according with the parameters indicated in the program: “Retention period for history table (month)” and “Retention period for error table (month)”

After processing, an execution log should be displayed with the result of the execution.

2

9 “Display previous logs”This program could be executed on line in this mode.

It will be displayed the previous logs, eventually narrowing down the selection according to the selected date entered on the selection screen.It will display a report with existing ALV extracts in descending order of their creation date and time. Double-clicking a line in the report will display the selected log.

2



2.13.3 Key Business Test Conditions


Post rebates processing mode 31 Execute the program for a company code with

values in table z2ccmt_1325_02No error items in the error history table for that company code.

The program should take the values in the table Z2CCMT_1325_02, and generate as many entries in CO-PA as in the table, aligned to relation material/customer/document/item.If all values are correct, history table should be updated with info of header data of the rebate doc. / item (no detail about the split of mat. Cust.).If no errors, no new values in the error table.After processing, an execution log should be displayed with the result of the execution.

3

2 Execute the program for a company code with values in table z2ccmt_1325_02At least an error item exists in the error history table for that company code.

The program should take the values in the table Z2CCMT_1325_02, and generate as many entries in CO-PA as in the table, aligned to relation material/customer/document/item.If all values are correct, history table should be updated with info of header data of the rebate doc. / item (no detail about the split of mat. Cust.).The line in the error table will be processed again. If it is posted correctly into Co-PA, the error item in the error table should be deleted, and history table item updated from ‘p’ to ‘c’, if all errors related to this doc. / item have been posted.If any error still happens, the item in the error table should be kept and the status in the history table maintained as ‘p’.Also specific message should appears in the log related this error.If no errors, no new values in the error table.After processing, an execution log should be displayed with the result of the execution.

3

3 Execute again a line from z2ccmt_1325_02 that belong to a Rebate Billing document already processed and posted in CO-PA correctly

If a rebate document has been already processed the line is in the history table as ‘completed’. The program should generate a message in the log (error message) saying that this Billing document was already processed successfully.The status in the Rebate History table should not change.

3

4 Execute the program for a company code that has a line in the error table that was not corrected.

The line in the error table will be kept with the same date and time.The status in the Rebate History Table for this Rebate billing document and item will be kept in “p” (errors pending) Also specific message should appears in the log related this error.

3

5 Execute the program for a company code that has a line in the error table that was corrected and no other error is pending to correct.

The line in the Rebate Error Table will be removed. The status in the Rebate History Table will be change to “c” (complete) just in case it was the last line remained without posting into CO-PA. If this is not the case, then the status will keep in “p” (errors pending)Also specific message should appears in the log related this error.

3




6 Take Error History table and be sure that exist a line (error) from previous period (or any other period in the past). Check that action has been corrected.Block the previous period (trx. OKP1) and rerun the program

The line in the Rebate Error Table will be removed. The status in the Rebate History Table will be change to “c” (complete) just in case it was the last line remained without posting into CO-PA. If this is not the case, then the status will keep in “p” (errors pending).

In the message log will be a reference to the change on the posting period: “Billing document &1, posting date in a closed period. Posting date changed to system date” due to the change in a posting date from initial Billing date due to period locking.

3

7 Process a line of a z2ccmt_1325_02 without any of these fields populated: rebates settlement billing doc, rebates settlement billing doc item, material, customer number, agreement type, condition value or currency.

This situation is not expected as rebated process is preventing this situation, but to keep this scenario force the testing.If no exist this situation, change one record of z2ccmt_1325_02 to get it

The error table should be informed with the billing doc the item, and all data available in table z2ccmt_1325_02 and error type ‘001’.In the Rebate History Table for this Rebate billing document and item a line should be included with status “p” (errors pending) and all data available.Also specific message should appears in the log related this error.

3

8 Process a line of a z2ccmt_1325_02 with a Billing document number that doesn´t exist for the sales organization.

This situation is not expected as rebated process is preventing this situation, but to keep this scenario force the testing.If no exist this situation, change one record of z2ccmt_1325_02 to get it

The error table should be informed with the billing doc the item, and all data available in table z2ccmt_1325_02 and error type ‘002’.In the Rebate History Table for this Rebate billing document and item a line should be included with status “p” (errors pending) and all data available.Also specific message should appears in the log related this error.

3

9 Process a line of a z2ccmt_1325_02 with a Billing document that exist but doesn´t belong to the company code selected (due to entries are billing document and company code).

This situation is not expected as rebated process is preventing this situation, but to keep this scenario force the testing.If no exist this situation, change one record of z2ccmt_1325_02 to reach it

The error table should be informed with the billing doc, and all data available and error type ‘003’.In the Rebate History Table for this Rebate billing document and item a line should be included with status “p” (errors pending) and all data available.Also specific message should appears in the log related this error.

3

10 Process a line of a z2ccmt_1325_02 with an “Agreement type” that is not in the mapping table Z0COPA_MAP_OFFIN.

If no exist this situation, change one record of z2ccmt_1325_02 to reach it.It would be ok too if no exist “Billing type” or “prior year indicator” or “new value field” in Z0COPA_MAP_OFFIN.

Error in the selection of value field. The error table should be informed with the billing doc, and all data available and error type ‘004’.In the Rebate History Table for this Rebate billing document and item a line should be included with status “p” (errors pending) and all data available.Also specific message should appears in the log related this error.

3

11 Take Error History Table and be sure that exist a line from previous period. Check that action has been corrected. So when try to make the posting in CO-PA, it will take system date. Then, block the current period (trx. OKP1) as well. Just in the next period, rerun the program in mode “Post Rebate Re-allocation”

The error table should be informed with the billing doc, and all data available and error type ‘005’.A message in the log also will be included with the text “Billing document &1, posting date derived as system date. System date period blocked for postings”.

3




12 A line is giving error in the posting in CO-PA. It could be due to derivation or valuation. The program should collect the message from CO-PA posting process.

The program should collect the message from CO-PA posting process. Error table should be informed with the billing doc, position and all data available, and error type ‘006’ in the CO-PA posting.In the Rebate History table will be updated with status ‘p’ pending errors. Also specific message should appears in the log related this error.

3


Post rebates correction processing mode 41 Execute the program for a rebate document,

the one we want to correct, in a company code.There is not any error item in the error history table for that billing document. Status in the history table is ‘c’ completed.

The CO-PA documents are reverted, and posted again with the new split values in the rebate reallocation table z2ccmt_1325_02.A message should be included in the log, with value “#XX CO-PA documents cancelled”.

4

2 Execute the program for a rebate document, the one we want to correct, in a company code (same as previous process).There is not any error item in the error history table for that billing document. Status in the history table is ‘c’ completed.

The original CO-PA document is not going to be reverted. A message should be included in the log:“Document &1 already cancelled by CO-PA document &2”.Any other CO-PA document not cancelled yet are reverted, and posted again with the new split values in the rebate reallocation table z2ccmt_1325_02.A message should be included in the log, with value “#XX CO-PA documents cancelled”.(Same possible errors than post rebates process, as it is doing these steps also).

4

3 Execute the program for a rebate document, the one we want to correct, in a company code.There is some error item in the error history table for that billing document. Status in the history table is ‘p’ pending errors.

Error entries in the error table are deleted.The CO-PA documents are reverted, and posted again with the new split values in the rebate reallocation table z2ccmt_1325_02.If errors are found again, the entries are included in the error table again.History table is updated accordingly (‘c’ complete or ‘p’ if there is errors pending)Messages included in the log accordingly to the cancellation and to the error tracks.

4

4 Execute the program for a rebate document, the one we want to correct, in a company code, which has not been processed to CO-PA yet (no in the history table).

The program should include a message in the log indicating that this billing document has not been posted in CO-PA yet:“Document &1 not in CO-PA table. No cancellation is possible”. No posting to CO-PA will be done.

4

5 Execute the program for a rebate document, the one we want to correct, in a company code, which has not been processed again and no new values are available in the rebate table.

The CO-PA documents are reverted. A message should be included in the log, with value “#XX CO-PA documents cancelled”.No new CO-PA document is generated, as no values are available in the rebates table.

4

6 Execute the program for more than one rebate document, the ones we want to correct, in a company code.

Rebates docs have to be cancelled in CO-PA according to above process, including the posting of new split if corresponds, aligned with above scenarios.

4




Purge data processing mode 51 Execute the program in purge mode for a

company code with old data in the history table (and/or in the error table). Check retention period to confirm old data.

A pop up appears to confirm the deletion of the data. Items in the history table (and/or in the error table) are deleted.Specific message should appears in the log:“Company code &1: Error table successfully deleted”“Company code &1: History table successfully deleted”After processing, an execution log should be displayed with the result of the execution.

5

2 Execute the program in purge mode for a company code with old data in the history table (and/or in the error table). Check retention period to confirm old data.

A pop up appears to confirm the deletion of the data. Cancel the process by clicking ‘cancel’. No data is deleted.A message in the log is included indicating the process has been cancelled.

5

3 Execute the program in purge mode for a company code without old data in the history table (and/or in the error table). Check retention period to confirm old data.

A pop up appears to confirm the deletion of the data.A message in the log is included indicating that no old data is in the corresponding table.After processing, an execution log should be displayed with the result of the execution.

5


Display tables (error and history data) 61 Execute the program in Display history table

for a company code.A report with history table values related to the company code selected should appear.The report must display all fields of table Z2REBATESHIST

6

2 Execute the program in Display history table for a company code with no values in the table Z2REBATESHIST.

A message should be displayed with text:“No entries found in the history table for company code &1”.

6

3 Execute the program in Display error history table for a company code.

A report with error history table values related to the company code selected should appear.The report must display all fields of table Z2REBATESERROR

6

Execute the program in Display history table for a company code with no values in the table Z2REBATESERROR.

A message should be displayed with text:“No relevant entries found in the error table for company code &1”

6


100137 AP355 EFD CO-PA Rebates Posting v0.8

Documents

Transcript of 100137 AP355 EFD CO-PA Rebates Posting v0.8