SAP Recycling Administration - Cookbook Recycling Fees in ......Pricing in MM/SD Figure 1: Integrating REA Pricing into a Sales/Purchase Process Figure 2 shows the process flow that

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com

© 2012 SAP AG 1

Cookbook IS-REA – Embedding

Recycling Fees in the Business

Processes

Applies to:

SAP Recycling Administration

Summary

This document describes how to consider the within IS-REA calculated recycling fees in the SD- and MM purchasing business processes with the help of pricing conditions. Furthermore the posting of the REA declarations into FI and the creation of possibly necessary adjustment documents are depicted also.

Author: Frank Meschig

Company: SAP AG

Created on: 2012-07-20

Author Bio

Frank Meschig, SAP AG, Senior Developer in the development team of SAP Recycling Administration

Cookbook IS-REA – Embedding Recycling Fees in the Business Processes


© 2012 SAP AG 2

Table of Contents

How to Use SD & MM Conditions from REA ...................................................................................................... 4

Introduction ..................................................................................................................................................... 4

Process Description ........................................................................................................................................ 4

Customizing and Configuration ....................................................................................................................... 6 Considerations ............................................................................................................................................................. 6

Conditions and Recycling Partners .............................................................................................................................. 6

Conditions and Business Processes ............................................................................................................................ 6

Conditions and Sales Units .......................................................................................................................................... 7

Conditions and Company Codes .................................................................................................................... 7 Company-Code-Specific Conditions ............................................................................................................................ 7

Conditions for Differing Country ................................................................................................................................... 8

Conditions and Country Grouping ................................................................................................................................ 8

Conditions and Currencies ........................................................................................................................................... 8

Creating Conditions ..................................................................................................................................................... 8

Condition Tables .......................................................................................................................................................... 8

Access Sequences .......................................................................................................................................... 8 Access ......................................................................................................................................................................... 9

Fields ........................................................................................................................................................................... 9

Condition Types ......................................................................................................................................................... 10

Pricing Procedure .......................................................................................................................................... 12 Configuring and Activating Condition Creation in REA .............................................................................................. 12

Configuring the Recycling Partner ............................................................................................................................. 12

Starting the Condition Generation in REA .................................................................................................... 12 Customer Enhancement ............................................................................................................................................ 13

Implementation .......................................................................................................................................................... 13

Interface and Function ............................................................................................................................................... 13

Customizing .................................................................................................................................................. 13

Advanced Functions ...................................................................................................................................... 15 Analyzing Logs ........................................................................................................................................................... 15

Automating Condition Generation .............................................................................................................................. 16

Deleting Conditions .................................................................................................................................................... 17

Improving Performance .............................................................................................................................................. 17

Suppressing Conditions that have value 0 ................................................................................................................. 18

Condition Table for Characteristics ............................................................................................................... 18

Condition Records ......................................................................................................................................... 18

Accruals ........................................................................................................................................................ 19

How to Transfer REA Declarations into FI ........................................................................................................ 20

Introduction ................................................................................................................................................... 20

Process Description ...................................................................................................................................... 20

Accounting Transactions ............................................................................................................................... 21 Considerations ........................................................................................................................................................... 21

Vendor Invoice ........................................................................................................................................................... 21

Customer Credit Memo .............................................................................................................................................. 21

Customizing and Configuration ..................................................................................................................... 21 Reference Transaction ............................................................................................................................................... 21



© 2012 SAP AG 3

FI Customizing .............................................................................................................................................. 22 Document Types ........................................................................................................................................................ 22

General Ledger Accounts .......................................................................................................................................... 25

FI Master Data Maintenance ......................................................................................................................... 29 Accounts Receivable ................................................................................................................................................. 30

Accounts Payable ...................................................................................................................................................... 31

REA Customizing .......................................................................................................................................... 33 REA Master Data Maintenance .................................................................................................................................. 33

REA Declarations .......................................................................................................................................... 34 Transferring an REA Document to FI ......................................................................................................................... 35

Posting an REA Reversal Document ......................................................................................................................... 36

FI Status of REA Documents ..................................................................................................................................... 37

REA Accounting Documents ......................................................................................................................... 38 Displaying an Accounting Document ......................................................................................................................... 38

Calling an REA Document from Accounting............................................................................................................... 40

How to Use Accruals for REA ........................................................................................................................... 41

Introduction ................................................................................................................................................... 41

Process Description ...................................................................................................................................... 41

G/L Accounts and Accruals in SD ................................................................................................................. 41 Account Assignment .................................................................................................................................................. 41

Pricing Procedure ...................................................................................................................................................... 43

Automatic Accruals Correction ...................................................................................................................... 43 Background ................................................................................................................................................................ 43

Functionality ............................................................................................................................................................... 43

Customizing ............................................................................................................................................................... 43

SD Customizing ............................................................................................................................................ 44

REA Customizing .......................................................................................................................................... 48

Program for Analyzing and Adjusting Amounts ............................................................................................ 50

Copyright........................................................................................................................................................... 53



© 2012 SAP AG 4

How to Use SD & MM Conditions from REA

Introduction

This document describes the process required to use pricing in REA in order to integrate the expected license fee for a product (MM material = REA article) into a purchase process or sales process. This usage involves the price calculation, displaying information on documents, and creating accruals. REA uses the condition technique as an interface to the SD/MM module. A prerequisite for this document is that the user already has a sound understanding of the condition technique.

Process Description

Figure 1 shows how REA pricing is integrated into R/3 pricing in MM and SD. This integration setup involves the use of conditions that you can define in SD/MM Customizing. The condition types that you define here can then be defined later in REA. If pricing is then triggered in REA (by changing the master data, for example), this condition type is then used to generate one or multiple condition records in the R/3 system. By integrating the condition type into the pricing procedure within R/3 pricing, REA pricing then becomes part of the R/3 pricing process. Depending on the settings in Customizing for R/3 pricing, the result of the REA pricing (= condition records) can then be used in the various R/3 subsequent processes.

