SPRO Deep Dive: Customizing Transport Requests, Project IMGs & Best Practices in SAP S/4HANA | Part 29 | FreeLearning365

 

SPRO Deep Dive: Customizing Transport Requests, Project IMGs & Best Practices

Day 14 of the S/4HANA Functional Consultant Track – A 20,000+ Word Hands-On Tutorial

By @FreeLearning365 and Tech Partner @techbook24

Introduction: The Silent Killers of a Live SAP System

Imagine this: It’s Friday evening. The business just signed off on a critical change — a new sales organisation that must go live Monday morning. You log in to the Development system, sprint through SPRO, save your configuration, and head home, confident that your transport request will sail through. Monday 8:00 AM, users can’t post sales orders. The transport is stuck. Panic grips the floor. The root cause? A tiny misstep in how the customising transport request was assigned, combined with a client landscape that no one had diagrammed since the original implementation.

Today, I will take you into the beating heart of SAP configuration management. We will go far beyond memorising SPRO paths. You are going to build a mental model that separates good consultants from great ones. This isn’t a theoretical overview. You will work through a real-life scenario at our virtual company TechBook24, following a functional consultant named Priya as she configures the sales organisation, manages transport requests, avoids a catastrophic Production mistake, and sets up the Transport Management System from scratch. Every screen, every transaction code, every warning is grounded in reality. By the end, you’ll know exactly what to do — and what never to do.

We will cover:

• SPRO structure: Enterprise IMG vs Project IMG – with scenario-based decision making
• Customising transport requests: automatic vs manual assignment, deep technical behaviour
• Client concept: client 000, 001, custom clients, and the landscape best practices that prevent meltdowns
• Transport Management System (TMS): routes, layers, import sequences fully configured and explained
• Change and Transport Organizer (SE09/SE10) – release, export, troubleshooting
• Dangerous SPRO changes – the forbidden screens and what to do instead
• Battle-tested best practices, pros & cons, real alternatives

Let’s dive in. No fluff, just the hard-earned wisdom you need.

1. The Two Faces of IMG: Enterprise IMG vs Project IMG

1.1 What Is the IMG Exactly?

The Implementation Guide (IMG) is SAP’s central configuration cockpit. Every customising setting – from defining company codes to assigning chart of accounts – is accessed through the IMG tree. But there is a fundamental split that surprises many juniors: the IMG comes in two flavours: Enterprise IMG (also called Reference IMG) and Project IMG.

When you first open transaction SPRO, you land on the Enterprise IMG by default. It contains every configuration activity that SAP delivers, regardless of whether your organisation uses those processes. In an S/4HANA 2023 system, the Enterprise IMG has thousands of nodes. It is the complete library.

Project IMG is a filtered subset created specifically for an implementation project. You use transaction SPRO_ADMIN (or the Project Management node inside SPRO) to define a project, select the countries, application components, and generate a tailored IMG that only shows relevant activities. Why is this critical? Because navigating a full Enterprise IMG is like finding a needle in a haystack when you only need Financial Accounting and Sales. More importantly, a Project IMG can enforce a controlled sequence and link directly to the project’s transport request strategy.

1.2 TechBook24 Scenario: Priya Creates a Project IMG

TechBook24 is a mid-sized online retailer implementing SAP S/4HANA on-premise (or using a private cloud with full SPRO access). The project scope covers Finance (FI), Controlling (CO), Sales (SD), and Materials Management (MM). Priya, the lead functional consultant, decides to set up a Project IMG to keep the team aligned and to generate a visual blueprint for configuration progress.

Step-by-step walkthrough:

1. Log on to the Development client (client 200 in TechBook24’s landscape).
2. Execute transaction SPRO_ADMIN (or in SPRO, click “Project Management”).
3. Choose “Create Project”. A dialogue box appears. Priya enters:
   • Project: ZTECH24_IMPL
   • Project Name: TechBook24 Global Template Rollout
   • Responsible: PRIYA_FUNC
4. Next, she selects the SAP components required. She ticks “FI”, “CO”, “SD”, “MM”. She also picks the countries “US”, “DE”, “IN” to load relevant country-specific settings.
5. The system then generates a Project IMG. She can now view it by opening SPRO and selecting the project under the “Project IMG” tab.

Screenshot Description: SPRO_ADMIN screen showing the generated project ZTECH24_IMPL with a hierarchical tree. The structure now only contains activities belonging to the selected modules. Green status lights indicate configurable nodes.

