What Can Open Mercato Do for Your Business?
Open Mercato is worth evaluating when your team needs custom workflows and can arrange the engineering and ongoing maintenance of a business application.
If you need a ready-to-use accounting or ERP package for your country, check those requirements first. CRM, sales and catalog modules alone do not establish local accounting support.
What is included?
CRM: customers and sales activity
The CRM module contains people, companies and deals, together with related activities, comments and addresses. These records provide a place to describe a customer and keep a history of contact. Custom fields allow the team to add information relevant to your industry. The structures give developers a starting point for your sales workflow.
For example, Acme Ltd, a contact named Alex and an “Equipment supply” deal can be linked records. A call note can capture the discussion about that sale. These are illustrative records showing how the information fits together.
Define the sales stages, required fields and access for each role. Test a complete sales case with users. Mailbox synchronization and migration from an existing CRM still need verification for the chosen connection. The records described here do not establish those integrations.
Source: CRM data models
Sales: quotes and orders
The sales module includes quotes and orders with line items. Documents reference customer and product records, while line items keep pricing data for calculations. The code contains totals, discounts, tax adjustments and configurable statuses. The implementation team decides how these structures map to the way your business handles a sale.
For example, a quote for Acme Ltd could contain ten units of one product variant. An order needs the buyer, line items, prices and an agreed status. A useful implementation test checks that those details stay correct when the order moves into fulfilment. This is a proposed test using illustrative data.
Quote approvals, pricing exceptions and connections to warehouse or accounting software belong in the project scope. Document models do not establish statutory accounting compliance or a working connector to your existing ERP.
Source: Sales documents and calculations
Catalog: products, variants and prices
The catalog stores products, variants and prices. A product describes the shared offering; variants distinguish specific versions, such as size or colour. The model includes SKU identifiers and pricing associations. Custom fields let the team add information needed to describe your range. Product definitions can then supply data used in sales documents.
For example, a “Chair” product could have “Natural” and “Dark” variants, each with its own SKU. A quote refers to the selected variant and price. These records are illustrative. Before importing a real catalog, check whether the current system groups products and variants in the same way.
Prepare naming, units and update rules, and identify where prices come from. If another PIM or ERP maintains the catalog, plan the connection and decide which system resolves discrepancies. The catalog model alone does not provide synchronization with every provider or a finished storefront.
What does the project need?
| Work | Decision needed |
|---|---|
| Workflow and rules | Which steps, exceptions and permissions must the first version support? |
| Migration | Which records will move, how will you clean them, and how will users check the import? |
| Integrations | Which systems exchange data, which one supplies the current values, and what happens after a failed transfer? |
| Operation | Who handles hosting, backups, recovery, support and updates? Include that work in the budget. |
Who can implement it?
Your own development team can build the application if it has the skills and time to maintain it. An external team can take on agreed development, integration and support work. You can also share delivery, for example by having your developers maintain the application while a supplier builds an integration.
In every arrangement, someone in your business needs to set priorities and test the result with users. Agree access to the source code, documentation, service responsibilities and a handover plan. These are project and contract decisions; they are not automatically included with the software.
Where to start?
- Name the first workflow you want to improve and one result users should notice.
- List the systems and data that workflow depends on.
- Choose someone who will test the application with the people using it.
Read the implementation guide →
Seven questions to print and discuss
Use these prompts to prepare a team discussion. Answers stay on your printed copy.
What do we want to improve, and what is causing problems today?
Who sets priorities and checks the result with users?
Which systems will we keep, and what data must they exchange?
What must the first version do, and what can wait?
Who will build the application, maintain it and help users?
What do specialists need to check: security, backups or legal requirements?
What result would justify continuing, changing the plan or stopping?