Pricing is

performed in

REA for an REA

article (product)

depending on

the business

process

The result of the

REA pricing is

transferred into

MM/SD pricing

as an R/3

condition record

The condition

record sent from

REA is fed into

MM/SD pricing

and made

available for

follow-on

processes

Pricing in REACondition Record

CreationPricing in MM/SD

Figure 1: Integrating REA Pricing into a Sales/Purchase Process

Figure 2 shows the process flow that is involved in R/3 pricing when used in combination with the condition records generated in REA. The Document is used to determine a Pricing Procedure (sometimes referred to on screen as a calculation schema). In this example, condition type ZREA has been defined in the pricing procedure. Condition type ZREA includes the access sequence J7L, which defines the sequence in which the condition tables are read. While reading the second condition table that contains the keys Material and Sales Unit from item 10 of the document, a condition record that contains a from scale is found. The correct scale value (1,00 EUR) is copied into the document.



© 2012 SAP AG 5

SAP AG

R

Calculation scheme

1. Price PR00

2. Fee ZREA

3. Rebate 2 RA01

Document

Item 10: 120 PC

Condition type: ZREA

Access sequence: J7L

Access key: J7L

Condition tables:

1. Material / Sales Unit / Customer

2. Material / Sales Unit

3. Material

no valid record exists

valid record exists

Records for condition type ZREA

PR00 Price 99 EUR

ZREA Fee 1+ EUR

RA01 Rebate 2- %

from 1 PC 0,50 EUR

from 100 PC 1,00 EUR

from 200 PC 1,10 EUR

Overview Pricing in R/3

Figure 2: R/3 Pricing Using Condition Type ZREA in the Pricing Procedure

The process shown in Figure 2 is based entirely on R/3 Customizing. The action required by REA is to fill the condition tables for condition type ZREA. The settings that you must make for this in R/3 Customizing and in REA Customizing are described in the next section.



© 2012 SAP AG 6

Customizing and Configuration

Considerations

As the process needed to form condition tables, access sequences and condition types can require a great deal of effort, it is a good idea to consider several factors at the outset. The aspects mentioned below must be considered as part of the following sequence:

Conditions and Recycling Partners

In REA, you can create separate condition records for each recycling partner. A separate condition type is then defined for each of these recycling partners, once for purchasing and once for sales.

As a second option, you can also create condition records in REA that apply for all recycling partners, meaning the pricing for one or more recycling partners is then grouped into one condition type.

As a third option, you can group all pricing information in REA under one (statistical) condition type. The mean value of the pricing information for the individual recycling partners is then fed into the condition records of these statistical conditions.

You can set all three of these options separately for sales and purchase processes in the Conditions screen group in REA Customizing under General Control Control, under Sales Condition Usage and Purchasing Condition Usage. If you want to use statistical conditions, here you can define the parameters needed for this (Condition Type, Usage, Application).

For test systems, you must define the value of the Condition Adjustment field as synchronous (see below).

Conditions and Business Processes

If REA contains mappings for business processes that may influence pricing for each REA article, you must structure the condition tables accordingly. If you fail to do this, errors will occur while creating the conditions in REA.

You can define the business processes that are relevant for a condition type by setting the Source for the recycling partner (Tools Recycling Partner General Control) in screen group Conditions Control. The following options are available to you:

[1] No Source conditions are not formed (?) [2] Splitting conditions are formed based on the license fee splitting setting [3] Trade Levels conditions are formed based on the settings made for transaction-specific trade

levels [4] Splitting and Trade Levels conditions are formed based on the settings made for license fee

splitting and transaction-specific trade levels

If option [2] to [4] is selected, consideration must be paid to which business processes are described in REA Customizing under Condition Types and Splitting Splitting and Regional Processing when creating the condition tables.

For example, if a recycling partner uses regional processing depending on the sales organization, you must define an access sequence for the condition type of this recycling partner that contains (as a minimum) one condition table with the Sales Organization field as a key. If you defined the source according to [2] or [4], REA attempts to generate pricing information that is dependent on this key (among others) for the condition type.

If a recycling partner uses transaction-specific trade levels that are based on the sales area, you must define (at least) one access sequence for the condition type of this recycling partner that contains (as a minimum) one condition table with the sales area (VKORG, VTWEG,



© 2012 SAP AG 7

SPART) as a key. If you defined the source according to [3] or [4], REA attempts to generate pricing information that is dependent on this key (among others) for the condition type.

In general, REA attempts to generate condition records for all key combinations that it comes across when evaluating the entries in REA Customizing Condition Types and Splitting Splitting and Regional Processing, providing the corresponding source has been set (see above). In doing so, REA interprets the entries in REA Customizing Condition Types and Splitting Splitting and Regional Processing as key values and therefore looks for condition tables that have the corresponding key fields for the condition type in question. If it fails to do so, an error log is output which outlines any condition tables that are missing by noting their key fields.

Conditions and Sales Units

In general, REA articles are maintained using the material number, company code, country and sales unit keys. This means that the condition tables also have these same keys at the very least. If an REA user only uses one sales unit as a rule, he or she can also create condition tables that do not contain the sales unit key. To do this, the user must activate the Create Conditions Independently of UM indicator in REA (REA Customizing General Control Control in screen group Conditions).

If a user has activated the Create Conditions Independently of UM indicator and maintains multiple sales units for each article, they are then unable to define any correct pricing information in SD/MM as a unique assignment is not possible.

