In-SAP retail store and cash-register program

L'Oréal USA acquired SalonCentric, a distributor of professional hair products with several warehouses and about 600 stores across the United States. To keep data in one place, the store and cash-register application was run directly inside L'Oréal's existing SAP system rather than in a separate point-of-sale package. Brought in to speed up developments that the existing team could not deliver on time: the store application, store replenishment from the warehouses and the successive regional go-lives. Continued through the program's later phases, which followed further L'Oréal acquisitions, and for new SAP tools.

The challenge

SAP's standard SD, MM, WM and FI/CO modules, which L'Oréal USA already ran, had no store or point-of-sale functions. L'Oréal had bought a retail add-on built by another SAP services company and installed it inside SAP; after installation, VISEO owned all changes to it. Store- and brand-specific needs and missing features had to be added in SAP, mostly in SD. Running the tills inside SAP avoided building interfaces and let stores reuse the existing product and price master data.

When I arrived, many developments were in flight and the delivery dates were out of reach for the existing team. The rollout covered about 600 stores. The first version carried all the store basics, and then a go-live came roughly every six months, each one covering a region of about 100 stores plus the warehouse or warehouses supplying them.

The store application

I worked as a developer on feasibility studies, technical design, development and testing for the cash-register application, and also on a call-center application used to take customer calls and phone orders.

The order-entry chain in the store ran:

1. Customer search
2. Scan the goods
3. Summary screen
4. Payment at the till

I worked on every step. Most of the changes were to the user interface: buttons, pop-ups for error messages and new screens. The screens talked to the store peripherals (barcode scanner, cash drawer, receipt printer and customer-facing pole display) through Java programs that bridged the devices and SAP.

The delivered add-on was very heavy to use. I took an active part in the graphical redesign, removing buttons and screens that store staff did not need so they saw only what their task required. I also added an advanced customer search that works on several criteria and does not need the full name.

Some of the ABAP reports I built were made reachable from the store application, so store teams could follow stock and real-time sales for one or several stores. Those reports had to respect the product hierarchy, which runs from the broadest level to the most precise (for example: luxury, women, professional product, shampoo, brand, shade).

Technical deep dive: choosing the right product version at scan time

The problem. At L'Oréal a SKU is a version of a product, while the UPC/EAN identifies the product itself, so one barcode can map to several SKUs. Versions differ by label, packaging color or small formula changes required by country regulations. Store barcodes were at UPC/EAN level, so the system could not know which version had been scanned. In retail you must be able to sell what the customer is holding even if system stock is zero, so negative stock was allowed. The standard behavior took the first SKU for the scanned UPC, which drove that version negative even when another version still had stock.

How scanning works. Scanned items appear in a table on the screen (code, type, description, price). The scanner emulates keyboard input followed by Enter, which fires the screen's input-processing event in ABAP. I put the logic in that event of the Dynpro screen.

The logic I designed:

1. Read the UPC of the scanned product.
2. Use SQL plus standard SAP functions to fetch every version linked to that UPC, with its stock level.
3. Sort the versions by ascending stock and pick the first one that is not at zero.
4. Display that version in place of the default one.

It runs in the background and is invisible to the cashier.

Why it mattered. Negative stocks surfaced in reports that teams then had to fix, and stores ran physical inventories to correct them, which costs time and staff. With stock handled more robustly, the business had less need to run those inventories. Because the algorithm consumes the lowest-stock versions first, it also cleared out old, unused product versions, which gave a cleaner database and clearer stock reports.

Finance and BI

Beyond the store screens, the program included finance implementations and the BW side. I was team lead for the SD, FI and BW DataSource work: enhancing the logistics DataSources, supporting the extractors that fed the BI layer built on Informatica and MSBI, and clearing BI delta queues when loads backed up. Later, report performance work moved onto SAP HANA, which I describe in the separate HANA sidecar assignment.

Project organization

The project floor in Berkeley Heights was organized by domain: sales, purchasing, finance, integration and BI. I joined the ABAP team, which grew to up to 10 developers including an offshore team. As technical lead I combined hands-on development with:

• requirements analysis and effort estimates;
• quotations, delivery scheduling, planning, budget and resource management;
• recruiting subcontractors and approving their timesheets;
• task follow-up and accountability for deliveries;
• steering-committee support;
• SAP upgrade cycles (workshops, configuration adjustments, tests, support).

After the SalonCentric rollout, L'Oréal kept acquiring brands to integrate, and projects designed in France for the group core system were also deployed in the US subsidiary. The program therefore ran in successive phases linked to those acquisitions, and I supported the application and the new phases.

Separately, I built a mock-up of a cash-register management application as part of a feasibility study of SAP Fiori, developed entirely with object-oriented ABAP and a modern user experience.

What I learned

This was where my SD specialization moved into retail. I learned to design screens around real store situations, such as a customer holding a product the system thinks is out of stock or a cashier who needs one click instead of three. I also learned to fix go-live issues quickly while a new region of stores depends on you. Retail came back later in my career on Cegid-based store projects. Leading mixed on-site and offshore teams here also prepared me for the project-management roles that followed.