Migrate from Alpha-E GSoft-POS to Odoo ERP

GSoft-POS Items carry barcode, SKU, MRP, size/color variant attributes, and HSN code. We map each Item to an Odoo Product template with the GSoft-POS barcode stored in barcodes, SKU in default_code, and MRP as list_price. Size and color variants migrate as Odoo product variants with attribute lines for size and color. HSN codes map to l10n_in_hsn_code on the product. Any GSoft-POS item categories become Odoo product categories for inventory valuation grouping.

GSoft-POS Customer records include contact name, phone, email, GSTIN, shipping address, billing address, and outstanding balance. We map each Customer to an Odoo Contact record with the GSTIN stored in vat (l10n_in_partner_latitude), the outstanding balance preserved in a custom field for reconciliation, and separate billing and delivery addresses via the Odoo Contact's address model. Customer type (retail walk-in vs. wholesale) maps to a l10n_in_reseller gst_partner_type field if present.

GSoft-POS Vendors map to Odoo Contacts with company_type=company, including supplier name, contact person, phone, email, GSTIN, and payment terms. Vendor GSTIN is stored in the Odoo Contact's vat field and validated against the Indian GST regex format during import. Payment terms from GSoft-POS (e.g., Net 30, Cash) map to Odoo Account Payment Terms records.

GSoft-POS Sales Invoices migrate to Odoo Account Moves with type=out_invoice. Each invoice line maps to an Odoo invoice line with the product reference, quantity, unit price, tax amount, and HSN code. The GSoft-POS invoice number becomes the Odoo move name; the invoice date becomes the move date. Payment state maps from GSoft-POS status (Paid / Unpaid / Partial) to Odoo's payment_state field. GST tax lines are mapped to Odoo's Indian GST tax accounts (CGST, SGST, or IGST based on the inter-state flag in GSoft-POS). Note: GSTR filing status does not transfer; we deliver a structured GST invoice extract for re-filing.

GSoft-POS Purchase Orders migrate to Odoo Purchase Orders. Each PO line carries vendor, item, quantity, rate, and tax. We map PO status (Pending / Received / Closed) to Odoo Purchase Order state. Any partially received quantities are recorded as Odoo purchase order lines with the received_qty field populated. Vendor GSTIN on the PO maps to the Odoo Contact record already imported.

GSoft-POS payment records linking invoices to cash or bank receipts map to Odoo Account Payment records. The payment amount, date, and mode (cash / bank / UPI / card) migrate. We resolve the payment against the corresponding Odoo Account Move (invoice) by matching invoice number and amount. Bank and cash account assignments use the GSoft-POS payment mode to select the correct Odoo journal and account.

GSoft-POS multi-location branch data is stored across branch-level tables or shared tables with a branch identifier. There is no single export. We write branch-specific extraction queries against the GSoft-POS database, extract stock levels, sales totals, and inventory adjustments per branch, and consolidate them. Each GSoft-POS branch maps to an Odoo Stock Warehouse record with its own location hierarchy (view location, input location, stock location, output location). Branch-specific stock levels become Odoo Stock Quant records under the corresponding warehouse.

GSoft-POS loyalty scheme records track member ID, points balance, and redemption history. Odoo CRM Loyalty (Enterprise) or community loyalty modules use a different data model. We map member ID to Contact, points balance to a custom loyalty_points field on the Contact, and redemption history to a custom redemption journal. If the destination uses the community loyalty app, we map to the app's loyalty.card and loyalty.reward models. The customer's Odoo implementation partner configures the loyalty program rules post-migration.

GSoft-POS chart of accounts, ledger balances, and trial balance transfer to Odoo's account.account and account.move models. Opening balances for the new fiscal year must be reconciled because GSoft-POS resets opening balances as carry-forward entries at year-end, while Odoo treats opening moves as explicit journal entries with a specific date (e.g., April 1 for Indian April-March fiscal year). We map GSoft-POS ledger closing balances to Odoo opening journal entries with a configurable opening date. Any inter-branch eliminations from GSoft-POS consolidated reporting require Odoo inter-company elimination journal entries.

GSTR filing status is a government portal state, not a database field, and does not transfer during migration. We extract the complete invoice-level data underlying the GSTR reports (invoice number, date, GSTIN of counterparty, HSN, taxable value, tax breakup, place of supply, reverse charge flag) in a structured CSV format compatible with the GST portal's offline utility for GSTR-1 and GSTR-3B. The customer files or reconciles all open periods directly in the GST portal post-migration. Odoo's l10n_in_gstr1 and l10n_in_gstr3b reports are configured for ongoing filings after go-live.