Oil trading logistics and pipeline sales on SAP TSW

Total was implementing SAP worldwide for the sale and transport of oil. Accenture ran the whole project, with about 50 mostly functional consultants in Châtillon and the ABAP development teams offshore in India. Bulk purchases, sales and transport planning ran in SAP IS-Oil TSW (Traders' and Schedulers' Workbench), which sits on top of SD and MM. Member of the four-person 'bulk' team, which handled nominations: the TSW documents that plan bulk transport by tanker, train and other bulk means. This assignment marked the move from developer to techno-functional consultant and the start of a specialization in logistics.

The challenge

TSW manages the purchase, sale and transport of petroleum products through plans, contracts, nominations and tickets. Volumes and values in the bulk business are very large. A separate "market" team handled retail flows such as tank-truck deliveries to service stations.

My team lead gave me a complete project: integrating pipeline sales into the system. Selling through pipelines was new to the system and part of Total's future strategy, so the project was highly visible. It was also my first role as a functional analyst after my years as a developer. I had taken SAP's SCM600 sales-process course before starting, and I spent several days at Total's offices with a key user for knowledge transfer.

How TSW nominations work

Tickets record the physical loading of product into a container (ship, tank, truck, client-owned or not), and the actual measured volume drives billing. Contracts and documents carry Incoterms, most commonly CIF (the seller arranges and pays sea freight and insurance) and FOB (the seller delivers onto the ship and the buyer takes over from there).

Solution design: the pipeline-sales flow

Nominations already covered planning and transport, so most of the work was standard SD sales-flow configuration in the IMG.

1. Contract. A contract carries schedule lines with dates, quantities and prices. For example, a crude-oil contract between two European sites with deliveries every two weeks for a year.
2. Sales orders created automatically from the contract. I configured the contract and order schedule lines and the copy-control rules (contract → order), so that an order was generated every two weeks from the contract schedule.
3. Delivery. It records the actual date, the exact quantity and the means of transport (pipeline).
4. Invoice. It is created from the delivery through further copy-control rules I configured, priced with a pricing procedure I created specifically for pipeline sales.

I created new sales order types, delivery types and billing types and linked the order types to the pricing procedures I configured, so the right price determination ran. The largest impact was on pricing and payment schedules.

Pipeline sales also had to post accounting documents. I used the SD-to-FI integration that turns sales documents into accounting documents, and I configured FI substitution rules (replace one account with another based on criteria) so that pipeline sales posted to the right accounts. The accounting team sat on the same floor but outside my scope. I worked with them so they designed their part around my SD design, and the full solution went live.

My developer background helped me decide where configuration was enough and where custom ABAP was justified.

Difficulties and how they were solved: the substitution-rule incident

What happened. All substitution rules were attached to one single schema. When my change was transported, the whole schema went with it, including other teams' in-progress, untested changes. Soon after go-live, users found wrong G/L accounts on sales and purchase postings across every flow that generated accounting documents. The pipeline flows themselves were correct, because they had been tested. Other documents could land in the right account or the wrong one, and for accounting the impact was very serious.

What I did:

1. Alerted the business and stopped production operations while the issue was analyzed, then briefed the accounting experts. They quickly assessed the impact and built a plan to find and correct the wrong postings. Correcting accounting data was outside my role.
2. Restored the production substitution rules with SAP's cross-system comparison tools, which compare programs, configuration and table contents between systems. I used the pre-production system, refreshed every day with a copy of production from the day before, as the reference to compare against and restore the rules correctly.
3. Re-applied my pipeline changes on top of the production version and re-transported them, isolated from the other in-flight projects that had caused the errors.
4. While the FI/CO team spent a week correcting every affected account, I covered their hotline to free their time.

I felt responsible for the disruption. The incident changed how I have handled delivery quality ever since.

Working with the offshore development team

ABAP development was done offshore in India. I was the functional consultant in front of them. All documents, emails, calls and the system itself were in English, which made this my first international project where English was mandatory.

My process for each requirement:

1. The team lead assigned the requirement.
2. I met the business and key users, by phone or in person, to confirm my understanding.
3. I estimated functional analysis, development and testing. My lead validated the estimate and presented it to the client for cost review.
4. Once Total approved, I did the functional analysis and wrote the specification. I compared the need against standard SAP and existing solutions to reuse as much as possible and limit cost. I used flow diagrams (especially for interfaces), configuration points, table names and values.
5. I wrote test books covering every business case plus non-regression cases.
6. As a former developer, I added a second part with the algorithm and logic: variables, tables to create, functions and classes to use. The combined document, a detailed functional and technical specification (SFT), went into the project repository and to India.
7. During the build I answered the developers' questions. I had no development access, but I could view programs and debug to help them.

Test levels I owned or supported:

The client required documented proof of tests. Production releases were monthly, so a late development slipped by a full month. The offshore teams did not feel the client pressure directly, and the six-hour time difference, the language and cultural differences all had to be managed. Billing was on demand, so delays or defects could bring financial penalties.

The system landscape

What I learned

• Sales-flow configuration and pricing are the core of SD, and they became the base of my logistics specialization in later SD and intercompany work.
• Every production change can regress something else. Non-regression tests and documentation are not optional.
• Abandoned or unused changes must be removed from test systems, or someone unaware of them will eventually push them to production.
• Transport management and cross-system comparison became standard practice on every project I did afterwards.
• Writing specifications precise enough for a remote team, in English, and testing them exhaustively, was a skill I reused on every offshore collaboration that followed.