US rollout and intercompany SO-to-PO flow

Longchamp, the French luxury leather-goods house, runs SAP in France for logistics, sales and stock transfers between warehouses and stores, with all IT architecture decisions made in Paris. The US subsidiary, with 17 stores, one warehouse in New Jersey and much of its distribution through department stores and wholesale accounts, was getting SAP through a rollout of the French logistics solution. Joined a team of four consultants and a project manager shortly before the planned June 2019 go-live, because developments were late, in particular the intercompany sales flows between the French and US entities. France kept strategic control of US stock: it needed exact visibility and created the orders and transfers that replenish the US.

The challenge

Intercompany flows record stock movements between entities and make sure each entity declares its own gains and losses; here each entity also had its own tax and customs declarations, since they were in different countries.

The business need was for French teams to trigger goods movements to the US: a planning program running at night analyses stock levels and creates sales proposals. If it finds low stock on two handbag references in the US, it creates a sales order from Longchamp France selling them to Longchamp USA. That sale then triggers the physical shipment by sea or air and the goods receipt at the New Jersey warehouse. On the US side, the same transaction must exist as a purchase order.

Alternatives considered

I first looked at standard SAP intercompany processing and set it aside for two reasons:

I needed a design that left France unchanged and still created the goods movements between the two entities.

Solution design

I built a custom intercompany flow that uses standard SAP objects wherever possible:

1. A sales order from France to the US is saved, typically from a sales proposal generated by the planning run and validated by a user.
2. SD user exits on sales-order save host my code, which checks that the sale is to the US entity. Every other sale is left untouched.
3. The code reads the sales document structures and maps their fields into the purchasing document structures. SD and MM organize their data in a similar way, which made the mapping straightforward.
4. The purchase order is created through the standard purchasing BAPI, which creates the document with all its dependent tables. I avoided direct database inserts, which are strongly discouraged in SAP.
5. The US then receives the goods against the purchase order with inbound deliveries at the Robbinsville warehouse.

Difficulties and how they were solved

• AFS-specific fields. Longchamp used SAP AFS (Apparel and Footwear Solution), an extension of the sales module for fashion products that I learned on the project from colleagues and my own research. Some AFS fields were not filled by the standard BAPI, so I added targeted handling to complete them after creation.
• Joining late. I arrived after the design workshops, close to go-live, and took over topics others could not deliver. I reused the French configuration for the US (transfer types, PO and SO types, warehouse configuration) and adapted it rather than redesigning.
• Development capacity. Each consultant owned one module (SD, MM or WM). Development was meant to go to VISEO's offshore ABAP center, but I had development skills the others lacked, so I coded the development parts of all three modules myself and caught up the lost time.

Result

A purchase order is now created directly whenever a France-to-US sales order is created. Longchamp's planning program can launch replenishments from the French warehouses to the US warehouse automatically, and users only validate the generated sales documents instead of keying them. Coordination between the two entities, previously by email and phone, became smoother and faster.

Project organization

I worked on site in the warehouse, where the small project team had its offices next to the end users. Walking the warehouse floor to see issues and fix them was very formative. Besides the intercompany flow, I tested goods receipt, picking, packing and shipping, ran the allocation run and wave-pick transfer orders, configured output types and form printing, and monitored IDocs, then took over user support and training after go-live.

What I learned

Most VISEO clients are French groups with US subsidiaries, so intercompany is a recurring topic. This project taught me to build a clean non-standard flow when standard SAP does not fit the business, while keeping standard objects (user exits, BAPIs) and isolating the change so the parent company's system is not affected.