Logistics and distribution
Epicor Vision and Eagle: exporting aftermarket distributor history
By SourceX Editorial · Updated
Short answer
An Epicor Eagle data export for an aftermarket distributor, and the same exercise on Epicor Vision, should preserve five record families before a migration or sale: sales lines, catalog lookups, lost sales, returns and warranty, and core charges and credits. Export at line level with store, account and part codes intact, and pull the code tables first.
Key takeaways
- Core charges, core returns and supplier core credits form a chain that only makes sense if every step is exported and linked.
- Lost sale codes are only as reliable as the stores that used them, so record which stores coded consistently.
- Distributors that grew by acquisition often run more than one system, and each needs its own extract and code crosswalk.
- Catalog content shown inside the system usually belongs to the catalog provider and stays out of the archive.
- Validate each extract against the system's own reports before the old platform is switched off.
What aftermarket history lives in Vision and Eagle?#
Aftermarket history in Epicor's Vision and Eagle systems typically covers the full store and warehouse cycle: counter and commercial sales, installer accounts, store-to-store transfers, purchasing and replenishment, returns, warranty, cores and, where staff used it, lost sales tracking. For many parts distributors these systems have run for a long time, so the history can span several vehicle generations.
The value of that history depends on what links survive. A sales line that still carries the store, the commercial account, the part, the vehicle lookup and any related return or core credit tells a complete story. The same line exported from a summary report tells almost nothing.
The specific export tools, database access and hosting arrangements differ by system version and by contract, so confirm the mechanics with Epicor or your support partner. The record families and links below apply either way.
Export checklist by record family#
The checklist below sets out which fields to keep for each record family and the gap that most often undermines the archive.
| Record family | Fields to keep | Common gap |
|---|---|---|
| Sales lines | Store, invoice, account, part, quantity, price, cost, vehicle if captured, timestamp | Vehicle not stored on the invoice line |
| Catalog lookups | Vehicle, part type, result, user, store, time | Logs held by the catalog tool, not the business system |
| Lost sales | Part or part type, reason code, store, user, date | Codes used by some stores and ignored by others |
| Returns and warranty | Original invoice, reason, condition, supplier claim status | Returns not linked back to the original sale |
| Cores | Core charge, core return, condition, supplier credit, rejection | Charges and credits exported without the linking reference |
| Transfers | From store, to store, part, reason, linked sale | Transfers that filled a sale recorded without the sale reference |
| Purchasing and stocking | Purchase orders, receipts, min and max changes, stock adjustments | Stocking rule history overwritten by the current setting |
| Commercial accounts | Account type, terms, delivery route, price level | Account notes containing personal contact details |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Why cores and warranty need their own pass#
Cores and warranty need their own pass because each involves a chain of records across the customer, the store and the supplier, often spread over weeks and several transactions. Exporting each transaction type separately without the references between them leaves a pile of charges and credits that cannot be reconciled.
The core chain usually looks like this, and each stage should be traceable to the next:
Warranty records follow a similar path: the customer's claim, the store's inspection, the replacement issued and the supplier's decision on the claim. Keep the failure reason, the original sale reference and the vehicle where it was captured, since together they show how parts perform in service and why claims were paid or denied.
| Core stage | Record created | Why keep it |
|---|---|---|
| Sale with core charge | Invoice line with core charge | Starts the chain and ties it to a customer and part |
| Core returned by customer | Core return or credit with condition | Shows customer behavior and core quality |
| Core sent to supplier | Supplier return document | Links store activity to supplier credit |
| Supplier credit or rejection | Credit memo or rejection reason | Explains margin leakage and supplier disputes |
Lost sales: keep the codes and the context#
Lost sales records are among the most useful history an aftermarket distributor holds, because they capture demand that never became an invoice. They are also among the least consistent, since they depend on counter staff taking the time to record why a customer walked away.
Export the reason code table along with the records, and add a simple assessment of which stores coded lost sales reliably and during which years. That note lets anyone using the archive later weight the data properly instead of reading a store's silence as a lack of demand.
If lost sales were sometimes captured as free-text notes rather than codes, export the notes too, but review them for customer names and phone numbers before they leave the system.
Planning the extraction#
The extraction plan should be written down before anyone runs a query, so that every store and system is covered and the results can be checked.
- Step 1: list every store and warehouse and the system each one runs, including acquired locations still on older platforms.
- Step 2: confirm the hosting model, support contract and what the license allows for bulk export or database access.
- Step 3: export code tables first: stores, account types, reason codes, part lines and supplier codes.
- Step 4: extract each record family by year and store, keeping invoice, return and core references.
- Step 5: validate counts and totals against the system's own reports for a sample of stores and periods.
- Step 6: build a crosswalk where different systems used different codes for the same store, account or part line.
- Step 7: store the archive in company-controlled storage with a short data dictionary and an owner.
Illustrative: a distributor merges store systems after an acquisition#
Illustrative: a fictional aftermarket distributor operates company stores on one Epicor system and acquired a jobber group whose stores ran on another. Leadership plans to move everyone to a single new platform within a year.
The IT lead treats each system as a separate extraction. Code tables come out first, then sales, returns, cores, transfers and lost sales by store and year. A crosswalk maps the acquired stores' account and part line codes to the company's own. Catalog content displayed in the systems is left out, because it belongs to the catalog provider, while the distributor's lookup results and outcomes are kept.
Validation finds that one acquired store's core credits were posted without the original invoice reference for part of its history. Rather than guess, the team flags that period as unlinked in the data dictionary. The finished archive lets the merchandising team compare core recovery and lost sales across both store groups for the first time.
What happens to the history in a sale#
What happens to the history in a sale depends on the deal structure and the purchase agreement. In a stock sale the records stay with the company the buyer acquires; in an asset sale they must be listed as purchased or excluded, and the seller may want a copy for tax and dispute purposes.
If the history is later offered for licensing, the SourceX fit check needs only a description of stores, systems and years, and the work then moves through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Catalog provider content and supplier part content are excluded, installer and customer details are removed, and the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization.
Frequently asked questions
Can we export catalog content along with our sales history?
Usually not for any use outside the system. Fitment and product content shown in the business system typically comes from a catalog provider or suppliers under subscription terms. Keep your own transactions, lookup results and outcomes, convert vehicle references to plain attributes, and check the catalog agreement before keeping any provider content.
Do our independent jobber stores' records belong to us?
It depends on the arrangement. Company-owned stores' records are the company's. Independent jobbers that use your system under a program agreement may own their own customer and sales records, with you holding only what the agreement allows. Read each program agreement before including their history in any archive or review.
Is installer and shop account data personal information?
Business accounts are mostly business information, but contact names, mobile numbers, emails and notes about individuals can be personal information under some privacy laws. Keep account types and terms, and remove or code individual contact details before any analysis outside the company.
How far back should we export?
Export everything the systems still hold unless a retention policy or agreement requires deletion. Older history shows how demand shifted across vehicle generations, and it costs little to store. Document any years with gaps, migrations or code changes so later users can interpret them correctly.
Who should own the archive after the migration?
Name one owner, usually in finance or IT, who controls access and answers questions. Without an owner, archives tend to be copied, forgotten or deleted during later projects. Record where it lives, who may use it and how long it will be kept.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.