Now, instead of scrolling past thousands of irrelevant nodes, Priya and her team work within a curated list. This drastically reduces the risk of accidentally configuring the wrong area and makes status tracking easy – each activity can be marked as “in process”, “completed”, or “not relevant”.

1.3 Enterprise IMG – When and Why You Still Need It

Don’t discard the Enterprise IMG. You’ll use it in these situations:

• Research and exploration: You need to find a setting that wasn’t included in your project IMG because the scope changed. For instance, after go-live, the business requests EDI settings. Instead of re-generating the Project IMG every time, you can quickly drill into the Enterprise IMG.
• Support and maintenance: After go-live, many organisations switch to the Reference IMG for daily customising because it’s the easiest way to reach any node without project overhead.
• Audit traceability: Some auditors prefer screenshots from the Enterprise IMG because it shows the full SAP standard path, ensuring no custom shortcuts were taken.

Pros and Cons:

• Enterprise IMG – Pros: Complete, always up to date, no setup. Cons: Overwhelming, easy to configure in wrong area, no built-in project status tracking.
• Project IMG – Pros: Focused, trackable, can be linked to transport requests and documentation. Cons: Needs maintenance, can miss activities if scope changes, requires regeneration when new countries/components are added.

2. Customising Transport Requests: Automatic vs Manual Assignment – The Devil in the Details

2.1 Why Every Click in SPRO Creates a Transport Entry

Whenever you perform a customising activity that is “client-specific” or “cross-client” depending on the object, SAP records the change in a customising request (if automatic recording is on) or demands that you assign a request. The transport request becomes the container that moves your configuration from Development to Quality and finally to Production. Mismanage this, and configurations end up in the wrong order, get overwritten, or never reach Production.

The key distinction: Customising tasks belong to a Customising request. Multiple tasks can exist under a single request (e.g., one request per functional area release). A task is usually assigned to a single user; the request can be owned by the project lead.

2.2 Automatic Assignment – The Default Trap

When you first enter a customising activity and start changing data, SAP can automatically assign the change to an existing modifiable customising request or create a new one. How? The system checks the Transport Organizer user settings. By default, automatic assignment is active. When you save, a pop-up may show the request number, and you confirm. Many consultants simply press Enter without reading the request text, leading to a mess of unrelated changes grouped in one request or changes assigned to a request that has already been released.

Real example: Priya was configuring the sales document type OR in the Development client. She had previously created a request DEVK900001 for company code settings. When she saved the sales document changes, automatic assignment put them into DEVK900001 because it was still modifiable. The transport then contained both chart of accounts assignments and sales order types. Later, the technical team tried to import only sales configuration into QAS, causing partial transport headaches. Lesson: never rely on automatic assignment without scrutinising the request.

2.3 Manual Assignment – Professional Control

Inside transaction SE10 (or SE09), you can pre-create a customising request. Priya now creates a new request:

1. Transaction SE10 → Select “Customizing Request” → Create.
2. Enter meaningful short description: “TechBook24 Sales Org Structure & Document Types - Phase 1”.
3. Specify the target (the standard customising request goes through the normal transport layer).
4. Now, before configuring, Priya goes to SPRO and uses menu “Environment → Transport Organizer” to check her default request assignment. She manually sets the newly created request as the default for her user.
5. She performs the configuration. The system automatically records changes to that specific request without prompting.

The difference? She maintains clean separation: one request for sales org structures, another for pricing. When a partial release is needed, she can release only the sales request without affecting other work in progress.

Screenshot Description: SPRO’s Environment menu showing “Set Customizing Request” dialog with the option “Manual” and a field for request number.

2.4 The Technical Underpinnings: Tables E070 and E071

For the curious: Every customising change writes an entry into table E071 (object list) and the request header is in E070. When automatic assignment is active, the system simply takes the user’s last modifiable request of the appropriate type. If none exists, it creates a new one with a generated number. Manual assignment prevents this blind piggybacking.

Pros and Cons:

• Automatic assignment – Pros: Fast, requires no pre-planning. Cons: Uncontrolled grouping, high risk of cross-contamination, audit non-compliance, impossible to selectively release.
• Manual assignment – Pros: Granular control, clean audit trail, easier troubleshooting, supports agile partial deployments. Cons: Requires discipline, might forget to create a request and be forced to redo the configuration.