If the customer uses reference units in REA, he or she may convert the reference unit into the sales unit as part of pricing in SD/MM. In this case, REA only generates condition records with the reference unit as a key for the sales unit (and for any sales units that have been defined explicitly). Alternatively, REA is also able to generate condition records for all units of measure that are defined through the reference unit. To do this, the user must activate the Create Conditions for all UM with Ref. UM indicator in REA (REA Customizing General Control Control in screen group Conditions).

Deactivating this Customizing setting does not delete any condition records that were created additionally.

In general, for any REA articles that have derivation type 3 as their sales units, condition scales are created for the base unit of measure for the REA article in question. The scale limits are obtained from the quantity limit of the sales units, which in turn are either determined from the article master data in MM by using conversion factors, or from the REA article master data (if they are overwritten there). In this case, you also do not need to integrate the sales unit into the access sequence as a key, as the scales always refer to the BUoM of the article.

Conditions and Company Codes

Company-Code-Specific Conditions

In general, condition records are generated for all company codes that are assigned to the recycling partner, providing this partner is intended for this use. The Company Code field is a required key field in the condition table, which is filled from within REA. Users have the option of controlling the creation of condition records differentiated according to SD and MM conditions for each individual company code for the recycling partner. The corresponding indicators for setting this are available under Tools Recycling Partner Company Codes Depending on Assigned Condition Types.



© 2012 SAP AG 8

This allows you to initiate condition record creation for a reference company code, for example.

Conditions for Differing Country

When creating condition records, the country of the article is usually used as a value for the Country key field in the condition table. However, you can also define an Other Country in the details for each company code of the recycling partner in question to override the article country (Tools Recycling Partner Company Codes).

Conditions and Country Grouping

If country grouping is being used in REA Customizing (REA Customizing General Control Country Grouping) and the article country is being used as a reference for other countries, then condition records are also created for all referencing countries as well as for the reference country itself.

The recycling partner assigned in each case must be created in the affected countries. If you want to use just one condition type multiple times, in other words for all countries, you must choose "S Statistical Conditions" or "E Conitions for All Recycling Partners" for the condition usage under General Control.

Conditions and Currencies

Conditions are usually created in the currency of the company code in REA. If the Use Price List Currency Re. Partner indicator is activated (REA Customizing General Control Control in screen group Conditions), the condition is then created in the currency of the recycling partner for the respective REA price list version (Tools Price List).

Creating Conditions

You can maintain SD conditions in R/3 Customizing under Sales and Distribution Basic Functions Pricing Pricing Control and MM conditions under Materials Management Purchasing Conditions Pricing.

Condition Tables

You have to create corresponding condition tables according to the settings made in REA. You can freely assign a table number within the customer namespace. You can select the required fields as key fields from the field catalog. If required, you can add further fields in other Customizing locations to extend the field catalog. The Company Code (BUKRS), Country of Destination (LAND1) and Material (MATNR) fields are required fields, which therefore also represents the minimum number of key fields. If regional processing is involved, for example, values must also be specified accordingly for the sales area.

Access Sequences

Access sequences are used to control the respective condition tables and the sequential access.



© 2012 SAP AG 9

Access

In general, accesses are structured from specific to general validity. The indicator set in the "Exclusive" column controls whether or not the first suitable condition record is to be used for gaining read access to pricing.

Figure 3: Example Access Sequence for REA SD Conditions

To ensure that condition records are structured correctly, only condition tables that are REA-compliant can be added to the access sequence. No check is made by REA to see whether the processed tables have the values required. If a check were carried out, side effects or technical problems could not be ruled out.

Figure 4: Example Access Sequence for Sales Conditions

As the sequential number in the first column can be assigned freely, we recommend that you avoid using an increment of 1 so that you can implement any subsequent changes or enhancements without encountering any difficulties.

Fields

Furthermore, you also have to make a field-based assignment of the characteristics for each condition table between the document and the condition table itself. In general, you can simply copy the document structures that are suggested (communication structures) along with their corresponding field assignments. To be absolutely certain, consult the specialist department regarding which source fields in the document are relevant, since these can vary depending on the process involved.



© 2012 SAP AG 10

Figure 5: Field Assignment in the Access Sequence for Sales and Distribution

Figure 6: Field Assignment in the Access Sequence for Purchasing

Condition Types

In most cases, making the following settings for the condition type is sufficient. As a rule, the condition type must be set up so that it is possible to create scales and use accruals.



© 2012 SAP AG 11

Figure 7: Basic Settings for the Condition Type



© 2012 SAP AG 12

Pricing Procedure

As can be seen in the example shown in Error! Reference source not found., the condition types that have been created can be included into the corresponding pricing procedure. This should be done in close cooperation with the department in question and/or an SD consultant, as this affects pricing depending on the document type involved. Within the pricing procedure, you can also assign an account (ActKy column) and a provisional (accrual) account (Accruals column) to REA condition types for creating accruals.

Figure 8: Control Data in the Access Schema

Configuring and Activating Condition Creation in REA

After creating the condition type, you then need to configure the condition creation in REA. You do this in REA Customizing under General Control Control in screen group Conditions. The meaning of these fields has already been explained above.

For testing activities, the Condition Adjustment must be set to synchronous. For a production environment,

Condition Adjustment must be set to asynchronous or manual. If the user wants to use statistical

conditions, he or she must set the corresponding entries in the Condition Type, Usage and Application fields. Purchase conditions and sales conditions are handled separately.

Configuring the Recycling Partner

If the user wants to use recycling partners or conditions that are valid for all recycling partners, he or she must define the Usage, Application and Condition Type in screen group Conditions Control (Tools Recycling Partner General Control). Purchase conditions and sales conditions are handled separately.

Starting the Condition Generation in REA

If the Condition Adjustment has been set to synchronous or asynchronous, simply saving an article is

