The plant floor, the bank and the tax portal

What’s available today

These integrations are part of the standard product and are switched on during the first week of go-live.

Barcode and label printing

Every document that moves stock—GRN, issue, transfer, dispatch—can print a label on any thermal printer that supports ZPL, EPL or ESC/POS. The label carries the document number, item code, batch, quantity, and a Code-128 or QR barcode. Users choose the template (batch, carton, rack) from a drop-down on the document screen; the printer is selected once in the store settings and remembered. No middleware is needed; the ERP sends the print job directly to the printer’s IP address.

Scanners and handhelds

Any Android or Windows handheld with a barcode scanner can be used for receiving, issue, transfer and dispatch. The device runs a simple web page served by the ERP; the user logs in with their normal credentials. Scanning a document number loads the line items; scanning an item code or batch number jumps to that line. Quantities are entered on the touch screen or via the scanner’s numeric keypad. Once the user taps “Post”, the transaction is written to the stock ledger in real time. No offline sync is required; if the network drops, the device buffers the last screen and posts when the connection returns.

Weighbridge and scales

Weighbridge and bench scales that output weight via RS-232, USB or TCP/IP can be connected to GRN and dispatch documents. The ERP opens a socket to the scale, reads the weight, and populates the gross, tare and net fields. For weighbridges, the driver’s name and vehicle number are captured on the same screen; for bench scales, the operator enters the batch number or item code. The weight is locked once the document is posted, so it cannot be altered later. No PLC programming is needed; the scale must simply send ASCII text in a format that the ERP can parse (e.g., “ST,GS 1234.5kg”).

Email and WhatsApp notifications

Every document that requires approval, and every report that is scheduled, can send an email or WhatsApp message. The ERP uses its own SMTP server or a customer-provided one; for WhatsApp, it connects to the customer’s official WhatsApp Business account via the WhatsApp Cloud API. Notifications are triggered by document status changes (e.g., “Approval pending”, “Posted”) or by scheduled report runs. The message includes the document number, date, amount, and a link that opens the document in the ERP. No third-party notification service is needed; the ERP sends the messages directly.

Excel and PDF exports

Every report and register can be exported to Excel (XLSX) or PDF. The export button is on the report screen; the user chooses the format and the file is generated on the server and downloaded. Excel exports preserve the report’s filters, groupings and totals; PDF exports use the same layout as the on-screen report. No additional licence is required; the export capability is built into the report engine.

What we build on request

These integrations are not in the standard product. They are quoted separately, built only after the core ERP is live, and require the customer to provide access to the external system or a test environment.

E-invoicing and tax portals

For countries that mandate real-time invoice reporting (e.g., India’s GST, Saudi Arabia’s ZATCA, Egypt’s ETA), the ERP can generate the required JSON or XML payload and submit it to the tax portal. The integration includes error handling, retry logic, and a dashboard that shows the status of each invoice (submitted, accepted, rejected). The customer must provide the API credentials and a test environment; the integration is built against the portal’s sandbox and then switched to production. No changes to the ERP’s core invoice schema are made; the payload is generated from the existing data.

Bank statement import and payment files

The ERP can import bank statements in MT940, CAMT.053 or CSV format, reconcile them against open invoices, and mark invoices as paid. It can also generate payment files in ISO 20022 (pain.001) or bank-specific formats for bulk payments. The customer must provide the bank’s file format specification and a sample file; the integration is built to parse the file and map the fields to the ERP’s payment tables. No direct connection to the bank’s API is provided; files are uploaded manually or via SFTP.

Machine counters and PLC data

For weaving, dyeing, finishing and stitching machines that output production data via PLC or OPC UA, the ERP can read the counters and post them to the production module. The integration includes a small service that runs on a local PC or Raspberry Pi, polls the PLC at a configurable interval, and sends the data to the ERP via its REST API. The customer must provide the PLC’s IP address, the memory addresses of the counters, and a mapping of counters to ERP production orders. No real-time dashboard is provided; the data is written to the production shift report and used for costing.

