Marg ERP is entrenched in pharmaceutical distribution, FMCG and retail chemist businesses, largely because of its batch and expiry handling. Any move away from it has to protect that capability first.
Batch and expiry data is the hard part
Ordinary accounting migration moves balances. A Marg migration also has to move live batch positions, because each batch carries its own quantity, expiry date and purchase rate.
Batch-level stock should be exported as one row per item-batch, never summarised to item level. OneBooks GST inventory treats batch as part of the stock identity.
Migration sequence for a distribution business
- Freeze new entries in Marg for the cut-off day.
- Export item master with HSN, pack size, unit and tax rate.
- Export batch-wise closing stock: item, batch, expiry, quantity, rate.
- Export party masters including drug licence numbers where held.
- Export outstanding receivables and payables.
- Import into the new system and reconcile stock value before resuming entry.
Do not lose the scheme and margin structure
Distribution pricing carries trade discount, scheme quantity and margin percentages that rarely survive a plain master export. Document the current scheme structure separately and rebuild it deliberately rather than assuming it migrated.
Verification specific to batch businesses
| Batch count per item matches | A missing batch means unsellable stock | Expiry dates carried correctly | Drives near-expiry returns and write-off | Batch-wise value totals to stock value | Confirms valuation is intact | Drug licence numbers on parties | Required on pharma invoices |
Preparing the warehouse before the cut-off
A batch migration is only as good as the physical stock position it starts from. Migrating a batch list that does not match the shelves just moves an existing problem into a new system.
- Run a physical count by item and batch, not by item alone.
- Reconcile counted batches against Marg's batch-wise stock report.
- Investigate batches showing stock that cannot be found.
- Write off expired stock before the migration rather than after.
- Freeze movement once the reconciled position is agreed.
Pricing structures need documenting separately
Distribution pricing is layered, and a plain master export flattens it. Record the current structure before the move so it can be rebuilt deliberately.
| Base purchase rate | Item master | Yes | Trade discount percentage | Party or scheme master | Rarely | Scheme quantity, free goods | Scheme master | No | Retailer margin | Price list | Sometimes | Party-specific rates | Party price list | Rarely |
Statutory records specific to pharma
Pharmaceutical distribution carries record-keeping obligations beyond GST, and these do not pause for a software change.
Keep the Marg installation readable until you are confident the new system reproduces every record an inspection could request.
Sequencing the first month after the move
- Week one: purchases only, confirming batch inward works as expected.
- Week two: add sales, checking expiry-first picking behaves correctly.
- Week three: run returns and credit notes, which are where batch logic is most often wrong.
- Week four: close the month and reconcile batch-wise stock value.
Mapping units and pack sizes
Distribution items carry nested units: a case contains boxes, a box contains strips. Getting this wrong at import produces stock figures that are out by an order of magnitude.
- List every unit in use and its relationship to the base unit.
- Decide the base unit for each item and keep it consistent.
- Convert opening stock into the base unit before import.
- Check a sample of items by recomputing the value from quantity and rate.
- Confirm purchase and sale defaults use the intended unit.
Credit notes and expiry returns
Return flows are where batch logic is tested hardest, and they are rarely covered in a migration plan until something goes wrong.
Verifying the first month-end after the move
| Batch-wise stock value | Physical count at month end | Total stock value | Trial balance inventory figure | Purchase total | Supplier statements | Sales total | GSTR-1 summary | Expired stock provision | Near-expiry report |
Running all five in the first month is the only reliable way to know the migration held. Discovering a batch valuation error in month four means four months of restatement.
Costing the move honestly
A Marg migration costs more than a general accounting move, and budgeting for it properly avoids abandoning the project halfway.
| Physical count by item and batch | One to three days, business size dependent | Master cleanup and unit mapping | Two to four days | Batch position export and import | One to two days | Rebuilding scheme and pricing structures | Two to five days | Parallel running and verification | One month, part time |
The scheme rebuild is the item most often underestimated, because it rarely exists as a single exportable table and usually lives partly in someone's head.
Deciding what history to carry
Distribution businesses accumulate large transaction volumes, and the instinct is to bring everything. Most of it is better archived.
- Carry current batch positions, since operations depend on them.
- Carry open receivables and payables.
- Carry item, party and licence master data.
- Archive closed transactions as exported reports.
- Keep the Marg installation readable for recall and inspection queries.
Signs the migration is complete
Frequently asked questions
Is a mid-year move from Marg advisable?
Less so than for a general trading business, because batch positions move daily. A financial year boundary, or a genuine stock-take date, gives a far cleaner cut-off.
What about pending purchase and sales orders?
Open orders are usually re-entered manually. There are rarely enough of them at a cut-off to justify building an import, and re-entry doubles as a review.
Can both systems run in parallel?
For one month, yes, and it is worth it. Run a full purchase-to-sale cycle in the new system while Marg remains available for comparison.
