Priyanka's ERP R1 Lean Spec Analysis

Code-Based Gap Analysis for the Remaining Items from Dan's Section 6 Review
Date: April 17, 2026 Analyst: Priyanka Rawat Scope: RTR-INT-002, RTR-INT-003, RTR-INT-010, EPM-INT-008, STP-INT-004
Scope: This page continues Ana's method for the remaining RICE items from Dan's analysis. Each finding is checked against live local code, ITINT estate inventory, and current implementation status rather than only the lean spec text.

Critical Corrections to Dan's Analysis

Quality Assessment by Remaining RICE Item

RTR-INT-002
COA Changes
🟢 Split / superseded - use existing workers, not coa-service
RTR-INT-003
Navan Journals Inbound
🟡 Outdated + code correction - staged batch scaffold differs from doc
RTR-INT-010
Oracle Actuals to Anaplan
🟠 Planned only - repo exists, not deployed
EPM-INT-008
Bank Statements from Kyriba
🟣 Wrong system target - evidence points to R2 / Blackline / NetSuite, not ARCS
STP-INT-004
Payment Status to SimpleLegal
🔴 Legacy path is Coupa -> SimpleLegal; target path is Oracle R2 -> simple-legal-service

Per-RICE Detailed Analysis

RTR-INT-002

Publish COA Changes from Oracle

Split / superseded ▶
Jira: ITINT-5240 / ITINT-5241 / ITINT-5242 Sources: dataflows.yaml, anaplan-worker, workforce-management-worker

Dan's Framing

Dan reviewed RTR-INT-002 like a standalone COA integration whose Section 6 needed additional contract detail around file format, timing, and downstream behavior.

🟢 Priyanka's Correction: This is no longer one standalone service

The original coa-service path was cancelled. Current estate data shows Oracle COA was refactored across existing workers instead of a new standalone service, but RTR-INT-002 should only cover the Anaplan and Workday legs. The Simple Legal COA leg should be treated as out of scope here.

# entint-knowledge/estate/dataflows.yaml:1123-1136
name: "Oracle COA -> Workday (CANCELLED - absorbed into workforce-management-worker)"
worker: coa-service
health: cancelled
notes: Superseded ... split across existing workers instead of a standalone coa-service.
# entint-knowledge/estate/dataflows.yaml:1191-1227
Oracle COA -> Anaplan (via anaplan-worker)
Oracle COA -> Workday (via workforce-management-worker)

What the code actually shows

anaplan-worker contains an Oracle COA workflow that retrieves a validated COA JSON file from R2, maps it to Anaplan CSV, and uploads it into Anaplan (anaplan-worker/internal/workflows/oracle_coa_to_anaplan.go:55-134). workforce-management-worker separately pulls validated COA JSON from R2, compares it against prior files by hash, and transforms it for Workday (workforce-management-worker/internal/coa/processor.go:59-148). Those are the two legs this lean spec should describe.

Next Steps

  1. Re-scope Section 6 so RTR-INT-002 describes the Oracle COA fan-out, not a new standalone coa-service.
  2. Document only the two in-scope legs explicitly: anaplan-worker and workforce-management-worker.
  3. Remove the Simple Legal COA leg from RTR-INT-002 and from the lean spec text for this item.
  4. Remove any language implying a net-new deployable COA service.
Spec correction

Recommended label: split / superseded scope correction.

Replace the standalone service framing with: Oracle OIC drops validated COA JSON into R2, then the in-scope existing workers independently pull and process their leg for Anaplan and Workday. Remove any Simple Legal COA references from RTR-INT-002.

RTR-INT-003

Navan Journals Inbound

Outdated + code correction ▶
Jira: ITINT-5244 Sources: navan-service origin/staging, estate docs

Dan's Assessment

Dan concluded that Section 6 was too thin and should be replaced with a full Enterprise Technical Design for a k8s-based navan-service.

🟡 Priyanka's Correction: Dan is directionally right, but the actual implementation path differs

The stronger issue is not just “missing content.” The current staged implementation does not match the documented Oracle event-driven flow. Local evidence points to a scheduled batch scaffold that pulls from Navan SFTP, decrypts files, and uploads CSVs to R2.

# entint-knowledge/estate/dataflows.yaml:1138-1147
direction: Oracle -> R2 -> navan-service -> Navan SFTP (PGP encrypted)
trigger: event, source: Oracle OIC drops journal file in R2
health: repo exists, not yet deployed
# Research verification against navan-service origin/staging
processor.go: download from SFTP -> decrypt -> upload to R2
main.go / Helm: job types = journal-fetch-daily, journal-fetch-weekly
helper.go: filenames built as Navan_Journals*<date>.csv

Current state

The service appears to be repo-only / not yet deployed (deployment-inventory.yaml:503-509, discovery-summary.md:22-24). The implementation is partly scaffolded, but there is enough concrete batch behavior to document the real path instead of writing Section 6 from zero.

Next Steps

  1. Replace Oracle event-trigger language with the actual staged batch behavior if that branch is still the intended implementation.
  2. Document the true file contract, batch schedules, and R2 landing behavior from the staged code.
  3. Explicitly state that the service is not deployed yet and that Section 6 reflects a staged implementation, not production reality.
Spec correction

Recommended label: outdated + code correction + still a gap.

Keep Dan's concern that Section 6 is incomplete, but rewrite it around the actual staged path: Navan SFTP -> navan-service batch download/decrypt -> R2, plus explicit note that deployment has not happened yet.

