PROPOSAL SPECIFICATION
These are my own SAP proposal specifications — proposed designs for systems I actually built on XeerSoft, with business flow, technical design, a development pipeline, a proposed team shape, and a rough effort estimate. They show how I scope and approach SAP delivery.
Proposed SAP Design · Scoping Exercise
4 delivered ERP systems · re-scoped as SAP design proposals

Technical Coding & Business Flow

A tech-consultant exercise: each of the four ERP systems I built end-to-end on XeerSoft Cloud ERP translated into a proposed SAP design — the business flow, the SAP technical/configuration design, a phased development pipeline, a sub-unit test plan (each module broken into ~10 sub-unit tests run on a 10-step manual criteria with 5 complex conditions), a proposed team shape (PM / consultants / developers scaled to each system), and a rough effort estimate. The intent is to show how I scope SAP delivery and reason about modules, configuration, RICEFW, testing, and the team it would take. Each test plan links to the executed sub-unit tests and defect log on the delivered XeerSoft system. Every estimate below is a planning figure, not a quote or a track record.

Source XeerSoft Cloud ERP · 4 live systems
Target SAP MM · SD · FI-AR · CO-PA · Test Mgmt
Artifacts Business flow · design · pipeline · sub-unit tests · team · estimate
Status Proposal specification
4 ERP systems re-scoped
5 SAP module areas · MM SD FI CO Test
40 sub-unit tests planned
8 RICEFW objects scoped
Built on XeerSoft · Procurement & Inventory

Procurement & Inventory SAP MM

Business Flow
  1. Purchase RequisitionME51N · EBAN
  2. PO releaseME21N · EKKO/EKPO
  3. Goods ReceiptMIGO · mvt 101 · MSEG
  4. Invoice VerificationMIRO · RBKP/RSEG

3-way match (PO · GR · invoice) posts the vendor liability; the GR posts inventory + a GR/IR clearing entry to FI automatically.

SAP Technical Design
  • MM org structure — purchasing org / group, plant, storage location
  • PO release strategy via classification class type 032
  • Reorder-point / MRP type & lot-sizing on the material master
  • Vendor / material master (Business Partner in S/4)
  • Transactions ME51N ME21N MIGO MIRO
Integration & RICEFW
  • MM → FI automatic account determination OBYC — keys BSX WRX GBB PRD by valuation class
  • Key tables EKKO/EKPO MSEG RBKP
RPR-approval report FPO print · Adobe Form

RICEFW = 2 objects (1 report, 1 form). Everything else is standard config.

Development Pipeline
  1. Fit-Gap2w
  2. Config3w
  3. Unit Test1w
  4. Integration / UAT2w
  5. Cutover1w
Sequential span ~9 weeks
Sub-Unit Test Plan
01PR create & validation 02PR approval (฿50K) 03PO & release strategy 04Goods Receipt + GL determination 05Invoice 3-way match 06Reorder · Poisson 07Reorder · Normal-Z 08EOQ + edition penalty 09Vendor scorecard 10PR-approval report (RICEFW)
10 sub-unit tests · 10-step manual criteria · 5 complex conditions each view the executed tests & defect log →
Proposed Team
  • 1Project Manager — shared / part-time
  • 1MM Functional Consultant — lead
  • 1ABAP Developer — PR-approval report
Core team ~3 people · single-module scope
Estimated Effort
~2.5months Rough planning estimate of calendar duration for the team above — a planning figure, not a quote.
Built on XeerSoft · Strategic Pricing & AR

Strategic Pricing & AR SAP SD pricing + FI-AR

Order-to-Cash pricing & receivables · view the delivered system →
Business Flow
  1. PricingV/08 · condition technique
  2. BillingVF01 · VBRK/VBRP
  3. AR postingVKOA · BSID
  4. DunningF150 · dunning run

Billing releases to accounting, which posts the receivable to FI-AR; the dunning run then walks open items by dunning level.

SAP Technical Design
  • Condition technique — condition tables → access sequence → condition types → pricing procedure V/08
  • Condition records VK11
  • Dunning procedure config FBMP, run F150
  • Credit management FD32 (FSCM in S/4)
  • AR aging / line items FBL5N
