How ERPNext and Unicommerce integration works for multi-marketplace sellers
A seller running orders across several marketplaces through Uniware, while accounting and stock stay in ERPNext, needs the two systems to agree on what exists, how much is available and what was sold. The ERPNext and Unicommerce integration uses Uniware's REST APIs and is delivered as a Frappe app that the Frappe team officially supports. It covers four flows: two-way item catalogue sync, one-way inventory sync from ERPNext to Uniware, new sales order sync, and sales invoice sync or generation. Each flow has its own direction and its own risks, so treat them as separate decisions rather than one switch.
The catalogue flow is the one to scope first. Items move in both directions, so the team must decide which system is the master for item names, codes, units and attributes before go-live. Inventory moves only from ERPNext to Uniware, which makes ERPNext the stock source of truth; any stock adjustments made directly in Uniware will not flow back, so the operations team needs an agreed rule for where receipts and adjustments are entered. Confirm the warehouse-to-location mapping with your own Uniware setup before you rely on it.
Sales orders arrive in ERPNext from Uniware, and sales invoices can be synced or generated from them. Ask the integration owner which document is created first, how taxes and marketplace charges are mapped, and what happens to cancelled or returned orders. The exact field behaviour, including how each field maps between Item and Uniware product records and which invoice options apply, is documented in the ERPNext Unicommerce integration documentation. Read that page against a test site before finalizing your mapping sheet.
What you need before installing the Unicommerce integration in ERPNext
The Unicommerce integration depends on four things lining up: a supported ERPNext and Frappe version, API access to Uniware, a network path from your server, and people who own the data. Confirm each one before anyone runs an install, because a gap in any of them usually surfaces as a failed sync after go-live.
Supported ERPNext and Frappe versions
Confirm that your ERPNext and Frappe Framework versions are still listed as supported on Frappe's support versions page before you choose a hosting path. Version 14 has reached end of life, so a site on that line needs an upgrade plan before the integration is added. Also check that the Unicommerce app's documentation names your version, since the app must match the ERPNext release it runs on.
Uniware account and API credentials
The integration authenticates to Uniware's REST APIs, so you need a Uniware account with API access enabled and credentials issued by Unicommerce. Ask Unicommerce which user or integration identity will be used, what permissions it carries, and whether credentials can be rotated without downtime. Store these outside shared spreadsheets from the start.
Outbound HTTPS to Uniware endpoints
The ERPNext server must reach Uniware's API endpoints over outbound HTTPS. Check this from the same host and network segment that will run the scheduled sync, including any egress firewall, proxy or NAT rules your security team controls. Confirm the exact endpoint hostnames with Unicommerce, because allowlists written against the wrong hostname block the sync silently.
A staging site for testing
Install and test the integration on a staging site with a copy of your item and warehouse masters before touching production. Staging lets you exercise the inventory push, order pull and invoice creation against test data, and it gives you a place to rehearse rollback. Confirm with Unicommerce whether a non-production Uniware tenant is available, since testing against live inventory can change stock levels for real marketplace listings.
A named master data owner
Assign one person to own item codes, item groups, warehouses and their mapping to Uniware facilities. The two-way catalogue sync and one-way inventory sync both depend on consistent identifiers, so duplicate SKUs or unmapped warehouses cause the most common mismatches. This owner signs off the mapping before the first sync and approves any later change to item or warehouse structure.
Installing and configuring the Unicommerce app step by step
This sequence takes an ERPNext site from a confirmed version to a tested, two-way Unicommerce connection, with each stage checked before the next one switches on. Working in this order keeps catalogue errors from spreading into inventory and orders.
Confirm the ERPNext site version
Before anything is installed, check that the ERPNext and Frappe Framework versions on the site are on a supported release line, using the supported versions page for Frappe products. Confirm the same with your Unicommerce contact, since the app's compatibility depends on the Frappe version in use. Your team should record the exact versions in the change ticket. The step is complete when the version numbers are written down and match a line that Frappe still supports.
Install the app on a staging site
Using the bench command line tool, install the Frappe-supported Unicommerce app on a staging site that holds a copy of your production data, following the install steps in the ERPNext Unicommerce integration documentation. Do not install it on production first. Run the migrate step after installation so the app's doctypes are created. The step is complete when the app appears in the site's installed apps list and the site loads without errors.
Enter Uniware credentials and tenant details
Open the Unicommerce settings in the staging site and enter the Uniware API credentials and tenant details supplied for your account, as listed in the integration documentation. Store the credentials only in the settings fields, not in custom scripts or shared documents. Save, then run the connection check the settings page offers. The step is complete when the connection test succeeds and the settings show your tenant, with no authentication errors in the error log.
Map warehouses and item groups
Map each Uniware facility to the matching ERPNext warehouse, and map the item groups you want to sync to the Uniware categories they belong to. Ask your ERP lead to sign off the mapping, because it decides where stock is counted and which items are created. Check that every active warehouse with stock has exactly one mapping and no warehouse is mapped twice. The step is complete when the mapping table lists every intended warehouse and item group, with no blank rows.
Run a catalogue pull before any push
Run the item catalogue pull from Uniware into ERPNext first, so existing SKUs are matched rather than duplicated. Review the items that were created, matched or skipped, and resolve mismatches in ERPNext before enabling any push. Then compare the item count in ERPNext with the active SKU count in Uniware. The step is complete when the two counts reconcile and a sample of matched items shows the right item codes, units and groups.
Enable inventory sync for selected warehouses
Turn on one-way inventory sync from ERPNext to Uniware for a limited set of warehouses, leaving the rest off until the first set is verified. Adjust stock in a test warehouse in ERPNext, then confirm that the quantity changes in Uniware within the sync window your team observes. Keep the warehouse list documented, since the sync only runs for the warehouses you select. The step is complete when a controlled stock change appears correctly in Uniware and matches the ERPNext stock ledger.
Enable order and invoice sync and trace a test order
Turn on new sales order sync and sales invoice sync or generation, and place a test order in the staging marketplace or Uniware sandbox your team uses. Follow the order from Uniware into ERPNext as a Sales Order, then through to the invoice, and check the customer, item lines, tax and totals against the source. Repeat with one order that has a return or cancellation if your process uses them. The step is complete when the test order is traced end to end with no mismatches, and the team signs off before production cutover.
Which records sync in each direction and who owns the source
The item catalogue is the only flow that runs in both directions, so it needs an explicit rule for which side wins when the same item changes in each system. Item codes, names, descriptions and identifiers are the records most likely to be edited in both places, and a silent overwrite can change how a listing appears on a marketplace. Decide the owner per field, not per record, because a team may want ERPNext to own pricing and accounting attributes while Uniware owns marketplace-facing listing details.
- Field-level ownership: List the item fields you will sync and name the owning system for each one, such as item code and cost in ERPNext and channel-facing attributes in Uniware.
- Conflict rule: Choose whether the most recent change, the owning system or a manual review queue wins when both sides change the same item.
- Item groups and units: Agree how ERPNext item groups and units of measure map to Uniware categories before the first full sync.
- Price lists: Confirm which ERPNext price list, if any, feeds selling prices, and whether Uniware keeps its own marketplace pricing.
- Initial load: Decide whether existing items are matched by code or created as new, since duplicate items are hard to unwind once orders reference them.
Before go-live, run the catalogue sync against a small test set and confirm the conflict rule behaves as written. Ask the connector's maintainers which fields are supported in your installed version.
Inventory sync is one-way from ERPNext to Uniware, which makes ERPNext the authority for stock counts and reservations. Uniware uses the figures it receives to decide what is available to sell, so any stock that ERPNext has not yet reserved, received or adjusted can be sold on a marketplace. The owner must decide which ERPNext warehouses count toward availability and how in-transit, damaged and quarantined stock is treated.
- Authoritative warehouses: List the ERPNext warehouses whose stock is offered in Uniware and exclude any that hold returns, samples or stock reserved for B2B contracts.
- Reservations: Decide whether open Sales Orders and pending deliveries in ERPNext reduce the quantity sent, so that committed stock is not sold twice.
- Stock movements: Confirm which ERPNext transactions, such as stock entries, purchase receipts and delivery notes, trigger an inventory update and how often the sync runs.
- Adjustments and damage: Agree who records stock write-offs and whether they must be posted in ERPNext before Uniware is updated.
- Batch and serial items: Check whether serial or batch tracking in ERPNext needs to be reflected in Uniware or whether quantities alone are enough.
Verify the sync by comparing ERPNext stock balances with Uniware availability for a sample of items after a full cycle. Ask for the sync frequency and the failure handling behavior in writing before you rely on it.
New sales orders originate in Uniware, which receives them from the marketplaces, and the connector creates matching Sales Orders in ERPNext. Uniware owns order status, marketplace identifiers and fulfillment events, while ERPNext owns the accounting and customer records that follow from the order. The owner must decide how marketplace orders map to ERPNext customers, taxes and shipping charges so that the same sale is not recorded twice.
- Customer mapping: Decide whether marketplace buyers become individual ERPNext customers, one generic customer per channel, or matched existing customers, since this affects receivables reporting.
- Tax templates: Assign the ERPNext sales tax templates that apply to each channel and region, and confirm them with your tax adviser before enabling sync.
- Shipping and fees: Map marketplace shipping charges and commission deductions to the income or expense accounts you want them posted to.
- Company and warehouse: Name the ERPNext company and default warehouse that receive each channel's orders.
- Cancellations and returns: Agree how cancelled orders are handled after a Sales Order exists, and who is responsible for correcting them in ERPNext.
Test with orders from each marketplace you sell on and confirm that the Sales Order, customer and tax lines match what Uniware shows. Confirm the order statuses that the connector treats as final.
Sales invoices can either be generated in ERPNext from the synced orders or synced from Uniware, and this choice decides which system is the accounting record. Generating invoices in ERPNext keeps the ledger in one place, while syncing from Uniware suits teams whose invoice numbering and compliance output already live there. The owner must choose one approach per channel and document the reason, because two invoices for the same sale distort revenue and tax reports.
- Invoice source: Decide whether ERPNext generates the invoice from the Sales Order or receives an invoice record created in Uniware.
- Numbering: Agree the invoice number series and who controls it, so invoices issued by the two systems never share a sequence.
- Timing: Define when an invoice is created, such as at order import, at dispatch, or at delivery, and whether it is posted to the ledger at that point.
- Returns and credit notes: Decide how returned items are reversed, whether through a Sales Return in ERPNext or a credit note synced from Uniware, and which warehouse receives the goods back.
- Tax and currency: Confirm the tax treatment on each invoice and the currency used for marketplace settlements.
Before relying on invoice sync, reconcile a month of ERPNext invoices against Uniware records and against marketplace settlement reports. Confirm with your accountant and tax adviser which invoice rules apply in your jurisdiction.
How items, warehouses, orders and invoices map between Uniware and ERPNext
This table lists how each Uniware object is expected to land in ERPNext during the Unicommerce integration, and which fields you must confirm against the app's current field list. Use it as a checklist before the sync goes live, not as a final specification. The main takeaway is that identifiers, tax and charge fields are where mismatches usually appear.
| Uniware object | ERPNext counterpart | Direction and sync type | What to confirm before go-live |
|---|---|---|---|
| SKU and item code | Item (item code, item name, item group) | Two-way catalogue sync | Confirm which Uniware SKU field becomes the ERPNext item code and how renamed or duplicate SKUs are handled |
| Facility or warehouse | Warehouse (within the company) | One-way inventory sync from ERPNext to Uniware | Confirm how each Uniware facility is linked to an ERPNext warehouse and which warehouse stock is pushed from |
| Channel and marketplace identifiers | Sales Order custom or reference fields | Inbound with new sales order sync | Confirm which marketplace order ID, channel and display order fields are stored and where they appear on the document |
| Sales order header and customer | Sales Order and Customer | Inbound with new sales order sync | Confirm how buyer records are created or matched, and whether marketplace customers are grouped under one customer |
| Order lines, quantities and rates | Sales Order items | Inbound with new sales order sync | Confirm how partially shipped, cancelled or returned lines are reflected and which rate field is used |
| Tax and tax templates | Sales Taxes and Charges template on the order and invoice | Inbound with sales invoice sync | Confirm which tax components Uniware sends, how they map to ERPNext tax accounts and whether tax is calculated or copied |
| Shipping charges and discounts | Additional charges or discount lines on the invoice | Inbound with sales invoice sync | Confirm the accounts used for shipping income and marketplace discounts, since these affect revenue reporting |
| Invoice number and invoice data | Sales Invoice (posting date, totals, status) | Sales invoice sync or generation | Confirm whether ERPNext generates the invoice or receives Uniware's invoice, and how invoice numbering stays unique |
Why inventory and order ownership decide the integration design
The one-way inventory flow from ERPNext to Uniware makes ERPNext the source of stock truth for every warehouse it feeds, so the integration design starts with a simple rule: a stock movement must be posted in ERPNext before the availability it creates is pushed to a marketplace. Goods receipts, stock transfers and manufacturing output (a Work Order's finished goods, for example) need to exist as ERPNext documents with the correct warehouse and item before the sync reads them. If a receipt is only recorded in a warehouse system or a spreadsheet, the marketplace will show stock that ERPNext does not yet hold, and the sync will report availability that the books cannot support. Ask the team which documents create on-hand quantity today and confirm that each one is posted on the day the goods physically move.
The larger risk is double counting. Marketplaces adjust listing quantities when orders arrive, Uniware adjusts its own inventory when orders are picked, packed and returned, and ERPNext adjusts stock when delivery notes, transfers and stock reconciliations are submitted. If more than one of these systems decreases the same unit, the same sale can reduce available stock twice, and the error grows with each order. Before go-live, settle one authority per warehouse: decide which system owns on-hand quantity for that location, which system only reports against it, and who is allowed to post adjustments. Write the decision down for each warehouse, including returns handling and damaged or quarantined stock, because these are the cases where teams most often adjust stock in two places.
Order ownership follows the same logic. The integration creates Sales Orders and sales invoices in ERPNext from Uniware, so the team must decide which system is the record of a sale at each stage, and which document reserves or deducts stock when the order is confirmed. Test this with a small set of orders in a staging site, including a cancellation, a partial shipment and a return, and compare the Bin quantities and the stock ledger after each step against what Uniware shows. Any step where the two disagree should be resolved in the design before the catalogue and inventory syncs are switched on in production.
Securing Uniware credentials and ERPNext access during the integration
The Unicommerce connector holds API credentials for Uniware and can create and update stock and sales records in ERPNext, so its security depends on several layers working together. The cards below cover where secrets live, who can change the connector, how the server is protected in transit, and how sync activity is reviewed and credentials are rotated.
Store Uniware credentials in site configuration
Keep the Uniware API credentials in the site configuration file rather than in Server Scripts, custom app code, Client Scripts or exported customizations, where they could be copied into version control or printed in a report. Confirm the exact configuration keys the app expects in the Unicommerce integration documentation before you write them. Restrict file permissions on the site configuration so only the bench user and administrators can read it, and check that backups and log files do not echo the secret values. Never paste a live credential into a ticket or chat thread.
Create a dedicated integration user
Run the sync under a separate ERPNext user that exists only for the integration, not under a person's account or an administrator login. Give that user only the DocType permissions the connector needs to read and write Items, Sales Orders, Sales Invoices and Stock records, and nothing for accounting masters or user management. Use role permissions and, where relevant, user permissions to limit the company or warehouse the user can touch. Review the role list after each app update, since new features can request additional access.
Limit who edits connector settings
The connector settings control which warehouses push inventory, how Uniware channels map to ERPNext records and whether invoices are generated automatically. Changing these values can alter stock levels or accounting entries across every marketplace at once. Restrict edit rights on the settings document to a small named group, and log who changed what. Ask the implementation team to document each mapping decision so a later change is reviewed against that record.
Serve ERPNext only over HTTPS
Uniware and ERPNext exchange order and inventory data over the network, and login sessions and API tokens must not travel in clear text. Terminate TLS on the ERPNext web tier with valid certificates, redirect plain HTTP, and confirm that the host name used for webhooks or callbacks matches the certificate. Check that the Frappe site is not reachable on an unauthenticated internal port from the internet. Your network team should confirm the firewall rules for outbound calls to Uniware endpoints.
Keep Server Scripts disabled
From version 15, Frappe disables Server Scripts by default and they must be enabled with the server_script_enabled setting. The Unicommerce app does not need them, so leave them disabled unless a specific custom step cannot be built another way. If you do enable them, treat each script as code that runs with server privileges, review it like any other change, and remove it once the step is no longer needed. Note that Frappe Cloud public shared benches do not allow Server Scripts at all.
Audit sync logs and rotate credentials
Review the integration's sync logs and the ERPNext Activity Log on a fixed schedule, looking for failed authentication, unexpected bulk changes to stock or pricing and sync runs from unfamiliar sources. Set a rotation procedure that is triggered when a staff member who knew the credentials leaves, when a vendor contractor finishes work, or when a secret may have been exposed. Confirm with Unicommerce how a key is reissued and whether the old key stops working immediately, then update the site configuration and test a sync before closing the change.
Common Unicommerce sync failures and how to fix them
This table lists the failures teams most often hit when running the Unicommerce connector, with the usual cause and the check that confirms it. Read the rows in order, because item and warehouse mapping must be correct before orders and stock can sync. Reproduce each fix on a test site first, and use the app's log entries in ERPNext together with Uniware's API responses to confirm the cause.
| Failure | Likely cause | Fix and how to confirm |
|---|---|---|
| Credentials rejected | API user lacks access, the token has expired, or the Uniware tenant details are wrong. | Confirm the API user's permissions with Unicommerce, re-enter credentials, and test the connection on a test site. |
| Orders fail to link to items | The SKU in the ERPNext Item differs from the Uniware item code in case, spacing or prefix. | Agree one SKU key, correct the mapping, re-run catalogue sync, then reprocess the failed orders. |
| Warehouse mapping missing | A Uniware facility has no matching ERPNext Warehouse, so stock and orders have no target. | Create or map a Warehouse for each facility, save the mapping, and check stock per facility after the next sync. |
| Inventory pushed before receipts | Purchase Receipts or stock entries were not submitted, so ERPNext sends zero or low stock to Uniware. | Post receipts and stock reconciliations before enabling inventory sync, and compare Uniware counts with the physical count. |
| Duplicate orders after a retry | A timed-out request was resent without checking whether the marketplace order already exists. | Search for the marketplace order reference before retrying, cancel duplicates carefully, and confirm retry behavior on a test site. |
| Tax template mismatch on invoices | Tax lines from the marketplace do not match the ERPNext Sales Taxes and Charges template for that region. | Create or confirm a template for each tax rate, map it, and check one test invoice's totals before going live. |
| Sync stops after an upgrade | ERPNext or the Unicommerce app moved to a version pair that is not compatible, or the scheduler is not running. | Check both versions against the supported versions list, confirm the scheduler runs, and upgrade the app on a test site first. |
Questions sellers ask before hiring help for the Unicommerce integration
How much does it cost to connect ERPNext to Unicommerce?
The cost depends on the written scope, and DeployOpen quotes it from that scope rather than from a price list. Self-hosting ERPNext is free under its open-source license, so the spend is on people and infrastructure. Cost components usually include planning the catalogue and stock mapping, installing and configuring the Frappe app, testing against your Unicommerce account, and any work on your own ERPNext customizations. Some costs are one-time, such as the build and first cutover. Others recur, such as hosting, Unicommerce subscription fees if they apply, and support or upgrade retainers. Ask for the quote to split these lines, and confirm Unicommerce licensing and API access with Unicommerce before you commit.
How long does an ERPNext and Unicommerce integration take?
Duration depends on how many sales channels feed Uniware, how clean your item master is, and how many invoicing rules differ from the app defaults. The main drivers are the catalogue mapping decisions, the number of warehouses and stock locations you sync, and the test cycles needed to confirm order and invoice flows. A simple single-warehouse setup with clean item data will move faster than a multi-warehouse operation with bundles and custom tax rules. Ask for a timeline in the written scope, with separate milestones for configuration, testing and go-live.
What do we need to provide before the work starts?
You need to provide a working ERPNext site where you have administrator access, a Unicommerce account with API access, and a clear list of the channels and warehouses in scope. Prepare an item master with consistent SKUs, since the catalogue sync depends on it. You should also decide your chart of accounts mapping for sales and tax, and name the people who will approve test orders and invoices. Confirm with Unicommerce which API credentials and permissions your account includes before the engagement starts.
Can our own team install the Unicommerce app without a partner?
Yes, a competent ERPNext administrator can install a Frappe app on a bench, but the installation is the smallest part of the work. The harder parts are configuring the sync direction for each item field, testing order and invoice behavior, and deciding how errors are handled. Your team should be comfortable with Frappe app installation, site backups before changes, and reading logs. If you lack that experience or your site runs on Frappe Cloud with restrictions, a partner can handle the setup while your team learns the operating model.
Which decisions drive the most implementation work?
Three decisions usually cause the most rework. The first is item ownership: the catalogue sync is two-way, so you must decide which system is the source for each field. The second is inventory: inventory sync runs one way from ERPNext, so warehouse and location mapping must match how stock is actually held. The third is invoicing: you must decide whether sales invoices are synced from Unicommerce or generated in ERPNext, along with tax and discount treatment. Settle these before configuration, because changing them later means re-testing orders and reconciling stock.
Does the Unicommerce app cover every marketplace we sell on?
The integration connects ERPNext to Uniware through its REST APIs, so marketplace coverage depends on what Uniware itself connects to. The app covers the catalogue, inventory, sales order and sales invoice flows described in the ERPNext documentation. It does not replace your marketplace accounts, and any marketplace-specific fee, settlement or return logic may need custom work. List every channel and its required data fields during scoping, then confirm with Unicommerce which channels your account supports.
Is the Unicommerce integration supported by the Frappe team?
The integration is delivered as a Frappe app that the Frappe team officially supports, according to the ERPNext Unicommerce integration documentation. Support from Frappe depends on running a supported ERPNext version and holding the matching support plan where required. Check Frappe's supported versions page before you choose a version, because end-of-life dates affect both security patches and warranty coverage. DeployOpen can plan the upgrade path and handle installation, but any warranty from Frappe is governed by your own agreement with them.
What happens after go-live?
After go-live, the integration needs monitoring of sync jobs, periodic checks on stock levels, and a plan for upgrading ERPNext and the app together. Expect ongoing work when marketplaces change, when Unicommerce updates its APIs, or when your product catalogue grows. Ask for a runbook that covers error handling, reprocessing failed orders and rollback steps. Support can be handled by your team or through a DeployOpen retainer, which is quoted separately from the build.
What to confirm with Unicommerce and your own environment before go-live
Confirm the integration's technical footing with Unicommerce and in a staging environment before you commit to a go-live date. The Unicommerce integration is described as using Uniware's REST APIs, but the page does not state which Uniware API version or endpoints the app calls. Ask the vendor for the exact API version and endpoint list, then check that your Uniware tenant exposes them. Also confirm the sync frequency for each flow (item catalogue, inventory, sales orders and sales invoices), since the frequency sets how stale your ERPNext stock figures can be during peak trading. Ask for any rate limits Uniware applies, and test a full day of order volume against them in staging, not on assumptions from this page.
Verify marketplace and warehouse coverage line by line. Make a list of every channel you sell on and every Uniware facility that holds stock, then ask Unicommerce to confirm each is supported and how each maps to ERPNext warehouses. Check how returns and cancellations are handled: whether a cancelled Uniware order reverses the ERPNext Sales Order or Sales Invoice, whether a return creates a credit note or a stock entry, and who owns that correction when the two systems disagree. Test these cases with real sample orders in a staging site built from a copy of your ERPNext data.
Confirm ERPNext version compatibility against the Frappe support policy before you install anything. Check the app's stated support for your ERPNext major version, and confirm your site is on a version that Frappe still supports. Frappe's supported versions page lists the end-of-life dates for each release line, so match your upgrade plan to those dates. Finally, record who in your organization signs off on sync results, how you will reconcile item counts and stock levels after the first live run, and which person owns each failure alert, so that a broken sync is caught in hours rather than at month end.
How DeployOpen scopes and delivers the ERPNext and Unicommerce integration
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For ERPNext and Unicommerce, we agree a written scope first, build the connector in your environment, and hand over the configuration, tests and runbooks your team needs to operate it.
How we scope
- Confirm which Unicommerce channels, warehouses and ERPNext companies the integration must cover.
- Agree in writing which items sync two ways and which records flow only from ERPNext to Uniware.
- Record the ERPNext and Frappe version you run, so the app version matches a supported release.
- Document how sales invoices are created or generated, and who approves the accounting entries.
How we build
- Install the Frappe-supported Unicommerce app on a staging bench before any production change.
- Map item codes, tax templates, warehouses and payment accounts against your chart of accounts.
- Configure the one-way inventory push and test stock levels against a controlled set of SKUs.
- Run sample sales orders through to invoice and confirm each record matches the agreed mapping.
How we hand over
- Deliver the configuration record, mapping tables and a list of every custom change made.
- Provide test cases and results covering catalogue sync, inventory sync, order sync and invoicing.
- Write runbooks for credential rotation, failed sync retries and checking inventory discrepancies.
- Train the named operators on monitoring, error review and the escalation path to DeployOpen.
How we support
- Support is available as a retainer covering upgrades, fixes and reviews after go-live.
- Plan ERPNext and app upgrades in a staging copy before they reach production sites.
- Review sync logs and error queues with your operations team on an agreed cadence.
- Confirm the scope of any new marketplace, warehouse or workflow in a separate written change.
