Previous value: -"The FULL replacement line set — every line the corrected bill should have, not only the one that was wrong. Same shape as create_bill_draft. Omit it entirely when you are only correcting header fields. A line Taokeh converted from a per-foot or per-piece price prints in tons at a whole-ringgit rate under a note like \"(150' @ RM 0.50/feet)\": send such a line in its FILED form — thickness, width, tally, unit 'feet' or 'pcs', the per-foot or per-piece price (on a purchase, the supplier's cost) and only the grade as the description, never the printed note. On a correction, a PURCHASE line may instead be sent back exactly as it stands on the document; a SELLING line sent back exactly as it stands is read back into its filed form only when its note's price reproduces it (otherwise keep it with { keep: <lineNo> } where offered, or correct the header only); any other line carrying the note follows the rule for a new line — a selling line read back only at its own tons and rate with no discount, a purchase line refused. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed. A BILL THAT RECEIVED GOODS AGAINST A PURCHASE ORDER: you can correct the header, or prices/discounts/SST codes with EVERY line of the whole bill sent back exactly as it is (same products, quantities, order and units — lines not on the order included); any other line change, on any line, is refused at filing and is made by the user on the bill's Edit screen in Taokeh (Purchases → the bill → Edit). A header-only correction (no `lines`) reposts the bill's own lines unchanged."New value: +"The FULL replacement line set — every line the corrected bill should have, not only the one that was wrong. Same shape as create_bill_draft. Omit it entirely when you are only correcting header fields. A line Taokeh converted from a per-foot or per-piece price prints in tons at a whole-ringgit rate under a note like \"(150' @ RM 0.50/feet)\": send such a line in its FILED form — thickness, width, tally, unit 'feet' or 'pcs', the per-foot or per-piece price (on a purchase, the supplier's cost) and only the grade as the description, never the printed note. On a correction, a PURCHASE line may instead be sent back exactly as it stands on the document; a SELLING line sent back exactly as it stands is read back into its filed form only when its note's price reproduces it (otherwise keep it with { keep: <lineNo> } where offered, or correct the header only); any other line carrying the note follows the rule for a new line — a selling line read back only at its own tons and rate with no discount, a purchase line refused. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed. LINE NUMBERS: give each line you keep or correct its `lineNo` (or { keep: <lineNo> }); a line without one is new, a line left out is removed. A line with a lineNo keeps its batch, its stock treatment and, when you omit taxCode, its own SST code; it keeps its product and unit (a different one is refused — drop the line and add a new one instead). A lineNo that is not on this bill, or the same lineNo twice, is refused. If the bill is edited in Taokeh after you read it, a draft that names lines can no longer be approved or revised — read the bill again and file a fresh one. A BILL THAT RECEIVED GOODS AGAINST A PURCHASE ORDER: WITHOUT line numbers you can only correct the header, or prices/discounts/SST codes with EVERY line of the whole bill sent back exactly as it is (same products, quantities, order and units — lines not on the order included); WITH line numbers you can change quantities, add lines and remove lines, and each named line keeps what it received against the order (a removed line's goods go back to being owed). A header-only correction (no `lines`) reposts the bill's own lines unchanged."

