Previous value: -"The FULL replacement line set — every line the corrected invoice should have, not only the one that was wrong. Same shape as create_invoice_draft. Omit it entirely when you are only correcting header fields. ⛔ LINE KEYS ARE STRICT, exactly as on create_invoice_draft: a key this schema does not list is REFUSED BY NAME and NOTHING is filed — the EDIT door and the CREATE door judge a line the same way (memory: erp-draft-lane-shared-rules)."New value: +"The FULL replacement line set — every line the corrected invoice should have, not only the one that was wrong. Same shape as create_invoice_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, exactly as on create_invoice_draft: a key this schema does not list is REFUSED BY NAME and NOTHING is filed — the EDIT door and the CREATE door judge a line the same way (memory: erp-draft-lane-shared-rules)."

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

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 payment term as it should read ('Due on Receipt', 'Net 7', 'Net 14', 'Net 30', 'Net 60', or whatever this business actually agreed — it is stored as written, so do not round a real term to the nearest familiar one). Pass null to clear it. ON A POSTED INVOICE THE TERM IS A PRINTED LABEL AND NOTHING MORE: correcting it does NOT move the due date, because the document has already been out of the building and its due date is what the customer was told. If the due date is wrong too, propose `dueDate` explicitly alongside it."New value: +"The payment term as it should read ('Due on Receipt', 'Net 7', 'Net 14', 'Net 30', 'Net 60', or whatever this business actually agreed — it is stored as written, so do not round a real term to the nearest familiar one). Pass null to clear it. On an ON-ACCOUNT invoice, changing to one of the five preset terms re-derives the due date from the invoice date (invoice date + 0/7/14/30/60 days), and the reviewer sees the new due date before approving; a term Taokeh does not recognise moves nothing. To change the term but KEEP the current due date, send `dueDate` alongside it — a stated dueDate always wins."

Previous value: -"The FULL replacement line set — every line the corrected invoice should have, not only the one that was wrong. Same shape as create_invoice_draft. Omit it entirely when you are only correcting header fields."New value: +"The FULL replacement line set — every line the corrected invoice should have, not only the one that was wrong. Same shape as create_invoice_draft. Omit it entirely when you are only correcting header fields. ⛔ LINE KEYS ARE STRICT, exactly as on create_invoice_draft: a key this schema does not list is REFUSED BY NAME and NOTHING is filed — the EDIT door and the CREATE door judge a line the same way (memory: erp-draft-lane-shared-rules)."

Added value: +false

Added value: +"The line text as PRINTED on the document, when it says more than the product name does — a size, a grade, a job reference, a period covered. It rides onto the posted line and prints on the customer's copy, so send what the paper says rather than a tidier phrasing of your own. Leave it out when the product name already says it. This is TEXT, not a field: Taokeh has no column for a dimension, a grade or a variant, so anything of that kind belongs here."

Added value: +1

Previous value: -"The corrected line quantity. On a measurement-profile workspace OMIT it whenever you give thickness/width/tally, or write the measure detail into the description ('2x2 = 10/10 12/14') — the server derives the authoritative quantity, and a quantity sent alongside a parseable tally is kept as advisory only, never used to compute."New value: +"The corrected line quantity. On a measurement-profile company OMIT it whenever you give thickness/width/tally, or write the measure detail into the description ('2x2 = 10/10 12/14') — the server derives the authoritative quantity, and a quantity sent alongside a parseable tally is kept as advisory only, never used to compute."

Added value: +"The corrected line quantity. On a measurement-profile workspace OMIT it whenever you give thickness/width/tally, or write the measure detail into the description ('2x2 = 10/10 12/14') — the server derives the authoritative quantity, and a quantity sent alongside a parseable tally is kept as advisory only, never used to compute."

Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The due date as it should read, YYYY-MM-DD. Pass null to clear it, and the invoice date becomes the due date. Send this ONLY when the due date itself is what is wrong — if you are only correcting the INVOICE DATE, leave it out and Taokeh moves the due date by the same number of days, which keeps the agreed credit period intact (Net 30 stays 30 days)."
+}

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 100,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The payment term as it should read ('Due on Receipt', 'Net 7', 'Net 14', 'Net 30', 'Net 60', or whatever this business actually agreed — it is stored as written, so do not round a real term to the nearest familiar one). Pass null to clear it. ON A POSTED INVOICE THE TERM IS A PRINTED LABEL AND NOTHING MORE: correcting it does NOT move the due date, because the document has already been out of the building and its due date is what the customer was told. If the due date is wrong too, propose `dueDate` explicitly alongside it."
+}