Editing a quantity or delivery address after sending a request does not finish the work. The supplier may still be acting on the earlier contents. This project's requests ask for visible changes, retained originals and prepared change messages. Before choosing a highlight color, I would establish how versions from different moments are preserved. Staff need a clear next action, and the owner needs a readable account afterward. Both should refer to the same history.
Today's document is not automatically yesterday's original
If the system lacks evidence of what was sent, it cannot assume the current document is that earlier version. Values may have changed. Preserved acceptance notes describe an explicit review boundary for legacy documents without a retained sending baseline. Introducing a new feature should not manufacture evidence for past communication. The absence of a verified original is information worth retaining, rather than a gap to fill with a convenient current copy.
A new retained version joins document identity, revision and contents while remaining separate from later editing. Updating a partner's details should not silently change an earlier document's recipient or destination. Image preservation also needs a relationship to the document version that produced it. An isolated image without its context can be the wrong artifact when somebody later tries to compare what was requested and what changed.
Highlighting identifies a difference, not approval
Comparing retained and current contents can reveal changed items, quantities, addresses or requested dates. Different formatting and different business values are not necessarily the same kind of change. A highlight points to a review location; it does not establish permission to apply the edit. Reducing quantity after dispatch or receipt exists can conflict with physical history, even if the new field value is syntactically valid.
The design therefore needs reasons, downstream-state checks and conditions that block the edit. Rewriting an earlier version to erase a difference, or silently removing a recorded receipt, would conceal the event being investigated. Preserve why the difference arose and what correction or new request follows. An owner reviewing a problem needs that decision and follow-up, rather than a colored number without an explanation of what somebody did about it.
Preparing a change message is not sending it
Generating explanatory text can save staff from retyping the same change. Copying that text or downloading an image remains distinct from actual transmission. The supplier has not necessarily received the revision merely because the clipboard was prepared. The original request and the later change can also have different sending times. Their records need enough separation to establish which version a communication refers to.
The preserved implementation distinguishes prepared changes from acknowledgment that they were sent. In a consuming business system, define the version, time, channel and person associated with that acknowledgment. If there is no external receipt confirmation, do not expand it into a claim that the supplier has read the message. Keep the source of each fact clear: what the application performed and what a person reported are related but different evidence.
Connected documents need different update boundaries
A company-specific application becomes convenient when one entry prepares related documents. That convenience also makes it necessary to define which records can still be updated automatically. A working draft and an outward version already sent should not share an unconditional replacement rule. Preserve their relationship while moving records with downstream history into an explicit correction path. More connections require clearer boundaries, rather than broader assumptions about what can be overwritten.
Use synthetic cases for editing before sending, changing an address afterward, changing quantities after partial dispatch and a legacy record without a retained original. Check preservation of both current and earlier contents, including repeated requests that should not duplicate a version. This article reviews selected change and image-preservation code and dated records. I did not send a real change request or inspect excluded source images. Software that is easy to change should also explain what changed and what must remain as it was at the time.