Added value: +{
+  "description": "Keep a line of the bill exactly as it stands: { keep: <lineNo> } and nothing else beside it. Counts as naming that line, so the whole set is read by line number.",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

Added value: +{
+  "description": "The bill's OWN line this line is — its lineNo from search_document_lines (docType 'bill'). Send it on every line you keep or correct; leave it off a NEW line. Once ANY line carries one, the whole set is read by line number: a line you leave out is REMOVED. A line keeps its product and its unit — to change the product, leave the line out and add the new product as a new line.",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

Previous value: -"The product id from resolve_product, or its exact SKU. Never a guessed name."New value: +"REQUIRED on every line except a { keep } — the product id from resolve_product, or its exact SKU. Never a guessed name."

Previous value: -"Leave it OUT and the server inherits the ORIGINAL bill's own SST code for this product, so a correction never quietly changes the input tax — an omitted code must never mean 'no SST'. Only set it when the code itself is what is wrong. A NEW product on a taxed bill has nothing to inherit and is refused by name."New value: +"Leave it OUT and the server inherits the ORIGINAL bill's own SST code for this product (on a line with a lineNo: that line's own code), so a correction never quietly changes the input tax — an omitted code must never mean 'no SST'. Only set it when the code itself is what is wrong. A NEW product on a taxed bill has nothing to inherit and is refused by name."

Previous value: -"Up to four decimals (e.g. 0.0325), exactly as invoiced — but a per-foot or per-piece price that Taokeh converts to tons: two decimals. Put a discount or tax in its own field, never folded into the cost."New value: +"REQUIRED on every line except a { keep }. Up to four decimals (e.g. 0.0325), exactly as invoiced — but a per-foot or per-piece price that Taokeh converts to tons: two decimals. Put a discount or tax in its own field, never folded into the cost."

Removed value: -[
-  "productRef",
-  "unitCost"
-]

Previous value: -"The FULL replacement line set — every line the corrected bill should have, not only the one that was wrong. Same shape as create_bill_draft. Omit it entirely when you are only correcting header fields. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed. A BILL THAT RECEIVED GOODS AGAINST A PURCHASE ORDER: you can correct the header, or prices/discounts/SST codes with EVERY line of the whole bill sent back exactly as it is (same products, quantities, order and units — lines not on the order included); any other line change, on any line, is refused at filing and is made by the user on the bill's Edit screen in Taokeh (Purchases → the bill → Edit). A header-only correction (no `lines`) reposts the bill's own lines unchanged."New value: +"The FULL replacement line set — every line the corrected bill should have, not only the one that was wrong. Same shape as create_bill_draft. Omit it entirely when you are only correcting header fields. A line Taokeh converted from a per-foot or per-piece price prints in tons at a whole-ringgit rate under a note like \"(150' @ RM 0.50/feet)\": send such a line in its FILED form — thickness, width, tally, unit 'feet' or 'pcs', the per-foot or per-piece price (on a purchase, the supplier's cost) and only the grade as the description, never the printed note. On a correction, a PURCHASE line may instead be sent back exactly as it stands on the document; a SELLING line sent back exactly as it stands is read back into its filed form only when its note's price reproduces it (otherwise keep it with { keep: <lineNo> } where offered, or correct the header only); any other line carrying the note follows the rule for a new line — a selling line read back only at its own tons and rate with no discount, a purchase line refused. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed. A BILL THAT RECEIVED GOODS AGAINST A PURCHASE ORDER: you can correct the header, or prices/discounts/SST codes with EVERY line of the whole bill sent back exactly as it is (same products, quantities, order and units — lines not on the order included); any other line change, on any line, is refused at filing and is made by the user on the bill's Edit screen in Taokeh (Purchases → the bill → Edit). A header-only correction (no `lines`) reposts the bill's own lines unchanged."

Previous value: -"Two decimals at most (whole sen, or whole cents in another currency), exactly as invoiced; put a discount or tax in its own field, never folded into the cost."New value: +"Up to four decimals (e.g. 0.0325), exactly as invoiced — but a per-foot or per-piece price that Taokeh converts to tons: two decimals. Put a discount or tax in its own field, never folded into the cost."

Added value: +"Two decimals at most (whole sen, or whole cents in another currency), exactly as invoiced; put a discount or tax in its own field, never folded into the cost."

Previous value: -"The piece tally (dimensional lines)."New value: +"The tally as pieces/length_ft pairs — '10/10 12/14' is 10 pieces of 10 ft and 12 of 14 ft — OR the total running feet like 400' when the paper gives no cut list. Never invent a cut list (no '1/400'). With thickness and width this is what the quantity is derived FROM. Every token must be a pieces/length pair — a tally with anything else in it (a grade word, a stray number, '=') is refused; put grade words in the description. A total-feet tally needs thickness and width (or a named size) to work out the tons, and has no pieces, so it cannot carry a per-piece price — both are refused."

Added value: +"The unit the PRICE is quoted in. On a timber company: 'feet' = per running foot, 'pcs' = per piece, 'ton' or omitted = per ton. A per-foot/per-piece price is converted to the per-ton rate from thickness/width/tally, or from a cut list in the description ('2x2 = 10/10 12/14'); a description cut list the server cannot read cleanly is refused — send thickness/width/tally instead."

Previous value: -"The FULL replacement line set — every line the corrected bill should have, not only the one that was wrong. Same shape as create_bill_draft. Omit it entirely when you are only correcting header fields. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed."New value: +"The FULL replacement line set — every line the corrected bill should have, not only the one that was wrong. Same shape as create_bill_draft. Omit it entirely when you are only correcting header fields. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed. A BILL THAT RECEIVED GOODS AGAINST A PURCHASE ORDER: you can correct the header, or prices/discounts/SST codes with EVERY line of the whole bill sent back exactly as it is (same products, quantities, order and units — lines not on the order included); any other line change, on any line, is refused at filing and is made by the user on the bill's Edit screen in Taokeh (Purchases → the bill → Edit). A header-only correction (no `lines`) reposts the bill's own lines unchanged."

Previous value: -"The SUPPLIER's payment term as it should read, stored as written (do not round a real term to the nearest familiar one). Pass null to clear it. Correcting the term does NOT move the due date; if the due date is wrong too, propose `dueDate` alongside it."New value: +"The SUPPLIER's payment term as it should read, stored as written (do not round a real term to the nearest familiar one). Pass null to clear it. On an ON-ACCOUNT bill, changing to one of the five preset terms re-derives the due date from the bill date (+ 0/7/14/30/60 days), shown to the reviewer before approval; an unrecognised term moves nothing. To change the term but KEEP the current due date, send `dueDate` alongside it — a stated dueDate always wins."