Negative prices on a quote nobody typed wrong
A quote printed with large negative prices on several lines. The prices on the record were correct. Adding a line in the UI didn’t fix it. The difference was how the quote had been created — through the API, by an AI assistant — and a script that never ran for it.
The symptom
A sales rep reported a quote whose PDF showed large negative prices on several lines. The record itself looked right: rates, amounts and totals all correct. The first theory — a discount percentage stored as 25 instead of 0.25 — was wrong; the raw values matched other quotes that printed fine. The rep had used an AI assistant to book the quote through the ERP’s REST API.
The smoking gun
Comparing the quote’s raw XML with a quote that printed correctly found one difference that mattered: a custom body flag, set to true on the good quote and false on the bad one. The PDF template branched on it:
<#if record.custbody_example_new_pricing == true>
... current price/discount logic ...
<#else>
... legacy logic from an older pricing model ...
</#if>The legacy branch read the discount field under an old assumption and produced the negative numbers.
Who sets the flag
System notes showed the flag being set on other quotes, but the author recorded was a generic integration or script actor, not the script itself. Reading the user event scripts deployed on quotes found the owner: a discount-pricing script that set the flag — but only in certain execution contexts:
const ctx = runtime.executionContext;
if (ctx !== runtime.ContextType.USER_INTERFACE &&
ctx !== runtime.ContextType.WEBSERVICES) {
return; // REST never reaches the logic below
}
applyDiscountMatrix(rec);
rec.setValue({ fieldId: 'custbody_example_new_pricing', value: true });When it was written, every quote came through the UI or a SOAP integration. REST records — and now AI-booked records — were never considered. So they skipped both the pricing logic and the flag, and the template did the rest.
The fix, in three layers
- Correct the record. Set the flag on the affected quote and confirm totals didn’t change.
- Remove the trap. The legacy template branch existed only for documents from a pricing model long since retired. Removing it from the quote and sales order templates means documents print correctly regardless of the flag.
- Close the gap. Decide deliberately which contexts the pricing logic should run in. A record’s pricing shouldn’t depend on whether a person or an API created it.
Why this matters more now
AI assistants that create records through an API are useful — we build them. But they enter through a door that a lot of older customization never expected anyone to use. Before letting any new channel create transactions, list what runs on that record type, check which contexts each script honours, and test a document printed from an API-created record against one created by hand.
Related: booking customer POs with AI, and why that column prints blank on your PDF.