Codes 'n' Coffee Tech
PressFit · Electrical manufacturing

Putting high-frequency SAP workflows into the hands of PressFit teams.

An Electron-based API Controller and department-specific application layer that keeps SAP at the core while making reports, workflows, documents, and everyday actions easier to reach.

Updated 24 July 2026

Illustrative workflow
SAP stays central while everyday work moves closer to teams
PressFit operating layer
Role applications
Reports
Client communication
Challan OCR
SAP core
Owned actionConnected contextUseful signal
Illustrative workflow based on the described operating scope. No live client data is shown.
PressFit logo
At a glance

From operating constraint to working system.

Problem statement

PressFit had SAP in place, but its practical value was constrained by how teams reached the information inside it. Employees still depended on other departments to extract reports, answer operational questions, and coordinate follow-up. The opportunity was to make SAP-backed information usable across departments without replacing the ERP or duplicating its governed records.

Delivered system

Codes 'n' Coffee Tech first built an Electron desktop application that acts as an API Controller. A companion backend connects to SAP and other ODBC-compatible data sources through ODBC, while the controller lets the team define reusable APIs and workflows for approved consumers. Department-specific applications then use that service layer to place reports, documents, customer context, and recurring actions directly in the hands of each team.

How the system connects

A configurable service layer around SAP

The architecture separates governed operational data from department-facing experiences, allowing new applications and workflows to be added through a reusable controller instead of point-to-point database access.

SystemProcessHuman reviewOutcome

The architecture separates governed operational data from department-facing experiences, allowing new applications and workflows to be added through a reusable controller instead of point-to-point database access.

  1. System: SAP and compatible data sources. Existing operational data stays in the systems that own it.
  2. Process: Delivery challan capture. Document images enter a structured OCR path.
  3. System: ODBC connector service. One compatible boundary reads the approved source context.
  4. Human review: OCR review workflow. Extracted information is reviewed before downstream use.
  5. System: Electron API Controller. The desktop controller manages reusable integration definitions.
  6. Process: Configured APIs and workflows. Stable contracts separate applications from source structures.
  7. Outcome: Department applications. Teams receive focused reports, documents, context, and actions.
  • SAP and compatible data sources to ODBC connector service: ODBC.
  • ODBC connector service to Electron API Controller: Approved data.
  • Electron API Controller to Configured APIs and workflows: Configure.
  • Configured APIs and workflows to Department applications: Reports & actions.
  • Delivery challan capture to OCR review workflow: Image.
  • OCR review workflow to Configured APIs and workflows: Reviewed document.
SAP remains the system of record. The API Controller and ODBC connector form the reusable boundary between enterprise data and department-facing applications.
Operating modules

Designed around the work people need to complete.

Each module has a clear responsibility and passes the right context into the next owned action instead of becoming another isolated tool.

01Configurable API Controller

The Electron application provides one place to configure data connections, API definitions, and the workflows required by downstream applications.

02ODBC-backed connectivity

The connector service reads from SAP and other ODBC-compatible data sources through a consistent integration boundary.

03Department applications

Each department receives a focused application for its reports, customer context, and recurring actions instead of a replica of the full ERP interface.

04Reports and document workflows

SAP-backed reports are available on demand, while delivery-challan OCR moves captured document information into a structured review flow.

How the operation runs

A department request through the governed operating layer

The department application chooses a configured report, workflow, or document path. Source-system access and document review remain behind the controller rather than moving into each app.

EntrySystemProcessDecisionHuman reviewOutcome

The department application chooses a configured report, workflow, or document path. Source-system access and document review remain behind the controller rather than moving into each app.

  1. Entry: Need information or action. A team begins from its role-specific application.
  2. Decision: Which path is required?.
  3. System: SAP or compatible source. The connector reads the approved operational context.
  4. Process: Capture delivery challan. An image starts the OCR document path.
  5. Human review: Review extracted document data. OCR supports capture before the governed workflow continues.
  6. Process: Apply configured API or workflow. The controller returns the contract defined for that department.
  7. Outcome: Report, context, or owned action. The team continues without another department extracting the information.
  • Need information or action to Which path is required?: Request.
  • Which path is required? to SAP or compatible source: Report / data.
  • Which path is required? to Apply configured API or workflow: Workflow.
  • Which path is required? to Capture delivery challan: Document.
  • SAP or compatible source to Apply configured API or workflow: Governed response.
  • Capture delivery challan to Review extracted document data: Image + extraction.
  • Review extracted document data to Apply configured API or workflow: Reviewed data.
  • Apply configured API or workflow to Report, context, or owned action: Deliver.
