Current Build

DNTT Payment Request Workspace

A payment request workspace designed around controlled approvals, finance release decisions, ERP job orchestration, and operational auditability.

Workflow Logic

Decision flow behind the automation.

START

Draft Request Created

A requester creates a draft with payment header, detail lines, and attachment uploads stored in object storage.

PROCESS

Submit Transaction

The API validates required data, resolves approvers, snapshots the workflow instance, and moves the request into pending approval.

DECISION

Which Approval Path Applies?

Department mapping, position rules, and thresholds decide whether the request stops at local approvals or escalates to CFO and CEO.

Local chain CFO / CEO escalation
PROCESS

Controlled Approval Routing

The request moves through Line Manager, Reviewer, and HOD with delegation support and need-to-know visibility at record level.

DECISION

Business Approved?

Rejected, returned, resubmitted, or cancelled paths stop the finance handoff. Only approved requests move into finance control.

Yes -> Finance release queue No -> End current cycle
DECISION

Release to ERP or Hold?

Finance Operations decides whether the request should create an ERP job immediately or remain on hold for further checking.

Release to ERP Hold sync
PROCESS

Worker Queue, Retry, Reconcile

The worker pushes ERP jobs asynchronously, retries failures under policy, and runs reconcile logic for anomalies.

END

Audit and Webhook Visibility

Audit history, request timeline, ERP job updates, and outbound webhooks expose the full lifecycle to operations and admin roles.

Business Context

DNTT is a payment request workspace built as an operational business application, not just a form demo. The repository combines requester flow, approval routing, finance release control, ERP job handling, and audit visibility in one layered workspace.

Pain Points Addressed

  • Payment requests usually become fragile when draft handling, approval logic, attachments, finance release, and ERP synchronization are mixed into one path.
  • Free-form approval design creates maintenance risk, inconsistent controls, and difficult UAT.
  • ERP release should not happen automatically at final business approval because finance still needs operational control before sync.
  • Audit, retry, and record visibility are often treated as afterthoughts even though they matter in real operations.

Application Solution

The project uses a layered stack with React web, Node.js API, PostgreSQL, Redis, MinIO, and a dedicated ERP worker. The application supports draft creation, submission, approval actions, attachment handling, department-based approval setup, request audit history, finance release control, outbound webhooks, and background ERP processing.

Workflow and Control Design

  • Submit is handled as a controlled transaction that validates data, resolves approvers, snapshots the workflow instance, and moves the request into Pending Approval.
  • The approval chain stays intentionally structured: Line Manager – Reviewer – HOD – CFO – CEO, with conditional escalation instead of free-form workflow sprawl.
  • Delegation is supported within validity windows, and approver deduplication avoids redundant steps.
  • Record visibility follows a need-to-know model instead of exposing every request broadly.
  • After business approval, the request enters a finance-controlled state before any ERP release happens.

Finance and ERP Layer

A strong part of the design is the separation between business approval and ERP synchronization. Finance Operations can keep a request on hold, approve only, reject, or explicitly release it to ERP. Once released, the worker processes the ERP job asynchronously, supports manual retry, and runs reconcile logic for anomalies. That keeps approval transactions clean and avoids tying ERP instability directly to user actions.

Current Delivery Status

  • Implemented: draft, submit, approve, reject, return, resubmit, cancel, finance release queue, ERP job list, retry, reconcile, approval setup UI/API, audit timeline, and generic audit log API.
  • Still open in the repo: attachment-level visibility, field masking, advanced template configuration, and production hardening beyond the current local and UAT scope.

Why This Project Matters

DNTT shows ownership across workflow control, approval design, finance operations, ERP integration boundaries, and environment orchestration. It reads less like a UI prototype and more like a system that was shaped around actual business operating pressure.

References