intelligent.pageDocs

Logic POS

LOGIC POS is the store till inside LOGIC ERP, not a separate product. Store sales, stock and loyalty come through the same ERP endpoints, scoped by branch.

LOGIC POS is the retail point of sale of LOGIC ERP Solutions Pvt. Ltd., the Mohali-based ERP vendor covered at /connectors/logic-erp. It is what runs at the till in an apparel, footwear, supermarket, pharmacy or electronics store: barcode billing, multiple tender types, loyalty and discount cards, gift vouchers, schemes and promotions, shift and cashier control, and a POS Back Office at branch level.

The most important thing to know before scoping anything: LOGIC POS is not a separate product with a separate API. It is a module of LOGIC ERP, on the same Microsoft SQL Server database, reached through the same endpoints with the same Basic Auth credentials. There is no /api/pos/... namespace, no store-level service and no per-till credential. Everything a store does surfaces as ordinary LOGIC documents scoped by BranchCode.

How this page differs from the Logic ERP page

The ERP page documents the whole API surface: sixty-odd endpoints across masters, purchase, orders, sale, inventory, accounts and payroll, the Basic Auth model, the GlobalModifyCode incremental filter and the changed-since stock feed. Read it first; everything there applies here.

This page covers only what is specific to the store:

  • which of those endpoints answer the four POS questions: sales per store, items, stock per store, customers,
  • the fields on a sale bill that only exist because it came from a till: loyalty membership, tender split, discount coupons, footfalls and gift vouchers,
  • what the POS product is operationally, including the Android app that is not the till,
  • and what is missing at store level that you would expect a POS to give you.

There is no separate authentication, no separate base URL, no separate rate limit and no separate versioning. If you have read the ERP page, do not re-read those sections here.

At a glance

Warning

Name collision, and it is a bad one. There is an unrelated open source point of sale project called LogicPOS, published by Logic Pulse, a Portuguese company. It has its own GitHub organisation, an API server project and a repository whose description reads "Customized application to integrate LogicERP with LogicPOS". None of that is this vendor. If you are searching GitHub for LOGIC POS integration code, everything you find under that name is the Portuguese project.

What it is

The LOGIC POS module is described by the vendor as an "advanced and fully configurable POS system" with multiple views for touch and mobile. Published capabilities:

  • Billing. Barcode driven, with batch and MRP-wise stock, schemes and promotions, and shift and cashier control.
  • Tenders. Multiple payment modes with integrated gateways, naming Paytm, PayU, Mobikwik and Pine Labs.
  • Loyalty. Points accrual and redemption, brand and category memberships, discount coupons and gift vouchers.
  • Multi-location. Central control of inventory, pricing and promotions across stores from a head office dashboard.

Operationally, the knowledge base shows the shape of the product through its configuration articles rather than through an architecture page. There is a "POS Options" section under global administration with a long list of till-level switches: whether retail customer selection is mandatory in billing, whether the till may create or modify a retail customer, whether footfall recording is allowed in sale bills and whether footfalls are recorded gender-wise, whether gift vouchers may be created from within billing, how credit amount posts against a retail customer, and several rules about whether loyalty and discount card discounts may combine with other discounts or apply to returns. There is a separate article on setting up shift and cashier for POS.

Two consequences for an integrator. First, the shape of a bill depends on the customer's POS Options, not on the product version, so ask which switches are on before mapping. Second, whether a bill even has a retail customer attached is a configuration choice, so do not build a customer-keyed model without checking.

Deployment

LOGIC POS is a Windows application, consistent with the vendor's own statement that the desktop product runs on Microsoft Windows only and the web application must be hosted on Windows Server. Stores run against the head office installation or against a branch database that consolidates to it.

The Android application named "LOGIC POS" on the Play Store, package com.logicerp.logicpos, is not the till. Its own listing describes it as an "App that lets you view reports, approve documents, etc", and it was last updated in February 2022. Do not plan an integration around it. The vendor's other Android apps cover warehouse picking, B2B ordering, delivery and customer feedback.

The knowledge base documents no branch-to-head-office data sync mechanism, which is a gap on the ERP page's terms but is also consistent with LOGIC's cloud and web-hosted model, where stores work against a central database rather than replicating. Establish which model the specific customer runs, because it determines how fresh the API's answers are: against a central database the API is live, and against a replicating branch database it is only as fresh as the last sync.

API access

Identical to the ERP. See /connectors/logic-erp for the full sequence. There is no POS-specific registration, no store-level onboarding and no separate plan: the customer's LOGIC installation is enabled for the API once, and every branch is reachable through it.

Authentication

Also identical to the ERP. In one line: HTTP Basic Auth with a user name and password issued against the customer's installation, POST to http://<host>/api/<EndpointName>, no token and no expiry. Insist on TLS, because the credential travels on every request.

