A price that survives the spreadsheet import

A catalogue import can report success while changing the meaning of every amount. The file opens, the expected rows appear and the website displays numbers with tidy punctuation. That is weak evidence if the importer read only part of the supplier's price string.

For an Argentine business exchanging spreadsheets with a remote development team, the useful agreement is more precise than “support local formats.” It states how a particular file separates columns, represents amounts, identifies currency and preserves codes. The same care belongs in a form that accepts prices or an integration that sends an approved amount to another system.

Follow one amount from source to screen

Consider a fictional supplier's semicolon-delimited catalogue. Its agreed format uses a comma for the decimal separator and a dot for thousands grouping. One row contains product code 000847, currency ARS and amount 2.450,75. The supplier confirms that this means 2,450 pesos and 75 centavos in the example, not 2.45 pesos. These are demonstration values, not current market prices.

The importer correctly separates the columns but passes the amount directly to JavaScript's parseFloat. That produces 2.45: parsing accepts the initial decimal-looking portion and stops at the comma. The result is a number, so a check that merely rejects non-numeric output does not catch the problem.

This behaviour is documented in the ECMAScript specification for parseFloat. It is a general parsing function, not an interpreter of the supplier's agreed number format. Formatting its result for an Argentine reader afterward cannot restore the digits that were discarded.

Separate the file rules from the amount rules

First inspect the original file as text. A spreadsheet application may automatically interpret values when opening it, concealing whether a change occurred in the source, during spreadsheet display or in the website importer. Keep the original sample intact and record the specific row and field under investigation.

In this example, the columns are separated by semicolons. The decimal comma belongs inside the amount field; it is not another column boundary. The import specification also defines character encoding, header names, quoting and what happens when a description contains a semicolon. Use a parser that follows those rules rather than splitting each line wherever a separator appears. Python's CSV documentation illustrates how a reader can use an explicit delimiter and quoting configuration; the same requirement applies when a different implementation is chosen.

After extracting a complete field, validate its entire contents against the approved amount format. Here the supplier and business agree to require two decimal places, permit correctly grouped thousands or an ungrouped integer part, and reject negative catalogue prices. These are rules for this feed, not universal Argentine formatting rules. A separate credit-note workflow would need its own approved treatment of negative values.

Make uncertain input visible

The corrected importer accepts 2.450,75 and produces the exact decimal value 2450.75 for internal use. It also accepts 180,50 as 180.50. It rejects 2,450.75, because that notation belongs to a different input convention, and rejects 2.45,75, because the grouping is malformed under the agreed format.

Removing every punctuation mark is not a repair. Nor is guessing a convention from whichever separator appears last. Such shortcuts can silently turn a wrong input into a plausible amount. If another supplier legitimately uses a different format, give that feed an explicit configuration and its own sample checks.

A rejected row should identify the product code, original amount and reason in a reviewable import report. For example: “Product 000847: amount does not match the selected supplier format; expected a decimal comma and two decimal places.” Keep sensitive or commercially restricted files within the agreed review channel. A staff member should be able to correct the source or select the appropriate documented feed configuration without manually reconstructing every row.

Blank fields require an equally clear decision. In this example, blank means the price is unavailable and the row cannot replace a live price. It does not mean zero. The import should preserve that distinction rather than accidentally advertising a free product.

Check the meaning of the neighbouring fields

The code 000847 is an identifier. Converting it to the number 847 changes the value used to match the supplier's product. Preserve it as text through import, review and export. A correctly parsed price attached to the wrong catalogue item is still a failed import.

Currency also needs its own field. A bare dollar sign does not provide the explicit currency identity this workflow requires. Keep ARS with the example amount and reject or separately route a row carrying a currency the feed is not configured to handle. This check is not an exchange-rate conversion.

Before extending the import into a checkout or quotation, the business must also establish what each amount represents: unit price, pack price, tax treatment and any applicable commercial conditions. Those decisions come from the business and its relevant advisers. The parser can preserve an approved amount accurately; it cannot decide whether that amount is the right selling price.

Rehearse a correction without replacing the whole catalogue

Use a small, isolated import containing the original failing row, a valid ungrouped amount, a malformed amount and a blank. Add a product whose existing price is already correct. Preview the proposed changes before any authorised live import.

The corrected result for 000847 is 2450.75, with the leading zeros and ARS preserved. The 180,50 control remains 180.50; malformed and blank inputs appear as exceptions rather than new prices. For those two accepted rows alone, a reconciliation total is 2631.25. A matching total is useful supporting evidence, but each product-to-price relationship still needs checking.

For money calculations, choose an exact decimal representation and an explicit rounding policy suited to the downstream system. Do not assume a display rounded to two places proves every internal calculation is correct. If a payment provider or accounting system is later connected, verify its current amount and currency contract separately before sending anything to it.

In the fictional investigation, the repair changes the supplier-specific parsing step and its error report. It does not change the underlying approved prices, infer missing amounts or reinterpret unrelated suppliers' files. The retained sample becomes a practical check whenever the export format or import code changes.

Define the first deliverable around a real file

A useful brief contains an anonymised source row, the expected amount and the wrong result, together with the export application's settings if known. Faith Forge Labs can inspect the boundary between file, form and receiving system, then build a limited import preview with understandable exceptions.

Discuss an integration or an online sales workflow. The first milestone can be small: one documented feed whose accepted values retain their meaning and whose uncertain rows remain visible for review.