Best Practice: Always create project-specific transport request naming conventions. For instance: T24K_SD_01 for first sales transport. Instruct all team members to use manual assignment with pre-defined request pools. Regularly run a report to list orphaned tasks (tasks not in any request) using SE09’s search functionality.

3. Client Concept: 000, 001, Custom Clients & the Landscape Blueprint

3.1 The Three Standard Clients Everyone Must Understand

• Client 000: SAP’s reference client. Do not configure here! It holds the SAP standard customising and control data. In a fresh installation, client 000 is your “pure” copy of the SAP golden image. It is used for initial client copy operations and as a reference for comparing changes. Never assign transport requests in client 000.
• Client 001: Usually a copy of 000 used as a sample/test client. Many implementations delete or ignore 001 after setting up their own clients. It can serve as a quick training sandbox but should not be part of the project transport landscape.
• Custom clients: You define clients like 100 (Sandbox), 200 (Development), 300 (Quality Assurance), 400 (Production). These are the workhorses.

3.2 TechBook24’s Landscape Design

Client	Role	Transport Layer	Purpose
100	Sandbox	No transport connection	Ad-hoc testing, prototype config
200	Development (DEV)	DEV	Source of all configuration transports
300	Quality Assurance (QAS)	QA	Integration testing, user acceptance
400	Production (PRD)	PROD	Live business operations

Critical Rule: All customising changes originate in client 200. Sandbox 100 has no transport routes; you can play freely without ever exporting a transport accidentally. For training, another client 500 could exist but it must be on a non-transport path.

Now, the client concept extends beyond numbers: it includes client settings like logical system, client role (Customizing, Production, etc.), and most importantly, whether the client is modifiable for customising. In client 200, you must allow changes. In client 400, you must set client to “Not Modifiable” using SCC4, and NEVER open it for direct SPRO changes.

3.3 Client Copy Methods: SCC1 vs SCC8 vs Client Export

When Priya wants to refresh QAS with production data, she doesn’t transport configuration. She uses client copy tools. SCC8 performs a complete client export/import across servers. SCC1 can copy individual customising tables between clients in the same system (e.g., copy configuration from 100 to 200 for a specific table). This is handy when you want to bring over a configuration prototype without transport routes. However, misuse of SCC1 can bypass the transport system completely – a dangerous act if not governed.

Real-life horror story: A consultant used SCC1 to copy company code configuration from Sandbox to Production directly, skipping the entire transport workflow. The result? The Production client got a half-baked configuration with inconsistent number ranges because the copy missed dependent tables. The business couldn’t post invoices for two days. Lesson: SCC1 is for emergency patches under strict change control, never for standard configuration propagation.

Best Practice: Define a landscape document showing all clients, their roles, transport routes, and who has authorisation to open/close clients. This document becomes the bible for the Basis and functional teams. In TechBook24, Priya maintains a visual diagram using draw.io, which is reviewed at every release.

4. Transport Management System (TMS): Routes, Layers, and Import Sequences

4.1 Configuring TMS from Scratch – Priya’s Walkthrough

TMS is the railway system of your SAP landscape. Without it, no transport can move. It must be configured once (by Basis or an authorised consultant) and then maintained. Priya, though a functional consultant, understands TMS deeply because she needs to know why her transport is stuck in import queue.

Step 1: Logon to the Transport Domain Controller (usually the DEV system or a dedicated transport host). Execute STMS → Overview → Systems. You will see all SAP systems in the landscape. If TechBook24’s QAS system is missing, go to the QAS system, run STMS → Other configuration → Include system in transport domain.

Step 2: Define Transport Routes In STMS → Overview → Transport Routes, Priya creates a consolidation route from DEV (client 200) to QAS (client 300) and a delivery route from QAS to PRD (client 400). She uses transport layers: SAP for standard objects, and ZDEV for custom developments. For customising, everything flows via the SAP customising layer.

Step 3: Configure Import Queues Each system has an import queue. When a transport is released in DEV, it appears in the QAS import queue. Priya schedules an import job or manually triggers import via STMS → Import Overview in the QAS system. The import sequence matters: transports must be imported in the order of creation to avoid object inconsistencies. The system enforces this unless you override with caution.

4.2 The Real Import Sequence – A Day in the Life

Let’s watch a transport DEVK900005 (Sales org) travel:

1. DEV: Priya releases the request in SE10. TMS exports the data file to the transport directory /usr/sap/trans. Two files are created: K900005.DEV (data) and K900005.DEV (cofile).
2. QAS: The transport daemon detects the new files and adds them to the QAS import buffer. The import queue shows the request in status “Ready”. Priya’s Basis colleague triggers the import (or an automated background job). After successful import, return code 0, the configuration is in QAS client 300.
3. Testing: Business users test the new sales organisation in QAS. No issues. Sign-off given.
4. PRD: After final approval, the same transport is moved to PRD import queue (via delivery route). Imported into client 400 during a change window. The sales org is live.

Common pitfalls: If someone imported DEVK900006 before DEVK900005 (sequence error), objects may activate with missing dependencies. TMS usually prevents this via sequence check, but if you bypass it, you get inconsistencies like a sales area without an assigned sales organisation. Always respect the queue order.

4.3 Transport Layers and Their Meaning

• DEV Layer: All changes from development systems are collected here. Standard customising uses layer SAP, custom ABAP uses a Z-layer.
• QA Layer: Configured to accept transports only from DEV. No changes should originate in QA unless it’s an emergency fix (then a return transport must be created and its risks assessed).
• PROD Layer: Usually set as “consolidation target” for nothing except emergency corrections. Changing this can open a backdoor.

Pro tip: In the STMS → Import Overview, use the “Transport Proposals” function to simulate the effect of multiple transport imports. This avoids broken sequences.

5. Change and Transport Organizer (SE09/SE10) – Release & Export Mastery

5.1 SE10 – The Control Center

Transaction SE10 is where transport requests are created, viewed, and released. SE09 is the extended view for all request types. Priya uses SE10 daily.

Key actions:

• Create request: Ensure the correct type (Customizing, Workbench, etc.). Customising request for IMG changes.
• Include objects: Sometimes a manual include of a table or view is needed if the automatic recording failed. In SE10, double-click the request, then “Request Object List” → “Include Objects”. Priya includes table T001 (Company Codes) if it wasn’t captured automatically.
• Release task first, then request: The hierarchy is Task → Request. The owner of a task must release it before the request owner can release the entire transport. If Priya created tasks under her own request, she releases each task, then the request.
• Check for errors: Before release, run “Check” in SE10. It validates object consistency, missing texts, and potential conflicts.

5.2 The Export Process – Behind the Click

When you click the release truck icon, the system does several things in sequence:

1. Adds the object list to the transport cofile.
2. Exports the customising table entries or view cluster changes to the transport data file.
3. Marks the request as released (no further changes possible).
4. Triggers the transport daemon to distribute the files to configured target systems.
5. Logs the export in the transport log.

If the export fails (e.g., no space in /usr/sap/trans), the request remains in “Release started” or “Error”. Never leave it hanging — the object lock might block further configuration. The remedy: check the transport log via SE09 → Goto → Transport logs, fix the issue (often disc space), and repeat the release.

5.3 The Infamous “Local $TMP” Request

Customising changes can be recorded in a local transport ($TMP) if the client is set to “No transport” or the user’s default is local. A $TMP request will never leave the system. It’s a common gotcha: consultant configures for hours, everything saved to $TMP, and when they try to move to QAS, there’s nothing to release. To avoid this, always verify in SPRO (bottom bar) that a proper customising request number appears, not $TMP. In TechBook24’s DEV client 200, the system settings enforce automatic assignment to real transports; local transports are only allowed in Sandbox client 100.

6. Dangerous SPRO Changes – What You Must Never Do in Production

6.1 The Forbidden List (with Real Consequences)

Over the years, I’ve seen consultants, including experienced ones, make devastating mistakes. Here is the list you should engrave in your mind. These are all activities that appear in SPRO but must NEVER be performed directly in a live Production client:

• Number Range Maintenance (transaction SNRO / SPRO): Changing the “current number” or number range status directly in Production can cause duplicate invoice numbers, gaps that violate tax regulations, or even database deadlocks. Always transport number range intervals with proper transport and use the “transport” icon in SNRO to capture the setting, then test in QAS.
• Deleting Customizing Entries: Deleting a company code, sales org, or plant without archiving and dependent cleanup can break all transactional data. Use the IMG’s “Delete” functions with extreme caution; many objects allow only transport of a deletion flag, not a direct delete.
• Changing Currency Codes or Exchange Rate Types: Changing the currency of a company code after postings leads to inconsistency. The only safe way is to carefully plan a conversion project with technical tools. Never do this via SPRO in Production.
• Activating or Deactivating Business Functions (SFW5): Activating a business function permanently changes the system’s data dictionary and can trigger irreversible data conversions. Always do this first in a sandbox, then DEV, then full regression test.
• Client-Dependent Settings in the Client Table (SCC4): Modifying client roles, logical system, or changeability in Production without a rollback plan. An accidental “Changes without automatic recording” instead of “Not modifiable” invites direct customising in Production.