Marketplace and e-commerce order intake

The ERP can pull orders from Shopify, WooCommerce, Amazon Seller Central or any marketplace that offers a REST API. The integration runs on a schedule (e.g., every 15 minutes), fetches new orders, and creates them in the ERP’s order book. The customer must provide the API credentials and a mapping of marketplace fields to ERP fields (e.g., “SKU” to “Item Code”, “Shipping Method” to “Delivery Terms”). No inventory sync is provided; stock levels are managed in the ERP and pushed to the marketplace via a separate integration if required.

Payroll and biometric attendance devices

The ERP can import attendance data from biometric devices that output CSV or Excel files, and use it to calculate payroll for daily-wage and piece-rate staff. The integration includes a screen where the customer uploads the file; the ERP parses it, matches the employee IDs, and posts the hours or pieces to the payroll module. The customer must provide the file format and a mapping of device fields to ERP fields (e.g., “User ID” to “Employee Code”, “In Time” to “Shift Start”). No direct connection to the device’s API is provided; files are uploaded manually.

The API

Every module exposes a REST API that uses the same authentication, permissions and data model as the web interface. The API is documented in OpenAPI (Swagger) format; the documentation is available at /api/docs on every installation. Authentication is via bearer tokens; the token is generated on the user’s profile screen and expires after 24 hours. Every API call is logged in the activity tracking module, including the user, the endpoint, the parameters, and the response time.

What the API can do

• Create, read, update and delete any document that the user has permission to access.
• Run any report that the user has permission to run, with the same filters and exports.
• Upload and download files (e.g., images, PDFs, Excel exports).
• Trigger approvals and post documents.
• Subscribe to webhooks for document status changes (e.g., “Approval pending”, “Posted”).

What the API cannot do

• Bypass permission checks. If a user cannot edit a purchase order in the interface, they cannot edit it via the API.
• Alter the ERP’s core data model. Custom fields can be added via the customisation module, but the API will not expose fields that do not exist in the database.
• Run in real time for high-volume data. The API is designed for transactional use (e.g., creating an order, posting a GRN); it is not optimised for bulk data export (e.g., downloading 100,000 stock transactions). For bulk exports, use the report exports or the database backup.
• Connect to external systems without the customer’s involvement. The customer must provide the credentials, the test environment, and the mapping of fields.

How to use the API

To use the API, the customer or their developer:

1. Generates a token on the user’s profile screen.
2. Reads the API documentation at /api/docs.
3. Writes code to call the API, using the token in the Authorization header.
4. Handles errors (e.g., 401 Unauthorized, 403 Forbidden, 400 Bad Request) and retries if needed.
5. Logs the API calls in their own system for audit purposes.

What we do not do

• We do not build custom integrations during the initial implementation. The core ERP must be live and stable before any integration work begins.
• We do not provide middleware or ETL tools. If the customer needs to transform data between systems, they must write the code themselves or use a third-party tool.
• We do not support direct database access. All integrations must use the REST API; no SQL queries are allowed on the production database.
• We do not guarantee uptime for external systems. If the tax portal, bank, or marketplace API is down, the integration will fail and the customer must retry later.
• We do not provide 24/7 support for integrations. Issues are handled during normal business hours; critical failures are prioritised, but no SLA is offered.

What happens in week one

During the first week after go-live, the following integrations are set up:

• Barcode and label printing: templates are created for batch, carton and rack labels; printers are configured in each store.
• Scanners and handhelds: a test device is registered; users are trained on the scanning workflow.
• Weighbridge and scales: the scale’s output is tested with a sample weight; the GRN and dispatch screens are configured to show the weight fields.
• Email and WhatsApp notifications: the customer’s SMTP and WhatsApp credentials are entered; test messages are sent to confirm delivery.
• Excel and PDF exports: users are shown how to export reports and where to find the export button.

No custom integrations are started in week one. The customer is given access to the API documentation and can begin testing API calls, but no production data is exposed until the core ERP is stable.

What you need to provide

For each integration, the customer must provide: