Data audit · 4 August 2026
Before You Add a North India Inventory Node: Audit These Order Data Fields
A new stock node is a data decision before it is a property decision. First check whether your order history is clean enough to show where orders went, what buyers ordered, what happened to each shipment, and which facts are still missing.
Start with the question
Define the decision your data must support
A Bengaluru, Mumbai, or Chennai brand may see many orders heading north and start looking for warehouse space. That move is too early if the order export cannot support a fair review. The first question is not “Which warehouse should we use?” It is “Can our records show demand, stock needs, shipment outcomes, and cost inputs without double counting or guesswork?”
Write down what your team means by North India before grouping a single row. You may use selected states, postcode groups, markets, or another business rule. Record that rule and its date. This is your demand grouping, not a provider coverage map. The same data may later support a wider North India inventory-node review, but this audit does not replace that decision.
A useful audit can end with “not ready.” That answer protects the next model from false detail. If postcodes are missing, dates use mixed meanings, or shipment costs repeat across rows, a precise chart can still be wrong. Repair the source and document the rule before comparing a current network with a possible new one.
Record level
Lock the data grain before you compare places
An order, a shipment, and an order line are not the same record. An order is the buyer transaction. A shipment is one parcel or dispatch under one shipment_id or tracking record. An order line is one SKU on the order. A multi-SKU order may create one shipment, while a split order may create two or more shipments with different dates, costs, and outcomes.
Use one row per shipment for the main audit table. Shipment facts include origin, destination, dispatch, delivery, RTO event, parcel weight, freight, and final outcome. Keep a linked order line table for SKU and quantity. Join the two tables with order_id and shipment_id. If the source cannot show which lines entered which parcel, record that gap instead of allocating units by assumption.
This grain stops common errors. An order-level freight total should not be copied onto every shipment row. A delivered first parcel does not make the second parcel delivered. A cancelled line should not become an RTO shipment. Store stable keys as text so leading zeroes and long tracking values survive spreadsheet imports.
Privacy first
Remove buyer details that the audit does not need
Make a working copy before sharing the export. Remove names, full addresses, phone numbers, email addresses, and free-text notes. These fields are not needed to check demand by postcode, SKU mix, shipment timing, payment type, or outcome coding. Keep the protected source inside the brand's approved system and follow its access and retention rules.
Use a pseudonymous order_id, shipment_id, and source row key so the team can trace a problem without exposing the buyer. Do not hash weak identifiers such as a phone number and assume that makes the file safe. The shared audit should contain only the minimum fields needed for the review. If a row cannot be traced after PII is removed, create a stable internal key before analysis.
Field dictionary
Audit the raw fields before you calculate anything
Map each source column to one clear field name. Preserve the source value and add a cleaned value beside it when needed. A clean field has a stated type, meaning, allowed states, null rule, and owner. Do not fill a blank with zero unless zero is the recorded fact. Use unknown when the source cannot answer.
The table below is a core audit view, not TheSameDay.Club's required onboarding schema. Your systems may use different names. Use the blank CSV for all 48 raw canonical headers and the dictionary CSV for all 48 raw plus 21 derived fields. Keep your source names in a separate mapping tab.
| Canonical field | Level | What it should mean | Audit check |
|---|---|---|---|
source_system | Shipment | System or file that supplied the record | Present and named consistently |
source_file | Shipment | Report or export name | Kept for traceability |
source_row_id | Shipment | Stable source row reference | Does not change after sorting |
order_id | Order | Stable buyer-order key stored as text | Required and not reused |
shipment_id | Shipment | Stable key for one parcel or dispatch | Required when dispatch occurred |
tracking_id | Shipment | Recorded carrier or airway-bill key | Stored as text; blank before booking only |
order_created_at | Order | Time the source accepted the order | Time zone and meaning are stated |
promised_date_raw | Order | Promise recorded in the source | Not replaced by a later estimate |
dispatched_at | Shipment | Defined dispatch or handoff event | Event meaning is written down |
delivered_at | Shipment | Recorded completed-delivery event | Matches a delivered outcome |
destination_postcode | Shipment | Delivery postcode stored as text | Valid shape; leading zeroes preserved |
origin_postcode | Shipment | Actual dispatch origin for the parcel | Not inferred from company address |
sku_id | Order line | Stable sellable SKU key | Aliases are mapped, not silently merged |
quantity_ordered | Order line | Units ordered for that SKU | Positive integer with a known meaning |
dead_weight_kg | Shipment | Measured physical parcel weight | Unit is explicit; blank is not zero |
billed_weight_kg | Shipment | Weight used on the carrier invoice | Kept separate from dead weight |
payment_mode_raw | Order | Payment label exactly as recorded | Map a copy to a documented set |
shipment_status_raw | Shipment | Original status label | Preserved beside the normalised status |
cancelled_at | Order/shipment | Time cancellation was recorded | Not grouped with RTO |
rto_initiated_at | Shipment | Time the RTO process began | Separate from customer return |
customer_return_requested_at | Return | Time a post-delivery return was requested | Separate from RTO |
Date and status checks
Test whether the event trail can be trusted
Dates need definitions, not only valid formatting. An order date is not a warehouse release date. A label-created time is not always dispatch. A first attempt is not delivery. Write down the event behind each timestamp and its time zone. Then flag impossible or conflicting sequences instead of moving them into a clean table.
Build an exception register with the source row, issue, owner, repair action, and status. Flag dates that appear in the wrong order. Examples include a promise before order_created_at or delivery before dispatch. Also flag a delivered status with no delivery event and an RTO date on a cancelled order. Keep unresolved rows outside the main comparison, but keep them for repair and count checks.
Status labels also need one shared map. Keep delivered, cancelled before dispatch, and RTO apart. A customer return after delivery is also a separate result. Use unresolved when the final result is not known. Unknown source labels stay unknown until an owner confirms them. This article checks whether RTO is encoded consistently; the RTO operations guide owns diagnosis, causes, and changes to test.
Product and parcel checks
Make stock and parcel facts repeatable
SKU names often drift across storefronts, marketplaces, kits, and old catalogues. Create an alias table that keeps the source label, canonical SKU, effective period, and owner. Do not merge variants because their names look alike. The audit should show which rows cannot be matched to a product key and which quantities lack a clear unit.
Keep product demand apart from parcel facts. SKU and quantity belong in the order line table. Weight, dimensions, dispatch origin, and freight belong to the shipment. If several lines share one parcel, link them through shipment_id. If one line splits across parcels, record the allocated units only when the source provides or supports that allocation.
Observed facts
Build the next review from history, not promises
Once the raw checks pass, the clean file can show facts from the period. These may include destinations, SKU units, split shipments, payment mix, and order results. It can also show which cost fields are ready for later work. Label the date range. Note any event that made the period unusual, such as a launch, sale, stockout, or channel change.
A model may then compare scenarios, but a model is not a service promise. Historical postcodes do not prove future coverage. A shorter map distance does not prove a delivery window. An observed freight cost does not prove a new rate. Use current carrier, warehouse, tax, and operating inputs from the relevant parties before a commercial decision. The same-day serviceability guide explains why an order promise needs current order-level checks.
Stop rules
Pause when the data cannot support the next question
Do not invent one data quality score for every brand. Each brand should set and record its own pass rule. Pause if split parcels exist but shipment_id is missing. Pause if destination_postcode cannot support the chosen group. Stop if RTO cannot be split from a customer return. Also stop when dates have unclear meanings or freight cannot be tied to the right parcel.
Other stop signs include two final results for one parcel and order keys that are reused. Check any zero or negative quantity unless the source explains it. Mixed weight units also need repair. Stop when SKU labels cannot show which stock would move. A major campaign or stockout should be marked before the period is treated as normal. Repair work is part of the decision, not an obstacle to hide.
Summarise the audit as ready, partly ready, or needs repair. List the fields that passed, the fields still open, and the owner for each repair. That conclusion is deliberately narrow. It does not decide whether a North India node is right, how much stock should move, which provider to choose, or what result a new network will produce.
Review pack
Take a traceable pack into the node discussion
Bring the clean shipment table and the linked order line table. Add the field map, result-code map, data check log, and exception register. State the rule used to define North India. Name the source and date of any postcode map, and list open assumptions. Keep the protected source export outside the shared pack.
For the next step, gather current proof for each key part. This includes area checks, work rules, rate inputs, stock facts, and written roles. Those inputs are outside this data audit. Use the core fulfillment service review when you are ready to test fit, stock planning, scope, and dependencies. Return to the D2C fulfillment blog for the supporting guides.
Limits
What this audit can and cannot show
This guide can help you see if the past records are fit for more analysis. It cannot confirm a site, postcode area, cut-off, delivery time, or capacity. It cannot confirm an integration, price, tax view, service level, saving, or RTO change. Those claims need current proof and written scope.
The worksheet is also not a required TheSameDay.Club schema. Your order, warehouse, marketplace, and carrier systems may hold different fields. Keep the structure that preserves your facts and traceability. The goal is not to force every export into one template. The goal is to stop weak data from turning into a confident network decision.
Check whether your export is ready for a node review
Bring an anonymised shipment export and the linked order-line file. Add the source-column map, postcode group rule, status meanings, and exception list. Do not include buyer names or full addresses. Leave out phone numbers, email addresses, and free-text notes.
Review the data pack