RTR-INT-010

Actuals for Reporting to Anaplan

Status correction ▶
Jira: ITINT-5243 Sources: estate docs, anaplan-worker code

Dan's Assessment

Dan reviewed Section 6 as if Oracle Actuals to Anaplan already had a concrete erp-service design that mainly needed environment configuration detail.

🟠 Priyanka's Correction: This flow is still planned, not implemented locally

Estate inventory says the worker is erp-service and not yet deployed. There is no local erp-service checkout here, and current Anaplan code still shows active actuals paths for NetSuite and RevPro, not Oracle.

# entint-knowledge/estate/dataflows.yaml:1111-1121
name: Oracle Actuals -> Anaplan
direction: Oracle -> R2 (oracle bucket, Actuals/In) -> erp-service -> Anaplan
health: repo exists, not yet deployed
# anaplan-worker still shows current actuals paths
revpro_to_anaplan.go: Revenue actuals upload to Anaplan
netsuite_to_anaplan.go: NetSuite files uploaded to Anaplan

Current state

deployment-inventory.yaml:503-509 explicitly lists erp-service as a service with a repo but no deployment. That means the lean spec should describe a planned target-state implementation, not imply the Oracle actuals path already exists in running code.

Next Steps

  1. Mark Section 6 as target-state / planned if the implementation has not landed.
  2. Separate current-state references (NetSuite / RevPro actuals) from future Oracle actuals behavior.
  3. Only add detailed environment IDs if they exist in the actual erp-service implementation or deployment config.
Spec correction

Recommended label: status correction.

Section 6 should explicitly say the Oracle actuals path is the intended erp-service design and is not yet deployed. Avoid presenting current Anaplan worker behavior as Oracle actuals support.

EPM-INT-008

Bank Statements from Kyriba

Wrong-system correction ▶
Sources: kyriba-worker, Boomi discovery, estate docs

Dan's Assessment

Dan treated this item as “Bank Statements from Kyriba to ARCS” and proposed writing the ITINT section from scratch.

🟣 Priyanka's Correction: ARCS is not supported by the local implementation evidence

Local code shows kyriba-worker pulling bank files from Kyriba SFTP and pushing them into R2. The Boomi estate inventory points to Kyriba -> Blackline and Kyriba -> NetSuite bank-statement flows. I could not find local evidence supporting an ARCS target.

# kyriba-worker/README.md:1-8
Process Bank Files ... Pulls files from a given SFTP directory, adds them to R2 and deletes them from SFTP
# kyriba-worker/internal/processor/processor.go:51-105
ProcessBankFiles(): list SFTP -> download -> PushFile(...R2...) -> delete SFTP file
# entint-knowledge/estate/boomi/discovery-summary.md:359-364
Kyriba -> Blackline (bank statement reconciliation)
Kyriba -> NetSuite (bank statements)

Next Steps

  1. Validate the target system name for EPM-INT-008 before drafting Section 8 content.
  2. If the intended target is Blackline, NetSuite, or HighRadius, correct the item naming first.
  3. Do not write an ARCS-specific technical design unless ARCS is confirmed by implementation evidence.
Spec correction

Recommended label: wrong-system / scope correction.

The first correction should be target validation. Current local evidence supports Kyriba SFTP -> R2 in Go and legacy bank-statement consumers in Blackline / NetSuite, not ARCS.

STP-INT-004

Payment Status Outbound to SimpleLegal

Target correction ▶
Jira: ITINT-5247 Sources: coupa-worker, temporal schedules, estate docs

Dan's Assessment

Dan focused on R2 path mismatches and timing issues in a future Oracle payment-status flow, and also called out stale references in the architecture diagram.

🔴 Priyanka's Correction: Anchor the analysis on the real as-is and to-be paths

The legacy flow is not Zylo. Local code and Temporal schedules show a daily Coupa -> SimpleLegal paid-invoice workflow. Estate docs say this will be replaced at go-live by Oracle_Payments CSV in R2 -> simple-legal-service.

# coupa-worker-new/internal/workflows/coupa_simpleLegal.go:41-97
CoupaToSimpleLegalPaidInvoices -> GetPaidInvoices -> PayInvoices
# coupa-worker-new/internal/coupa/activity.go:53-64
payment-date[gt_or_eq] defaults to yesterday UTC
# temporal-schedules.yaml:277-282
[Coupa > Simple Legal] [Invoice] Bulk Send Paid Invoices [Production]
frequency: daily at 00:25
# dataflows.yaml:1068-1082
CronJob Payments: R2 (Oracle_Payments CSV) -> SimpleLegal invoice/payment API

Current state

erp-migration.yaml:236-240 says the legacy Coupa -> SimpleLegal Payment Status Outbound flow is replaced at go-live by Oracle R2 -> simple-legal-service CronJob. That is the more important correction to preserve in Section 6 than any unrelated Zylo mention.

Next Steps

  1. Document the real as-is path as daily Coupa -> SimpleLegal batch processing.
  2. Document the to-be path as Oracle_Payments CSV in R2 -> simple-legal-service.
  3. Remove any Zylo references from this RICE item entirely.
  4. Only state a new Oracle cron time if that schedule exists in deployment config or Temporal inventory.
Spec correction

Recommended label: target / transition correction.

Frame STP-INT-004 as a go-live replacement of a legacy Coupa batch flow. The new design should start from the R2 Oracle_Payments contract and the simple-legal-service CronJob, not from unrelated historical system names.

Summary of What We Should Update