Generator FAT Scope: Define Acceptance Before Ordering

“FAT required” is not a test plan. Keep the factory acceptance test (FAT) open until six items are fixed: the exact build, row matrix, acceptance sources, evidence, exception authority, and release effect. A later PASS label cannot repair a missing pre-test agreement.

Resolve those points before the purchase order. Attach a revision-controlled FAT Scope and Acceptance Matrix to the order. Use a separate plan when the test needs detailed steps. Each matrix row should link the exact build to reviewable evidence and a stated release effect.

This guide covers pre-order business and evidence control. It does not set one test value for all generators, qualify a supplier, prove conformity, or replace an engineering review. A routine factory test, factory audit, and first-article approval remain separate controls. So do the pre-shipment check, site test, and commissioning, even when they share records.

Offered generating set and document hierarchy

Identify the object being tested before defining any FAT row. A family name, catalogue page, or phrase such as “same as sample” leaves room for the quoted, tested, and shipped sets to differ.

The FAT scope sheet should identify the offered build in enough detail for the order. Name the generator set, engine, alternator, controller, enclosure, fuel setup, breaker or switchgear, starting setup, output, and control links. Also list the supplied options, market variant, labels, manuals, accessories, and relevant software or setting revision. Copy the rating and duty basis from the approved offer. Do not infer a missing value.

Also state what group the FAT represents. Is it every unit, one named unit, the first unit, or a chosen sample? If serial numbers come later, state when they will be assigned. Define how the tested ID will link to the shipped ID. A similar-model report is only reference material unless the buyer accepts its use and limits for this order.

Put the governing files in an order of precedence. The list may include the signed PO, FAT attachment, approved build sheet, project spec, drawings, wiring and interface files, approved changes, and supplier test plan. Give each item a number, revision, date, owner, and approval state. State how to resolve a conflict. A newer supplier worksheet must not silently override an agreed PO attachment.

A workshop photo cannot close an identity gap. The matrix must link the physical unit, its build record, each result file, and the release pack. Use the generator documents before order checklist to control the wider file return. Then cite the approved files instead of copying loose attachments into a new FAT folder.

What the FAT must demonstrate

Replace broad phrases with observable decisions about the supplied build. “Test all functions” cannot be reviewed; each applicable control-mode row needs the command, expected response, evidence file, and acceptance source.

Choose only characteristics that apply to the project. The scope discussion can ask:

• Which start commands, starting sequence, control modes, and stopping sequence are included in the offer?
• Which stable-condition readings must be captured, at which separately agreed operating points and under what stated conditions?
• Which load application, removal, transition, or sequence events matter to the buyer’s application?
• Which alarms, protections, shutdowns, permissives, and interlocks exist in the approved configuration, and how may each be demonstrated safely?
• Are an ATS, remote start, dry contacts, communication link, monitoring system, or other control interfaces included, and where does the FAT boundary end?
• Which visual, nameplate, document, accessory, and packing interfaces should be checked during the event?
• Which project options require an observable state or an exported record?

Fuel use, sound, emissions, insulation, and other specialist measures need a valid contract basis. The contract must give the method, conditions, report basis, acceptance rule, and reviewer. A request for a measure is not permission to invent the method or treat a factory reading as a legal finding.

Keep scope and test detail in separate controlled records. The matrix states what decides each item and what the decision changes; the test plan holds the sequence, connection drawing, safety steps, data capture, stable-state rule, abort rule, and restore steps. The plan may explain a matrix row, but it cannot add an acceptance rule after the price or result is known.

FAT Scope and Acceptance Matrix

Give every requirement a stable item ID. One row should represent one decision that can be traced, witnessed where applicable, and assigned a status without hiding a different result in the same cell.

Use these fields as a starting structure, then tailor them to the order:

Use the BEAR generator catalogue to identify the product record behind the FAT request, then require the selected configuration to return the matrix's exact build, control, evidence, and release fields.

An acceptance cell that says only “as standard” or “supplier standard FAT” is incomplete. It needs the exact controlled source and rule. A result cell that says only “OK” is weak when the row calls for a value, state, event, or raw file. The buyer should be able to rebuild why the row passed without relying on the tester's memory.

Keep the matrix usable. Put detailed safety and wiring steps in the test plan. Put a large tool register in a controlled appendix and business duties in the contract schedule. Cite those files and revisions from the row. Copying one rule across loose files creates later conflicts.

Methods, conditions, instruments, and evidence

Method and condition give meaning to a result. A value recorded without its operating state, test point, connected arrangement, or unit identity may be impossible to compare with the criterion.

For each applicable row, define or cite:

• the controlled sequence or method.
• starting state and prerequisites.
• running point, change, simulated input, or other condition.
• supplied load gear, simulator, interface emulator, or agreed setup.
• relevant site or setup fields to record.
• observation or stable-state rule when the project needs one.
• data source and sample or export method.
• safety stop and technical abort conditions.
• restoration state after the row.

These are fields, not values for every generator. Load points, duration, site conditions, electrical bands, power factor, transient limits, sound, emissions, protection, and insulation depend on the build and project. Adopted sources, market duties, and the engineer's decision also matter. Mark an unresolved rule OPEN, assign its owner and due date, and block that row before the test.

Build the tool list from the measures the FAT needs. Record each tool's ID, useful range or capability, required status proof, and valid date when relevant. Link it to the result channels it supports. “Calibrated meter used” has no value without that ID link.