enough to generate the condition records. In the case of a synchronous condition adjustment, the transaction waits until the conditions have been created. For an asynchronous condition adjustment, the user can continue working immediately.



© 2012 SAP AG 13

You can display the relevant condition records in the article dialog by choosing Environment Condition Info Purchasing or Sales. This is the same as using transaction VK13 for displaying SD condition records and transaction MEK3 for displaying purchasing condition records.

If the Condition Adjustment is set to manual, it must be triggered using a report.

Customer Enhancement

There are certain processes where it also makes sense to restrict the condition records that are generated by considering the data volume involved. As well as the option of using the available company-code-specific approach to create condition records for the recycling partner, this enhancement can also be used to make a differentiated selection, if required. For example, one possible scenario could be that for products which are delivered to one particular customer group of goods recipients, no accruals are to be formed using conditions, as these are self-managers.

Implementation

From a technical perspective, the customer enhancement is realized using a function module that must be created and freely assigned in the customer namespace in advance. You can use the shipped function module J_7L_KOND_FILTER_EXIT as a template for this.

You must exercise extreme caution when selecting condition records, as this process may have a direct impact on pricing in SD and/or MM.

Interface and Function

The interface is used to transfer the following fields as characteristics for each material in question:

VGTYP Transaction category (V = sales & distribution, E = purchasing and S = other)

MATNR Material number

BUKRS Company code

LAND1 Country of destination

VRKME Sales unit

In addition, internal table J_7LE01_TAB lists all of the recycling partners for the country in question along with its most important corresponding master data, in the same way as transparent table J_7LE01.

Another table which is relevant for the condition record selection is table KONDITIONEN_TAB, which contains all current condition records. By deleting specific entries from this table, you can prevent a corresponding condition record from being created. If such a condition record has however already been created previously, the system sets a deletion flag for this data record in the database.

Where country groupings are involved or company codes are referenced, the function module can run multiple times for each material, as in this case it is then triggered for each company code and country.

Customizing

After you have implemented the function module, it has to be activated in REA Customizing (REA Customizing General Control Control).



© 2012 SAP AG 14

Figure 9: Activating a User Exit



© 2012 SAP AG 15

Advanced Functions

Analyzing Logs

From a technical perspective, REA generates condition records by processing the input data in transaction VK13 or MEK3 in the background (batch input session). If an error occurs while processing the condition records, the log is formatted as an R/3 application log and is either displayed directly or can be called by the user directly under Environment Condition Info Error Log (Current) / Error Log (Historical).

Figure 10: Log Overview

The hierarchical list on the left-hand side shows all of the log entries. Choosing a node on the left-hand side displays all messages that belong to that node on the right-hand part of the screen. This hierarchy always has the structure Transaction Program / Module Pool Screen Input Field. After this a success message is then displayed, which logs the key that caused the error in a long text for the following error message.

.

Figure 11: Reference to Inbound Parameter in Long Text

The long text then contains the following information:

Recycling partner, usage of the condition, application, condition type, transaction category



© 2012 SAP AG 16

Key combination of the business process (sales area, customer characteristic, customer)

Or purchasing organization, vendor characteristic, vendor number

Details about the period

Figure 12: Long Text Indicating Missing Condition Tables (Key Field Combinations)

This log evaluation is helpful when analyzing and correcting errors as described above.

You can use transaction SLG1 or SLG2 to display or delete all of the entries in the R/3 application log. The log for the condition adjustment has the object J7LM and the subobject CHANGE_CONDITION. The key (External Identification) is obtained from the article key (MATNR+BUKRS+LAND1+VRKME). You can also use transactions SLG1 and SLG2 to evaluate even more information relating to the error log (time point, user), however the data is then formatted in a different form than the one shown here.

The R/3 application log is usually archived (or deleted) centrally and at regular intervals.

Automating Condition Generation

You can use the selection made for the Condition Adjustment in REA Customizing General Control Control in screen group Condition to specify whether you want to trigger the condition adjustment in dialog (synchronous/asynchronous) or individually using a (background) process. In making this decision, you must consider the following aspects:

If the adjustment is started in dialog, the conditions are updated close to the time when the article master data is changed.

If the adjustment is started using a background process, the change to the article master data and change to the conditions are decoupled.

The condition adjustment blocks a work process in the R/3 system. If a large number of conditions need to be updated following a master data change due to the way in which the master data is



© 2012 SAP AG 17

structured (referencing), an asynchronous adjustment executed in dialog can seriously affect the entire system performance.

Adjustments that are made to price lists or to other configuration data do not directly lead to all of the master data being adjusted – even if the option for triggering an adjustment in dialog was selected. This is only done when saving master data, and only for the master data that is being saved.

Using the general interface to import master data only triggers an update of the conditions if you choose the synchronous adjustment.

Considering all of the points above usually results in the following recommendation:

For a standard master data structure, set the condition adjustment to asynchronous. If any

changes are made to the configuration, start the adjustment using a background process.

If mass changes are involved (general interface, programs in package J7LUTILITY), decouple the master data change and the condition adjustment by performing the change first and then updating the conditions using a background process.

If you are dealing with a master data structure that leads to lengthy update times when making changes in dialog, set the condition adjustment to manual and start it at regular intervals

using a background process.

Regardless of the settings you make for the condition adjustment, you can also start the update manually in REA Customizing under Adjustments Conditions or by calling transaction J7LB.

Deleting Conditions

If REA has created condition records due to an incorrect configuration, you can delete these records using transaction J7LUTILITY5.

Improving Performance

You can improve performance in the following ways:

Minimize the total number of condition records

Minimize the number of condition records by simplifying the business process