Requests and governed responses move through configured contracts. Department applications do not connect directly to SAP or an operational database.
Implementation process

From operating reality to a system teams can run.

The implementation separates discovery, domain rules, architecture, module delivery, validation, and live operational improvement.

  1. Phase 01

    Report dependency discovery

  2. Phase 02

    Domain and contract modelling

  3. Phase 03

    Controller architecture

  4. Phase 04

    Department application delivery

  5. Phase 05

    Integration validation

  6. Phase 06

    Release and continuous improvement

Implementation phase detailRead how discovery, modelling, architecture, delivery, validation, and continuous improvement were handled.
  1. Phase 01

    Report dependency discovery

    Map which teams requested information from other departments, which SAP records were involved, and how frequently each request occurred.

  2. Phase 02

    Domain and contract modelling

    Translate recurring report and workflow needs into stable data contracts instead of exposing database structures directly to every application.

  3. Phase 03

    Controller architecture

    Build the Electron API Controller and ODBC-backed service as the configurable integration boundary around SAP and compatible data sources.

  4. Phase 04

    Department application delivery

    Create focused experiences for each department, consuming only the APIs and workflows needed for that team's responsibilities.

  5. Phase 05

    Integration validation

    Reconcile application responses with SAP-backed records, test connection and workflow failures, and complete department-level user acceptance checks.

  6. Phase 06

    Release and continuous improvement

    Introduce applications by operational need, then add APIs, reports, and workflows as departments identify the next high-value use cases.

Implementation detail

Decisions, validation, and clear system boundaries.

The complete technical explanation remains available here without interrupting the primary operating story.

Technical decisionsHow each operating constraint shaped an implementation choice and ownership boundary.
Constraint

Teams depended on other departments for routine SAP information.

Implementation

Deliver separate department applications backed by focused API contracts.

Why it matters

Teams can reach the information they need without reproducing the complete ERP experience.

Constraint

Operational data may live in different database products.

Implementation

Use an ODBC-backed connector boundary for compatible data sources.

Why it matters

The integration pattern remains consistent while the underlying database can vary.

Constraint

New reports and workflows continue to emerge after launch.

Implementation

Make API and workflow definitions configurable through the Electron controller.

Why it matters

The service layer can evolve without rebuilding every consumer around direct database access.

Validation and rolloutScenarios used to test the combinations most likely to disrupt live operations.

Record reconciliation

Compare controller responses and department reports with the corresponding SAP-backed records.

Connection failures

Exercise unavailable data sources, invalid queries, and interrupted ODBC connections without presenting stale success states.

Department acceptance

Validate terminology, report definitions, and actions with the teams responsible for the underlying work.

Workflow regression

Recheck existing consumers when API definitions, document flows, or source structures change.

Technical boundariesWhat the architecture owns, and where adjacent systems or human decisions remain responsible.
  • SAP remains the system of record; the applications simplify access rather than replacing ERP governance.
  • The connector boundary supports ODBC-compatible data sources rather than every database technology.
  • OCR supports challan capture and review; it does not replace the governed document workflow.
Ongoing engineering partnership

Technology that keeps moving with operations.

Codes 'n' Coffee Tech provides ongoing product engineering and application support, including workflow design, development, integrations, releases, maintenance, and operational improvements.

SAP integrationMobile applicationsOCR document capture
“We have been working with Codes 'n' Coffee Tech. for over 2 years now on a wide range of projects – web apps, desktop apps, mobile apps, chatbots, and all of them have been working flawlessly. The team is good and open to regular improvements. Working with them is fuss-free. Thanks to Codes 'n' Coffee Tech., we have the confidence that our tech stack can compete with bigger competitors with in-house tech teams.”
Aakash Rajwani·Business Developer, PressFit
Related capabilities and industries
ERP simplification Zoho Creator manufacturing workflows Enterprise operations
Let's talk

Make the ERP easier to use where work actually happens.

We can map the actions leaving your ERP and design a focused operating layer that keeps governed data connected.

Book a discovery call
Codes 'n' Coffee Tech
Share the constraint
Map the operating flow
Choose a practical next step