Skip to main content
Glama
RitwijParmar

O2C Deployment Workbench MCP Server

by RitwijParmar
README.md
# O2C Deployment Workbench

A complete, clearly synthetic customer implementation for ERP receivables: source onboarding, canonical data, cash application, deductions, collections, controls, KPI benchmarking, MCP access, multi-agent exception review, observability, UAT, cutover, and hypercare.

> All SAP S/4HANA-style, Oracle Fusion-style, and NetSuite-style files in this repository are generated simulations. They are not genuine exports or live integrations. KPI movement is a controlled implementation benchmark on synthetic data, not customer impact.

## Why this is an implementation project

The workbench starts with customer configuration and three incompatible source layouts, not a clean analytics table. It applies validation gates, preserves payment residuals, routes exceptions, prioritizes collections, shows unmet targets, and produces the artifacts a deployment team would use from discovery through go-live.

The architecture deliberately keeps financial matching deterministic and auditable. Agents handle judgment-heavy work: exception investigation, data-quality diagnosis, collection planning, and go-live monitoring. They cannot post to an ERP, issue a refund, write off debt, or alter master data.

```mermaid
flowchart LR
    A["Three simulated ERP export sets"] --> B["Configuration-driven adapters"]
    B --> C["Seven canonical receivables tables"]
    C --> D["Validation control gate"]
    D --> E["Deterministic cash matching"]
    E --> F["Exception and collections queues"]
    F --> G["MCP evidence tools"]
    G --> H["Supervisor agent"]
    H --> I["Cash Application Agent"]
    H --> J["Data Quality Agent"]
    H --> K["Collections Agent"]
    I --> L["Human approval gate"]
    J --> L
    K --> L
    E --> M["Controlled KPI benchmark"]
    M --> N["Go Live Monitor Agent"]
    O["OpenTelemetry traces"] -.-> B
    O -.-> E
    O -.-> H
    O -.-> N
```

## Run it

```bash
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
o2c-workbench --project-root .
streamlit run app.py
```

The reproducible seed-42 run creates 1,908 canonical records, detects 18 intentional duplicate bank transactions as warnings, and leaves zero validation errors. Open [the static dashboard](output/dashboard.html) or use the Streamlit app.

## MCP server

The server uses the current MCP Python SDK and exposes structured tools, resources, and prompts. Local clients should use `stdio`; deployed clients can use Streamable HTTP.

```bash
o2c-mcp --transport stdio
o2c-mcp --transport streamable-http --port 8000
```

Tools: `get_implementation_summary`, `investigate_payment`, `get_collection_priority`, and `run_controlled_benchmark`. Resources: `o2c://configuration`, `o2c://benchmark`, and `o2c://observability`.

## Multi-agent paths

The default path is offline and deterministic so a reviewer can reproduce handoffs and controls with no account or API key. It produces `output/agent_decisions.csv`, `output/agent_control_summary.json`, and OpenTelemetry spans.

An optional model-backed review uses the OpenAI Agents SDK with specialist handoffs and structured output:

```bash
pip install -e ".[ai]"
export OPENAI_API_KEY="..."
o2c-agent-review SAP-P001-09 --project-root .
```

The model path is intentionally not required for benchmark KPIs. It can recommend but cannot execute controlled financial actions.

## Repository map

- `config/` — implementation configuration, mappings, tolerances, weights, routes, controls, KPI targets, agent limits.
- `data/raw/` — generated, visibly labeled simulated ERP exports.
- `data/canonical/` — normalized customers, invoices, payments, remittances, deductions, promises, and activities.
- `src/o2c_workbench/` — adapters, matching, collections, controls, agents, MCP, observability, KPI logic.
- `output/` — benchmark evidence, queues, traces, and dashboards.
- `docs/` — process designs, mapping, controls, RTM, 28 UAT cases, cutover, monitoring, training, and research basis.
- `deliverables/` — implementation workbook.
- `demo/` — five-minute narrated implementation walkthrough and script.

## Seed-42 benchmark

| KPI | Current state | Configured future state | Movement |
|---|---:|---:|---:|
| Auto-match rate | 10.0% | 80.7% | +70.7 pp |
| Manual-review rate | 90.3% | 21.9% | -68.5 pp |
| Unapplied cash | $2,192,667 | $550,209 | -$1,642,459 |
| DSO | 115.9 days | 51.6 days | -64.3 days |
| CEI | 8.7% | 75.7% | +67.0 pp |
| Past-due AR | 69.5% | 44.9% | -24.6 pp |
| Processing time | 67.7 hours | 13.0 hours | -54.7 hours |

Four stretch targets remain unmet, so the monitor recommends a **conditional go**, not a victory lap. That is intentional implementation realism: proceed only with human approval controls and focused hypercare for unapplied cash and residual overpayments.

## Verification

```bash
pytest -q
```

See [research basis](docs/research_basis.md) for the primary sources that informed the payment cases, MCP transport choice, agent handoffs, and telemetry conventions.

TDQS

A3.7/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct function: summary/KPIs, payment investigation, collection priority, and benchmark regeneration. There is no meaningful overlap or ambiguity between them.

Naming Consistency4/5

All names use lowercase snake_case and follow a verb_object pattern, but the verb set is mixed (get, investigate, run). This is still predictable and readable, with only minor stylistic variance.

Tool Count5/5

Four tools is a tight, well-scoped surface for a synthetic O2C benchmark workbench. Each tool serves a distinct purpose without unnecessary bloat or missing core functionality.

Completeness4/5

The tool set covers the main workflows: viewing benchmark status, investigating a payment, checking collection priority, and regenerating outputs. A minor gap is the lack of explicit discovery tools for available synthetic payment or invoice identifiers, but this may be addressed through the summary.

Maintenance

ActivityMaintained
ResponsivenessNo issues