Finance and BW competence center

Allianz France (formerly AGF) had grown through many acquisitions across insurance, assistance, credit insurance and banking. Its SAP competence center delivered development, configuration and expertise to every business line, for all SAP systems in production and in development. On the financial side, several SAP systems covered real-estate leases, IT and office-equipment spend, cost accounting and the general ledger, and multi-GAAP consolidation for the German parent. An exchange layer (SAP XI) moved their data into SAP BW for decision reporting. The assignment added capacity to a team of five developers and a project manager for fixes and enhancements on FI, CO and BW.

The finance system landscape

Each night, data was extracted from the finance systems into buffer tables, written to flat files, passed through XI and loaded into BW by load routines.

How work flowed

1. Requests were logged in a ticketing tool linked to the project's document management. The project manager planned the work and assigned tickets.
2. I estimated each request with predefined effort by complexity and development type. For example, a simple ABAP report change was estimated at two days including unit tests. I adjusted it for complexity and sent it to the business for validation.
3. I wrote the detailed technical specification, using tracked changes so that whoever took the topic over could see every modification.
4. I developed in ABAP: mostly loads of accounting documents between systems, but also user exits, reports, interfaces, Dynpro screens and BW load routines.
5. Another analyst reviewed my code against project standards. I unit-tested it and delivered it to the functional teams for functional and integration testing.
6. I also reviewed colleagues' code with a standards checklist. I logged anomalies, sent blocking issues back for correction and re-checked them before approving.

Technical deep dive: object-oriented redesign of the accounting loads

The problem. Interfaces extracted the general-ledger and cost-accounting documents entered by each subsidiary every day. They transformed them, loaded them into buffer tables and wrote the flat files for XI and BW. The interfaces were redundant and procedural, and each subsidiary had its own rules. Every change rippled through all the dependent programs and functions, so regression risk was high, the code was hard to read and support got harder with each change.

The solution. During a quieter period of the project, I proposed and carried out a redesign of the load from the cost and general accounting system into BW:

• I grouped the interfaces and pooled the shared processing.
• I moved from procedural code to ABAP Objects. Each subsidiary became a class with its own attributes and methods, and common behavior was inherited from a parent class, so it was written once for all entities.
• Polymorphism handled the differences. For example, the AGF IART and Calypso subsidiaries were separate classes, and a single call to a common method transcoded their cost centers, each applying its own rules.
• I stopped the scope at the load into the buffer tables, so the rest of the chain (files → XI → BW) ran unchanged.

Testing. Volumes were large and the criteria many. I kept the old code and ran it in parallel with the new version. I built a comparison program that automatically checked that both produced identical buffer-table data, which let me complete all the necessary tests in a fairly short time.

Why. A full rewrite is risky and hard to justify on cost and regression. My bet was that time invested up front would save time later. Readability and reliability improved a lot, regression risk fell, and because the competence center received frequent change requests from every subsidiary, the redesign reduced the team's future development effort.

Production monitoring of the BW loads

Accountants posted documents every day and analyzed them in the source systems or in BW, by company and with drill-down. BW cubes gave the multidimensional views those volumes needed. Every night, accounting documents and cost-center, profit-center and other financial data were extracted and loaded with the previous day's data.

My daily routine:

1. Check the export into the buffer tables on the production machines.
2. Check transit through the XI interfaces.
3. Check the load into the BW InfoCubes. Some loads were automatic and some manual. BW loading ran as a multi-step process chain, with custom code in load routines (calculations, formatting, package splitting).
4. Compare volumes and integrity for each document type (vendor and customer invoices, credit and debit notes, payments, due dates), and raise or fix bugs in the ABAP load routines.
5. Send users a status report before the accountants' day started, with the status per flow and per system.

Difficulties and how they were solved: a failed load during pre-close

What happened. One day several loads failed, and fixing and reloading them took hours. My status table showed each flow as "OK" in green or "KO" in red. During pre-close, one user complained that he could not tell which loads were available, and the emails grew tense.

Root cause. I alerted my team and analyzed every step of the chain:

• Source extraction: database tables (SQL or SAP table display), extraction logs, and system logs for crashes.
• File creation and copy: I connected to the FTP servers to check whether the files were there.
• Target: the BW read, format and post steps.

The files had not been copied because the batch system user had lost its rights: a read/write permission parameter on the FTP servers had changed. I gathered error screenshots and raised a ticket to the Basis team.

Communication fix. I realized the user might not be able to tell the colors apart, and that "OK" and "KO" look alike. I restructured the report into two labeled sections, "Loads ready" and "Loads in error", updated the email template and asked colleagues to do the same, because it was clearer and more inclusive for everyone.

What I learned

• Object-oriented ABAP was still seen as an innovation then. I reused it later, for example for a Fiori cash-register mock-up for L'Oréal.
• The BW skills I built here came back on L'Oréal's BW DataSource work.
• Production monitoring, with clear and credible communication under close deadlines, is the core of every hypercare after a go-live.