Migrate your Deacom ERP data

The Item Master table (dmprod) uses pr_id as a sequential integer primary key. We export all item records including UOM definitions, catch-weight settings, and facility restrictions in a single pass. Item IDs are stable integers, making them reliable foreign-key targets in downstream object exports.

Bill of Materials are stored per Item per Revision with support for default, lab-only, and regulatory-only BOMs. The BOM revision system (versioned via the BOM form's active/default flags) requires we export BOM records in revision-date order so the destination can reconstruct the current formulation state without orphaned component links.

Customer records (dmcust) use cu_id as the primary key. We export customer hierarchies, credit terms, and customer-part associations (dmcust cross-links). Customer-specific pricing sheets are stored as separate dt-type records and must be sequenced after the customer header during import.

Vendor master data uses a naming convention consistent with dm-type maintenance tables. We export vendor records including purchasing lead times, preferred UOMs, and vendor-specific part cross-references. Vendors are required to pre-exist before we can import purchase orders that reference them.

Production orders are dt-type transaction records that reference the Item (pr_id) and BOM revision. We export job costing, routing steps, and labor tracking entries. Open production orders must be handled separately from closed historical jobs — open orders may require destination-side status mapping.

QC tests are set up per Item/Revision and stored with cross-references to dmd3 pick-list UDF options. The QC test schema (threshold values, test types, pass/fail criteria) varies by facility. We map test definitions field-by-field and flag any test that references custom UDF pick-lists for explicit destination configuration.

Deacom stores lot numbers and shelf-life dates at the inventory transaction level. We export lot genealogy records with parent-child lot relationships for co-manufactured or bulk-split scenarios. Serialized tracking uses the same dt transaction table, requiring we join lot output records to production order completions.

All inventory movements — receipts, issues, adjustments, and transfers — live in dt-type tables linked to Items and lots. We sequence these in timestamp order and exclude any records that reference lots not yet exported. Multi-facility transfers require facility IDs to be remapped at the destination.

GL postings are real-time and drill-down to dt transaction level. We export account codes, journal line items, and source document references (AR/AP/inventory). Custom financial statements per company structure require us to also export the dx-type reporting configuration records.

Accounts payable and receivable modules integrate directly with the GL. We export open invoices, payment applications, credit memos, and aging details. Multi-currency AR requires we also export exchange rate history linked to the ECB or Bank of Canada API feed records.

User-defined fields use dmd3 for pick-list options, which reference dxcaption2 via d3_c2guid links. These _guid references are system-generated and non-transferable across databases. We export the option labels and flag the guid-based links for manual destination reconfiguration.

EDI transaction records are stored as document references linked to trading partner setups. We export EDI mapping configurations and functional acknowledgements but note that EDI translation rules are partner-specific and may require destination EDI platform re-mapping.

Sales order headers and lines are dt-type records referencing Customers, Items, and pricing. We export order status (open/fulfilled/invoiced) and handle drop-ship and DSD (Direct Store Delivery) orders as distinct line-level flags.

Deacom's iOS and Android mobile apps for sales and warehouse use cached local data that is not persisted to exportable database tables independently. Mobile-specific notes and offline entries are not available as standalone export objects — they merge into the parent CRM or inventory records when synced.