Environmental regulations differ throughout countries, leading environmental fee reporting to be very difficult. See how an SAP add-on — SAP Recycling Administration — works to keep your data consistent and in line with the different regulations.
Key Concept
Environmental fee reporting is required in many countries for packaging, batteries, and waste on electrical and electronic equipment (WEEE). Some countries have further special legal requirements to report on other substances and sold tonnage. Usually the manufacturer (in the consumer product industry) or the company bringing the goods on the market is responsible for the reporting. Fees are charged to cover the recycling cost for the goods or packaging that the end consumer either throws away or recycles. Those goods are marked according to the fee systems they are subject to: Printed symbols like a green dot (for packaging) or a crossed dustbin (for WEEE) indicate relevancy to one or more fee systems.
Legal requirements for environmental reporting have existed in European Union (EU) member states for the last decade and are making their way into other countries as well. In recent years, countries on other continents (such as Canada, South Korea, Australia, and some states in the US) published similar legal requirements. Usually the fee reporting underlies regular (annual) audits. Because legal requirements are published country by country, responsibilities in many companies are fragmented across departments, resulting in a low priority for environmental fee reporting. Some companies respond by establishing local reporting systems with minimal effort and are later afflicted with high unexpected data volume.
Many companies in the consumer product industry are subject to one or more of the following aspects:
- Various environmental fee reporting systems in one region or hub
- Different IT systems in place for packaging, battery, and waste on electrical equipment (WEEE)
- Performance issues because of growing packaging master databases
- Similar legal requirements from Asia and the US
- Mergers & Acquisitions and its related additional fee database volume causing extra complexity on legal compliant fee reporting
SAP Recycling Administration (REA) is an add-on to SAP R/3 4.5B systems up to SAP ERP Central Component (ECC) 6.0 to effectively treat these topics. I’ll explain some of the key features of REA and how you can use it bolster your environmental reporting processes.
You can find REA in the system by following menu path Logistics > Sales and Distribution > Billing > Recycling Administration (Figure 1).
REA uses the available R/3 standard material master data and contains its own packaging master data. Figure 2 shows an example with a camera packaging consisting of 27 grams of paper or carton. The SAP material number is the technical prerequisite to create a packaging or article with the same number in REA. An article in REA is a finished good being placed on the market that is subject to any type of fee reporting.
Figure 1
REA menu linked to the Billing menu tree in R/3
Figure 2
Packaging maintenance providing the link between the finished good, its packagings, and recycling partners
One type of master data is REA internal packaging master data, which includes:
- Packaging fractions such as paper, glass, metal, or battery types
- Their weights
Another type of REA master data is a recycling partner. This represents an organization to which companies report their recycling tonnage or that recycles the tonnage. Those partners also have REA-specific master data such as:
- Fee type (e.g., item- or weight- dependent fee)
- Price lists
- Company codes
- Special reporting rules (e.g., the declaration needs to show the tonnage and the number of sold finished goods)
A third type of master data is finished good-related data such as:
- Relationships to recycling partners and packaging (Figure 3)
- Special discounts (e.g., for bulk packaging) because of certain physical or chemical properties
- Their packaging level (e.g., consumer or transport packaging)
Figure 3
Article maintenance providing the link between the finished good, its packaging, and recycling partners
Figure 3 shows the basic article data maintenance regarding company codes, time frames of validity, assigned packaging, and their level. Column Lv shows the consumer packaging level — in the example, the 1 indicates it is the primary packaging level — for the sample camera packaging.
For legal compliant reporting, REA combines the REA master data (in particular, the weights) with the sold quantities from the billing documents to the total tonnage for a reporting period (e.g., a month or year) as shown in Figure 4. You need to consider the physical flow of the goods for reporting because returns decrease the fee.
Figure 4
Sample month-end report based on recycling partner-specific template
Legal compliance reporting is key for REA: It provides partner-specific rules and documents to reflect country- specific requirements. SAP provides those rules in the REA standard package. You usually don’t need to modify them because annual Support Packages reflect recent changes to legal documents. As a benefit, custom ABAP developments are not required even for companies that are subject to several fees. REA provides recycling partner-specific templates to print reports without further modification. The standard package provides complex documents with consecutive document types as attachments.
Apart from the legal reporting schemes, a new challenge for manufacturers appears on the horizon and is something that REA can address. Recently, larger retailers encouraged their manufacturers to reduce the “footprint” on the environment caused by packaging. The footprint measures the packaging tonnage exchanged between both parties and some related packaging attributes. REA may be a suitable system to report the shipped packaging tonnage to verify if the company achieved packaging optimizations.
In this section, I’ll go into detail about interaction and integration with the Sales and Distribution (SD), FI, and Materials Management (MM) modules in R/3 (Figure 5).
Figure 5
Integration and interaction of REA with the standard R/3 SD, FI, and MM modules
- REA uses available customer master data including customer hierarchies and partner functions for reporting
- R/3 billing documents are the transactional basis on which to calculate the relevant fee tonnage. REA can analyze cross-border billing documents for reporting on imports or exports.
- SD condition types:
- Condition types are the standard R/3 link REA uses to write financial cost data back to FI. Traditionally this was used because the initial releases of REA built accruals on expected fees per country. During billing document creation, the system creates SD condition types for fee reporting in the background on an accrual account to get an estimate on monthly fees. SAP extended this functionality in its recent Support Package (January 2008): REA documents created by the periodical reporting runs create credit memos to cancel those accruals or start an FI document flow.
- REA customizing uses the standard and flexible SD condition type functionalities to build its own logic for price calculations
- REA reads the units of measure (UoM) data, weights, volumes, and their units from the MM module. The system copies weights and volumes to its own master data structures. This sounds like double data storage, but in fact it isn’t: What is agreed as the standard net weight in the consumer goods industry is not equal to what some legal documents understand as a net weight. As a result, the best practice is to use the material master net weight, but modify it wherever required. REA provides user exits to calculate weights according to legal documents and available MM data. As opportunities for further REA improvements, some companies ask for additional links to more fields from the material master, such as the material group. Their vision is to minimize REA data maintenance by using properties of the material master attributes to create articles and packaging. This is usually created by some custom code.
- You can use available R/3 bills of materials (BOMs) to automatically link packaging and their weights to the finished goods, meaning the REA articles. Again, when the user imports the BOM to create the article to packaging links, the system copies the BOM details to the REA data structures. However, later BOM changes do not automatically reflect in the article data and may need manual interaction again.
Because REA is an add-on to a standard R/3 package, after licensing you need to download it from the SAP Marketplace with the respective installation guidelines. As a prerequisite to start any customizing or recycling partner setups, the implementation team needs to clarify the involved countries, company codes, fee types, and packaging fractions on which to report. In the REA area, SAP follows a less stringent differentiation between recycling partner master data and REA customizing data. As a consequence the recycling partner master data is usually set up in parallel with customizing activities. REA customizing mainly considers these areas:
- General settings. The general settings include company codes for reporting and data maintenance, involved transactional and customer master data tables for tonnage reporting, and document number ranges.
- Packaging settings. These settings include packaging levels and the mapping of REA internal fractions to recycling partner fractions.
- Condition type settings. These include tonnage splitting between partners and discounts for special fee calculation cases.
- Data filter settings. In general, these are inclusion or exclusion logic for transactional and master data such as:
- Material types for packaging, articles, and BOMs
- Billing document properties (billing or item types)
Other customizing transactions that address the needs of some company- specific requirements are available. The parallel setup of the recycling partner master involves the settings of all earlier mentioned partner- specific master data.
Two types of maintenance are integral to your post-implementation success.
Minimizing cutover master data maintenance. As in many other SAP areas, master data accuracy, completeness, and available upload functionalities are key project success factors. Normalizing various local databases is usually a first step for the master data conversion. This includes converting partner-specific recycling data to a neutral format based on physical or chemical properties, such as the chemical system of a battery or a packaging fraction (e.g., paper or glass). You can also add other recycling partner-specific attributes as additional fields in scope for the conversion.
The normalization allows you to convert the data with a standard REA inbound program. This program may upload the packaging data, their recycling partners and articles, and any relationship between these types of master data. Its effective use is vital in decreasing the cutover efforts for the master data setup, because the complexity of the REA master data structures is quite high to support any type of fee reporting. As an additional unwanted complexity, the recycling partner-specific data in one country may depend on the partner data in another country. Thorough planning of the master data migration strategy from your local databases to REA is required to minimize the initial data maintenance after the cutover. With increasing project size, the effort for the master data conversion increases disproportionately and may require approximately 30%-50% of the total implementation cost on the IT side. Some companies have more than 40 recycling partners in production; a typical larger project may cover 15 or more additional partners to achieve certain economies of scale on implementation costs.
Ongoing data maintenance. REA allows various data maintenance setups, such as central, local, and hub-based data maintenance concepts. However, SAP recommends and most companies prefer a centralized data maintenance concept to minimize data errors by infrequent users who are less familiar with the REA transaction screens.
Dietmar Giljohann
Dietmar Giljohann is an SAP business systems analyst in the consumer goods industry. He has a mechanical engineering diploma and a Ph.D. in computational acoustics. His expertise areas are SAP R/3 SD, PP, PS, MM, REA, EDI, and SAP NetWeaver. He is a speaker for the German and the European REA user groups.
You may contact the author at dietmar.giljohann@gmx.de.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