6.2 A Cautionary Tale – The Direct Number Range Fix

At a previous project, a finance user reported that the system could not create new asset numbers because the internal number range was exhausted. A junior consultant, aiming to be helpful, executed SNRO directly in Production, extended the number range to the next block, and saved. No transport. Two days later, the Dev system had a different number range configuration. When new transports went through, they overwrote the Production adjustment, causing duplicate asset numbers. Auditors flagged it. The company had to manually correct hundreds of assets. The cost: tens of thousands of dollars in consulting fees and a bruised reputation.

The correct approach: Extend the number range in DEV, transport it through QAS, validate, then import into Production. If it’s truly urgent, open an emergency transport, create the change in DEV, export, and fast-track to Production using the approved change management process (ChaRM or manual approval). Never, ever, touch the dial in Production.

6.3 Alternatives to Dangerous Direct Changes

• BC Sets (Business Configuration Sets): For repeating a set of SPRO settings across clients without transport, BC Sets can create consistent configuration. Priya uses BC Sets to activate a standard best practice scenario from SAP Best Practices content.
• eCATT / LSMW: For mass maintenance of configuration values (e.g., updating tax codes in 50 countries), use eCATT scripts that run in the Dev client and generate transports. Never run them directly in Production.
• Maintenance of change documents: Enable table logging for critical customising tables. If a change is made directly in Production, you can at least identify who did it and roll back using the transport logs.

7. Bringing It All Together – The TechBook24 Release Weekend

Let’s fast-forward to a release weekend. Priya’s team has a bundle of 12 customising transports ready for import into Production. She follows the proven checklist:

1. Pre-import check: In QAS, all transports imported successfully with no return codes >4. Sequence verified.
2. Backup and fallback: The Basis team performs a full online backup of the Production system and exports the current customising tables as a fallback BC Set.
3. Transport import: Using STMS, the imports are executed in the exact queue order. Priya monitors the import logs in real time.
4. Post-import validation: Functional team logs into Production client 400 (with read-only access to SPRO for verification only) and checks a few critical configuration entries, e.g., new company code 2100 appears in table T001.
5. Business sign-off: Business process owners perform smoke tests (create a sales order, post a journal entry) in Production to confirm.
6. Closure: All transports marked as “imported”. Documentation updated. The SPRO project status in the Project IMG set to “Go-Live Complete”.

The release finishes two hours ahead of schedule because of the rigorous transport discipline. No firefighting, no 3 AM calls. That’s the power of mastering SPRO transport management.

8. Best Practices Quick Reference (Print This)

• Always use a Project IMG for ongoing implementations; switch to Enterprise IMG post-go-live for maintenance.
• Create dedicated customising requests per logical unit (e.g., one for FI-GL, one for FI-AP).
• Never use automatic transport assignment in a multi-consultant project.
• Keep a landscape client map visible to the whole team; label the purpose of each client.
• Before any transport release, run SE10 check and review the object list for unintended entries.
• Store a “golden” client copy offline for disaster recovery of configuration.
• Block SPRO changeability in Production using SCC4 (client role “Production” and changes “Not allowed”).
• Implement a change control tool (ChaRM or ServiceNow SAP module) for approval workflows.

Conclusion: Confidence Comes from Control

You have just walked through the entire life cycle of SPRO configuration management — from the moment you open the IMG to the instant a transport lands safely in Production. If you apply the concepts, scenarios, and best practices shared today, you will not only avoid the pitfalls that trap most functional consultants but also become the person your project team relies on when it really matters.

Remember: the transport request is not a technical nuisance; it is the heartbeat of your system integrity. Respect it, master it, and you will deliver projects that go live without drama.

This article is Part 29 of the “SAP S/4HANA Deep Dive” series. Day 15 will unpack the S/4HANA Activate Methodology, Configuration Workbook, Scope Items, and Fit-to-Standard — your bridge between business requirements and SAP Best Practices.

Stay connected: @FreeLearning365 and tech partner @techbook24