System context — Frappe, ERPNext, Lee Kim, and docs

Purpose

Situate Lee Kim customizations within the same mental model as ERPNext and the Frappe Framework: web app, background jobs, database, and external services. This page also shows that this documentation site (Astro + Starlight on Cloudflare Pages) is not part of the ERP runtime.

References

ERPNext introduction — product modules and concepts.
Frappe architecture — apps, sites, DocTypes, hooks.

System context (logical view)

Notes

Desk is the standard Frappe/ERPNext UI; custom Pages and Print Formats extend it per site.
Lee Kim logic lives mainly under leekimerp/lee_kim_alliance_erp/, leekimerp/api/, and leekimerp/hooks.py.
The handover docs you are reading are static HTML; they do not process ERP transactions.

Trust boundaries (who can do what)

Understanding trust zones prevents accidental exposure of PII, financial data, or integration tokens.

Zone	Typical actors	Trust assumption
Desk (authenticated)	Staff users with Frappe roles	Session + permission model; audit via Doc revision
Website / portal	Customers or applicants	Often limited DocTypes; may use guest APIs — treat as semi-trusted
Integration callbacks	Xero, Stripe, DocuSign, Singpass	Verify signatures / OAuth state; never trust raw payload without checks
Background workers	Scheduler, email queue	Run as site context; can mutate data without a human click
Docs site (static)	Developers, auditors	Untrusted for secrets — must not embed credentials

Implication: Any @frappe.whitelist(allow_guest=True) endpoint sits on the boundary between public internet and your database. Maintain an explicit list (API inventory) and review periodically.

Data classification (practical)

Use this as a working model for runbooks and access reviews (refine with your DPO):

Class	Examples	Handling
Public	Marketing copy, non-sensitive FAQs	Normal web caching OK
Internal	Internal notes, non-PII operational metrics	Desk roles
Confidential	Customer financials, payroll, incorporation documents	Strict roles; encryption at rest via Frappe; limit exports
Regulated identifiers	NRIC/FIN patterns, government IDs (where applicable)	Minimize storage; follow local PDPA / sector rules

Singpass and MyInfo flows often involve regulated identifiers — treat related DocTypes and logs as highest sensitivity.

Failure and degradation modes

When an external system is down, the ERP should fail safely:

Dependency	User-visible symptom	Engineering response
Xero API	Sync lag, invoice mismatch	Surface status in DocType; queue retries; avoid double-posting
Stripe	Payment link errors	Do not duplicate invoices; check webhook idempotency
Email provider	Missing notifications	Monitor email queue; alert ops
MariaDB	Full outage	Stop-the-line; restore from backup (Runbook)

Document SLOs (even informal) in your internal ops wiki; this handover site does not replace live monitoring.

Optional socket.io layer

Some deployments pair a Node / socket service with Frappe for realtime UI updates. If present in the repo (sockets/ or root package.json), treat it as a separate process with its own deploy and health checks — see Socket.io realtime.