Regression across merged org units

Reconciliation proves the data arrived. Regression proves the business still runs on it, in the new organizational units and in the old ones. After a consolidation the same process has more variants than before: a sales order in 1910 must find Mexican tax, CFDI output and the Monterrey profit center, while the same order in 1710 must still find exactly what it found last month. The efficient way to cover that is one end-to-end scenario run many times with different organizational data, before and after every mock.

The regression scope matrix

Process	Variant	Company code / plant / sales area	UI	Compare after the mock
Order to cash	Standard order, delivery, billing	1710 / 1710 / 1710-10-00	Fiori and SAP GUI	Unchanged accounts, tax, profit center CMC-FLEET
Order to cash	Standard order with CFDI output	1910 / 1910 / 1910-10-00	Fiori	Mexican tax, CFDI stamped, MXN revenue
Intercompany	1710 buys alternators from 1910	1710 and 1910	SAP GUI	Intercompany billing, trading partner, both sides post
Procure to pay	PO over $25,000 with approval	1710 / 1710	Fiori	Flexible workflow still triggers
Procure to pay	Lakeside rotor PO for Monterrey	1910 / 1910	Fiori	Extended BP 17300001 used, MXN or USD as designed
Record to report	Period-end close tasks	1710, 1810, 1910	Fiori and SAP GUI	Close sequence completes for all three

An extract from the Wave 2 merged-org regression scope (illustrative course data).

Two rules keep the matrix honest. First, every existing company code stays in scope: 1710 and 1810 share the client, account determination, output rules and derived roles with 1910, so any Wave 2 transport can reach them. Second, the comparison is about outputs, not just green ticks: the posted G/L account, tax code, profit center and segment, the output that went out, and the document flow. A test that passes because a document was created, while its revenue now lands on a different profit center, is a failed test.

Baseline, mock, rerun, compare

The baseline-and-rerun loop around each W2 mock separates changes to existing company codes from defects in the new one.

The Sign-Off Table · thesignofftable.com/academy/sap-dmg-305

The baseline runs in CMQ client 100 shortly before each W2 mock load; the rerun runs after the load and its transports. Use the same test data and the same version of the scripts, or differences become impossible to attribute. Record the outputs that matter as values in the results (document numbers, G/L accounts, tax amounts, profit centers) so the comparison is a diff, not a memory exercise.

Data-driven, not copy-and-paste

Writing one script per company code multiplies maintenance with every new org unit. Instead, build the scenario once and feed it rows of organizational data: company code, plant, sales area, customer, material and the expected outputs. Adding 1910 then means adding rows, not scripts. In ACCELQ, the worked example for the automation layer in this course, each input of an Action becomes a parameter of the Scenario, and the Test Cases tab holds one row per data set. Values can come from the test case, from a fixed value or Global Property, from a Run Property supplied at run time, or from an earlier step's output. The same scenario can then run on SAP GUI for Windows, which ACCELQ documents for ECC 6.0 and higher through SAP GUI scripting and a Local Agent, and on SAP Fiori through its general web recorder; ACCELQ has no Fiori-specific documentation, so prove Fiori stability in your own pilot.

Test case	Company code	Sales area	Customer	Expected profit center	Expected output
TC-1710	1710	1710 / 10 / 00	17100001 Great Lakes Fleet Services	CMC-FLEET	Invoice by output control (EDI and e-mail)
TC-1720	1710	1710 / 10 / 00, plant 1720	Aftermarket customer	CMC-AFTMKT	As 1710
TC-1910	1910	1910 / 10 / 00	Flotillas Monterrey	As designed for 1910	CFDI stamped

One order-to-cash scenario, three data rows: adding an org unit adds a row, not a script.

The Sign-Off Table · thesignofftable.com/academy/sap-dmg-305

Hands-on lab · ACCELQ

Capture a regression baseline before a mock and rerun it after

Practice the baseline-and-rerun loop: build a small regression suite, run it as a baseline, then rerun it unchanged and compare the two results the way you would around a W2 mock.

Practice on SAPUI5 Shopping Cart demo app (public, no login)

If you haven't set up ACCELQ yet, do the setup lab first. Create a Context for the cart app and an Action Add product to cart, recorded with the Web Recorder in Fluid mode: open any category, pick any product, add it to the cart.
Switch to Intent mode and add Verify Element Text on the cart entry for the product name. This is your output check, like a profit center or tax code in an SAP order.
Build a Scenario O2C baseline stand-in that starts with Initiate Browser Session on the app URL and calls your Action.
Create a Test Suite of type Static named W2 regression and add the Scenario.
Run the suite from the Run modal on your Local Agent. Note the run as your baseline and keep the Test Report link.
Treat the time in between as the mock load. Rerun the same suite with the same data and nothing edited.
Open the Test Suite Dashboard, which shows the latest run and the run history, and compare baseline and rerun step by step. Write down any difference and whether the app or the script caused it.

Done when Two runs of the same suite with matching results, a written comparison, and both Test Report links stored with the date and the "mock" they bracket. That pair of reports is the shape of the evidence you keep for each W2 mock.

Learn more in ACCELQ’s docs: Test Suites in ACCELQ · Test Suite Dashboard

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Hands-on lab · ACCELQ

Run one scenario across several org-unit rows

Turn one scenario into a data-driven regression: each Test Case row stands for one organizational combination, with its own expected output, the way TC-1710, TC-1720 and TC-1910 do in the lesson.

Practice on SAPUI5 Shopping Cart demo app (public, no login)

If you haven't set up ACCELQ yet, do the setup lab first. Open the Action from the previous lab and replace the recorded category and product with Action Parameters category and product.
Add a third parameter expectedName and use it as the expected value in your Verify Element Text statement, so each row carries its own expected output.
In the Scenario's Test Cases tab, add three rows with different categories and products you can see in the app. Name them like org units, for example row-1710, row-1720 and row-1910.
Add a fourth row whose expectedName deliberately does not match its product. This is your negative control: it must fail.
Run the Scenario. Check that three rows pass and the negative control fails at the verification step, not earlier.
Fix the fourth row's expected value and rerun. Note how adding a new org unit to the suite meant adding a row, not editing logic.

Done when Three passing rows, one deliberate failure caught at the verification step, then four passing rows after the fix. Keep both Test Reports: they show that the verification really checks the output.

Learn more in ACCELQ’s docs: Working with Test Cases in ACCELQ · Configuring Parameter Sources in a Scenario

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Run the suite unattended after every mock. In ACCELQ a run can be scheduled or created as a CI Job and triggered from a pipeline or through its REST trigger, and Perspectives in the Test Report break results down by a custom field such as company code, so Lucía reads 1910 and Maria reads 1710 without searching.

The rerun is triggered by the end of the load, not by someone remembering on Monday.

The Sign-Off Table · thesignofftable.com/academy/sap-dmg-305

What would you do?

After W2 Mock 1, the rerun shows that TC-1720 now posts revenue to profit center CMC-FLEET instead of CMC-AFTMKT. The baseline the day before showed CMC-AFTMKT. The 1910 rows are fine. What should Priya do?

Key points

Regression covers the new and the existing org units, because they share one client.
Run a baseline before each mock and the same suite after it, then compare outputs, not just pass rates.
Build scenarios once and feed them rows of org data with expected outputs.
Trigger reruns automatically when the load finishes, and report results by company code.

The regression scope matrix

Baseline, mock, rerun, compare

Data-driven, not copy-and-paste

Lesson check