Migrate from Infor SyteLine / Infor CloudSuite Industrial to Odoo ERP

SyteLine customer master records map to Odoo res.partner with the customer flag enabled. Address records (primary and shipping) map to res.partner address fields; SyteLine's credit_limit and payment_terms map to credit_limit and property_payment_term on the partner. Multi-site customer structures in SyteLine where the same customer exists across sites require deduplication during export to avoid creating duplicate res.partner records in Odoo. We use the SyteLine cust_num as an external identifier to prevent duplicates on re-migration.

SyteLine vendor records map to Odoo res.partner with the supplier flag enabled. SyteLine's vendor address, banking, and purchasing terms map to the corresponding Odoo partner fields. Vendor records must be imported before purchase orders because Odoo enforces vendor_id as a required foreign key on purchase.order. SyteLine vendor codes migrate as external identifiers on the res.partner record.

SyteLine items map to Odoo product.product with product type (stockable, consumable, service) derived from the SyteLine item type field. Items with Bill of Materials in SyteLine generate mrp.bom records in Odoo with the BOM type set to kit or manufacturing depending on the SyteLine Job Bom flag. SyteLine routing data attached to the item becomes mrp.routing on the associated BOM. Stock costs from SyteLine's cost layers migrate to Odoo's standard cost field. Product variants in SyteLine (size, color, configuration) map to Odoo product.template with product.attribute.value lines.

SyteLine Jobs are the core manufacturing entity, linking materials (mJobMtl), labor (mJobOper), and operations to a production order. We map Job headers to Odoo mrp.production with the product_id, product_qty, and bom_id resolved from the item and BOM mapping. Job operations migrate to mrp.workcenter.line (or mrp.routing.workcenter depending on Odoo version), with workcenter_id resolved from the SyteLine wc_code. Material requirements migrate to mrp.bom.line via the Job BOM linkage. Job status (released, in process, complete) maps to Odoo state values (confirmed, progress, done). We preserve the original Job number as an external identifier on mrp.production for traceability.

SyteLine BOMs (mBillMatl) map to Odoo mrp.bom records with product_tmpl_id referencing the finished item. BOM components and quantities migrate directly to mrp.bom.line. SyteLine BOM effectivity dates (start and end validities) map to Odoo's valid_from and valid_to date fields. Phantom BOMs in SyteLine map to Odoo type kit on the mrp.bom. Multi-level BOMs where a component is itself a sub-assembly with its own BOM generate nested mrp.bom records in Odoo.

SyteLine sales orders (co_mstr with coitem lines) map to Odoo sale.order with the customer_id resolved from the customer mapping, and order lines migrated as sale.order.line. SyteLine's order total and tax calculations are recomputed in Odoo during import rather than migrated as values to avoid rounding discrepancies. Order dates, required dates, and promised dates migrate as the corresponding Odoo fields. Blanket orders with scheduled releases map to sale.order.type with line schedules migrated as sale.order.line scheduled dates. Line status from SyteLine (open, closed, cancelled) maps to Odoo's state values.

SyteLine purchase orders (po_mstr with poitem lines) map to Odoo purchase.order with vendor_id resolved from the vendor mapping. Odoo enforces vendor_id as a required field before the PO header can be saved, which is why vendor import completes first. Line items map to purchase.order.line with product_id resolved from the item mapping, quantity, and unit price. Landed costs, prepayment percentages, and terms from SyteLine's po_mstr fields migrate to corresponding Odoo purchase.order fields or custom fields if no standard equivalent exists.

SyteLine's Chart of Accounts (coa_mstr, coa_codes) maps to Odoo account.account with account.code preserved exactly. SyteLine's multi-segment COA structure (used for cost center or department sub-accounting) requires Odoo configuration: either a single-segment account code with cost center mapped to account.analytic.account, or a custom COA structure using Odoo's account.group for hierarchical segment grouping. Account type (asset, liability, equity, income, expense) maps from SyteLine's account type code. The full GL structure including inactive accounts migrates for audit trail completeness.

SyteLine employee records (emp_mstr) map to Odoo hr.employee after the HR application (hr module) is installed and enabled in the destination Odoo instance. Employee name, department, and job title migrate directly. Compensation fields (pay rate, pay type) migrate to hr.contract or custom fields depending on the Odoo payroll module configuration. SyteLine stores HR data differently depending on whether the HR module is active; we inspect the SyteLine schema to identify active HR tables before defining the employee mapping scope.

SyteLine quotes generated via the CPQ module map to Odoo sale.order in draft (quotation) state rather than a separate quote object. Quote line configurations that represent complex product setups in SyteLine CPQ may require manual rebuilding in Odoo if the configuration complexity exceeds Odoo's standard variant configuration capability; we document these as exceptions in the migration scope for the customer to assess. Quote headers and item summaries migrate with basic pricing preserved.

SyteLine's project entity wraps job costing, billing, and revenue recognition into a single structure. Odoo does not have a direct equivalent for project-based job costing with integrated billing. We assess whether the customer uses SyteLine's project for manufacturing work orders (in which case mrp.production is the correct Odoo destination) or for project services (in which case project.project with project.task and timesheets is the appropriate destination). The customer confirms the intended Odoo project usage during scoping, and we map accordingly. Revenue recognition and billing data from SyteLine projects require custom field mapping or manual re-entry.

SyteLine custom fields appear as extended columns in the source SQL schema (not in a separate metadata table). During extraction, we inspect the full column set of each SyteLine table to identify non-standard columns. Each extended column is evaluated: SyteLine enumerated lists map to Odoo selection fields; date fields stored as integer in SyteLine SQL convert to Odoo date; Y/N checkboxes map to Odoo boolean fields. Unsupported SyteLine field types (such as bespoke Infor control types) are documented as requiring manual Odoo custom field creation before data import. We pre-create all identifiable custom fields in Odoo before the migration data load begins.