Activating the Price-Dep. Conditions indicator in screen group Conditions in REA Customizing under General Control Control can help to keep the overall number of condition records to a minimum. When this indicator is activated, new versions of a condition record are only generated if the value of the record actually changes. If this indicator is not set, new condition records that have a different validity period are created every time a price list version is changed.

You can also reduce the number of condition records by filtering company codes for the recycling partner. You can also control the creation of condition records for the recycling partner based on specific company codes.

Another thing that can help to keep the overall number of condition records to a minimum is to convert sales units in SD/MM instead of generating condition records for sales units that are defined using reference units.

If an REA user uses the various referencing options that are available in REA, it may happen that a very large number of conditions have to be adjusted when master data is changed if the condition adjustment has been set to synchronous or asynchronous. This can potentially block an R/3 work process for a long period



© 2012 SAP AG 18

of time. In a case such as this, it makes far more sense to update the conditions in question manually by scheduling a job.

In R/3 Customizing for condition types (Sales and Distribution Basic Functions Pricing Pricing Control Define Condition Types), you can use the Delete from DB selection box in the Master Data screen group to specify whether the condition records of a condition type are to be deleted physically or logically. If you do not need to display the deleted condition records, choosing a physical deletion can help to reduce the number of condition records, as they are then actually removed from the database altogether.

You can prevent conditions being created for all business processes of an REA article by using condition records with the value 0, as described below.

The complexity of the business processes involved plays a decisive role in determining the number of condition records that are generated.

For example, if the REA user has defined a large number of exceptions at customer level in REA Customizing under Condition Types and Splitting Splitting and Regional Processing, the number of condition records increases proportionally as a result. In this instance, it makes sense to clarify whether you can reduce the number of entries by using a common customer characteristic or by grouping them together under a single partner role within a customer hierarchy.

Suppressing Conditions that have value 0

You can use "zero" condition records to prevent certain condition records from being created. These records are identified by the fact that they do not have a material number and have condition amount 0. You can then use the further characteristics to specify the versions for which you do not want any conditions to be created. As this information must be available right at the start when processing condition records, you need to include the respective condition table in the leading position in the access sequence.

Alternatively, you can also control the condition record selection using a customer enhancement.

Condition Table for Characteristics

You can select records for sales and distribution transactions by using the VKORG, VTWEG, SPART, KUMRK and KUNNR characteristics, and for purchase transactions by using EKORG, LIMRK, and LIFNR. You must create at least one characteristic as a criterion for the transaction type.

You must fill the condition table with fields BUKRS, LAND1 and MATNR and one or more of the characteristics named above.

Condition Records

As the table is not filled from within REA, you need to enter the corresponding entries manually, for instance by using transaction VK13. This allows you to suppress the generation of conditions for one or more



© 2012 SAP AG 19

customers, for example. In general, the respective item for the condition record must have the condition value 0 and its header must not contain a material number.

Accruals

You can use conditions to create accruals, against which you can then post REA declarations. You can assign a provisional (accrual) account in the pricing procedure. For more information about this procedure, see the chapter “How to Use Accruals for REA’.



© 2012 SAP AG 20

How to Transfer REA Declarations into FI

Introduction

This document describes how you can use the FI connection in REA to post the license fee that was determined to financial accounting. The postings that are generated comprise invoices and credit memos that take value-added tax into consideration, as well as retransferring accruals, if required. The user in question must have previous experience of using, maintaining and configuring SAP Financial Accounting and must perform the configuration in close cooperation with the department.

Remember that you must grant the authorization rights that are required for using and maintaining financial accounting.

Process Description

Figure 1 shows the process steps that are relevant from a financial accounting perspective. If conditions have been set up in REA (see section “How to Use SD & MM Conditions from REA”), you can use these condition types to create accruals in pricing. The REA declaration that is created at a later stage is based on transaction data obtained from billing documents or material movements and is saved to the database as a separate document. If you have set up REA to use an FI connection, you can now transfer this REA document from the declaration system into FI.

Durch die

Verwendung von

REA

Konditionen in

der SD/MM

Preisfindung

können

Rückstellungen

gebildet werden.

Auf Basis der

SD/MM-Belege

wird das

Ergebnis einer

REA-Meldung

als eigener

Beleg gesichert.

Durch die

Überleitung des

REA Belegs in

die Buchhaltung

wird dieser

gegen die

Rückstellungen

gebucht

Preisfindung SD/MM REA Meldung Beleg im FI

Figure 13: Process Flow from an FI Perspective



© 2012 SAP AG 21

Accounting Transactions

Considerations

In general, the fees determined in the REA declaration represent a liability for the recycling partner or customer. In financial accounting, the REA document can be used to offset any accruals that were formed due to billing documents or purchasing. In a similar way, the value-added tax that is defined for the company code or REA price list of the REA declaration is also taken into consideration.

Vendor Invoice

As a rule, an REA declaration is created as a vendor invoice in accounting for direct settlement that involves a recycling partner. In principle, the declaration can be viewed as a fee for services provided by a vendor which are then invoiced to the same company.

Regardless of whether an FI connection is used, the recycling partners are created in the vendor master and can be assigned at this point to an account in the general ledger.

Customer Credit Memo

If the fee is charged to the recycling partner through a customer, you have the option of reimbursing this fee to the customer using a credit memo for a previous invoice.

Customizing and Configuration

Reference Transaction

For auditing purposes, it can be helpful to communicate the REA declaration as a reference procedure for accounting. This makes it possible for you to navigate to the REA declaration from the accounting document being generated. Furthermore, this also ensures that accounting documents can only be generated or reversed from within REA.

Figure 14: Maintenance Dialog for SM31



© 2012 SAP AG 22

Figure 15: Entry in Table TTYP

