When a Pack Price Looks Like a Unit Price After Extraction

A selling unit might appear beside the amount, inside the description, in a column heading, or in a note covering several rows. The extraction boundary needs enough context to connect that information to the right item. Reading only the amount column may discard it before the model or validator has a chance to interpret it.

Preserve the relevant source wording rather than saving only a normalised label. If a reviewer sees box, they may still need to establish how many items the box contains. A familiar word is not evidence that every vendor uses the same package size.

For the example, an offer contains amount, currency, sellingUnit, and itemsPerSellingUnit. A pack of ten has a different basis from an individual item, even if both amounts are equal. Keep the product identity separate too: matching a description does not prove two offers refer to interchangeable products.

Field names should make the denominator visible. A generic unitPrice property can be misleading if readers assume it always means one physical item. Prefer an explicit definition in the API contract and display that meaning next to the number wherever a user selects or compares an offer.

Dividing a pack amount by its item count may produce a per-item reference value, but it does not establish that the vendor sells individual items. Minimum order quantities, indivisible packs, and differing product specifications can still make that reference unsuitable for a project's actual purchase quantity.

If the application supports a conversion, retain the original offer and record the conversion basis separately. Define decimal precision and rounding for the derived value. PostgreSQL numeric provides exact decimal storage within its declared limits, but choosing a numeric type cannot supply a missing pack count or decide a purchasing rule.

Before sorting two offers by amount, check the dimensions that make the comparison meaningful: product identity, currency, selling basis, and the pricing conditions the application supports. A mismatch should produce a visible explanation. For this exercise, offers with different selling units remain unranked until a user selects a documented comparison basis.

Avoid a coloured cheapest badge that quietly assumes conversion rules. A useful interface can show 900.00 per pack of ten next to 900.00 per item and explain why direct comparison is unavailable. That gives the reviewer enough context to investigate instead of presenting a confident but incomplete answer.

A project asking for four packs is different from one asking for four individual connectors. Store and display the quantity's basis along with the chosen offer. If a user changes the unit, make any conversion or rounding behaviour explicit before updating the selection.

The accepted offer should remain inspectable from that project row. A reviewer can then follow the selected quantity back to the vendor's wording. This becomes particularly useful after a supplier publishes a new sheet with the same product code but a different pack size.

Build fixtures with a known pack size, a missing pack size, a unit mentioned only in the heading, and the same amount offered in two currencies. Check that unsupported comparisons remain unresolved and that a reviewer can still find the original unit evidence after editing a description.

This adds some visible complexity to the record and the interface. The benefit is that the complexity belongs to the actual source rather than an accidental implementation detail. A dependable pricing workflow keeps enough meaning attached to the amount for the next person to understand what is being selected.