Making the preview and the spreadsheet agree

A retail export can look clean and still land in the wrong week, client, tab or column. My Retail Reporting contributions built and evolved the staging workflow between raw exports and Google Sheets: parsing, grouping, editable review, mapping and commit results.

The useful question is not whether the file uploads. It is whether the operator can explain every intended destination before the write.

From rows to destination cells

The authored change introduced editable parsed rows and batched spreadsheet updates. The authored change connected client-scoped configuration to destinations. The authored change added one-to-many routing, live sheet structure, an aggregated commit preview and saved profiles.

My subsequent work expanded CSV ingestion, description-based grouping, retailer scopes, per-group date offsets and custom source columns. Those are different input contracts. Requiring the same fixed columns for every configuration would reject valid data or create a preview that disagreed with server validation.

Inspect the system diagram

Open full-size SVG →Horizontal version →

Diagram models and exports. Writes to multiple destinations and the staged-run update are not one atomic transaction.

One resolver for several contracts

The authored change introduced a shared resolver used by ingestion, required-field UI, preview and commit preflight. It distinguishes tab templates, grouping-level column maps, legacy mappings and mixed configurations. Each required field retains the source of its requirement.

That provenance explains a blocked import.

A template-driven tab does not need a SKU merely because the original workflow did. A grouping that matches by SKU still introduces a SKU dependency. Non-legacy configurations also retain an implicit date requirement. The resolver checks stale grouping references and reports missing mapped columns instead of silently applying the legacy assumptions.

I can explain the accepted complexity here: supporting old and new workflows creates more configuration states. Sharing the resolver reduces disagreement between those states' UI and server checks. It does not make all configuration valid.

Preflight before external work

The authored change addressed missing grouping ownership and destination configuration. The current route checks those conditions before Google Sheets authentication and writes. It rejects missing or stale grouping references and validates client ownership rather than treating an incoming grouping ID as sufficient authority.

Matching suggestions have another boundary. The inspected SKU resolver combines string similarity and brand affinity into a ranked suggestion. Its score is a heuristic, not a calibrated probability or measured accuracy. Staging and operator review remain part of the system's meaning.

Preflight checks configuration. External writes still need their own failure handling.

A successful write can still be a partial commit

The inspected commit route processes destination tabs, catches per-tab errors and tracks updated cells. If some writes succeed and others fail, the response is partial, with success: false. If Sheets writes succeed but marking the staged run committed fails, the response is also downgraded to partial.

The external cells may already have changed.

That limit is consequential for recovery. An operator needs the destination, error and stage information before retrying. A single successful batch request does not establish atomicity across tabs, spreadsheets and Firestore. The HTTP response can be 200 while the application result is failed or partial; clients must inspect the result fields.

The workflow continued to expose new failure classes

My later contribution history records a nonexistent append method and date/value-parsing repairs in the authored change, payload-size failures addressed by the authored change, and the authored change.

These changes postdate the local source snapshot. Their descriptions support the evolution story, but their exact behavior still needs revision inspection. The reported payload reduction is not presented here as a newly measured benchmark. Formula-detection heuristics also need assessment before making a universal protection claim.

Synthetic review and recovery

I use an invented workbook and destinations for this sequence.

1. A source tab contains Week, Units and Retailer. A template maps units into a destination grouping without SKU matching.
2. The resolver retains date and mapped-field requirements. It does not add the old SKU requirement.
3. A second grouping still uses SKU matching. Its additional requirement is visible, with its configuration source.
4. A stale destination grouping blocks commit before external authentication or mutation.
5. After repair, destination tab A updates while tab B fails. The response reports partial work and the staged run is not represented as cleanly committed.
6. The operator inspects tab A and the failure on B before choosing recovery. The sequence does not assume a universal rollback or safe blind retry.

Results and interview material

My record supports an inspectable data-preparation workflow and concrete consistency and failure fixes. Current operator count, time saved, data-error reduction and the deployed revision remain unverified. Merged code, a staged run and a clean destination are separate evidence claims.