For REA versions lower than EhP4, you must create this reference procedure in the customer namespace manually using transaction SM31. This allows you to choose ZJ7L instead of J7LR, for example. Entering function module J_7L_AC_DOCUMENT_SENDER_V1K is mandatory, and you can assign any description as required. However, we recommend that you do this within the REA context, as this is specified in the accounting document. Note that this description is also language-specific.

FI Customizing

This section describes the Customizing settings required for financial accounting.

Document Types

The document types differentiate the various business transactions and control document storage, meaning that it makes sense to define one or more specific document types for REA accounting documents. You can assign these to specific documents in REA at a later stage. You can assign a separate number range to each of these document types.

Figure 16: Initial Screen for Maintaining Document Types

You can freely assign the document type and must define a language-specific description for it.



© 2012 SAP AG 23

Figure 17: Example of REA-Specific Document Types

The detailed screen shown below allows you to make basic settings for the document type. In particular, this is where you can specify your own number range. You can keep the reverse document type specified as it is, as a real reversal document is generated for reversed REA documents in accounting, not just an offsetting entry.



© 2012 SAP AG 24

Figure 18: Detailed Screen for FI Document Type: Vendor Invoice Example

You can also simply copy and adjust the document types shipped as standard, such as "KR" for a vendor invoice or "DG" for a customer credit memo.

You can maintain the number ranges in Customizing at the location shown below. The maintenance dialog for this is the same as the general schema used for number range object maintenance.



© 2012 SAP AG 25

Figure 19: Number Range Maintenance for an FI Document Type

General Ledger Accounts

You can create one or more general ledger accounts for accruals for the purpose of offsetting vendor invoices or customer credit memos. It goes without saying that you can of course also use an existing general ledger account for this same purpose.

Figure 20: Maintaining G/L Accounts



© 2012 SAP AG 26

Figure 21: Overview of G/L Accounts

G/L account 89600 can only be used as an example. For example, you could restrict the tax category, enter a different sort key, or define the currency you require. The descriptions you enter here are also freely assignable and language-specific. In general, you can simply copy the settings given under the "Control in Chart of Accounts" and "Account Management in Company Code" areas.

The figures below give an example outlining possible settings that can be used for a G/L account used for accruals.



© 2012 SAP AG 27

Figure 22: G/L Account: Type/Description

Figure 23: G/L Account: Control Data



© 2012 SAP AG 28

Figure 24: Creating a G/L Account

Figure 25: Entering and Translating Texts for a G/L Account



© 2012 SAP AG 29

Figure 26: G/L Account Texts in the Chart of Accounts

Figure 27: Accounts Payable and Accounts Receivable

FI Master Data Maintenance

You assign the accounts used for accounts payable and accounts receivable in master data maintenance.



© 2012 SAP AG 30

Figure 28: Accounts Payable and Accounts Receivable

Accounts Receivable

You can maintain the account assignment under the Master Records menu option.

Figure 29: Accounts Receivable Menu Option

In the example shown below, reconciliation account 140000 has been specified in the company code data for customer 2.



© 2012 SAP AG 31

Figure 30: Reconciliation Account for a Customer

Accounts Payable

You can maintain the account assignment under the Master Records menu option.

Figure 31: Accounts Payable Menu Option

In the example shown below, reconciliation account 160000 has been entered in account management for the vendor SUPPLIER.



© 2012 SAP AG 32

Figure 32: Reconciliation Account for a Vendor



© 2012 SAP AG 33

REA Customizing

By activating FI as a follow-on function, the fields that are relevant for maintaining master data are displayed first. If activated, you must specify the reference procedure for accounting. You can then maintain all remaining settings for the REA document category.

Figure 33: Activating the FI Update

You can only assign the reference procedure once, as this represents a unique identification for the REA postings in FI. The reference procedure is not fixed, as these can be created manually and assigned freely in REA versions prior to EhP4.

REA Master Data Maintenance

You can make the following settings as part of master data maintenance for the recycling partner. The FI Integration tab page on the detailed view for the document type allows you to control whether or not generating an accounting document is to be possible.

You can use the settings under "FI Integration Mode" to control whether a document category is to be generated in accounting and, if so, which one. In general, the REA document will be a vendor invoice, meaning it is a payable to the recycling partner (vendor).

You can choose between the following options:

No Transfer to FI -> No transfer is possible for the document category.

Vendor Invoice -> A vendor invoice is generated in accounting for the respective recycling partner.

Customer Credit Memo for R-Part. -> A customer credit memo is created for the customer number that was specified for the recycling partner.

Customer Credit Memo for Doc. -> A customer credit memo is created for the customer number that was entered as a selection criterion in the declaration screen.

In the settings available under Update Options, you can define the FI document type that you want to use as a differentiation criterion in accounting. You also have to specify a corresponding G/L account for accruals in this section to be used for offsetting.



© 2012 SAP AG 34

The advantage of assigning a document-specific provisional (accrual) account in this way is that you are then able to assign various accounts in SD and MM to the condition types created in REA. For example, this allows you to have different accrual accounts for packagings, electronic waste or batteries, and specify these here to be used as part of offsetting for specific partners or specific documents.

If you activate the option for posting a reversal to FI automatically, which is located in the area under "Reversal Processing", any REA document that is reversed is transferred to FI immediately upon reversal.

As this reversal posting actually involves a real reversal, the declaration being reversed must be transferred to FI first. If you fail to do this, the system displays an error message.

Figure 34: FI Settings for a Document Type for a Recycling Partner

REA Declarations

If the FI connection is activated and the document type settings have been entered correctly for the recycling partner, the functions described below are available and the corresponding pushbuttons are displayed.

To be able to execute the transfer, the user must have authorization to change REA documents as well as the corresponding authorizations needed in FI.

