Migrate from VIENNA Advantage to Odoo ERP

VIENNA Advantage Business Partners unify customers, vendors, and employees under a single record type with a BP Type field (Customer, Vendor, or Employee) determining the entity role. We split each Business Partner into an Odoo Contact (if Customer), a Supplier record (if Vendor), or an Employee record in the Odoo HR app (if Employee). The split is computed using the c_bp_type or equivalent column from the source schema, with the original BP name, address, tax ID, and payment terms carried across each derived record. The original VIENNA Advantage Business Partner ID is preserved in a custom field va_bp_id__c for audit traceability.

VIENNA Advantage Products map to Odoo Product Template records. Standard fields (name, SKU, UOM, category, cost price, sale price) transfer directly. BOM-linked manufactured items require additional mapping: Odoo distinguishes between product type (stockable, consumable, service) and requires a BoM record to be created for each manufactured item. Product variants (size, colour) in VIENNA Advantage map to Odoo Product Attribute and Variant lines on the Product Template.

VIENNA Advantage Sales Orders map to Odoo Sale Order; Purchase Orders map to Odoo Purchase Order. Order headers (partner reference, date, payment terms, incoterms) transfer directly. Order lines map product, quantity, UoM, unit price, discount, and tax from the VA order line schema. Status mapping (Quotation, Quotation Sent, Sales Order, Done, Cancelled) aligns with Odoo's sale order states. Warehouse assignment on VA lines maps to Odoo's picking policy on the sale order.

VIENNA Advantage Accounts Receivable and Accounts Payable invoices map to Odoo Account Move with move_type = out_invoice (for AR) or in_invoice (for AP). The partner_id, invoice_date, invoice_number, and line-level account, debit/credit amounts, and tax transfer. Payment state in Odoo (in_payment, paid, partial) is computed post-import by matching the VA payment records. Open invoices versus posted/voided status must be preserved so that Odoo calculates correct outstanding balances on day one.

VIENNA Advantage Payment records map to Odoo Account Payment, linked to the reconciled Account Move via reconcile_model_id. Payment method (cash, bank transfer, cheque) maps to Odoo's journal, payment_method_line, and amount. Partial payment versus full payment is preserved via the amount field. The reconciliation link between Payment and Invoice is reconstructed by matching VA's invoice_number or payment_reference to the Odoo Account Move reference.

VIENNA Advantage General Ledger journal entries map to Odoo Account Move with move_type = entry. We chunk journal extraction by fiscal period to avoid oversized API payloads and to preserve Odoo's fiscal lock mechanism. Each journal entry line carries account code, debit, credit, and dimension tags (cost centre, project) which map to Odoo's analytic account if configured. VA dimension labels are captured and documented for the Odoo implementation team to map to the correct analytic account structure in Odoo.

The VIENNA Advantage chart of accounts (COA) maps to Odoo's account.account table. We extract account code, name, account_type (asset, liability, equity, income, expense), and reconcile flag. The VA account structure is loaded into Odoo before any journal entries or invoices so that all move lines reference valid account IDs. If VA uses a non-standard COA, we generate the accounts in Odoo using the country-specific COA template as a baseline and patch mismatches.

VIENNA Advantage warehouse-level stock records (on-hand quantity, reorder point, locator, expiration date) map to Odoo's stock.quant table for current quantities and stock.location records per warehouse site. We extract the VA warehouse name, code, and address to create matching Odoo stock.location records with location_type = internal. On-hand quantities per product per warehouse import as stock.quant entries. Open and confirmed picking orders in VA map to Odoo stock.picking records with the corresponding picking_type.

VIENNA Advantage Projects map to Odoo Project records. Phases, assigned resources, billing rules (billable vs. non-billable), and time entries transfer. Sub-task hierarchies in VA map to Odoo Task with parent_id set. Billable flags map to Odoo's sale_line_id on Project if the customer uses Odoo's billing integration with Sales. We preserve the original VA project code in a custom field va_project_id__c.

VIENNA Advantage DMS documents (binary files, version history, folder metadata) require a separate extraction pipeline. We extract binary files and the parent record metadata (BP ID, Order ID, Project ID) from the DMS schema, then re-associate each file to the migrated Odoo record as an IrAttachment. Odoo's document management relies on the ir.attachment model; we re-create the folder structure as Odoo document directories and attach files to the correct res_model and res_id. Documents without a resolvable parent record are held in a catch-all document directory for manual re-association by the customer's admin. Version history and workflow routing metadata are captured in a separate document.

Custom fields added via the VIENNA Advantage Canvas framework are stored per-module with type, required flag, and default value metadata. We extract the full custom field schema alongside the data and generate the equivalent Odoo custom field definitions (ir.model.fields with the matching field_type). Canvas-specific field types (e.g., virtual fields, calculated fields) are documented as is because Odoo does not natively replicate Canvas's declarative calculation model; the implementation team evaluates Odoo Computed fields as the replacement. Custom module logic does not migrate; we deliver the schema and data, not the behaviour.

VIENNA Advantage workflow automation rules (approval routing, document routing, conditional triggers) are declarative configurations stored in the VA framework with no documented export format. We do not migrate workflow definitions as executable records. During discovery, we capture screenshots and configuration notes for every active workflow, categorise them by module and trigger type, and deliver a Workflow Reconstruction Handbook mapping each VA workflow to an equivalent Odoo Studio automation, Server Action, or Base Automation rule. The customer's Odoo implementation consultant rebuilds the approval chains; we do not include workflow rebuild in the standard migration scope.