Retail software becomes useful when it follows the counter instead of asking the shopkeeper to maintain a separate notebook, WhatsApp thread, spreadsheet, and printer workaround for every exception. HisabLekha's current public product documentation now calls out twenty workflow updates for Indian apparel, fabric, footwear, boutique, uniform, and multi-store retailers. They are practical additions rather than a promise that every shop has the same hardware or plan configuration.
Keep mobile forms clear while the on-screen keyboard is open
On supported touch devices, HisabLekha detects the on-screen keyboard and hides selected fixed bottom controls, including mobile navigation, checkout, and action or print bars, while it is open. Those controls return after the keyboard closes. Moving these selected bars gives the active form more room; it does not promise that every field will be visible on every phone or browser.
Try the workflow on the exact phone and browser used at the counter: open a supported billing or customer form, focus a field, and check that the selected fixed controls move away and return when typing ends. The behavior depends on the device's keyboard and viewport. See the mobile keyboard controls in the product overview.
What is included in the 2026 workflow update?
- Mobile keyboard-aware controls: On supported touch devices, selected fixed bottom navigation, checkout, and action bars hide while the on-screen keyboard is open and return after it closes. This creates more room around the active form; check the exact phone and browser workflow.
- Customer receivables and supplier payables: In Reports > Outstandings, switch between pending customer sale bills and supplier purchase bills for the active shop. Review age by invoice date or recorded due date, expand bill details, and print or export CSV; missing due dates use the invoice date.
- Dashboard privacy mode: Start the dashboard with money figures masked, reveal them with the eye control for up to 60 seconds, and let them mask again automatically. This is a shoulder-surfing privacy affordance for the dashboard, not access control; printed bills remain unchanged.
- Combined-sale payment history: In Sales History, each participating shop's row can show the original combined checkout's payment methods and any advance applied. The same whole-sale summary repeats on each row for context; it is not the shop's individual collection, and later returns or exchanges stay separate.
- Clothing alteration jobs: Record the garment, work instruction, promised date, tailor, status, optional charge, measurements, printable slip, and ready-for-collection handover.
- Customer loyalty points: On eligible plans, configure earning, point value, minimum-bill, and expiry rules; let saved customers earn points on completed bills, review a shop-scoped balance and history, and redeem points as a bill discount. Owner-only manual adjustments require a reason, while estimates, unsupported pricing modes, and redeemed-bill corrections remain outside this workflow.
- Same-shop return-credit allocation: For a positive return-credit payment, apply eligible credit FIFO to older completed-sale dues for the same customer and shop; cash-refund returns remain outside this automatic allocation.
- Exchange-visit summary card: When the visit balances, Sales History can show one summary card with the returned items, the new items, and reconciled all-shop context. Keep the existing history card when the visit does not reconcile; availability depends on the latest app and database deployment.
- Retry-safe connected checkout: For supported online new sales, returns, exchanges, and combined checkout, keep the same request when a response is lost so a confirmed result can be replayed instead of silently recorded twice; an unknown outcome stays visible for review.
- Eligible completed purchase corrections: Review supported price, date, freight, notes, and child-line changes while explicit variant-parent guardrails refuse quantity increases, parent inserts, and parent-to-child moves before a write.
- Opening stock without a supplier bill: For pre-system inventory, record fixed-piece quantity or metre length with a reason and notes, then review the signed stock movement in dashboard activity. Use the purchase workflow when a supplier bill exists.
- Combined estimates and deposits: For participating shops, record shop-scoped deposits, show the amount received and balance pending across the estimate, and carry the scoped deposit into the final shop-wise sale conversion.
- Open customer estimates across linked shops: In Customer Ledger's All Shops view, review estimates from authorized, linked shops with each shop name, estimate total, deposit received, and pending estimate balance. These amounts stay separate from completed-sale customer dues; other-shop rows are read-only here, and unresolved customer-link conflicts are excluded from the combined view.
- Hosted invoice and estimate links: Create a secure customer-facing link for supported sale, return, exchange, and estimate documents, then copy, share, or revoke it from the billing workflow.
- Per-roll fabric barcode copies: Select open physical rolls and choose how many labels each roll should receive, instead of treating every roll like one generic SKU quantity.
- Cross-shop roll barcode lookup: During supported combined checkout, resolve a compatible physical roll barcode from another participating shop through a shop-membership check before loading the real roll or SKU.
- Inline taxonomy setup: Owners can create a category or a category-scoped subcategory while adding a SKU, without abandoning the product form.
- Desktop A4/A5 document printing: Save a system printer for sheet-fed bills, test the route, and keep document printing separate from the shop's thermal receipt printer.
- Invoice Builder controls: Save the order of supported item columns, show optional MRP fields in supported templates, and use ruled bill-book layout controls while checking the real printed output.
- Exchange-safe A5 invoice tables: Let long item descriptions wrap while numeric figures stay readable and the Amount column remains within the printed exchange table. Test the real item names, paper width, and printer driver before rollout.
Let eligible fashion shops reward repeat customers
A loyalty programme is useful only when its rules are visible at the counter. On eligible HisabLekha plans, an owner can configure the rupees-per-point rate, point value, minimum bill, and expiry rules. Completed bills can earn points for saved customers, and the customer record can show a shop-scoped balance and history before points are redeemed as a bill discount.
The control boundaries are part of the feature. Manual point adjustments are owner-only and require a reason. Points do not run through estimates or unsupported pricing modes, and redeemed-bill corrections remain outside this published workflow. Check the shop's current plan, earning rule, expiry setting, and discount result in a demo before promising a loyalty programme to customers. Start with the customer loyalty points workflow and review current plan terms.
1. Keep alteration jobs connected to the garment sale
A fitting, hem, repair, or other clothing alteration is easy to lose when the bill is in one place and the tailor's instruction is in another. The documented alteration workflow keeps the customer or walk-in, garment, work description, promised date, notes, tailor assignment, status, and optional charge together. A job can be started from the alteration worklist, a customer record, or an eligible sale line that needs work.
Saved customers can keep versioned customer measurements in a profile. When a new measurement is saved, the earlier version remains available for review instead of being silently overwritten. The current profile can be attached to the job and its printable slip. The worklist then separates pending, in-progress, ready, delivered, and cancelled jobs, with due-date signals for the counter.
This is deliberately a retail handover workflow. In the current v1 boundary, alteration writes are online-only, measurements require a saved customer, and a combined multi-shop bill cannot carry an alteration job. It does not claim cutting-room planning, full custom-tailoring production management, or tailor payroll. Read the alteration management software page and the clothing alteration guide for the full workflow and limitations.
Allocate eligible return credit to older same-shop dues
A return can leave a customer with credit while an older bill is still due. In the current production workflow, a positive return-credit payment can be applied FIFO to older completed-sale dues for the same customer and shop, with the allocation bounded by the return's effective time. This keeps the due settlement tied to the return instead of asking the counter team to make a second manual adjustment.
The boundary matters: cash-refund returns are excluded from this automatic allocation. The shop should review the source invoice, customer, shop, amount applied, remaining credit, and configured return policy, while its accountant decides the applicable GST, refund, and credit-note treatment. Start with the retail return and exchange page and test an older same-shop due plus a return-credit case before rollout.
Can Sales History summarise an exchange visit?
A size exchange can involve a returned garment, a replacement item, a payment difference, and another shop's invoice. The documented exchange-history preview is designed to make that visit readable in Sales History: for a visit that balances, one summary card shows the returned items, the new items, and reconciled all-shop context.
The card is shown only when the visit balances; when the facts cannot be reconciled, the existing Sales History card remains. Availability depends on the latest app and database deployment. Review the exchange-visit history preview and verify the exact deployment with a test exchange before relying on it.
Retry-safe checkout when a connection drops
A counter can lose the response after pressing Pay even when the server has already received the request. In supported online new sales, returns, exchanges, and combined checkout, the current production workflow keeps the same request identity while the result is unknown. A retry can replay the confirmed result instead of silently recording a second transaction.
This does not turn every flow into the same online checkout. If the server cannot confirm the first attempt, HisabLekha keeps the outcome in doubt and tells staff to review it; it does not guess. Offline queues, existing drafts or estimates, loyalty or advance applications, and some exchange paths follow separate rules. Test a dropped-response case in the shop's own deployment before relying on the recovery path.
2. Give customers a hosted invoice or estimate link
Customers often want a bill on their phone rather than another paper copy. For supported sale, return, exchange, and estimate documents, the billing workflow can create a hosted link with a share token, copy it, use the device share action, or offer the WhatsApp sharing path. Staff can see the link status and revoke a link when it should no longer be available.
The useful distinction is between a link the shop controls and a screenshot that can be forwarded without context. A hosted document can present the customer-facing invoice facts in one place, while the shop retains a record of the link's status. Expiry, revocation, plan entitlements, document eligibility, and the actual deployment still need a live test; do not promise a hosted link for a purchase document or for a transaction type the shop has not verified.
For the product surface, start with the HisabLekha product overview, then test one completed sale, one return or exchange, and one estimate on the shop's real phone. The pricing page remains the source of truth for plan scope and renewal terms.
Review completed purchase corrections with explicit variant guardrails
A completed supplier bill should not be changed by silently rewriting a stock number. In the current production workflow, eligible completed purchase records can be opened for supported price, date, freight, notes, and child-line corrections. The edit path keeps the purchase, stock, and supplier-ledger update connected while the shop reviews the result.
The variant rules are explicit. If a historical line belongs to a parent that was later split into sizes or colours, a quantity increase, a new parent line, or a parent-to-child move is refused before a write and the counter receives plain guidance. Extra pieces should be recorded as a purchase of the exact size or colour; a reversal should use the purchase-return workflow. Completed size-leaf purchase edits remain outside this published scope, so verify the exact variant shape, stock result, supplier balance, and return path in a demo.
Record opening stock without a supplier bill
When a shop starts using a billing system, some stock already exists without having entered through a supplier invoice in the new system. The opening-stock workflow records that pre-system inventory separately: fixed-price items can carry a quantity, metre-tracked items can carry a length, and the entry keeps a reason and notes for the shop's review.
The dashboard activity view can show the signed stock movement with the product identity, so the counter team can distinguish an opening-stock intake from a purchase, sale, return, or exchange. This is not a way to rewrite a supplier bill or bypass purchase records. When a supplier invoice exists, use the purchase workflow; for opening stock, verify the SKU price type, shop permissions, entry date, notes, and resulting stock history in a demo. See the inventory section and use this workflow-specific demo to check the shop's real stock shape.
Review customer dues and supplier purchase bills by age
Reports > Outstandings gives the active shop separate Receivables and Payables views for pending customer sale bills and supplier purchase bills. Staff can switch the aging basis between invoice date and recorded due date, search for a customer or supplier, expand a bill breakdown, and print or export the report as CSV. When a bill has no recorded due date, the aging view falls back to its invoice date.
This is an outstanding-bill review for the selected shop, not a multi-branch balance roll-up and not a supplier-payment action. A relevant supplier-debt insight can open this same report directly on Payables. Read the customer and supplier outstanding report overview for the workflow and scope. The product feature overview shows where the report sits in the wider system; check a real shop's dates and pending bills before relying on the aging buckets.
Mask financial figures when the shop dashboard is visible
A shopkeeper may need to open the dashboard while a customer, staff member, or delivery partner is standing beside the counter. The documented dashboard privacy mode starts with money figures masked behind a uniform display. An authorized user can tap the eye control to reveal the figures for up to 60 seconds, after which the mode masks them again automatically.
This is a shoulder-surfing privacy affordance, not an access-control system: it changes what the dashboard paints, not what the account can fetch or store. The scope is deliberately the dashboard, so printed bills remain unchanged. See the dashboard privacy mode on the product page and review the workflow-specific demo with the shop's team.
Combined estimates with shop-scoped deposit handoff
A customer may choose items from two participating shops and pay a deposit before the final sale is ready. A supported combined-estimate flow keeps the estimate tied to the participating shops, records the deposit associated with each shop, and shows the combined amount received and balance still pending instead of making the counter team reconstruct the visit from separate notes.
When the customer confirms the order, the scoped deposit can be carried into the conversion to separate shop-wise GST invoices. The conversion validation counts the deposit only for the estimate actually being converted and only for the shops still participating. If one shop is dropped, its estimate and deposit remain separate rather than silently paying for the other shop's sale. Start with the multi-store POS workflow and verify the branch permissions, estimate status, payment allocation, and printed or hosted output on the actual deployment.
Read the original payment for a combined multi-store sale
When one customer checks out items from participating shops together, each shop still has its own bill. Sales History can now add a Combined line to each participating shop's row, showing the payment methods and any advance applied to the original sale. This gives staff a clearer view of the billing settlement without opening each participating bill first.
The same whole-sale snapshot repeats on every participating shop's row for context; it is not the amount collected by each individual shop, so do not add the repeated figures together. A return or exchange created later remains separate from the original at-billing summary. Review the multi-store POS workflow and Sales History feature overview, then test a combined checkout with the shop's own participating branches.
Review open customer estimates across linked shops
When a customer has a saved record in more than one branch, staff can use Customer Ledger's All Shops view to review that customer's open estimates from shops they are authorized to access. Each entry identifies its shop and shows the estimate total, deposit received, and remaining estimate balance, so a pending quotation is not mistaken for money already due on a completed sale.
Estimates held by another shop are visible for context but read-only from this view; estimate actions stay with the shop that owns the estimate. If customer records have an unresolved link conflict, the combined customer ledger is not shown. See the multi-store customer estimate workflow and product overview, then test a resolved customer with open estimates in two accessible shops.
3. Print barcode copies per physical fabric roll
A fabric shop may have one fabric SKU represented by several physical rolls, each with its own roll code, barcode, and remaining metres. Printing one generic label count for the SKU does not give the stockroom a useful identity for each roll. The updated barcode workflow loads open physical rolls for metre-tracked products, lets staff select the actual rolls, and gives each selected roll its own copy count.
The bulk copy control also applies to the selected open rolls, so a shop can choose several rolls and set the same number of labels per roll before printing. The generated barcode objects use the individual roll barcode and retain the roll code and remaining-metre context. Piece-based products continue to use their normal SKU-level copy behaviour.
Before printing a large batch, select two real rolls with different remaining lengths and scan the labels back into the inventory flow. Confirm that the label identifies the physical roll the staff member intended, rather than assuming that a shared fabric SKU is enough.
Look up a roll barcode from another participating shop
A combined checkout can include products held by more than one participating shop. During that supported flow, a compatible physical roll barcode from another participating shop can pass through a shop-membership check before HisabLekha loads the real roll or SKU. This gives the counter a concrete lookup path for a fabric roll without turning the system into a global search across unrelated shops.
Test this with a real participating shop, a roll that is set up for barcode lookup, and the scanner model the counter will use. Verify the loaded roll, remaining metres, shop identity, and resulting invoice before promising cross-shop barcode coverage for every product or branch.
4. Finish category setup while adding a SKU
Product entry often breaks the counter rhythm when the right category does not exist yet. The inline taxonomy controls let an owner create a category or create a subcategory under the selected parent from the SKU form, then continue with the item setup. A subcategory cannot be created as an orphan: the parent category must be selected first.
This control is intentionally owner-only because the underlying permission policy does not allow every staff account to change shop taxonomy. It is also online-only. When the device is offline, the control is disabled so the form does not suggest that a change was saved when the server could not create it. Owners should create the category, confirm it is selected, and then save the SKU as one short test path.
5. Route A4 and A5 bills to the right desktop printer
Sheet-fed document printing and thermal receipt printing are different jobs. A shop that chooses A4 or A5 for its bill should not have to send that document to an 80mm receipt printer by accident. In the HisabLekha desktop app, the document-printer setting can list the computer's system printers, save the selected printer for the shop, and print an A5 diagnostic page before the counter starts using it.
The bill still follows the shop's selected document size, while the thermal receipt path remains separate. Browser and mobile users continue with the ordinary device print dialog because a browser tab cannot name an operating-system printer in the same way as the desktop app. Test the actual paper, margins, printer driver, and invoice template before promising a particular output to a customer.
Exchange bills receive an additional print-safety check: item descriptions may wrap in the A5 exchange tables, while quantity, rate, tax, and Amount figures stay readable and the Amount column remains inside the table width. Use a long real item description and a real exchange bill when validating the printed result.
Configure invoice columns and optional MRP output
Invoice output needs to fit the way a shop reads a bill. The Invoice Builder can save the order of supported item columns and expose optional MRP fields in supported templates. The ruled bill-book template adds a structured print layout, while the selected paper size, printer, logo, tax fields, and shop configuration still determine the finished document.
Treat the builder as a controlled print workflow, not as a promise that every template has the same columns. Move one column, enable MRP where the selected template supports it, preview the bill, and print a real exchange or sale with the shop's paper and printer. Use the Invoice Builder section for the product surface and check the actual output before rollout.
How to test all twenty workflows in one demo
- Mobile keyboard: On a supported touch device, open a billing or customer form, focus a field, and confirm the selected fixed bottom navigation, checkout, or action controls step aside while the on-screen keyboard is open and return after it closes. Repeat on the exact phone and browser used at the counter.
- Customer receivables and supplier payables: In Reports > Outstandings, switch between pending customer sale bills and supplier purchase bills for one shop; compare invoice-date and due-date aging, search a party, expand a bill, and test print and CSV. Confirm the report does not combine shops or make supplier payments.
- Dashboard privacy: Open the dashboard beside a test customer, confirm money figures start masked, reveal them with the eye control, hide them manually, wait for the automatic timeout, leave and return to the page, and confirm a printed bill is still complete. Do not use live customer data for the test.
- Alteration: Save a test customer, complete an eligible fixed-price garment sale, attach measurements, assign a tailor, print the slip, and move the job to ready.
- Loyalty points: On an eligible plan, configure a test earning rule and expiry, complete a bill for a saved customer, review the shop-scoped balance and history, redeem points as a discount, and confirm that any manual adjustment requires an owner reason.
- Return credit: Use a customer with an older same-shop completed-sale due, record a positive return-credit payment, and confirm the FIFO allocation plus any remaining credit. Repeat with a cash-refund case to confirm it stays outside this automatic path.
- Exchange history: Open Sales History for a reconciled exchange visit and confirm that the summary card shows the returned items, the new items, and the branch context once. Confirm that an unreconciled visit keeps the existing history card.
- Retry safety: In a test workspace, submit a supported online bill, return, exchange, or combined checkout while simulating a lost response; retry with the same request and confirm the existing result is replayed, while a still-unknown result stays visible for review. Do not test against live customer data.
- Completed purchase correction: Open an eligible completed supplier bill, change a supported field, confirm the variant-parent guidance for a guarded line, and review the resulting purchase, stock, supplier balance, and edit history.
- Opening stock: Add a pre-system fixed-price item and a metre-tracked item, record the quantity or length with a reason and notes, and confirm the signed stock movement appears in dashboard activity without presenting it as a supplier purchase.
- Combined estimate: Use two participating shops, record a deposit for each, print or open the combined estimate, convert it to the sale, and confirm the deposit is counted once in the remaining balance.
- Combined-sale payment history: In a test workspace, complete one supported combined checkout using the participating shops, then open each shop's Sales History row. Confirm the same original payment-method and advance-applied summary appears on each row, and do not treat the repeated whole-sale total as each shop's collection. Add a later return or exchange and confirm it remains separate.
- Linked-shop customer estimates: In Customer Ledger's All Shops view, review one resolved customer's open estimates across two accessible shops and verify estimate totals stay separate from customer dues and other-shop entries are read-only.
- Hosted document: Create a link for a supported sale or estimate, open it on a second phone, use the share or WhatsApp path, and revoke it to confirm the status change.
- Fabric rolls: Load two open metre-tracked rolls, select both, set a per-roll copy count, print, and scan each physical label.
- Cross-shop roll: In a supported combined checkout, scan a compatible roll barcode from another participating shop and confirm the loaded shop, roll, and remaining-metre context.
- SKU setup: As the owner, create a category and a parent-linked subcategory while online, then finish the SKU without reloading the form.
- Documents: On desktop, choose A4 or A5, select the system printer, print the diagnostic page, and compare the result with the browser/mobile print flow.
- Invoice Builder: Move one supported item column, enable optional MRP in a supported template, preview the bill, and print it on the shop's real paper.
- Exchange-safe A5 print: Print an exchange bill with a long item description and confirm that the item wraps without clipping the Amount column.
Know the boundaries before rollout
Test each workflow in the actual shop setup rather than relying on a feature label. Mobile keyboard-aware controls apply only to selected bottom bars on supported touch devices. Dashboard privacy masks figures on the dashboard, is not access control, and does not mask printed bills. Opening stock is for pre-system inventory, not a substitute for a supplier purchase invoice. Loyalty points depend on eligible plans; estimates, unsupported pricing modes, and redeemed-bill corrections are outside the published workflow. Linked-shop estimates require a resolved customer link and authorized shop access, stay separate from customer dues, and are read-only from another shop. Alteration writes are online-only, and reusable measurements require a saved customer. Return-credit allocation is limited to positive return-credit payments against the same customer's older completed-sale dues in the same shop and within the return's effective-time boundary; cash-refund returns are outside it. Retry-safe recovery applies to supported connected paths; offline queues, existing drafts or estimates, loyalty or advance applications, and some exchange paths use separate rules, and an unconfirmed result still needs staff review. Completed purchase corrections are limited to eligible fields and child-line changes; variant-parent quantity increases, parent inserts, parent-to-child moves, and completed size-leaf edits are not blanket editing promises. Combined estimate deposits are scoped to participating shops and the estimate being converted; a dropped shop keeps its own estimate and deposit. The combined-sale summary repeats the original whole-sale figures on each participating shop's history row, so it is context rather than a branch contribution and must not be added across rows. Hosted links apply only to supported document types and remain subject to expiry, revocation, plan, and deployment checks. Cross-shop roll lookup requires a supported combined checkout, participating-shop access, compatible roll setup, and scanner verification; it is not global search. Per-roll labels are for open physical rolls, not a substitute for SKU-level labelling. Inline categories are owner-only and online. Invoice columns and MRP depend on the template and require a print check. Direct operating-system printer selection is a desktop capability; mobile and browser printing use the normal print dialog.
Next step for an Indian retail shop
Use the product overview to see the wider billing, inventory, GST, and shop-operations context, then compare customer dues and supplier bills, linked-shop customer estimates, combined-sale payment history, the dashboard privacy mode, the mobile keyboard-aware controls, the opening-stock workflow, the loyalty-points workflow, the return-credit workflow, the alteration workflow, or the multi-store POS workflow with the shop's real process. Review current pricing and plan terms, and book a workflow-specific demo with the shop's products, phone, scanner, and printer ready. That test is more useful than a generic claim that a retail system supports everything.