Carve-out tests, SoD and access cutoff

A carve-out has to prove two things that pull in opposite directions: the buyer received everything the sold business needs, and nothing else left with it. Advisers call these positive and negative tests, and both seller and buyer run them. The same thinking applies inside an absorption, where the question becomes: can the new company's users do their jobs, and only their jobs? This lesson builds both kinds of test and the access evidence around them.

Negative tests: proving absence

A negative test searches for data that must not exist and expects zero. Write one per object and org key, and run it against the delivered copy, not against a sample. SE16H gives counts grouped by a field, which makes the results easy to read: group the journal entry table by company code and expect only 1810. Count statistics from TAANA can show which org values a table holds. Agree the list with the buyer, because the buyer's legal team will ask for the same evidence.

The business partner check is the one teams forget. Deleting company code data leaves the central partner record behind: name, address, tax number, sometimes bank data. A copy can therefore pass every company code check while still carrying 1,200 of Contoso's other customers. Define "belongs to 1810" precisely (a company code extension, a sales area extension, a role used by 1810, or an open item) and count everything outside that definition. Treat change documents, attachments and archived data the same way.

Positive tests: proving completeness and usability

Positive tests are the reconciliation layers from lesson 1, applied to 1810 alone, plus process tests: the buyer creates a sales order for a Toledo customer, delivers, bills and posts; receives against an open 1810 purchase order; runs a payment proposal; and closes a period. The intercompany flows from 1710 at the $200 internal price become ordinary purchases from a third party, so the test also checks that no open intercompany item survived without a settlement decision.

Access: right users, right org units

In an absorption, the access question is whether new users can do their work and see nothing else. At Contoso the role design sets organizational values only in derived roles, so most Wave 2 role work is creating 1910 derivations of existing task roles. The tests follow: Lucía's team can create and bill orders in sales area 1910 / 10 / 00 and gets an authorization failure in 1710; Maria's team sees 1710 and not 1910. Use SU53 for SAP GUI failures and STAUTHTRACE with /IWFND/ERROR_LOG for Fiori, not a second GUI session.

Then run SoD analysis. In SAP Access Control 12.0, which Contoso runs, an access risk is an action or permission that, combined in one user, creates the potential for fraud or error; risks are segregation of duties, critical actions or critical permissions. Run user-level risk analysis for every 1910 user after role assignment, and regenerate rules after any rule set change. A merged user base often brings combinations nobody designed, such as a Monterrey supervisor who held both supplier maintenance and payment release in the legacy ERP.

Access cutoff evidence

In the Toledo what-if, the seller must show that 1810 users lose access to Contoso data at a stated time, and that buyer users under the TSA see only 1810 until physical separation. Evidence is a set of before-and-after reports taken at the cutoff time: user lists with validity dates and locks (SUIM), role assignments per user, emergency access granted and its logs, RFC destinations in SM59 and trust relationships removed or changed, and single sign-on federation updated. An access review a few weeks after cutoff confirms nothing crept back.