How My Local Shops Works: Purchase, Inventory, Billing, Payments and Reports in One Connected System

A connected wholesale management system keeps the same business event useful from the moment goods are ordered until they are sold and paid for. In My Local Shops, Trade Manager, Inventory Manager, Order Manager, Staff Bill, reports and the public digital shop work with the same seller's business data instead of asking the owner to maintain unrelated copies.

This guide follows the complete operational flow. If you first need an overview of the platform and all four apps, read the complete My Local Shops platform guide.

At a glance

Business stage	My Local Shops tool	Main result
Purchase placement and movement	Trade Manager	The owner knows what was ordered, paid, shipped, received, claimed and completed
Stock creation and location	Inventory Manager	Received goods become products and colour-size SKUs with quantity at the correct shop or godown
Owner billing	Order Manager	The owner creates GST or non-GST wholesale invoices and records payment status
Staff billing	Staff Bill	Authorised staff create invoices without seeing owner-only cost, profit or reports
Payment follow-up	Order Manager	Party outstanding reflects partial, credit, later-paid and agreed-settlement cases
Business review	Order Manager reports	The owner reviews sales, cost, profit and month-end information for the CA
Customer discovery	My Local Shops website	Selected inventory appears in the wholesaler's public digital shop with availability and enquiry options

Why connection matters more than having many features

A wholesaler may already have a purchase notebook, WhatsApp chats with suppliers, an inventory spreadsheet, invoice software and a folder for the CA. The problem is not always that one of those tools is missing a feature. The bigger problem is that the information does not travel with the goods.

Consider one shirt design:

• the supplier calls it one item;
• the shipment contains several cartons;
• the godown receives fewer pieces than expected;
• inventory separates it into colour and size SKUs;
• the retailer buys a mixture of those SKUs;
• staff creates the bill;
• the retailer pays only part of it; and
• the owner needs the profit and outstanding to remain truthful.

When each stage is isolated, someone must repeatedly type, remember or recalculate the same facts. A connected workflow reduces that repeated work and makes differences—such as short receipt, low stock or unpaid balance—visible at the stage where they matter.

The complete My Local Shops workflow

Step 1: Record the purchase trade

The flow begins in Trade Manager, not when the goods reach the shop.

The owner records the domestic or international purchase trade, including the supplier, ordered goods, quantity, expected movement, payments and applicable charges. Consignments or shipments can be followed separately when the trade does not arrive in one movement.

This creates a record of what the business expected to receive and what it spent to bring the goods in.

Step 2: Record shipment, payment, receipt and claims

As the trade progresses, the owner updates what actually happened:

1. payment made to the supplier or another trade party;
2. consignment or shipment movement;
3. additional applicable charges;
4. quantity received;
5. damaged or missing quantity;
6. claim raised or resolved; and
7. trade completion.

The received quantity is important. If 100 pieces were ordered and only 80 reached the business, the system should not treat the missing 20 as available inventory.

Trade Manager also helps the owner understand the recoverable cost of the pieces actually received. That costing result becomes useful when deciding the product's selling price.

Step 3: Turn received goods into structured inventory

Inventory Manager gives the received stock its operational structure.

A product represents the common design or item. Its SKUs represent sellable variations. For example:

• Product: Mickey Mouse printed T-shirt
• Item code: 6120
• Colours: red, green and blue
• Sizes: small, medium and large
• Total SKUs: 9

The common name and item code do not need to be recreated for every size. Each SKU still keeps the details that can differ, including its quantity, selling price and image.

The owner also records the location of the stock. This allows the same business to know what is available at a shop and what remains in a godown instead of showing one combined number with no operational meaning.

Step 4: Keep the product details useful for billing

Inventory Manager stores the information Order Manager needs when a product is sold:

• product name and item code;
• system-generated SKU;
• colour, size or other variant;
• available quantity by location;
• SKU image;
• prefilled selling price;
• HSN code; and
• GST rate where applicable.

HSN and GST details are shown intentionally during invoice preparation. Existing values remain protected against accidental changes but can be deliberately edited when the authorised user must correct them. If they are missing, the user can complete them before creating a GST invoice.

Step 5: Decide what customers can see online

Inventory Manager also controls the connection to the public My Local Shops website.

For each relevant product, the owner can decide:

• whether it should appear on MLS; and
• whether its price should be public.

The public shop uses inventory availability rather than presenting every old style as if it were still for sale. An out-of-stock variant remains visibly out of stock, while available variants can still be selected. If the complete product is unavailable, the customer can still enquire through the shop's available contact options.

This keeps the digital wholesale shop connected to the inventory the owner already maintains. It avoids building and updating a second catalogue only for the website.

Step 6: Select a party and create the wholesale invoice

The owner uses Order Manager, while authorised staff use Staff Bill.

The user first selects the retailer or other sales party. Party lists are paginated instead of downloading an unlimited history. Search helps find a party by relevant identity details when the business has accumulated many customers.

