Skip to content

Pricing Bug Analysis & Proposed Fix

Users have reported a critical bug where the final price for an order item is sometimes incorrect, often appearing as zero. This happens even when the item seems to be correctly identified and validated. The issue is most prevalent in orders processed automatically from PDFs, leading to inaccurate quotes and requiring manual correction, which undermines the efficiency of the system.

The investigation traced the journey of an item’s price from initial PDF upload to final order approval, identifying how and when the unitPrice is determined.

The process begins with the pdf_processor_service using the Google Gemini model for data extraction.

  • Price Origin: The unit_price is extracted directly from the PDF content by Gemini.
  • Normalization & Defaulting: The Python backend normalizes this value by stripping currency symbols and commas. Crucially, if the price is missing or invalid in the PDF, it defaults to 0.0. This zero-price is then saved to the database and is a primary source of the bug.

When a user reviews an extracted order, the data is managed by pdfOrderStore. The unitPrice can be changed in several ways, with a clear order of precedence:

  1. Highest Precedence: Manual User Edit: A user can directly edit the unitPrice in the UI. This action provides the definitive price before submission.
  2. Second Precedence: Manual ERP Item Selection: When a user manually searches for an item (searchItem) and selects a result from the ERP, the unitPrice from that ERP search result overwrites the price extracted from the PDF.
  3. Lowest Precedence: Initial PDF Extraction: The baseline price is the value extracted by the PDF processor, which could be the incorrect 0.0 default.

The key finding is that the attemptAutoValidateItems function, while it successfully matches items and updates their erpItemId and itemName, does not update the unitPrice. It leaves the original, potentially zero, price from the PDF extraction in place.

The final price submitted to the ERP is whatever value is currently in the pdfOrderStore, reflecting the precedence rules above. If an item is auto-validated but never manually validated or edited, the incorrect zero-price from the initial extraction is sent to the ERP.

This diagram visualizes the flow and identifies the points where the price can change.

sequenceDiagram
participant User
participant PDFUpload.tsx
participant pdf_processor_service
participant Database
participant pdfOrderStore.ts
participant ERP_API
User->>+PDFUpload.tsx: Uploads PDF
PDFUpload.tsx->>+pdf_processor_service: Triggers processing task
pdf_processor_service->>pdf_processor_service: Extracts text with Gemini AI
Note over pdf_processor_service: Normalizes price: <br/>- Strips '$', ','<br/>- Converts to float<br/>- **Defaults to 0.0 on failure**
pdf_processor_service->>+Database: Stores extracted items<br/>(unit_price as decimal)
Database-->>-pdf_processor_service: Stored
pdf_processor_service-->>-PDFUpload.tsx: Processing complete
User->>pdfOrderStore.ts: Navigates to review page
pdfOrderStore.ts->>Database: Fetches extracted order data
Database->>pdfOrderStore.ts: Returns order data
Note right of pdfOrderStore.ts: Initial `unitPrice` is from PDF extraction.
alt Manual Item Validation
User->>pdfOrderStore.ts: Searches for an item
pdfOrderStore.ts->>+ERP_API: /api/erp/parts
ERP_API-->>-pdfOrderStore.ts: Returns search results with price
User->>pdfOrderStore.ts: Selects an ERP item
Note right of pdfOrderStore.ts: **PRECEDENCE 2:**<br/>`unitPrice` is overwritten by the price from ERP item search result.
end
alt Manual Price Edit
User->>pdfOrderStore.ts: Edits price field in UI
Note right of pdfOrderStore.ts: **PRECEDENCE 1 (HIGHEST):**<br/>`unitPrice` is overwritten by user's direct input.
end
User->>pdfOrderStore.ts: Clicks "Generate" or "Approve"
pdfOrderStore.ts->>+ERP_API: Submits final order data
Note right of pdfOrderStore.ts: Final `unitPrice` (from PDF, ERP search, or manual edit) is sent.
ERP_API-->>-pdfOrderStore.ts: Returns success/failure