Integration & RICEFW
  • SD → FI revenue account determination VKOA — account keys via condition types KOFI/KOFK
  • Key tables KONV/PRCD_ELEMENTS VBRK BSID
EPricing routine · VOFM RAR aging report FDunning letter

RICEFW = 3 objects (enhancement, report, form). The pricing routine handles the tiered / mixed-terms logic standard condition types can't.

Development Pipeline
  1. Fit-Gap2w
  2. Config4w
  3. Unit Test2w
  4. Integration / UAT3w
  5. Cutover1w
Sequential span ~12 weeks
Sub-Unit Test Plan
01Pricing condition technique 02Condition records (VK11) 03Billing document 04AR posting 05Credit check (FD32) 06Dunning (F150) 07AR aging (FBL5N) 08Payment terms · partial pay 09Mixed terms across siblings 10Statement reconciliation
10 sub-unit tests · 10-step manual criteria · 5 complex conditions each view the executed tests & defect log →
Proposed Team
  • 1Project Manager
  • 1SD Consultant — pricing / billing
  • 1FI Consultant — AR / dunning
  • 1ABAP Developer — pricing routines
Core team ~4 people · two-module scope (SD + FI)
Estimated Effort
~3.5months Rough planning estimate of calendar duration for the team above — a planning figure, not a quote.
Built on XeerSoft · Loyalty / Star Reward (UAT)

Loyalty / Star Reward SAP Test Management & Cutover

Realize / Deploy workstream · view the delivered system →
Business Flow
  1. UAT cyclesCloud ALM · Realize
  2. Defect trackingdefect mgmt · triage
  3. Go-live readinesscutover sign-off
  4. Cutovertransport · Deploy

The loyalty logic itself would be a custom RICEFW enhancement; this card scopes the test & cutover discipline around it.

SAP Technical Design
  • SAP Activate Realize / Deploy test discipline
  • Solution Manager / Cloud ALM test suite & test cases
  • Defect management — severity, triage, retest
  • Cutover plan & transport strategy
Integration & RICEFW
  • The loyalty engine is the enhancement under test — accrual, tier recalculation, idempotent awards
  • Regression scope — the enhancement touches billing / member master, so both are in the test set
ELoyalty engine enhancement

RICEFW = 1 object. This card's value is the test & cutover discipline that de-risks it, not new config.

Development Pipeline
  1. Test strategy1w
  2. Test cycles4w
  3. Cutover readiness1w
Defect resolution — runs in parallel across the test cycles
Sequential span ~6 weeks + parallel defect resolution
Sub-Unit Test Plan
01Points accrual / earn rules 02Bulk star import 03Tier recalculation 04Tier-boundary edges 05Points reversal 06Lifetime vs term rollup 07Member enrollment 08Duplicate-award / idempotency 09Leaderboard report 10Authorisation / staff scope
10 sub-unit tests · 10-step manual criteria · 5 complex conditions each · the discipline this card scopes view the executed tests & defect log →
Proposed Team
  • 1Project Manager — test lead
  • 1Functional Consultant
  • 1ABAP Developer — loyalty enhancement
  • 1QA / UAT Tester
Core team ~4 people · test & cutover workstream
Estimated Effort
~2months Rough planning estimate of calendar duration for the team above — a planning figure, not a quote.
Built on XeerSoft · STEM Billing & Profitability

STEM Billing & Profitability SAP SD billing + FI-AR + CO-PA

Billing to profitability analysis · view the delivered system →
Business Flow
  1. BillingVF01 · VBRK/VBRP
  2. AR postingVKOA · BSID
  3. Profitability by segmentCO-PA · KE30

One billing document posts the receivable to FI-AR and, in parallel, derives the CO-PA segment (segment = subject) so margin reports read from the same source.

SAP Technical Design
  • Billing doc types & copy control VF01
  • Revenue account determination VKOA
  • CO-PA characteristics / value fields (segment = subject)
  • Account-based CO-PA (S/4 — Universal Journal)
  • Profitability reports KE30