The product picker shows product-level listings. Selecting one product then opens its available SKUs together, allowing the user to enter quantity and confirm price for several colour-size variants without searching for the same design repeatedly.

Before saving, the system validates requested quantity against available stock. If one SKU has only 98 pieces and the user enters 100, that SKU is identified near its own quantity field with a visual nudge and haptic feedback. The valid SKUs are not silently sold while one line exceeds stock; the user must correct the invoice plan first.

Step 7: Save the invoice and update stock safely

When the invoice is saved, the selected SKU quantities are deducted from the correct inventory location.

This write is concurrency safe. If another owner or staff member sells the same SKU at nearly the same time, Firestore checks the current document state during the transaction. A conflicting attempt is retried against current data, and an invoice that would now exceed stock is stopped instead of overwriting the earlier sale.

The normal billing flow remains simple for the user, but the protected write matters when two devices are active in one or two shops.

Step 8: Record the payment decision correctly

Every invoice is not paid in the same way. Order Manager supports three common starting choices:

1. Paid in full: the parties agree that the invoice is closed.
2. Paid partial: some money was received and the remainder is still due.
3. Full credit: nothing was received at invoice time and the full amount remains due.

“Paid in full” does not always mean the cash received exactly equals the printed invoice total. A retailer may owe ₹51,000, pay ₹50,000, and both parties may agree that nothing more will be collected. The invoice should remain ₹51,000 for the business and tax record, while the ₹1,000 difference is recorded as an agreed settlement or write-off—not as a false outstanding balance.

If staff mistakenly records such a case as partial, the owner can later review the outstanding invoice, record a payment or close the agreed difference before finalising the relevant CA report.

Step 9: Follow party outstanding without rereading every invoice

Outstanding views query invoices that are still outstanding rather than repeatedly fetching a large invoice history and calculating everything on the phone.

The owner can see:

• which party owes money;
• which invoices contribute to that balance;
• amount already paid;
• amount still due; and
• later payment history.

The invoice detail remains available from the review list so the owner can understand the bill before recording another payment or settlement.

Step 10: Review profit and prepare reports

For a GST invoice, the owner should not mistake tax collected for business profit. The business summary therefore separates the sale before GST, GST amount, total with GST, recorded product cost, profit and margin.

For a non-GST bill, GST labels and fields are omitted instead of displaying irrelevant zero-tax rows.

At month end, the owner can review pending invoices for the period before generating the CA information. This gives the owner a chance to resolve an invoice that was recorded as partial even though both parties had already agreed to close it.

The goal is not to make tax decisions on behalf of the business. It is to give the owner and CA organised, reviewable records without reconstructing the month from notebooks, payment messages and old invoice photographs.

One realistic end-to-end example

Assume a garment wholesaler orders 300 pieces of a new printed shirt design.

Purchase and receipt

• Ordered quantity: 300 pieces
• Supplier rate: ₹200 per piece
• Applicable additional trade costs: ₹3,000
• Actual good quantity received: 290 pieces
• Missing or damaged quantity: 10 pieces

Trade Manager records the difference and any related claim. The owner can evaluate recoverable cost against the goods that actually became sellable instead of dividing costs across 300 imaginary available pieces.

Inventory structure

The 290 received pieces are organised into:

• four colours;
• four sizes;
• 16 SKUs; and
• quantities assigned to the correct shop or godown.

Each SKU can keep its own image, quantity and selling price. The common product name, item code, HSN and GST rate remain available for billing.

Wholesale sale

A retailer purchases three pieces of each of the 16 variants: 48 pieces total. Order Manager opens the product once, lets the user prepare all required SKU lines, validates available quantity and creates one wholesale invoice.

If an authorised staff member creates it through Staff Bill, the owner can later see the bill in Order Manager, but the staff member does not see the owner's product cost or profit.

Payment and report

The retailer pays part by bank transfer and keeps a remaining balance. The invoice enters outstanding for that party. A later payment reduces the balance without changing the original invoice total.

The owner sees sales before GST, the appropriate tax breakdown for a GST invoice, recorded cost and profit. At month end, the invoice contributes to the owner and CA reporting views according to its invoice type and recorded payment facts.

Public shop

If the owner enabled MLS visibility, the same shirt design can appear in the public shop. As invoices reduce inventory, unavailable variants show their stock state instead of continuing to look available.

What information moves between each stage?

From	Used by	Connected value
Trade record and receipt	Inventory decision	Actual received goods and costing context help the owner decide what stock exists and how it should be priced
Inventory product and SKUs	Order Manager and Staff Bill	Name, item code, SKU, variant, image, price, HSN, GST and location-level availability
Inventory visibility settings	My Local Shops website	Whether the product appears publicly and whether its price is shown
Saved invoice	Inventory	Sold quantities reduce stock at the selected location
Saved invoice and payments	Outstanding views	Party balance reflects what remains genuinely collectible
Invoice, tax, cost and payment records	Owner and CA reports	Reviewable sales and tax separation without rebuilding the month manually
Inventory image update	Connected apps and website	Versioned image URLs allow the updated image to appear without keeping stale permanent copies

