Combining Branch Spreadsheets Without Mixing Their Records

Imagine a multi-branch furniture retailer handling this situation. Two branches use order number 128 in separate files.

The consolidated workbook merges them as though they were the same purchase. This fictional situation could begin with a perfectly sensible shortcut. The difficulty emerges when more people rely on the result, because an informal understanding is no longer enough to support the next decision. It helps to examine what the next person needs, rather than simply adding another notification.

Local references are unique only within a branch. Consolidation assumes a wider uniqueness rule than the source systems provide.

The source branch is part of a reference's meaning when numbering starts independently at each location. Losing that context makes an apparently clean merge unreliable.

The combined reference should be generated consistently wherever data is consolidated. Staff can still see their familiar local order number, but cross-branch operations need the broader identity. Reimporting the same branch file should not create another set of records under a slightly different label. The practical consequence is uncertainty at the handover. One employee must stop and investigate, while another may already be acting on an assumption. Repeating the information in another message can help for the moment without fixing the reason the uncertainty arose.

Use a combined branch-and-order reference and retain the original source filename or export reference. Validate branch identity before adding rows to the central view.

Check whether built-in import settings or a clearer workbook structure solve the problem before commissioning code. Define what each relevant column means before deciding how it should be read or written. An identifier, a measured quantity and a displayed value may look similar while requiring different treatment. The output should be checked in the receiving application, not only in the spreadsheet used to prepare it. If an automated step changes existing information, preview the proposed changes and retain a correction route. Keep the original file unchanged while testing the import or calculation on a controlled copy. Unexpected values should produce a usable review item rather than a plausible-looking guess.

Combining records should not automatically give every branch access to all customer-level information.

For background relevant to branch record references, see What Happens When Two Systems Disagree. The issue here is the narrower workflow described in this example.

Import matching local order numbers from two branches and a repeated file from one branch. Try the proposed change on a limited set of suitable records first. Write down the expected outcome before running it, then inspect the result with the relevant staff. Include the correction path so a mistake does not become a second unsupported workaround.

For branch record references, review the proposed outcome with the staff responsible. Compare the original values, stored values and receiving-system output for the chosen sample. Counts alone will not reveal every interpretation error. Keep rejected rows visible with an explanation so the administrator can correct the cause rather than guessing at a replacement. Keep a short note of the rule, its owner and the recovery route. That makes the improvement easier to operate when the person who set it up is unavailable.

At Software Logic, we explore how spreadsheet processes can support everyday work, including the decisions that should remain with the people responsible. Which identifiers stop being unique when you bring your branches together?