Odoo Implementation / Nimex Solutions
An ERP implementation designed around how your business actually works.
We start with your processes, not with a module list. Nimex maps how orders, stock, production and money move today, decides per process what is standard Odoo, what is configuration and what needs engineering, and implements it as one connected environment.
- Official Odoo Partnerprojects on Odoo 18 and 19, Community and Enterprise, Odoo.sh included
- How we workarchitecture before configuration
Discovery and analysis
Before a single screen is configured, we know how your order moves.
Discovery is workshops with the people who do the work, not a questionnaire. We walk one real order from quotation to cash with each department and write down what we find: who decides, what is approved, which file holds the truth today.
Process mapOrder to cash · as-is · Kuzey Gıda sampleSample data
- Quote in Excelprice list v7, by hand
- Customer confirms by e-mail
- Order re-typed into the ERPpain: 2 systems
- Stock checked in a notebookpain: no reservation
- Shipping approved by the manager
- Delivery note printed in Word
- Invoice from the delivery note
- e-Fatura keyed into the portalpain: double entry
- Receivable followed in a ledger file
- pain point
- approval
- document outside the system
- 01Departments and people
Who works in each department, their responsibilities and the hand-overs between them.
- 02Processes and approvals
Each process step by step, with the approvals and the limits that trigger them.
- 03Current software and data sources
Spreadsheets, a legacy ERP, portals: what each one holds and which copy is trusted.
- 04Pain points and documents
Where work is re-typed or waits, and every printed or e-mailed document with its fields.
- 05Integration points
Banks, e-documents, carriers, machines and marketplaces that must exchange data with Odoo.
- 06Reporting needs
What management reads weekly, and which record in Odoo will produce each figure.
ERP architecture
Standard where it fits, configured where it must, built only where nothing else works.
The architecture document decides, per process, which layer answers it. It is written before configuration starts and it is what the project is tested against.
- Standard applications: the Odoo apps and the version, Community or Enterprise, Odoo.sh, cloud or on-premise.
- Configuration: warehouses, routes, taxes, fiscal positions, price lists, sequences and approvals.
- Custom engineering: the few places where standard behaviour must change, built as upgrade-safe extensions.
- Security, companies and data: roles and record rules, multi-company, which application owns each master record.
- Integrations: e-documents, banks, carriers and machines, each with its direction and trigger.
The engineering examples in the demo (planning cockpit, smart imports, Turkish e-documents) exist in our catalogue; whether your project needs them is decided in discovery, not assumed.
Implementation lifecycle
Nine stages, each with an output the next one needs.
Our company method on the About page has four phases: Discover, Design, Implement, Launch and Support. An implementation project runs those four through nine concrete stages, with a deliverable at the end of each.
- Discovery
Workshops, process map, data sources, pain points.
- Solution design
Architecture document: standard, configure or build per process.
- Configuration
Companies, warehouses, accounts, taxes, roles, sequences.
- Custom engineering
Only the extensions the design approved, with tests.
- Data migration
Test imports, validation, reconciled opening data.
- User acceptance
Scripts per role on staging; issues fixed and re-tested.
- Training
By department, on the staging copy with real scenarios.
- Go-live
Controlled cutover against the acceptance criteria.
- Hypercare and support
Daily contact after go-live, then the support contract.
Stages overlap in practice: engineering starts while configuration runs, and migration is rehearsed several times before acceptance. The gates (06 and 08) do not.
Testing and launch
Staging is where things break. Production is where they do not.
Every project has a staging environment separate from production. Test scripts are written with the process owners, run on staging builds, and a failed script stays failed until the fix is deployed and the script is run again.
What has to be true before we switch
- Acceptance criteria met
Every UAT script passed on the final staging build; open issues are either fixed or accepted in writing.
- Opening data reconciled
Partners, products, stock quantities and receivables compared source against Odoo, differences explained.
- Essential workflows rehearsed
Quote, confirm, receive, produce, deliver, invoice and pay, run end to end by the people who will do them.
- Access rights reviewed
Each role logged in and checked on staging: what they see, what they can change, what they cannot.
- Contingency agreed
Who decides to pause the cutover, what the fallback is, and how long the old system stays readable.
Department connectivity
In one environment, every document has a prerequisite.
Connecting departments is not a slogan. It is the chain of prerequisites Odoo enforces once the architecture is right: nothing is invoiced that was not delivered, nothing is delivered that was not reserved, nothing is produced without its components.
| Before this happens | This must exist | Who feels it | Source |
|---|---|---|---|
| Customer invoice | A confirmed sales order with an invoicing policy, and for delivered-quantity policies, a validated delivery | Accounting stops re-typing what sales promised | Odoo documentation |
| Delivery | Reserved stock in the source location; the transfer is Waiting until it is available | Warehouse sees what is promised, in order | Odoo documentation |
| Manufacturing order | A bill of materials, its components reserved or planned, a work centre | Production plans from demand, not from a phone call | Odoo documentation |
| Vendor bill | A confirmed purchase order and, where the control policy is On received quantities, the receipt | Purchasing and accounting agree on what was received | Odoo documentation |
| e-Fatura sent | A posted invoice with the customer's tax details verified | Compliance is a state of the invoice, not a portal session | In our code |
| Production released | Supply decided per component and the technical drawing received, where the planning cockpit is used | The factory starts on complete orders only | In our code |
Policies such as invoicing on ordered or delivered quantities and bill control on ordered or received quantities are settings; we choose them with you in solution design. The two last rows describe Nimex extensions from the engineering catalogue.