Accord ERP Automation is a production engineering organization focused on ERPNext-centered operational systems: warehouse execution, mobile workforce flows, delivery processes, scale integrations, Zebra printing, read-optimized ERP APIs, and automation layers that keep real operations measurable and reliable.

The organization builds around a simple boundary: ERPNext remains the system of record, while specialized services provide fast mobile APIs, deterministic read models, hardware orchestration, notification flows, and operational tools that are easier to test, benchmark, deploy, and evolve independently.

The platform is developed as an engineering research program around practical ERP performance and reliability:

• Preserve ERPNext business semantics while reducing operational latency.
• Use direct MariaDB reads only for deterministic read models and search.
• Keep mutations inside ERPNext REST so validations, hooks, permissions, and document side effects remain owned by ERPNext.
• Validate service changes with production-like datasets before declaring a replacement ready.
• Treat mobile users, warehouse staff, operators, scales, printers, and back-office workflows as one connected system instead of isolated apps.
• Prefer measured evidence over assumptions: benchmark first, optimize second, document the result.

flowchart TB
    ERP["ERPNext<br/>Documents, permissions, hooks"]
    DB["MariaDB<br/>ERPNext read model source"]
    Custom["accord_erp_custom_field<br/>Structured bridge fields"]

    RustMobile["accord_mobile_server_rs<br/>Production mobile backend"]
    Mobile["accord_mobile<br/>Flutter mobile app"]

    GScale["gscale-platform<br/>Scale, Zebra, Telegram, archive"]
    CatalogGo["gscale-erp-read<br/>Go read-only catalog API"]
    CatalogRust["gscale-erp-read-rs<br/>Rust read-only catalog API"]
    GScaleApp["gscale-mobile-app<br/>Flutter GScale client"]

    FCM["Firebase Cloud Messaging"]
    AI["Gemini Vision<br/>Werka image search"]
    Hardware["Scales and Zebra printers"]
    Telegram["Telegram operations"]

    ERP --> DB
    ERP --> Custom
    DB --> RustMobile
    DB --> CatalogGo
    DB --> CatalogRust
    Custom --> RustMobile
    RustMobile --> ERP
    RustMobile --> FCM
    RustMobile --> AI
    RustMobile --> Mobile

    Hardware --> GScale
    GScale --> ERP
    GScale --> Telegram
    CatalogGo --> GScale
    CatalogRust --> GScale
    GScale --> GScaleApp

The Accord mobile platform is built from a small set of focused systems:

• Mobile backend: accord_mobile_server_rs, Rust/Axum/Tokio.
• Mobile client: accord_mobile, Flutter/Dart.
• ERPNext extension: accord_erp_custom_field, Python/Frappe.
• Mobile client contract: unchanged HTTP routes, auth order, status codes, JSON shapes, push behavior, and ERPNext side effects.
• Read strategy: direct MariaDB projections for read-heavy mobile views.
• Write strategy: ERPNext REST for all document mutations.
• Local state strategy: LMDB for sessions, profile preferences, push tokens, and admin operational state.

The mobile backend has a published production release:

• Latest release: accord_mobile_server_rs v1.1.0
• Production validation includes restored ERPNext data, benchmarked hot paths, SQL pushdown checks, HTTP/healthz tuning, Hyper HTTP/1 accept-loop tuning, and FD-pressure testing.
• Verification baseline: cargo fmt --check and cargo test --locked.

Every production-facing service is expected to satisfy four engineering conditions before being treated as release-ready:

• Contract safety: the mobile API must keep stable route behavior, response shapes, auth behavior, and ERPNext side effects.
• Data safety: reads may be optimized, but business mutations stay inside ERPNext's document lifecycle.
• Performance evidence: important hot paths are benchmarked with production-like data and documented before rollout.
• Operational resilience: services must preserve health under load, connection pressure, and local-state growth.

Detailed benchmark evidence lives inside the service repository rather than the organization profile.

Business mutations go through ERPNext REST. Direct database access is used only for read models, lookup, search, aggregation, and projections where the result can be proven equivalent to the mobile contract.

Replacement services must preserve the mobile client contract: routes, query defaults, auth order, error bodies, status codes, JSON shapes, push behavior, and ERPNext side effects.

Optimization is accepted only with reproducible evidence: before/after benchmarks, production-like datasets, failure counts, latency percentiles, CPU and memory observations, and documented tradeoffs.

Session, profile, push-token, and admin runtime state are small, hot, persistent operational datasets. LMDB is used where full JSON rewrites create latency amplification under login/session pressure.

Search, filtering, mobile flows, printer integration, and notification behavior are designed for real warehouse and delivery users, including staff with uneven technical literacy. A fast system is not allowed to become less usable.

• ERPNext workflow automation.
• Warehouse receiving, confirmation, return, and delivery operations.
• Supplier, customer, Werka, and admin mobile workflows.
• Scale and Zebra printer orchestration.
• Read-only ERP catalog APIs.
• Push notification and operational messaging flows.
• AI-assisted item/customer/supplier search.
• Archive, audit, and field-activity traceability.

• Keep ERPNext credentials, Firebase service accounts, and production secrets out of repositories.
• Report vulnerabilities privately through the organization security policy.
• Benchmark with production-like data, but avoid unsafe mutation stress against live ERPNext documents.
• Treat hardware integrations and mobile field workflows as production systems, not demos.
• Keep operational handoff documents current when architecture or performance behavior changes.

Accord ERP Automation exists to make ERPNext-backed operations faster, observable, and safer without hiding the business system underneath.