Name the raw evidence before the event. A file name can join the project, matrix row, unit or serial, date or run, and file revision. Save native exports when available. A cropped screen image may add context, but it does not replace the agreed raw data. If photos or video are allowed, define the visible ID, required display, recorder, file handoff, and limits.

The final report should index the approved matrix, results, instrument and attendance records, raw files, deviations, repair/change evidence, retests, comments, and signatures.

Hold, witness, and review points

Buyer attendance is a control point, not an acceptance rule. A witness may see a failed result. The buyer may waive an absence. A signature may confirm attendance without approving the unit. Define each meaning before booking travel or remote access.

Close the logistics in the FAT attachment or a linked schedule. Include the notice period, draft agenda, and in-person or remote format. Add site and safety rules, attendee names and roles, working language, time zone, and link test. Close camera and data permission, display access, sample or serial choice, raw-file handoff, signature route, and absence or waiver rule.

The contract should price buyer changes, supplier delay, repeat attendance, and retests. The test team must not assume those terms. Name who can approve a scope change and its price or timing effect. A spoken request during the event is not a new acceptance rule without a controlled change record.

For a remote witness, define what the video feed must show. This may include the unit ID, tools, control commands, data screen, and files for download. Record each break and hidden view. “Buyer attended online” does not prove access to every required item.

Pre-FAT readiness and execution records

Do not issue the FAT notice until the readiness pack is complete enough to execute. The supplier should return the current build list, matrix, test plan, drawings, rule sources, planned unit or sample, tools, setup, agenda, attendees, access needs, raw-data plan, and open deviations. The buyer records review state and comments against each revision.

Do not spend the witness event fixing basic file conflicts. Stop if the offered controller differs from the approved build, a rule is OPEN, or needed gear will be missing. The authorized owner can revise the scope, move the date, accept a stated limit, or cancel the affected row.

At execution, start a run record rather than overwriting a blank template. Capture:

• project, order, matrix, test plan, and build revisions.
• physical unit or serial, or the approved sample ID.
• date, place, run ID, supplier record owner, operator, and attendees.
• start state, setup, connected gear, and relevant site fields.
• actual observations and values for each row.
• tool IDs and raw-evidence filenames.
• start, stop, abort, restart, and finish states when they apply.
• witness comments, signatures, absence, or waiver.
• deviation, NCR, and retest references.
• row status and reviewer.

Keep the unit ID through repairs and reruns. If a controller setting, part, wire, firmware, test setup, or acceptance source changes, show the state before and after. State which old results still apply. Do not copy a clean result into the first run as if no stop occurred.

A supplier certificate can join the pack. Yet a model-family certificate that says only “passed” cannot replace row results. A family report, selected screen images, or witness signature also cannot prove that the quoted build was tested or that all required gaps were closed.

Deviations, aborts, repairs, and retests

Define status values before the test. Four useful states are:

Do not use N/A as a convenient way to close missing equipment or time. If a row was applicable when the order was agreed, changing it requires the same controlled authority as another scope change.

Each NCR or deviation record should name the finding, affected unit or build, and matrix rows. Add the actual evidence, short-term control, planned decision, and technical and business approval roles. Record the repair, setting, or other change and the build before and after it. Then state the retest scope, new raw evidence, reviewer, open or closed state, and shipment effect.

An abort is also evidence. Record why the run stopped and which values may be invalid. State what changed before restart. Then identify whether the full sequence or only named rows must run again under the approved rule. A restarted display does not erase the first event.

Avoid phrases such as “minor, okay to ship.” Use them only if the contract names who can decide and that person records the basis. Witness attendance is not decision authority. Supplier completion is not buyer acceptance. Technical closure of one row is not always business release for shipment.

Test completion versus shipment release

A FAT can finish while the order stays on hold. Use a non-compensating gate. Many passing rows cannot cancel one open row that the agreed scope marks as a shipment blocker.

The closeout review should answer five questions:

1. Does the executed pack identify the same configuration and unit population that the order covers?
2. Does every applicable matrix row have a defensible status, required raw evidence, and reviewer?
3. Are all deviations, repairs, changes, aborts, and retests linked and dispositioned by the authorized roles?
4. Are remaining open items visible, with explicit effects on continued work, packing, and shipment?
5. Has the named shipment-release authority recorded a separate decision for the exact unit, serial range, lot, or other controlled boundary?

The release record should cite the matrix and evidence-pack revisions. Name the released unit or group, closed and accepted gaps, approved remaining conditions, decision date, approver, and next handoff. Give packing checks or a pre-shipment inspection checklist their own scope. FAT completion does not prove quantity, final packing, or shipment condition.

Before signing, require one supplier return pack. It needs the current build and file hierarchy, completed matrix and test-plan revisions, rule sources, and tool and raw-evidence plan. It also needs witness, notice, waiver, deviation, retest, and approval fields. Add an exception list with every open field, owner, due date, and business effect. Return a pack that replaces agreed row evidence with a family report, unnamed tool, screen image, attendance signature, or pass certificate.

For a BEAR-specific inquiry, send Miya the destination, application, proposed configuration, quantity, document list, requested FAT rows, witness format, and release expectations. BEAR test facilities, methods, instruments, acceptance criteria, costs, timing, documents, and ability to support any requested FAT scope remain to be confirmed for the exact order.