Bulk Copy

Background

Price or facility changes often required recreating several contracts with only a few fields changed. But bulk registration supported new contracts only. Re-contracts had to be registered as new, then corrected one by one through developer requests.

Retrieving existing contract data required help from PO and onboarding. Collection manuals, notes, and tags had to be copied by hand, while the Allbaro disposal plan was not copied at all and could be missed. Even a small change meant repeating data preparation, registration, correction requests, and review.

Copy, not bulk edit

The recurring need was to create re-contracts without losing existing information, rather than edit many contracts in place.

I compared bulk editing with copy-based re-contracting against recurring onboarding requests. Most requests changed a few fields while creating a successor contract. That made eliminating data re-entry and post-registration developer requests the priority.

I checked settlement and contract-operation requirements with accounting and CX, then agreed with designers and developers on Excel-based batch processing and how to show failed items. In QA, I verified that each contract’s changes and transfer options were applied as intended.

I limited the scope to disposal contracts. Selecting a source copies contract data, collection manuals, notes, and tags. Volume transfers and schedule reassignment use the rules from the re-contract redesign. I planned which fields could change, when transfers were allowed, how to handle individual failures, and how operators would review the results.

Not every field should be edited only in bulk. Many contracts share a re-contract start date, while each may have a different price. I combined bulk changes to common values with per-contract adjustments, reducing repeated entry without discarding individual terms.

Separate copying from transfer eligibility

Being able to copy a contract does not mean its volume and schedules can safely transfer. I defined separate eligibility checks based on what changed.

Changing a name or signing date has a different effect from changing waste type or the discharger’s registration information. A change to waste or registration details requires checking whether existing collection records and Allbaro handover information still apply. Even when a field is editable, separate checks determine whether recorded work and dispatch can transfer automatically.

Adding a processor preserves existing work’s processing route, while replacing or removing one can leave the actual facility absent from the new contract. I allowed additions that retain the existing processors. Switching between bag delivery and other plans is also excluded because it changes the work and billing model.

This table defines volume/schedule transfer validation, not which fields the screen allows users to edit. Processors may only be added to the existing set; switching between bag-delivery and other plans excludes automatic transfer.

Automation options

Preparing a contract in advance does not mean its work and schedules should move immediately. Operators choose each transfer option when copying.

Creating a contract and moving unbilled work or future dispatch do not always happen at the same point. Operators can prepare the contract and choose transfers to fit the operational situation. Only one child may receive automatic transfers from a source, preventing several contracts from competing for the same work and schedules.

The Allbaro disposal plan was easy to miss when only contract fields were copied. A new contract without its plan may not support the subsequent handover-document workflow. Copying the plan is therefore mandatory to attempt, with failures reported separately from contract creation.

Volume/schedule auto-transfer applies to only one child per source, preventing the same work and schedules from being linked to multiple contracts.

One failure does not stop the remaining contracts

I separated per-contract results so one failure would not require restarting the whole batch, and distinguished contract creation from document-copy success.

Rolling back the whole batch for one error would force operators to register and review valid contracts again. Each contract runs in its own transaction so a failure does not affect the others. Contract creation and document copying report separately, and a document-copy failure leaves the created contract intact.

Operators can see progress during execution and total, success, and failure counts afterward. The Excel result lists the source and new contracts, failure reasons, changed schedules, and transferred work. They can check which contracts were created and where the work and schedules moved.

I also separated transfers skipped because the conditions were not met from transfers attempted but failed. Operators need to know whether to review the contract’s changes or investigate a processing error.

Reduced data re-entry and correction requests

Operators can select an existing contract, edit only what needs to change, and create a re-contract with its collection manuals, notes, and tags. This reduced repeated data entry and post-registration requests for developer corrections.

Eligible work and schedules also move to the new contract, with per-contract results and failure reasons available in Excel. The reduction in manual support was measured together with the re-contract process redesign, which shipped alongside this work.