What the owner sees

The owner can use the connected system to answer operational questions without asking staff to search several records:

• Which purchase trades are still active?
• What quantity was actually received?
• What stock exists in each shop or godown?
• Which styles are low in stock and which are completely out?
• Which invoice did staff create?
• Which parties still owe money?
• How much of a bill was paid, written off or left on credit?
• What was the recorded cost and profit of an invoice?
• What should be reviewed before preparing the month's CA information?

What staff can and cannot see

Staff Bill is connected to the owner's business but does not copy the owner's authority.

Authorised staff can:

• access their assigned business context;
• find permitted parties and products;
• see available sellable quantity;
• prepare multiple SKU lines;
• confirm selling price;
• create invoices; and
• record the payment received during billing.

Staff cannot use that access to see owner-only product cost, invoice profit or private reports. Owners should remove staff authorisation promptly when employment ends.

Cloud connection across devices and apps

My Local Shops business records are stored in Firebase against the authenticated seller and authorised staff relationship. The apps do not depend on one specific phone as the only copy of the business.

This means an owner can change a supported device and sign in again using the same authorised account. It also means an image or inventory update made through one connected owner app can be reflected where the same data is used elsewhere.

The system uses caching to avoid downloading unchanged images repeatedly, while versioned image URLs allow a changed product photo to replace the old cached version. Logging out removes private app cache where required; access to cloud records remains controlled by authentication and Firestore rules.

Common workflow mistakes

Recording only the final stock

Adding stock without recording the purchase trade may produce an inventory number, but it loses the history of payments, shipment, shortages, claims and true acquisition cost.

Completing a trade before resolving receipt differences

If ordered and received quantities differ, record the difference and claim status first. Otherwise the owner's cost and supplier follow-up can be misleading.

Using one combined SKU for every colour and size

A common product should group its variants, but each sellable colour-size combination still needs its own SKU and quantity. Otherwise billing cannot validate the exact stock sold.

Giving staff the owner login

Use Staff Bill authorisation instead. Sharing the owner account exposes sensitive information and makes staff activity harder to separate.

Marking an agreed settlement as permanently partial

If both parties agree that no more money is due, leaving the invoice partial creates a false outstanding balance. Record the settlement or write-off explicitly while keeping the invoice total unchanged.

Finalising the month without reviewing pending invoices

Before preparing the CA report, review the month's outstanding invoices. Payments or settlements recorded later may need to be reflected in the business review before finalisation.

Assuming a save succeeded without confirmation

Connected stock and invoice writes require internet access. If connectivity fails, wait for the app's success confirmation or retry safely rather than assuming the data was stored.

Frequently asked questions

Do I have to enter the same product separately in every app?

No. Inventory products and SKUs are shared with the billing workflow. Order Manager and Staff Bill use product listings and current SKU details from the seller's inventory instead of requiring a separate billing catalogue.

Does Trade Manager automatically decide my selling price?

No. It helps the owner understand recorded purchase and landed-cost information. The owner still decides the selling price, and each SKU can use a different price where required.

Can one product contain many colour and size variants?

Yes. The product picker works at product level, then presents its SKUs together so a wholesaler can plan several colour-size lines before adding them to one invoice.

What if staff and the owner sell the same SKU together?

The invoice save uses concurrency-safe stock transactions. Firestore rechecks the current document when writes conflict, preventing a stale quantity from silently replacing a newer sale.

Does a fully paid invoice always require the amount received to equal the bill total?

No. If both parties agree that a lower received amount closes the bill, the invoice total remains unchanged and the difference is recorded as settlement or write-off. It should not remain as collectible outstanding.

Are GST and non-GST bills mixed together?

Both are supported, but non-GST bills do not display unnecessary GST labels. Reporting can separate the relevant invoice information for owner and CA review.

Will website products update when inventory changes?

Products selected for MLS use connected listing and availability data. Visibility, price-display and stock changes can therefore affect what the public shop shows without maintaining another manual catalogue.

Can I start with only the app I need today?

Yes. The apps have focused jobs, but their value increases as the workflow becomes connected. Review how the apps fit together, download them from the apps page, and check current access terms on pricing.

Build one record through the whole business

The practical value of a connected wholesale management system is not that every employee sees every screen. It is that each authorised person records the right fact once, in the right part of the workflow, and the owner can use that fact later.

Start with the purchase, record what arrived, structure the inventory, bill the correct SKU, save the payment truthfully, review outstanding and profit, and let selected stock support the public digital shop. That is how My Local Shops connects daily operations without turning one app into an overloaded accounting screen.