Repeat PCBA orders should reference an approved combination of board revision, BOM, firmware, configuration, and test procedure. Reusing an old purchase order or product name does not by itself define those items clearly enough for a new production batch.
This matters when an earlier shipment worked and a buyer simply wants more of the same. Stock availability, software releases, fixture settings, and component approvals can change between orders. The useful purchasing question is therefore: what must remain identical, and what changes require a new approval?
repeat-pcba-orders.webp
Illustrative configuration-control aid; example revisions are not customer records.
What Does “Same As Last Order” Need To Specify?
Start with the released product configuration. The order should identify the manufacturing package and where its approved version is held.
Include the bare-board revision, assembly variant, BOM revision, approved alternate rules, firmware image, device settings, labeling, and acceptance procedure. If an item is intentionally unchanged, say which revision remains valid.
A supplier can then compare the new order against the baseline and report exceptions before procurement or assembly begins.
| Controlled Item | What To Lock | What Can Go Wrong Without It |
|---|---|---|
| PCB and assembly variant | Released files and populated/DNP positions | Similar-looking boards receive different component populations |
| Components | Exact part numbers and conditional alternates | Purchasing assumes an unreviewed substitute is acceptable |
| Firmware | Release identifier, approved file, and integrity check | A development build enters production |
| Device configuration | Boot, calibration, identity, and protection rules | Identical application code produces different behavior |
| Test process | Script, fixture, limits, and required records | Two batches pass different definitions of acceptance |
| Product marking | Label revision and identity allocation | Shipment labels do not identify the actual configuration |
The baseline should be usable by purchasing, engineering, and production. A document that only one software developer understands will leave gaps at handoff.
Which Changes Must Be Raised Before The Repeat Build?
Request an exception list that identifies proposed differences. For each difference, ask who needs to approve it and which evidence demonstrates suitability.
Examples include a new memory manufacturer, another MCU suffix, a changed connector, revised firmware, an updated programming project, or a modified functional-test limit. Not every difference requires a board redesign, but each needs the appropriate review.
Track shortage-driven changes through component sourcing and obsolescence management. Commercial approval of a price or delivery date should not silently become engineering approval of compatibility.
Use Conditional Approvals Explicitly
An alternative may be acceptable only with a particular software release. In that situation, adding it to the BOM without a condition can create an unsupported combination later.
The following is a fictional example showing how to record decisions. It is not a compatibility recommendation for real devices.
| Board | Memory | Firmware | Test Release | Decision |
|---|---|---|---|---|
| Rev B | Original MPN | 1.4 | T03 | Existing approved baseline |
| Rev B | Proposed MPN | 1.4 | T03 | Hold: no compatibility evidence |
| Rev B | Proposed MPN | 1.5 | T04 | Release only after documented validation |
| Rev C | Original MPN | 1.4 | T03 | Hold: new hardware combination requires review |
A familiar part or filename does not authorize a new row. The engineering owner must approve the combination and define its manufacturing instructions.
How Do You Keep The Programming Station On The Correct Release?
Issue an approved job package that identifies both the firmware and the programming settings. Verify that the station loaded that package before releasing the setup.
The SEGGER J-Flash manual describes project settings, verification, logging, and serial-number handling. These illustrate why controlling only the application file leaves part of a programming process unspecified. The actual process must use documentation and tools suitable for its target devices.
Record the image’s approved hash as a file-integrity check. However, a matching hash does not prove that the selected release is authorized for this board, nor does it prove that the board runs correctly.
Therefore, combine package identification, device verification, and the required functional test. Retain their results against the assembly identity.
Keep Unique Data Separate From Shared Firmware
A batch can share an application while requiring different serial numbers or calibration data. Define those differences explicitly so a common image does not overwrite them.
Microchip’s SQTP overview describes serialization in device programming. It is one example of tooling for unique data, not a universal method for every MCU or memory family.
Also specify how failed programming, scrap, and repair affect identity allocation. Ordinary retries should not accidentally create duplicate identities or assign a scrapped unit’s identity to another product without an approved policy.
What If Firmware Changes After Production Has Started?
Establish a cutover instruction before changing the station. Identify the last assembly or work order using the old release and the first authorized to use the new one.
Then classify existing units by status: unprogrammed, programmed but untested, tested, packed, and shipped. Determine which groups require reprogramming, additional testing, relabeling, or no action under the engineering decision.
| Inventory State | Decision To Make | Record To Preserve |
|---|---|---|
| Unprogrammed | Which job now applies? | New release authorization |
| Programmed | Is updating required, and what data must survive? | Previous and new software identity |
| Tested | Which tests become invalid after the change? | Approved retest scope and outcomes |
| Packed | Must labels or shipment documents change? | Reconciliation of physical units and documents |
| Shipped | Does engineering require any field action? | Affected population and responsible owner |
Avoid changing only a label while leaving the underlying unit unverified. Conversely, do not assume every software change requires the same retest: base the scope on the actual change and its possible effects.
How Much Reconfirmation Does A Repeat Order Need?
The answer depends on what changed and what evidence remains valid. A repeat order does not automatically require full requalification, but it should not bypass a setup check.
Use first article inspection to confirm the released files, component population, programming job, and relevant test output before the batch proceeds. If the change introduces new risks, expand the review through the NPI process.
Also confirm fixture condition and instrument status. A previously approved script cannot compensate for worn contacts or an unsuitable measurement setup.
The buyer and manufacturer should agree the review depth before the build. That makes the quoted scope and release expectations clear instead of arguing about “same order” after a problem appears.
What Evidence Should Accompany The Shipment?
Agree a release summary that identifies the order, quantity, configuration, approved deviations, and test-record reference. For serialized products, define how each unit connects to that information.
The PCBA traceability record should distinguish material lots, software releases, and reworked units when required by the product. The required tracking detail should match the contracted process: batch records and individual board records provide different levels of visibility.
A practical repeat-order release check asks:
- Does the shipment match the approved configuration matrix?
- Have all substitutions and exceptions received the required approvals?
- Do programming and test records identify the actual units or agreed batch?
- Are failed, quarantined, or unreconciled units excluded from shipment?
- Can both parties locate the records for a later inquiry?
These checks make the release decision reviewable. They also help purchasing identify exactly what to reference when placing the following order.
What Should You Send Haode With A Repeat PCBA Order?
Provide the previous order reference, the approved release package, required quantity, and a clear statement of changes or unchanged revisions. Ask Haode to return an exception list covering material availability, manufacturing instructions, programming, and testing before production release.
If you want the next batch to behave like the first, define the configuration that created the first result. Repeat PCBA orders become easier to verify when “same as before” points to approved files, compatible revisions, and identifiable production records.