If collective declarations are used (consolidation), the user must decide whether he or she wants to transfer the respective document category of each individual declaration into FI or the document type of the collective declaration. The REA document type can be used to control this, otherwise the user is responsible for making sure that the correct REA document is transferred each time without leading to multiple postings.



© 2012 SAP AG 35

Transferring an REA Document to FI

After an REA document has been created, it can then be transferred to FI from within the declaration dialog.

The posting periods and the fiscal year are derived from the posting date of the declaration. The user can select the posting date when creating the declaration.

If it is not possible to transfer the document to FI due to the posting period (year-end closing) having already been closed for the posting date of an REA declaration, you must either reopen the posting period in question or reverse the REA declaration involved and then create a new one for the same settlement period. Alternatively, you can also make a new posting by indirectly using a collective declaration (consolidation) for the original document, providing the document type of this collective declaration has been set up for transfer to FI.

Before the accounting document is generated, the system checks to see if a valid accounting document already exists and if the REA document has already been reversed.

The tax code is copied from the REA document and can then be entered for the company code or REA price list.

Figure 35: Pushbutton for Transferring a Declaration to FI

After an accounting document has been generated successfully, it is then entered as a consecutive document in the "Reference" field of the REA declaration. Both the net amount and tax amount that were transferred are displayed in the "Amounts When Transferring to Accounting" field group, along with the currency. Choosing the "Accounting" pushbutton displays the accounting document that was assigned.



© 2012 SAP AG 36

Figure 36: General REA Document Display

Transferring declarations to FI is only possible for saved production runs that have a net value which is not zero.

Posting an REA Reversal Document

Reversed declarations are transferred to FI in exactly the same way as a normal declaration. Prerequisite is that the declaration being reversed has already been posted in FI, as transferring the cancelation declaration reverses the corresponding accounting document. If no accounting document exists, an error message is output and the transfer process is terminated.

If automatic transfer to FI is activated for reversals, the reversal accounting document is created immediately after the REA reversal document has been generated.



© 2012 SAP AG 37

FI Status of REA Documents

The FI Status column in the REA declaration display contains icons that show you the current status of the transfer.

For declarations that have a flag icon in this column, it means that no accounting document exists, however these can still be transferred to FI. After a transfer has been executed successfully, a lightning-bolt icon is displayed in this column. This applies to both declaration documents and their (possible) reversals.

If an icon is displayed in this column next to a declaration, it means that the declaration in question is blocked from being posted in FI because the net amount of the document is zero. No posting is supported at this point.

Figure 37: REA Declaration Overview

Navigating to accounting and transferring an REA document is only possible in the dialog for the document in question.

If no icon is displayed in the FI Status column for a particular REA document, this either means that transferring to FI is not supported for this particular REA document type, or it has already been reversed prior to the transfer.



© 2012 SAP AG 38

REA Accounting Documents

This section deals with the accounting documents that are generated for REA documents.

You can only generate or reverse REA accounting documents from within the REA application. It is not possible to do this manually in accounting. This approach generally applies for all reference transactions, such as for billing documents from SD, for instance.

Displaying an Accounting Document

The example featured below shows accounting document 6500000042 that has been created for REA document 280, which is also being used as a reference to the transaction in accounting. This reference is a transaction-based piece of information and is listed in all dependent accounting documents. The actual corresponding REA document number is listed as a reference document ID in the header record of the accounting document. You can display this overview by either branching from the declaration dialog or by calling transaction FB03.

Figure 38: REA Accounting Document

In the items section of this example, the Assignment column also indicates the reference. This field is used as a sorting criterion in accounting, and allows a user to select its contents depending on the G/L accounts required (see the Sort Key field in Figure 23).

You can navigate to a reversal document directly either from within the corresponding REA document or by double-clicking a reversal document number.



© 2012 SAP AG 39

Figure 39: Reversed REA Accounting Document

As a rule, the settlement period of the REA document is written into the document header text for informational purposes, as this may sometimes be different to the periodicity.

Figure 40: Document Header Display



© 2012 SAP AG 40

Calling an REA Document from Accounting

For auditing-related reasons and in order to give users a better overview, REA documents that are involved in the reference transaction are included in the navigation of the accounting document flow.

You can navigate from accounting to the REA declaration system directly by choosing "Original document" from the menu. The corresponding REA document is already preselected and can be displayed straight away.

Figure 41: Switching to REA Declaration System



© 2012 SAP AG 41

How to Use Accruals for REA

Introduction

You can also use conditions to create accruals, which you can then offset against REA declarations. You can assign a provisional (accrual) account in the pricing procedure for the respective condition type.

Process Description

The figure below shows an overview of the functions involved using billing documents as a basis for an REA declaration. This same flow can also be used for material documents.

Pricing

Conditiontype AAA

for accruals

G/L account

12345678

Conditiontype BBB

for accruals

Invoice

Conditiontype xxx

for accruals

G/L account

xxxxxxxx

Pricin

g P

roce

du

re

REA

Declaration

Pricing

Net Value

Tax

Pricin

g P

roce

du

re

Vendor

Account

G/L account

87654321

Tax

Account

Sales and Distribution

REA

ma

teria

l a

nd

qu

an

tity

flo

w

FI

Offse

t a

ga

inst a

ccru

als

Figure 42: Process Based on Billing Documents

G/L Accounts and Accruals in SD

REA can use the general ledger accounts (G/L accounts) that are used to reverse accruals. You can enter the G/L account in the document type of the recycling partner next to the FI document type. For more information about this procedure, see the document entitled HOWTO_FI_Connection_Vx.x.pdf.

Account Assignment

You can define the G/L accounts used for recycling fees and their corresponding accruals in account assignment in SD. After you have done this, these accounts can then be used as part of the pricing procedure.



© 2012 SAP AG 42