Integration & RICEFW
  • SD → FI revenue determination VKOA; CO-PA derivation KEDR maps segment to value fields
  • Key tables VBRK BSID ACDOCA (Universal Journal)
ECO-PA derivation RMargin / profitability report

RICEFW = 2 objects. The derivation makes every invoice line report its own segment margin without a separate allocation run.

Development Pipeline
  1. Fit-Gap2w
  2. Config5w
  3. Unit Test2w
  4. Integration / UAT3w
  5. Cutover1w
Sequential span ~13 weeks
Sub-Unit Test Plan
01Billing document (VF01) 02Revenue determination · GL split 03AR posting 04CO-PA derivation (segment=subject) 05CO-PA value fields 06Cost allocation 07Profitability report (KE30) 08Period-end / settlement 09Dunning / collection 10Margin reconciliation
10 sub-unit tests · 10-step manual criteria · 5 complex conditions each view the executed tests & defect log →
Proposed Team
  • 1Project Manager
  • 1SD Consultant — billing
  • 1FI-CO Consultant — AR & CO-PA
  • 1ABAP Developer — billing / CO-PA RICEFW
Core team ~4–5 people · three-module scope (SD + FI + CO)
Estimated Effort
~4months Rough planning estimate of calendar duration for the team above — a planning figure, not a quote.
Advanced · the code behind the config

Where standard config stops, code begins.

Most of an SAP build is configuration. The gaps that config can’t reach become RICEFW objects — and this is what they actually look like. Three real objects from the cards above: an ABAP pricing routine, the OBYC account-determination table, and a CO-PA derivation rule. Switch objects, click a highlighted line to read what it does, or run an execution trace.

FRM_KONDI_WERT_601 ABAP · VOFM routine
1* FRM_KONDI_WERT_601 — VOFM pricing value routine2* Condition ZTIR · attached in V/08 · tiered volume, sibling-aware3 4FORM frm_kondi_wert_601.5 6  DATA: lv_qty  TYPE komp-mgame,   " rolled-up sibling qty7        lv_tier TYPE konp-kbetr.   " resolved unit rate8 9* 1 · Standard conditions price one sold-to at a time —10*     roll quantity up across the customer's siblings first.11  PERFORM read_sibling_qty USING    komk-kunnr12                           CHANGING lv_qty.13 14* 2 · Resolve which price tier that combined volume earns.15  SELECT SINGLE kbetr INTO lv_tier16    FROM ztir_scale17   WHERE vkorg    = komk-vkorg18     AND qty_from <= lv_qty19     AND qty_to   >= lv_qty.20 21* 3 · Return the value; SAP posts XKWERT as the condition.22  xkwert = komp-mgame * lv_tier.23 24ENDFORM.
Click a highlighted line to read what it does — and why it’s built that way.
Watch the config post. Procure-to-Pay · MM → FI

The OBYC table above isn’t abstract — it decides the GL accounts every movement hits. Step through a purchase and watch the automatic double entry land in the ledger. GR/IR and the vendor should each clear to zero when the flow completes.

Inventory / Stock
BSX 130000
Debit
Credit
balance
GR/IR clearing
WRX 191100
Debit
Credit
balance
Input VAT
VST 154000
Debit
Credit
balance
Vendor (AP)
KBS 200000
Debit
Credit
balance
Bank / Cash
GL 113000
Debit
Credit
balance
3 postings · net vendor liability ฿10,700 incl. 7% input VAT
ABOUT THESE SPECIFICATIONS

Everything on this page is a proposal specification. The four source systems are real — I built and went live with them on XeerSoft Cloud ERP — while the SAP modules, configuration, T-codes, pipelines, sub-unit test plans, team shapes, and month estimates here are my own proposed designs. They exist to show how I scope and approach SAP delivery: how I read a business flow, map it onto SAP modules and RICEFW, decompose it into sub-unit tests, size the team, sequence the work, and estimate effort. The sub-unit test plans link to the real, executed UAT and defect logs on the four delivered XeerSoft systems — the proposal is hypothetical, the testing discipline behind it is not.

See the delivered track record these designs are built on — 6 capabilities, verified →