nearle_daily/backend_fiesta
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Route offline sales by the branch named on each spreadsheet row

Browse Source 
The offline-sales import required one workbook per outlet and a store
picked in the UI. A merchant running several branches had to download,
fill and upload a file per branch, and the picker defaulted to the
tenant's first outlet — so an admin who never touched it silently
credited the wrong store, which no validation could catch because the
file and the selection agreed with each other.

One workbook now covers every branch. getsaletemplate takes locationid=0
(the default) to span the tenant, stamping tenantid, locationid and the
store name onto every row, and that row's locationid is what decides
which branch a sale is deducted from. The INNER JOIN on tenantlocations
confines it to outlets the tenant owns, so a template can never disclose
another merchant's catalogue.

uploadofflinesales accordingly takes locationid on each bill. The
locationid on the request itself becomes a scope constraint rather than
a destination: left at 0 the bills go where their rows say, and set to a
branch it pins the upload there and refuses anything else. That is what
holds a store user to their own store — the pin comes from their session,
so editing the locationid column in the spreadsheet changes nothing.
Every branch referenced is checked against the tenant regardless.

Branch context and catalogue are resolved once per branch and reused; a
workbook covering six outlets would otherwise re-run both queries for
every bill in it.

Duplicate detection is now per branch. Bill numbers only have to be
unique within a store, since counter books at different outlets
routinely restart numbering at 1, and treating a shared number as a
repeat would have silently dropped a real sale.

Verified against tenant 1087, whose two branches both stock product
6998 at 100 units: a single upload of two bills moved 1097 to 97 and
1135 to 95 independently; the same bill number at both branches imported
as two separate orders; an upload pinned to 1097 imported its own bill
and refused the 1135 one; a row naming another tenant's outlet was
refused; and re-uploading the file deducted nothing. All five test
orders were cancelled afterwards and both branches confirmed back at 100.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
abhishek
2026-07-31 12:17:52 +05:30
parent 583cd89063
commit c290e1729a
6 changed files with 234 additions and 83 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
models/order.go
View File

@@ -460,9 +460,18 @@ type OfflineSaleItem struct {
}
// OfflineSaleBill is one counter bill — the rows of a spreadsheet grouped by
// their billno. Billno is what makes a re-upload of the same file safe: it is
// recorded on the order and refused if it is already present for this outlet.
// their branch and bill number.
//
// Locationid is the branch the bill was rung up at, taken from the spreadsheet
// row rather than from a store the operator picked in the UI. One workbook can
// therefore carry sales for every branch a merchant runs, and each bill's stock
// comes out of its own outlet. Bills are grouped per branch, so the same bill
// number at two outlets is two separate sales, not a duplicate.
//
// Billno is what makes a re-upload of the same file safe: it is recorded on the
// order and refused if already present for that branch.
type OfflineSaleBill struct {
Locationid int `json:"locationid"`
Billno string `json:"billno"`
Saledate string `json:"saledate"`
Paymentmode string `json:"paymentmode"`
@@ -472,9 +481,16 @@ type OfflineSaleBill struct {
Items []OfflineSaleItem `json:"items"`
}
// OfflineSalesUpload is the request body. Locationid is the outlet the sales
// belong to and is authorised server-side against Tenantid — a store user
// editing the spreadsheet cannot post sales into another branch.
// OfflineSalesUpload is the request body.
//
// Locationid here is a scope constraint, not the destination. Left at 0 the
// bills go to whichever branch each one names, which is what a multi-branch
// owner uploads. Set to a branch it pins the whole upload to that outlet and
// any bill naming a different one is refused — that is how a store user is
// held to their own store no matter what the spreadsheet says.
//
// Every branch referenced is checked against Tenantid regardless, so no upload
// can reach an outlet the merchant does not own.
type OfflineSalesUpload struct {
Tenantid int `json:"tenantid"`
Locationid int `json:"locationid"`
@@ -492,7 +508,11 @@ const (
// OfflineSaleResult reports one bill's fate. Bills are independent, so a file
// with one bad bill still imports the rest and names exactly what it skipped.
// The branch is echoed back because a single upload spans several, and "bill 7
// failed" is not actionable without knowing which store it belonged to.
type OfflineSaleResult struct {
Locationid int `json:"locationid"`
Locationname string `json:"locationname"`
Billno string `json:"billno"`
Status string `json:"status"`
Orderid string `json:"orderid"`

45
models/product.go
View File

@@ -327,19 +327,27 @@ type ProductLocationRef struct {
Productid int
}
// SaleTemplateRow is one line of the downloadable offline-sales spreadsheet:
// a product actually stocked at one outlet, with the numbers the person at the
// till needs to see before they type a sold quantity against it.
// SaleTemplateRow is one line of the downloadable offline-sales spreadsheet: a
// product stocked at one branch, with the numbers the person at the till needs
// to see before typing a sold quantity against it.
//
// Tenantid and Locationid ride on every row because one workbook covers every
// branch a merchant runs. The row's own Locationid decides which branch's stock
// its sale comes out of — a tenant-level import would be wrong, since the same
// product is held separately at each outlet.
//
// Productid is the only field that identifies the product. It cannot be
// productsku: across the live catalogue 6,245 products share just 93 distinct
// sku values (one tenant has 463 products all carrying sku "1"), and 154 are
// blank, so a sku is not a key. Productname is nearly unique per tenant but
// not reliably ("rice" appears 6 times for one tenant), so it travels as a
// blank, so a sku is not a key. Productname is nearly unique per tenant but not
// reliably ("rice" appears 6 times for one tenant), so it travels as a
// human-readable confirmation only and is never matched on. That is why the
// spreadsheet has to be generated from this endpoint rather than typed from
// scratch — the productid column is filled in for the user.
// scratch — productid and locationid are filled in for the user.
type SaleTemplateRow struct {
Tenantid int `json:"tenantid"`
Locationid int `json:"locationid"`
Locationname string `json:"locationname"`
Productid int `json:"productid"`
Productname string `json:"productname"`
Productunit string `json:"productunit"`
@@ -350,15 +358,24 @@ type SaleTemplateRow struct {
Taxpercent float64 `json:"taxpercent"`
}
// SaleTemplate is the payload the web app turns into an .xlsx workbook. The
// tenant/location identity travels with it so the generated file records which
// outlet it belongs to, and the upload can be checked against the file it came
// from instead of trusting a hand-typed location.
// SaleTemplateLocation is one branch covered by the workbook, so the sheet can
// list what it spans and the UI can summarise it without walking every row.
type SaleTemplateLocation struct {
Locationid int `json:"locationid"`
Locationname string `json:"locationname"`
Productcount int `json:"productcount"`
}
// SaleTemplate is the payload the web app turns into an .xlsx workbook.
//
// Locationid is 0 when the template spans every branch of the tenant, which is
// the normal case for an owner or admin. A store user gets a template for their
// own branch only, and it is then the single entry in Locations.
type SaleTemplate struct {
Tenantid int `json:"tenantid"`
Locationid int `json:"locationid"`
Locationname string `json:"locationname"`
Products []SaleTemplateRow `json:"products"`
Tenantid int `json:"tenantid"`
Locationid int `json:"locationid"`
Locations []SaleTemplateLocation `json:"locations"`
Products []SaleTemplateRow `json:"products"`
}
type ProductSubcategory struct {