There is no per-store credential and no per-till identity in the API. Stores are addressed by BranchCode or Branch_Codes_From inside the request body. That means one credential can read every store on the installation, which is convenient and is also something to raise with the customer if they expected store-level isolation.

Objects we can read

Sales per store

POST /api/GetSaleInvoice with Branch_Codes_From set to the branch, and GlobalModifyCode as the incremental cursor. The response gives a rich retail bill. Header fields that only matter because it is a till bill:

Lines come back in a ListItems array:

{
  "SL_Txn_Code": 2,
  "LogicUser_Code": "900000637",
  "AddlItemCode": "",
  "Lot_Code": 24120,
  "Lot_Number": "POT-16",
  "PackName": "S",
  "CF_1": 1.0,
  "CF_2": 1.0,
  "CF_3": 1.0,
  "Quantity": 1.0,
  "Rate": 1050.0,
  "Net_Rate": 1050.0,
  "Gross_Amt": 1050.0,
  "Net_Amt": 1176.0,
  "Round_Amt": 0.0,
  "Sale_Amt": 1050.0,
  "HSN_Code": "9876540",
  "Tax_Amt_1": 63.0,
  "Tax_Amt_3": 63.0,
  "MRP_SaleBill": 1250.0,
  "Item_MRP": 1250.0,
  "Lot_MRP": 1250.0,
  "Item_Sale_Rate": 1050.0,
  "Item_Pur_Rate": 650.0,
  "Lot_Sale_Rate": 1050.0,
  "Lot_Pur_Rate": 550.0,
  "Lot_Basic_Rate": 550.0,
  "Item_Sp_Rate_1": 50.0,
  "Item_Sp_Rate_5": 50.0,
  "Lot_SP_Rate1": 50.0,
  "CD": 0.0,
  "TD": 0.0,
  "SP_CD": 0.0,
  "CD_Per": 0.0,
  "TD_Per": 0.0,
  "SP_CD_Per": 0.0,
  "Scheme_Unit": 0.0,
  "Scheme_Rs": 0.0,
  "Sale_Or_SR": "SL"
}

Reading that line:

  • Tax_Amt_1 and Tax_Amt_3 are the two GST halves in the sample, 63 and 63 against a 1050 base, which is a nine plus nine split. The slot numbering is customer configuration, so confirm which numbered slot is which component rather than assuming.
  • HSN_Code is on the line, which is better than on the item master for reconciliation, because it is what was actually billed.
  • Prices appear three times over: at item level, at lot level and as billed. MRP_SaleBill is the MRP printed on this bill, Item_MRP the current master value. For historical accuracy use the bill values, not the master.
  • Discounts come in three types, cash, trade and special cash, each as both an amount and a percentage, plus scheme in units and rupees. There is no single discount number.
  • Sale_Or_SR distinguishes a sale line from a sale return line.
  • Lot_Number and Lot_Code carry batch identity, which matters for pharma and FMCG.

Sale returns come through POST /api/GetSaleReturnInvoice, and the same endpoint family covers sale challans and challan returns.

Items

POST /api/GetItemMaster. This is chain-wide, not per store. It returns the style, shade, pack and the thirty configurable group slots described on the ERP page, with BasicRate, PurRate, SaleRate and MRP.

There is no documented per-store price list endpoint. If a customer runs store-specific pricing, the only price you can read reliably is the one that was actually billed, from MRP_SaleBill and Rate on the invoice line. Raise this early: for a POS integration it is often the difference between a working price feed and none.

Stock per store

POST /api/GetStockInHand, with Branch_Codes and optionally Godown_Name. Two branches of the same chain are two calls, or one call with several branch codes depending on how the customer's parameter is configured.

Two modes, and the second is the reason a LOGIC POS connector can be efficient:

  • Barcode mode: pass a comma-separated list in LogicUserCode or AddlItemCode and get stock for exactly those items.
  • Delta mode: set StockType to DELTA with a RequestDate and get only what has changed since. Run this per branch on a short interval and you have a live per-store stock feed without polling the whole catalogue.

Rows carry Branch_Code, Branch_Name, Godown_Name, Godown_Code, Stock_Qty, Carton_Stock, lot identity with purchase and expiry dates, and both lot and item prices.

Customers

POST /api/GetPartyMaster reads ledger accounts. The retail customer file, which is the POS-side customer, is written through POST /api/SaveRetailCustomer and POST /api/UpdateRetailCustomer but has no documented dedicated read endpoint. In practice the retail customer identity comes back attached to bills, through the RCU_ fields.