You can maintain G/L accounting in Customizing under the "Basic Functions" node in the hierarchy.

Figure 43: Menu Option for Assigning G/L Accounts

Figure 44: Access Sequence Used in Account Determination

Figure 45: Assigning G/L Accounts



© 2012 SAP AG 43

Pricing Procedure

You can assign account keys ZRE and ZRU to the corresponding condition types in the pricing procedure. These account keys are used to determine and post the accounts during account determination.

Figure 46: Maintaining a Pricing Procedure

Automatic Accruals Correction

You can use this function that is available as part of accruals correction to calculate accruals for a defined period at a later stage.

Background

The pricing information that is included in the condition records which are generated from within REA is obtained from the corresponding valid price lists and the values entered for an article / packaging, such as splitting. If any prices should change retrospectively, these are not considered for any accruals created from billing documents or material documents that have already been posted. To overcome this potential problem, you have the option of determining and posting any difference amounts at a later stage, however you can only do this for billing documents.

Technical limitations mean that it is only possible to calculate a potential difference amount for billing documents.

Functionality

After making the required settings in Customizing, you can trigger the accruals correction using a separate routine or automate it by updating the condition records. In general, during an accruals correction the system checks to see whether any price changes have occurred within the conditions for a particular period of time. If price changes have indeed occurred, all of the relevant documents are read for the period in question and the price is recalculated using the most current REA conditions. The value difference is then created according to the settings defined in Customizing along with a new document and a corresponding adjustment amount. As a rule, this generally involves a credit or debit memo, which is preceded by a corresponding request document. You can then perform a transfer to FI, either manually or automatically.

Customizing

You can maintain the settings for an accruals correction using the menu options described below.



© 2012 SAP AG 44

SD Customizing

The example in the figure below outlines the settings required for a condition type that is to be used for a correction document. In general, the most important points to note here are that the calculation type is 'B' and that no access sequence has been defined.

The difference amount is assigned as a fixed value without considering any other pricing criteria. This means that a more detailed access sequence is not required.



© 2012 SAP AG 45

Figure 47: Condition Type for an Adjustment Amount



© 2012 SAP AG 46

You can define the default settings for generating accruals corrections in SD under the menu option "Define and Assign Pricing Procedures".

Figure 48: Menu Option for Maintaining Procedures

The figure shows one example for settings defined for a pricing procedure. As the documents being generated are defined in REA Customizing uniquely, an access sequence is only used for the purpose of making an assignment for pricing in SD.

Figure 49: Maintaining a Pricing Procedure

Under Control data, you enter the condition type and the account key. It is important that you activate the indicator for manual maintenance, as the price (difference amount) is not transferred through pricing but through the interface directly when generating the document.



© 2012 SAP AG 47

Figure 50: Assigning a Condition Type and Account Key

The figure below shows how you can define a new document pricing procedure.

Figure 51: Defining a Document Pricing Procedure

The document pricing procedure is assigned to the respective document types for the order and billing documents.

Figure 52: Document Pricing Procedures for Sales Documents

Figure 53: Document Pricing Procedures for Billing Documents

A corresponding pricing procedure is assigned, depending on the sales area involved.



© 2012 SAP AG 48

Figure 54: Defining a Pricing Procedure

REA Customizing

Figure 55: IMG Menu Path for Maintaining an REA Accruals Correction

You can assign a condition type to a correction condition type under the menu option "Assign Condition Types for Automatic Accruals Correction".

Figure 56: Assigning a Condition Type to a Correction

The following section describes the document settings that are required for the adjustment posting. This is where you can assign the document types that you defined previously in SD Customizing.

The only mode option available is to Create Sales Documents. Depending on the result of the difference amount, you can generate a debit memo or credit memo with a chosen plus/minus sign depending on the general settings made in SD. The document type and billing document type used in the example have the same name.

If you set the "Sep.Doc.CondTyp" indicator, a separate sales document is generated as a correction document for each condition type / recycling partner.

You can use the options relating to the billing date to define the selection period of the periods used as a basis for the correction for the billing documents. The starting point is the date on which the condition record in question was changed.

These settings are also used to prefill fields for the program described in the next section.



© 2012 SAP AG 49

Figure 57: Settings for Posting Accruals Corrections

Key for definition/profile of the automatic adjustment of accruals after changes to conditions. Profiles for the automatic adjustment of accruals control the correction of accrual postings after REA article conditions have been changed, for example as a result of changes made to the article master data. You can specify different profiles to define different adjustment processes for different combinations of "company codes and recycling partners".



© 2012 SAP AG 50

Figure 58: Assigning a Condition Type to a Correction

Program for Analyzing and Adjusting Amounts

You can use the following program to perform a manual accruals correction or for analysis purposes. You can run this program from Customizing or by calling transaction J7LRKR0.

Here you select any change documents for the condition records – and therefore any price-relevant changes that have been made to the article – according to the selection criteria specified for the articles and the condition type. Furthermore, you can use the fields under "Billing Document Selection" to define selection criteria for the billing documents. Corresponding to the materials that have been preselected, the corresponding billing documents are then analyzed for the selection that you have made.

The last section on this screen enables you to control the document generation for the accruals correction. Only the "SD" mode for generating sales documents is available here.

For the options relating to the document flow, the possibility of creating separate documents for each condition type, and releasing to FI, you can select the default values specified in Customizing. The SD documents are created and posted automatically, providing the posting mode has been set to "B".

The log output can be split into three levels and written to a spool request if required.



© 2012 SAP AG 51

Figure 59: Analyzing and Posting Accruals Corrections



© 2012 SAP AG 52



© 2012 SAP AG 53

Copyright

© Copyright 2012 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Oracle Corporation.

JavaScript is a registered trademark of Oracle Corporation, used under license for technology invented and implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.