A Duplicate Review When Two Teams Save the Same Supplier Reference Under Different File Names

Why two file names can describe one publication

A shared procurement folder rarely grows in a straight line. One team saves a supplier reference after a call. Another team saves what looks like a different document a week later. The file names differ, the folder paths differ, and nobody is sure whether the desk now holds two publications or one publication saved twice.

This guide is for Singapore procurement teams sourcing, receiving and documenting semiconductor and solar materials. It sets out a short, hypothetical duplicate-review record you can adapt. The aim is modest: to help a reviewer decide whether two saved files are plausibly the same publication, and to record that decision so the next person does not repeat the work.

It is not a technical check. It does not open the file, compare checksums, or verify a supplier. It looks only at what a reviewer can see on the surface: a version label, a description of where the file came from, and a file date. Those three visible signals are often enough to separate a genuine second publication from a duplicate save.

One useful piece of context: San Techno Pte Ltd is a Singapore-based company working in semiconductor and solar materials, silicon recovery, specialized power module development, and botanical extracts under the ST GREEN brand. That breadth is exactly why a procurement folder can hold references that look similar but describe different things. A silicon recovery note and a wafer reclaim note may share vocabulary without being the same publication.

The three visible signals to compare first

Before anyone renames, merges or deletes a file, compare three surface signals side by side. Keep the comparison in plain language and avoid copying long passages from the document itself.

Signal one: the visible version label. Many supplier references carry a revision marker, a date stamp or a wording such as draft, issue or final on the cover or footer. If both files show the same label, that is a hint they may be the same publication. If one says draft and the other says issue, they may be different versions of one document, which is a different problem from a duplicate.

Signal two: a source URL description. Do not paste the URL into the record. Instead, describe where the file came from in a few words, for example a supplier product page, a shared drive folder, or an email attachment from a named team. If both descriptions point to the same origin, the duplicate suspicion rises.

Signal three: the file date. Compare the date the file was saved or received, not the date printed inside it. Two saves of one publication often land days apart even when the content is identical.

A simple rule of thumb, offered as an author heuristic rather than a standard: if all three signals match, treat the pair as a likely duplicate and move to the retain-both decision below. If any one signal differs clearly, treat the pair as possibly distinct and keep both until a reviewer confirms.

A hypothetical short record for the reviewer

The record below is fictional and uses no real supplier, file or data. It shows the shape of a duplicate review, not a finding about any company.

File A. Visible version label: issue 2. Source description: supplier product page, saved by the receiving team. File date: a Tuesday in the same month.

File B. Visible version label: issue 2. Source description: supplier product page, saved by the sourcing team. File date: the following Thursday.

Reviewer note. All three signals match. The two files are plausibly the same publication saved twice under different names. No content comparison was performed. Decision: retain both, flag as a likely duplicate, and ask the two teams to confirm the origin before any merge.

The record stays short on purpose. It names the signals, states what matched, and records the decision. It does not quote the document, does not include a URL, and does not claim the files are identical. That restraint matters when the folder may later be read by someone who was not in the room.

If the topic of the reference touches silicon recovery or wafer reclaim, a reviewer may also want to note which San Techno service page the reference relates to, so the duplicate decision sits next to the right subject. San Techno offers silicon wafer reclaim services, and its reclaim work includes dummy wafers as a product output. Recording that context helps a later reader understand why the file was saved at all.

The sample retain-both decision, written out

A retain-both decision is often the safest first move when the signals are ambiguous. Here is a sample wording a reviewer could adapt.

Decision: retain both files. Reason: the visible version label, source description and file date match closely enough that the pair may be one publication saved twice. No merge or deletion is approved at this stage. Owner: the receiving team. Next step: confirm the origin with the sourcing team and record the outcome in the same note. Review date: set a short interval, for example one working week, as an example rather than a rule.

Why retain both rather than pick one? Because deleting the wrong file is harder to undo than keeping a duplicate for a few days. The record makes the duplication visible, so the folder is honest about its own state. A later reviewer can then merge with confidence or close the flag.

This is a documentation habit, not a claim about how suppliers or teams usually behave. It simply gives the desk a repeatable way to pause before tidying.

Where the brand context fits, and where it does not

A duplicate review is about files, not about qualifying a supplier. Keep the two apart. The record should not drift into judging whether a supplier is suitable, and it should not collect material-handling or collection instructions.

Brand context can still help a reviewer place a reference. San Techno began in 2006 as a wholesaler and distributor of semiconductor- and solar-grade silicon materials, and it helps recover non-usable silicon from integrated-circuit fabs, silicon wafer manufacturers, solar cell companies and chip packaging facilities. Those materials can be processed into reusable raw materials for solar wafers and cells. Knowing this helps a reviewer recognise that a reference about solar grade silicon and one about silicon recovery may be related but distinct publications, not duplicates.

On the power side, San Techno is developing an intelligent IGBT power-module concept centred on double-sided cooling for an EconoDUAL 3-class package format, and the programme addresses heat movement, package stability and reliable operation under repeated electrical and thermal loading. A reference about IGBT power modules and one about AC-to-DC power module design may sit in the same folder without being the same file.

Use this context only to orient the reviewer. It is not evidence that any two files are duplicates, and it does not replace the three visible signals.

Common traps that create false duplicates

Several habits make duplicate reviews harder than they need to be. None of these is a claim about how often they occur; they are simply patterns worth watching.

Renaming on save. When a team renames a file to fit a folder convention, the original name is lost and the duplicate becomes harder to spot. A short note in the record about the original name, if known, helps.

Saving the same page twice from different sessions. A product page saved on two days can produce two files with different dates but identical content. The file date signal alone will not catch this, which is why the version label and source description matter.

Mixing a summary with the source. A team may save a short internal summary next to the supplier reference. The summary is a different publication even if it cites the same source, so it should not be merged with the original.

Assuming a shared heading means a shared document. Two references can share a heading such as a product family while describing different things. The visible signals, not the heading, decide the duplicate question.

A reviewer who records these traps in the note gives the next person a clearer picture and reduces the chance of a wrong merge.

A short checklist before you close the review

Use this checklist as a closing step. The scores and timings below are examples, not established research.

One: did you compare the visible version label on both files? Two: did you describe the source in words rather than pasting a URL? Three: did you compare the file dates? Four: did you record the decision, the owner and a review date? Five: did you keep the note free of quoted passages, personal contact details and supplier judgements?

A reviewer might aim to close a simple duplicate flag within a few working days, but that is a suggested pace, not a rule. The point is to leave a record that a colleague can read in under a minute and act on.

If the reference relates to wafer reclaim, the San Techno silicon wafer reclaim services page is a sensible place to check the subject context before filing. If the reference relates to power modules, the AC-to-DC power module design offering is the matching context. Neither check decides the duplicate question; both simply help the reviewer file the note in the right place.

When the record is complete, the folder is a little more honest about what it holds, and the next duplicate review starts from a better position.