Migrate from Proteus E12ERP to Acumatica

Proteus Customer records (with name, billing address, credit terms, and status flags) map to Acumatica ARCustomer. Every ARCustomer requires a BranchID and a CompanyID before it can be saved — we extract the branch assignment from Proteus's cost-center field or default to the primary company.

Proteus Vendor master records with payment terms, tax ID, and RemitAddress map to Acumatica APVendor. Acumatica stores vendor-specific attributes (VendorClass, TermsID, PrepaymentAccount) in separate DAC fields — these are created as custom fields or mapped from equivalent Proteus lookup values during migration.

Proteus stock items carry item type, unit cost, and warehouse quantity in one record. Acumatica splits this into InventoryItem (item attributes, valution method, tax category) and SiteStatus (per-warehouse AvailableQty and Available for shipment flags). We extract warehouse code from Proteus location fields, then upsert the warehouse and item together.

Proteus service items or items flagged as non-inventory map to Acumatica NonStockItem. Each requires an ItemType (Service or Labor), a default sales account, a default expense account, and a TaxCategory. The migration pulls those four attributes from Proteus's product-type metadata, creates the NonStockItem, and links the accounts and tax settings. Missing accounts or tax categories generate a pre-load warning for the admin.

Proteus Sales Order header (order number, customer ref, order date) becomes Acumatica SOOrder with order type (打了) and a status of Pending or Open. Line items map to SOLine referencing the InventoryItem or NonStockItem created in the prior step. Acumatica enforces that ordered stock items have AvailableQty — we flag any order referencing an out-of-stock item for manual allocation review.

Proteus PO records map to Acumatica POOrder with a POLine per product. Acumatica requires a vendor to be active (APVendor with Active flag) before the PO can be confirmed. We pre-validate vendor status before loading POLines and surface any inactive vendor as a pre-migration flag.

Proteus GL account codes (account number, description, account type) map to Acumatica Account. Acumatica also requires the Active flag and SeparateGLacct checkbox — we set Active=true and SeparateGLacct=false unless Proteus marks the account as a control account, in which case we set SeparateGLacct=true per Acumatica's chart-of-accounts setup rules.

Proteus AR invoices map to Acumatica ARInvoice with DocType=Invoice and line items as ARTran records. Acumatica enforces that every ARTran references an ARCustomer and an Account — Proteus invoices that stored account against the customer record instead of the line require a lookup transformation. Open invoices preserve original DocDate and DueDate; paid invoices are created with Hold=false and status Closed.

Proteus AP bills map to Acumatica APInvoice with DocType=Invoice and APTran lines. Similar to AR, Acumatica requires an APVendor and an expense Account per line. We map Proteus's bill distribution lines to APTran and flag any lines that reference an account not yet created in Acumatica.

Proteus Energy Division project records (stage name, deadline, assigned team member) map to Acumatica PMProject. PMProject requires the Project Accounting module to be licensed; we map project stage to PMTask and attach document uploads as Acumatica attachments. If the Construction or Distribution edition is not enabled, projects land in a staging custom object for post-migration activation.

Proteus stores contact name, phone, and email alongside address data in shared address records. Acumatica separates these into Address (street, city, state, postal code, country) and Contact (first name, last name, email, phone, job title). We split Proteus contact records during migration — address fields go to the Address DAC linked via the AddressID lookup, and contact fields go to Contact linked to the parent Customer or Vendor.

Proteus cycle count entries or inventory adjustment records map to Acumatica INAdjustment with reason code and line-level variance qty. Each adjustment line creates an INTran with TranType=Adjustment and the InventoryItem reference. We preserve the original count date as the inventory adjustment's reference date.