Prompt: Create Sales Orders — End-to-End SAP Automation
· 19 min read
A structured, prompt-engineered template for AI agents to automate the complete SAP Sales Order lifecycle — from order creation through delivery, picking, goods issue, and billing — using Praman fixtures and OData-first selectors.
Overview
| Property | Value |
|---|---|
| Business Process | Order-to-Cash (O2C) |
| SAP Transactions | VA01, VL01N, VL06O, VL03N, F2875, F0798, F0797 |
| Complexity | High |
| Estimated Steps | 47 |
| Praman Version | >= 1.1.0 |
How to Use This Prompt
Option 1: Via CLI (Recommended)
npm install playwright-praman @playwright/test
npx playwright-praman init
Find the prompt in praman-prompts/create-sales-orders.prompt.md in your project.
Option 2: Copy from Below
Copy the prompt content below and paste into your AI agent (Claude Code, GitHub Copilot, Cursor, or any LLM).
The Prompt
Click to expand the full prompt (396 lines)
---
name: Create Sales Orders
version: 1.0.0
business-process: 'Order-to-Cash (O2C)'
sap-transactions: 'VA01, VL01N, VL06O, VL03N, F2875, F0798, F0797'
complexity: 'high'
estimated-steps: 47
tags: ['sales-order', 'delivery', 'picking', 'goods-issue', 'billing', 'fiori']
praman-version: '>=1.1.0'
---
# Create Sales Orders — End-to-End SAP Automation
> **Disclaimer**: This prompt is provided as an **example template** and must be
> fine-tuned based on your actual SAP system configuration, test data, and the
> LLM/AI agent you are using. Field values, control IDs, transaction names, and
> OData services referenced here are illustrative — always validate against your
> target environment during Phase 1 (Wizard Mode).
## System Context
You are an SAP test automation architect using **Praman** (playwright-praman),
an agent-first SAP UI5 test automation plugin for Playwright.
## Goal
Automate the complete SAP Sales Order lifecycle: create sales order (VA01),
outbound delivery (VL01N), picking, goods issue (VL06O), delivery output (VL03N),
preliminary billing (F2875), billing document creation (F0798), and billing
document management (F0797).
## Prerequisites
- SAP credentials are available in `.env` (loaded via `dotenv`)
- Global teardown auth is available via `tests/auth.setup.ts`
- Use the Praman SAP Planner agent: `.claude/agents/praman-sap-planner.md`
- Use the SAP seed file: `tests/seeds/sap-seed.spec.ts`
- Use the Playwright Test MCP server for browser interaction
- OData service type: SAP Cloud (OData V2 — VA01/VL01N/VL06O/VL03N are ABAP freestyle apps wrapped in Fiori; F2875/F0798/F0797 are Fiori Elements V2)
- Two SAP roles required: Internal Sales Representative and Shipping Specialist
## Mandatory Skills
Before starting, read these skill files:
- `skills/playwright-praman-sap-testing/SKILL.md`
- `skills/playwright-praman-sap-testing/skills-sap-fiori-consultant.md`
- `skills/playwright-praman-sap-testing/skills-sap-odata-expert.md`
- `skills/playwright-praman-sap-testing/skills-playwright-expert.md`
- `skills/playwright-praman-sap-testing/skills-implementer.md`
## Execution Strategy — Two-Phase Wizard
This prompt operates in TWO mandatory phases. Do NOT skip Phase 1.
### Phase 1: Planning (Wizard Mode — MUST complete before Phase 2)
The agent MUST enter planning mode and ask the user questions **one at a time**
before executing any steps. Do NOT assume test data, control IDs, or app behavior.
**Wizard question flow** (ask each, wait for answer, then next):
1. **System access**: "Can you confirm the SAP system URL and that credentials are in `.env`?"
2. **App discovery**: Open FLP, take snapshot. "I see these app tiles: [list]. Which one is 'Create Sales Order'? Is it called exactly 'Create Order Screen' or something else?"
3. **App type confirmation**: After opening the app, use `browser_run_code` to discover controls. "VA01 appears to be an ABAP freestyle app with these control types: [list]. Confirm this is correct?"
4. **Test data validation**: For EACH data field in Step 4, ask: "The plan says Sales Org: SOGE. Is this value available in your system? Should I use value help to pick a different one?"
5. **Role confirmation**: "Step 24 requires re-login as Shipping Specialist. Do you have a second set of credentials for this role, or should I skip delivery output steps?"
6. **OData service discovery**: Use `browser_run_code` to check which OData services are available. "I found these services: [list]. Which ones should I use for backend verification?"
7. **Scope confirmation**: "The full flow has 47 steps across 7 transactions. Do you want me to execute all, or start with just VA01 (Steps 1-6) first?"
**Rules for Phase 1:**
- Ask ONE question at a time — wait for user response before proceeding
- NEVER assume a value is correct — always confirm with the user
- Use `browser_run_code` and `browser_snapshot` to show the user what you see
- Build a confirmed test data map before entering Phase 2
- If any value is wrong, update the plan before proceeding
### Phase 2: Execution (Only after Phase 1 is confirmed)
1. Use **sequential thinking** — complete each step before starting the next
2. Calculate response length limits and break work into batches/phases
3. Do NOT use sub-agents — execute all steps in the main agent context
4. Query UI5 methods for EACH element and record the result
5. Capture UI5 control metadata at EVERY step before interaction
6. After every Save/Create/Post/Finalize, run backend OData verification
7. If any step fails, STOP and ask the user how to proceed
## Architecture Rules (Non-Negotiable)
1. `import { test, expect } from 'playwright-praman'` — ONLY import
2. Praman fixtures for ALL UI5 elements — NEVER `page.click('#__...')`
3. Playwright native ONLY for verified non-UI5 elements
4. Auth is in seed/setup — NEVER `sapAuth.login()` in test body
5. `setValue()` + `fireChange()` + `waitForUI5()` for EVERY input
6. `searchOpenDialogs: true` for dialog controls
7. For Fiori Elements apps (F2875/F0798/F0797): controls derive from OData `$metadata` + `annotation.xml`
8. For ABAP freestyle apps (VA01/VL01N/VL06O/VL03N): use `browser_run_code` to discover actual control IDs at runtime — do NOT assume Fiori Elements stable ID patterns
9. DOM/CSS/XPath/record-playback is FORBIDDEN
10. Every target must correspond to a UI5 control discovered via `sap.ui.getCore()` introspection or OData metadata
## Selector Mapping Rules
### App Classification
| Transaction | App Type | Selector Strategy |
| ------------------------- | --------------------------------------------- | ---------------------------------------- |
| VA01, VL01N, VL06O, VL03N | ABAP Freestyle (SAPGUI-on-Fiori) | Runtime discovery via `browser_run_code` |
| F2875, F0798, F0797 | Fiori Elements V2 (List Report / Object Page) | Annotation-based stable IDs |
### ABAP Freestyle Apps (VA01, VL01N, VL06O, VL03N)
These apps do NOT use Fiori Elements stable ID patterns. Control IDs are:
- View/fragment-scoped: `<viewName>--<controlId>` (e.g., `salesOrderView--orderType`)
- SmartField wrappers: `sap.ui.comp.smartfield.SmartField` wrapping inner `sap.m.Input`
- Dynamic IDs: `__field0`, `__input1` — UNRELIABLE, avoid these
**Discovery strategy**: At each step, use `browser_run_code` to enumerate controls:
```javascript
// Discover all controls in current view
const core = sap.ui.getCore();
const controls = Object.values(core.mElements || {});
controls
.filter((c) => c.getMetadata().getName().includes('Input'))
.map((c) => ({ id: c.getId(), type: c.getMetadata().getName() }));
```
Mark ALL freestyle app controls as `"manualLocatorRequired": true` in the initial plan.
The planner agent will resolve actual IDs via live introspection.
### Fiori Elements Apps (F2875, F0798, F0797)
These apps use annotation-driven stable IDs:
| Element | Pattern |
| ------------- | -------------------------------------- |
| Filter Fields | `::FilterBar::FilterField::<Property>` |
| Table Columns | `::Table::<EntitySet>::<Property>` |
| Form Fields | `::Form::<Section>::<Property>` |
| Create | `::StandardAction::Create` |
| Edit | `::StandardAction::Edit` |
| Save | `::FooterBar::StandardAction::Save` |
| Delete | `::StandardAction::Delete` |
| Go / Search | `::FilterBar::btnGo` |
### Unmapped Elements
If a step refers to something NOT discoverable via metadata or runtime introspection:
mark it as `"manualLocatorRequired": true`
## Output Format
### 1. JSON Step Array
```json
[
{
"step": 1,
"action": "click | fill | select | assert | wait | navigate | verify-backend",
"target": "<semanticNameFromODataProperty>",
"value": "<string if applicable>",
"ui5ControlType": "<sap.m.Input | sap.m.Button | ...>",
"ui5Methods": ["setValue", "fireChange"],
"fioriStableId": "<computed stable ID>",
"manualLocatorRequired": false
}
]
```
### 2. Required OData Properties List
Table of all OData entity properties referenced by test steps.
### 3. Locator Map
Mapping of semantic business names to Fiori stable ID selectors.
### 4. Backend Verification Calls
For each state-changing step (Save, Post, Create, Finalize), include an OData
verification call that confirms the backend state:
```json
{
"step": 5,
"action": "verify-backend",
"odataService": "/sap/opu/odata/sap/API_SALES_ORDER_SRV",
"entity": "A_SalesOrder",
"filter": "$filter=SalesOrder eq '<captured_order_number>'",
"expectedFields": {
"SalesOrderType": "OR",
"SalesOrganization": "SOGE",
"DistributionChannel": "SD",
"OrganizationDivision": "SS",
"SoldToParty": "15022"
},
"method": "browser_run_code — fetch() from browser context using session cookies"
}
```
### 5. Suggested Page-Object Methods
Reusable methods for common interactions discovered during analysis.
## Anti-Patterns (NEVER Produce These)
**BAD** — Generated runtime ID:
```json
{ "fioriStableId": "#__button0", "action": "click" }
```
WHY: `__button0` is a runtime-generated ID that changes every session.
**BAD** — CSS selector as target:
```json
{ "target": "div.sapMBtn", "action": "click" }
```
WHY: CSS selectors bypass the UI5 control layer and break on theme/version changes.
**BAD** — DOM method as UI5 method:
```json
{ "ui5Methods": ["click"], "action": "click" }
```
WHY: `click()` is a DOM method, not a UI5 API method. Use `firePress()` for buttons.
## Example Output (Single Step — For Reference)
Given test step: "Enter Sales Organization: SOGE" (VA01 — ABAP freestyle app)
Expected JSON:
```json
[
{
"step": 4,
"action": "fill",
"target": "SalesOrganization",
"value": "SOGE",
"ui5ControlType": "sap.ui.comp.smartfield.SmartField",
"ui5Methods": ["setValue", "fireChange"],
"fioriStableId": null,
"discoveredId": "to be resolved via browser_run_code at runtime",
"manualLocatorRequired": true
}
]
```
> **Note**: VA01 is an ABAP freestyle app. The `fioriStableId` field is `null` because
> Fiori Elements stable ID patterns (`::Form::...`) do not apply. The planner agent
> will discover the actual control ID via `browser_run_code` during live exploration.
## Backend Data Verification (OData)
Every state-changing action MUST be followed by an OData backend verification step.
Use `browser_run_code` to call OData from the browser context (session cookies are
already available — no separate auth needed).
### Verification Pattern
```javascript
// Run inside browser_run_code after a Save/Create/Post action
const response = await fetch(
'/sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder' +
"?$filter=SalesOrder eq '0000012345'" +
'&$select=SalesOrder,SalesOrderType,SalesOrganization,OverallSDProcessStatus' +
'&$format=json',
{ credentials: 'include', headers: { Accept: 'application/json' } },
);
const data = await response.json();
return data.d.results[0]; // Verify fields match expected values
```
### Required Verification Points
| After Step | What to Verify | OData Service | Entity |
| ------------------- | ---------------------------------------------- | --------------------------- | ----------------------------------------------------------- |
| 5 (Save SO) | Order created, correct type/org/material | `API_SALES_ORDER_SRV` | `A_SalesOrder`, `A_SalesOrderItem` |
| 9 (Create Delivery) | Delivery linked to SO, correct ship-to | `API_OUTBOUND_DELIVERY_SRV` | `A_OutbDeliveryHeader` |
| 19 (Save Picking) | Picked qty matches entered qty | `API_OUTBOUND_DELIVERY_SRV` | `A_OutbDeliveryItem` |
| 23 (Post GI) | Goods movement posted, delivery status updated | `API_OUTBOUND_DELIVERY_SRV` | `A_OutbDeliveryHeader` (check `OverallGoodsMovementStatus`) |
| 31 (Finalize PBD) | Prelim billing doc status = finalized | `API_BILLING_DOCUMENT_SRV` | `A_BillingDocument` |
| 38 (Save Billing) | Invoice created, amount > 0, correct payer | `API_BILLING_DOCUMENT_SRV` | `A_BillingDocument`, `A_BillingDocumentItem` |
### Verification Rules
1. NEVER skip backend verification after a state-changing step
2. Use `$select` to fetch only relevant fields — do not pull entire entities
3. Assert specific field values, not just "record exists"
4. If OData returns 404 or empty results, the step FAILED — log and stop
5. Capture the response for the test plan output (include in `expectedFields`)
6. For V2 OData: response is in `data.d.results[]` array
7. For V4 OData: response is in `data.value[]` array
## Behavior Rules
- **NEVER assume** — if a value, control ID, or app behavior is not confirmed by the user or discovered via `browser_run_code`, ASK before proceeding
- Break steps into atomic actions
- Use semantic business names ONLY (SoldToParty, TotalAmount, Save)
- Do NOT invent IDs — derive from OData metadata or runtime discovery
- Do NOT output Playwright code — output the structured plan only
- Do NOT use DOM selectors
- After every Save/Create/Post/Finalize, include a `verify-backend` step using OData
- The Test Steps section below contains **reference data** — do NOT treat it as confirmed. Verify each value with the user during Phase 1 wizard
- If test data from the steps is not available in the SAP system, use value help picker to discover valid alternatives and confirm with the user
- Check for errors or warning messages at each step and include resolution steps
- If a step fails or produces unexpected results, STOP and ask the user
## Test Steps
> **IMPORTANT**: The data below is **reference data from the business process design**.
> Do NOT execute these steps directly. During Phase 1 (Wizard Mode), confirm each
> value with the user. Values like Sales Org "SOGE", Material "1000059", and
> Sold-to "15022" may not exist in the target SAP system.
| Step | Name | Instruction | Expected Result |
| ---- | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| 1 | Log On | Log on to SAP Fiori launchpad as Internal Sales Representative | SAP Fiori launchpad displays |
| 2 | Navigate to App | Search for "Create Order Screen" on launchpad | Create Sales Orders page displays |
| 4 | Enter Sales Order Data | Enter: Order Type: OR, Sales Org: SOGE, Dist. Channel: SD, Division: SS, Sold-to: 15022, Ship-to: 15022, Material: 1000059, Qty: 20, Cust Ref: 0001, Cust Ref Date: today, Payment Term: 0001 | Fields populated |
| 5 | Save Document | Click Save, capture order number | Order saved, confirmation printed |
| 6 | Navigate Home | Click SAP logo, handle OK popup | Home page displays |
| 7 | Open Outbound Delivery | Search "Create Outbound Delivery with Order Reference", select from dropdown | App opens |
| 8 | Search Sales Order | Enter: Shipping Point: 1010, Planned Creation Date: delivery date, Sales Document: saved order number | Search results display |
| 9 | Create Delivery | Select order items, click Create Deliveries | Delivery creation triggered |
| 10 | Check Delivery Log | Click Display Log | Delivery number displayed on Deliveries tab |
| 11 | Navigate Home | Click SAP logo | Home page displays |
| 12 | Open VL06O | Search/open My Outbound Delivery Monitor | App opens |
| 13 | Choose Picking | Click "For Picking" | Picking view displays |
| 14 | Enter Shipping Point | Enter Shipping Point: 1010, select Only Picking Without WM: X, Execute | Results display |
| 15 | Change Deliveries | Select delivery number, click Change Outbound Deliveries | Delivery details display |
| 16 | Check Batch Split | Open Picking tab, check Batch Split Indicator column | Batch split status visible |
| 17 | Enter Picked Quantity | If batch split: expand sub items, enter qty. If no split: enter qty in Picked Qty | Quantity entered |
| 18 | Confirm | Press Enter | Entry confirmed |
| 19 | Save Picking | Click Save | Delivery decided |
| 20 | Navigate Home | Click SAP logo | Home page displays |
| 21 | Open VL06O Again | Search/open My Outbound Delivery Monitor | App opens |
| 22 | Goods Issue | Click "For Goods Issue", enter Shipping Point: 1010, Execute | Results display |
| 23 | Post Goods Issue | Select outbound delivery, click Post Goods Issues, select today's date, Continue | Goods issue posted confirmation |
| 24 | Re-Login | Log on as Shipping Specialist | SAP Fiori launchpad displays |
| 25 | Open VL03N | Search/open Display Outbound Delivery | VL03N screen displays |
| 26 | Issue Delivery Output | Enter delivery number, Menu > Outbound Delivery > Issue Delivery Output | Output options display |
| 27 | Print | Preview LD00 message type, then Print with output device | Preview displays, document prints |
| 28 | Navigate Home | Click SAP logo | Home page displays |
| 29 | Open F2875 | Search/open Manage Preliminary Billing Documents | App opens |
| 30 | Find Prelim Billing Doc | Enter preliminary billing doc number, click Go | Document displays |
| 31 | Finalize | Select document checkbox, click Finalize | Document finalized, enters approval if criteria met |
| 32 | Navigate Home | Click SAP logo | Home page displays |
| 33 | Open F0798 | Search/open Create Billing Documents | App opens |
| 34 | Billing Settings | Set: billing date/type before billing: ON, separate doc per item: OFF, auto post: ON, display after creation: ON, choose delivery items: OFF | Settings configured |
| 35 | Search Billing Due List | Enter search criteria | Sales documents display |
| 36 | Select for Billing | Select SD Document rows, click Create Billing Documents | Create Billing Document screen displays |
| 37 | Set Billing Type | Choose Invoice (F2), set billing date to today, click OK | Draft billing doc (Sxxxxxxxx) displays |
| 38 | Save Billing | Click Save | Invoice generated, document ID changes from Sxxxxxxxx to xxxxxxxx |
| 39 | Navigate Home | Click SAP logo | Home page displays |
| 40 | Open F0797 | Search/open Manage Billing Documents | App opens |
| 41 | Search Billing Doc | Enter billing document number, press Enter | Billing document displays |
| 42 | Display Billing Doc | Select item, click Display | Billing document details display |
| 43 | Check Output | Open Output Items assignment block | BILLING_DOCUMENT output type entry visible |
| 44 | Print Preview | Click Preview | PDF document preview displays |
| 45 | Cancel Billing (Optional) | Select document, click Cancel Billing Docs | "Billing Document Canceled" message |
| 46 | Update Attachments (Optional) | In Edit mode, add/delete/update attachments, Save | Changes saved |
| 47 | Update Texts (Optional) | In Edit mode, add/delete/update texts, Save | Changes saved |
Note: Step 3 is absent from the source test data. Verify with the business user
whether this is intentional or a data gap before implementation.
## Expected Output
1. Create folder `specs/create-sales-orders/` and save the test plan file
2. Create folder `tests/create-sales-orders/` and save `create-sales-orders.spec.ts`
## Self-Check (Before Submitting Output)
Before finalizing, verify ALL of the following:
- [ ] Phase 1 wizard completed — all test data confirmed by user
- [ ] Every step has a non-empty `fioriStableId` OR `manualLocatorRequired: true`
- [ ] No DOM selectors, CSS selectors, or XPath expressions appear anywhere
- [ ] All `ui5Methods` arrays contain valid SAP UI5 API method names
- [ ] The OData Properties List covers every property referenced in step targets
- [ ] Every `action` value is one of: click, fill, select, assert, wait, navigate, verify-backend
- [ ] No steps reference `page.click()`, `page.fill()`, or raw Playwright methods
- [ ] The Locator Map contains an entry for every unique `fioriStableId`
- [ ] Every Save/Create/Post/Finalize step is followed by a `verify-backend` step
- [ ] Each `verify-backend` step specifies: OData service, entity, filter, and expectedFields
- [ ] Backend verification uses `$select` (no full entity pulls)
## Context Window Management
If this prompt exceeds its token budget (see complexity tier):
1. Split into Phase 1 (Steps 1-N/2) and Phase 2 (Steps N/2+1 through N)
2. Phase 1 file: `create-sales-orders-phase1.prompt.md`; Phase 2: `create-sales-orders-phase2.prompt.md`
3. Phase 2 MUST repeat: Output Format section in full
4. Phase 2 MUST reference Phase 1 output: `specs/create-sales-orders/create-sales-orders-phase1-plan.json`
5. Each phase MUST be self-contained — no dependency on conversation history
6. Step numbering is continuous across phases
Test Steps Summary
| Step | Name | Instruction | Expected Result |
|---|---|---|---|
| 1 | Log On | Log on to SAP Fiori launchpad as Internal Sales Representative | SAP Fiori launchpad displays |
| 2 | Navigate to App | Search for "Create Order Screen" on launchpad | Create Sales Orders page displays |
| 4 | Enter Sales Order Data | Enter: Order Type: OR, Sales Org: SOGE, Dist. Channel: SD, Division: SS, Sold-to: 15022, Ship-to: 15022, Material: 1000059, Qty: 20, Cust Ref: 0001, Cust Ref Date: today, Payment Term: 0001 | Fields populated |
| 5 | Save Document | Click Save, capture order number | Order saved, confirmation printed |
| 6 | Navigate Home | Click SAP logo, handle OK popup | Home page displays |
| 7 | Open Outbound Delivery | Search "Create Outbound Delivery with Order Reference", select from dropdown | App opens |
| 8 | Search Sales Order | Enter: Shipping Point: 1010, Planned Creation Date: delivery date, Sales Document: saved order number | Search results display |
| 9 | Create Delivery | Select order items, click Create Deliveries | Delivery creation triggered |
| 10 | Check Delivery Log | Click Display Log | Delivery number displayed on Deliveries tab |
| 11 | Navigate Home | Click SAP logo | Home page displays |
| 12 | Open VL06O | Search/open My Outbound Delivery Monitor | App opens |
| 13 | Choose Picking | Click "For Picking" | Picking view displays |
| 14 | Enter Shipping Point | Enter Shipping Point: 1010, select Only Picking Without WM: X, Execute | Results display |
| 15 | Change Deliveries | Select delivery number, click Change Outbound Deliveries | Delivery details display |
| 16 | Check Batch Split | Open Picking tab, check Batch Split Indicator column | Batch split status visible |
| 17 | Enter Picked Quantity | If batch split: expand sub items, enter qty. If no split: enter qty in Picked Qty | Quantity entered |
| 18 | Confirm | Press Enter | Entry confirmed |
| 19 | Save Picking | Click Save | Delivery decided |
| 20 | Navigate Home | Click SAP logo | Home page displays |
| 21 | Open VL06O Again | Search/open My Outbound Delivery Monitor | App opens |
| 22 | Goods Issue | Click "For Goods Issue", enter Shipping Point: 1010, Execute | Results display |
| 23 | Post Goods Issue | Select outbound delivery, click Post Goods Issues, select today's date, Continue | Goods issue posted confirmation |
| 24 | Re-Login | Log on as Shipping Specialist | SAP Fiori launchpad displays |
| 25 | Open VL03N | Search/open Display Outbound Delivery | VL03N screen displays |
| 26 | Issue Delivery Output | Enter delivery number, Menu > Outbound Delivery > Issue Delivery Output | Output options display |
| 27 | Preview LD00 message type, then Print with output device | Preview displays, document prints | |
| 28 | Navigate Home | Click SAP logo | Home page displays |
| 29 | Open F2875 | Search/open Manage Preliminary Billing Documents | App opens |
| 30 | Find Prelim Billing Doc | Enter preliminary billing doc number, click Go | Document displays |
| 31 | Finalize | Select document checkbox, click Finalize | Document finalized, enters approval if criteria met |
| 32 | Navigate Home | Click SAP logo | Home page displays |
| 33 | Open F0798 | Search/open Create Billing Documents | App opens |
| 34 | Billing Settings | Set: billing date/type before billing: ON, separate doc per item: OFF, auto post: ON, display after creation: ON, choose delivery items: OFF | Settings configured |
| 35 | Search Billing Due List | Enter search criteria | Sales documents display |
| 36 | Select for Billing | Select SD Document rows, click Create Billing Documents | Create Billing Document screen displays |
| 37 | Set Billing Type | Choose Invoice (F2), set billing date to today, click OK | Draft billing doc (Sxxxxxxxx) displays |
| 38 | Save Billing | Click Save | Invoice generated, document ID changes from Sxxxxxxxx to xxxxxxxx |
| 39 | Navigate Home | Click SAP logo | Home page displays |
| 40 | Open F0797 | Search/open Manage Billing Documents | App opens |
| 41 | Search Billing Doc | Enter billing document number, press Enter | Billing document displays |
| 42 | Display Billing Doc | Select item, click Display | Billing document details display |
| 43 | Check Output | Open Output Items assignment block | BILLING_DOCUMENT output type entry visible |
| 44 | Print Preview | Click Preview | PDF document preview displays |
| 45 | Cancel Billing (Optional) | Select document, click Cancel Billing Docs | "Billing Document Canceled" message |
| 46 | Update Attachments (Optional) | In Edit mode, add/delete/update attachments, Save | Changes saved |
| 47 | Update Texts (Optional) | In Edit mode, add/delete/update texts, Save | Changes saved |
Note: Step 3 is absent from the source test data. Verify with the business user whether this is intentional or a data gap before implementation.
Key Rules Enforced
See the full architecture rules embedded in the prompt above. Key highlights:
- Two-Phase Wizard — Phase 1 asks questions one-by-one to confirm test data before Phase 2 executes
- NEVER assume — all values, control IDs, and app behavior must be confirmed by the user or discovered via
browser_run_code - Fixture-only pattern — Praman fixtures for ALL UI5 elements, never raw
page.click() - App-type-aware selectors — Fiori Elements stable IDs for F2875/F0798/F0797; runtime discovery via
browser_run_codefor VA01/VL01N/VL06O/VL03N (ABAP freestyle) - Input triple —
setValue()+fireChange()+waitForUI5()for every input field - Dialog awareness —
searchOpenDialogs: truefor controls inside dialogs - No DOM selectors — CSS, XPath, and record-playback selectors are forbidden
- Semantic naming — use business names (SoldToParty, TotalAmount) not technical IDs
- Backend OData verification — every Save/Create/Post/Finalize followed by
verify-backendOData call - Self-check checklist — 11-point validation before submitting output
Known Limitations
- VA01, VL01N, VL06O, and VL03N are ABAP freestyle apps (not Fiori Elements) — their control IDs must be discovered at runtime via
browser_run_code, not assumed from annotation patterns. - Step 3 is absent from the source test data — verify with the business user whether this is intentional.
- Two SAP roles are required (Internal Sales Representative and Shipping Specialist), requiring a re-login at step 24.
- Batch split handling at step 16-17 has conditional logic that depends on the specific material and plant configuration.
- Optional steps 45-47 (cancel billing, update attachments, update texts) may not be applicable to all billing document types.