The retail customer record is unusually detailed for an ERP, and is clearly built for apparel and footwear CRM. Documented fields include membership series and number, title, first, middle and last name, email, mobile (the only mandatory field), birth date, gender, marital status, age, house number, location, city, state, pin code, country, branch, spouse name and birthdate, shoe size, two children's names and dates of birth, anniversary date, three address lines, GST state code, GST number and a discount card number.

Treat all of it as PII, and treat the children's names and dates of birth as a category that should probably not leave the customer's systems at all. Ask before syncing that file.

Writing back: sales, invoices and stock

Everything on the ERP page applies. The store-relevant writes:

On the write side a bill carries the till-specific pieces as structured input rather than as the flattened columns you get back on the read:

  • RCU_Mem_Prefix, RCU_Mem_Number, RCU_Mobile_No, RCU_Email, RCU_First_Name, RCU_Last_Name, RCU_City, RCU_State, RCU_PinCode, RCU_Country attach or create the retail customer.
  • TenderDetails is an array of TenderType, CardName, CardNo, GiftVoucherNo and Amount. Split tenders are supported. Never persist CardNo.
  • Token_No and PaymentMode carry the till token and payment mode.
  • BillSeries with Bill_Number set to 0 lets LOGIC allocate the next number in that branch's series.

Gift vouchers are a first-class object rather than a tender string. SaveGiftVoucher takes a voucher group and short name, a ledger account code, optional commission basis and value, a voucher prefix and number, amount, barcode, creation branch and expiry date. Mandatory fields are the group, the group account code, the prefix, the number and the amount.

Footfalls are recorded as an array of counts, which is a genuinely useful retail object that most POS APIs do not expose:

[
  { "BranchCode": 2, "FootFallDate": "01/07/24 12:00:00 AM", "FootFallTime": 6, "FootFallCategory": "Female", "Count": 5 },
  { "BranchCode": 2, "FootFallDate": "01/07/24 12:00:00 AM", "FootFallTime": 10, "FootFallCategory": "Kids", "Count": 5 }
]

FootFallTime is an hour slot, FootFallCategory a demographic bucket, and the whole thing is per branch per day per hour. Combined with the bill count from GetSaleInvoice this gives a conversion rate per store per hour. Note that it is a write endpoint: LOGIC accepts footfall counts from a door counter, it does not publish a read.

Stock is never set to a number. Push a godown transfer, an issue or a receipt.

Webhooks and notifications

None. There is no bill-closed event, no till heartbeat, no shift-close callback and no stock-change notification.

Poll, per branch:

  • Bills: GetSaleInvoice with Branch_Codes_From and GlobalModifyCode, every 5 to 15 minutes during trading hours. Filter out Bill_Cancelled.
  • Stock: GetStockInHand with StockType set to DELTA and RequestDate set to the previous run, every 15 to 30 minutes.
  • Items: GetItemMaster with GlobalModifyCode, hourly, chain-wide rather than per branch.

Multiply the branch count into your request budget and agree the total with the customer's IT contact before enabling anything. A 600 store chain polling every branch every five minutes is 7,200 requests an hour against a Windows Server that is also billing.

Rate limits and pagination

Not published, and there is no pagination on any endpoint. The filter is the page control. For a POS connector that means always setting Branch_Codes_From and either GlobalModifyCode or a narrow date window, and always preferring the delta stock mode.

Mapping to the unified model

Only the store-specific fields are listed. Everything else is on the ERP page.

Gaps and open questions

  • No per-store price list endpoint is documented. GetItemMaster is chain-wide. If the customer prices per store, the only reliable read is the billed rate.
  • No shift, cashier or till reconciliation endpoint. The knowledge base documents shift and cashier setup as a product feature, but nothing in the API exposes a shift summary or a till close. Cash reconciliation has to be rebuilt by summing the tender columns across bills for a branch and a day, which will not match a till close that includes float, pay-ins and pay-outs.
  • No loyalty points balance read. Points accrual and redemption are product features, and GetEmployeeDiscountPointsStatus covers employees only. A customer's points balance is not exposed.
  • No retail customer read endpoint. The file can be written and updated but not listed.
  • No footfall read. Footfalls can be pushed in but not pulled out.
  • No terminal or device identity on the bill. You cannot tell which till raised it from the documented fields.
  • No branch or godown list endpoint, although both are parameters everywhere. Harvest codes from documents or ask the customer.
  • Which numbered Tax_Amt_ slot is CGST, SGST, IGST or cess is customer configuration and is undocumented.
  • Action_Code and GlobalModifyCode semantics are unexplained, which matters more at store volume than at head office volume.
  • Whether the customer's stores work against a central database or a replicating branch database is not documented anywhere and determines data freshness. Ask.
  • No rate limit, no pagination, no idempotency key on writes.
  • The Android application named LOGIC POS is a reporting and approvals companion, last updated February 2022, not the till. Do not build against it.

Sources