Route offline sales by the branch named on each spreadsheet row

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>

models/product.go

@@ -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 {