Migrate from Runple to Acumatica

Runple stores a customer as a single record with name, email, phone, and address fields. Acumatica requires a CR.Customer record (account-level: company name, class ID, credit terms) and a separate Contact record (person-level: name, email, phone). FlitStack splits Runple's single customer row into both Acumatica records and links them via the ContactID on CR.Customer.

Runple vendors map to Acumatica's AP.Vendor (account-level: vendor name, terms, tax ID) and Contact (person-level: primary contact details). Vendor class ID in Acumatica determines default GL accounts for AP batches — we set this based on Runple's vendor category field or default to a generic vendor class.

Runple products are classified by stock/non-stock type in a type field. Acumatica requires separate table entries: IN.InventoryItem for stock items (with stocking unit, valuation method, and class code), Non-Stock Item for non-physical goods, and Service Item for labor/descriptions. The mapping derives the correct Acumatica item type from Runple's product type field.

Runple's customer invoices map directly to AR.Invoice in Acumatica. Document date, due date, description, reference Nbr, and line items transfer as-is. Hold and Voided flags map to ARInvoice.Hold and ARInvoice.Status respectively. The migration preserves original Runple invoice numbers as ARInvoice.RefNbr for traceability.

Runple customer payments map to AR.ARPayment records. The payment date, amount, and payment method transfer. For payments matched to invoices in Runple, we create ARPayment applications in Acumatica's application screen batch — the migration creates the application links with original application dates preserved in a UsrAppliedDate field.

Runple vendor bills map to AP.APBill. Bill date, due date, vendor reference, and line items transfer. Hold and Released flags map to APBill.Hold and APBill.Released. The APBill status workflow in Acumatica (Pending Approval → Balanced → Released) is applied after migration based on Runple's bill status.

Runple vendor payments map to AP.APPayment records. Payment date and amount transfer. Application to AP bills is recreated using Acumatica's payment application logic. If Runple used cash-basis accounting for vendor payments, we note this for Acumatica's ledger setup since AP payments affect GL differently depending on posting method.

Runple's flat account list maps to Acumatica's GL.Account with segment structure. We analyze Runple account usage patterns and recommend a segment structure (typically: 1=Entity, 2=Department, 3=Account, 4=Subaccount). Accounts Payable and Accounts Receivable control accounts from Runple map to dedicated GL accounts that Acumatica's AR/AP modules reference.

Runple tax codes map to Acumatica's TX.TaxZone (jurisdiction) and TX.TaxCategory (rate type) combination. We perform value-by-value mapping of each Runple tax code to the corresponding Acumatica tax agency and rate. If Acumatica does not have the exact tax rate, we create a new Tax Category with the correct percentage and attach it to the relevant Tax Zone.

Runple stores custom fields as JSON key-value pairs on customers, vendors, products, and invoices. Acumatica requires custom fields to be defined as Usr-prefixed fields on the appropriate DAC before import. We create the Usr field schema, publish the customization project, then populate the Usr fields during the data load.

Runple's stock movement records (receipts, issues, adjustments) map to Acumatica's IN.InventoryTrans for transaction history and IN.InSiteStatus for current on-hand quantities. Each movement's warehouse location, quantity, and unit cost transfer with the appropriate batch sequence. Acumatica's IN.INSiteStatus is updated automatically after each transaction batch runs to reflect current stock levels.

Runple file attachments on invoices, bills, or products are downloaded and attached to the corresponding Acumatica document using the Note entity or Files on Document screen. File size limits in Acumatica apply (default 25MB per file). Large inline images are resized if needed.

Runple team members map to Acumatica users for login access and to Employee records for HR/payroll contexts. Owner resolution in transactions uses email matching — we map each Runple owner email to the corresponding Acumatica user by email lookup. Unmatched owners are flagged before migration for admin assignment.

Runple's roles-and-permissions model has no direct Acumatica equivalent. Acumatica uses Role-based access control tied to screens and fields, with row-level security via Branch and Department assignments. We export Runple role definitions as a reference for rebuilding access groups in Acumatica's Access Rights screen.

Runple automations (conditions, email triggers, field-update rules) do not transfer to Acumatica. Acumatica's State Workflow Engine controls document state transitions through code-based definitions (graph extensions using PX.Data.WorkflowAPI). We export Runple automation definitions as a rebuild reference for your Acumatica implementation team.