BOM Accuracy Validator Copy link

➜ Back to AI Skills
Description
Category: Manufacturing
Plugin: Blitz Report Excel Add-in Skills (br-bom-validator)
Works with: Claude in Excel, Microsoft 365 Copilot in Excel
Updates EBS creates or updates Oracle EBS data through Blitz Uploads, only after your confirmation

Validate Oracle EBS bill-of-material accuracy against how the shop floor actually consumes material: compare BOM structures with WIP component requirements and shortages, flag suspect components (never issued, always short, quantity drift), and stage approved BOM corrections via the BOM Bill of Materials Upload — only on explicit user confirmation.

When to use it

  • Use when the user asks whether BOMs are accurate, why jobs are always short the same part, or wants BOM cleanup done.
  • Recommend-first; WRITES to Oracle EBS only via the gated correction step.
Install
  1. Download the skill zip. br-bom-validator.zip
  2. In Claude in Excel open Customize > Skills > Create skill and upload the zip.
  3. Connect the Blitz Report Excel add-in to your Oracle EBS instance, then ask Claude for the task in your own words.

Requirements: Blitz Report and the Blitz Report Excel add-in, connected to your Oracle EBS instance, plus Claude in Excel or Microsoft 365 Copilot in Excel.

🚨 Blitz data = Excel worksheet UDFs, not MCP tools/connectors. Extract data only by writing =br_...() into a cell (via execute_office_js) and reading the spill — never tool_search for br_*, never refresh_mcp_connectors, and never conclude "no Oracle EBS / Blitz connector is set up" (the Blitz Report add-in is an Excel add-in, not an MCP connector, so it never appears in the connector list — its absence there is expected). Load the extraction mechanism first: read_skill("br-run-reports").

Performance: read br-analytics-standards at the start of every run. For the correction step, read br-run-uploads FIRST.

When to use

"Are our BOMs accurate", "why is every job short part X", "clean up the BOM for assembly Y", "which BOM components are dead". For job-level health and WIP value use br-wip-variance-analysis; this skill judges the BILL, using the jobs as evidence.

Inputs

  • Organization Code (required) — ask if not supplied.
  • Assembly scope — an assembly, a range, or org-wide (warn on org-wide size; narrow if the user can).
  • Evidence window — default 12 months of WIP history; say so.

Reports and uploads used (authoritative names — do NOT broad-search for them)

NameTypeRole
BOM Bill of Material StructureReportthe bills as defined — components, quantities, yields, effectivity
WIP Required ComponentsReportwhat jobs actually required/issued per component
WIP Discrete Job ShortageReportrecurring shortages — the "bill says X, floor needs more" signal
WIP Component ReportReportissue detail cross-check on suspect components
BOM Bill of Materials UploadUploadwrite path for approved corrections

Pass the exact names; fall back to a search only on #BLITZ_REPORT_NOT_FOUND. Engineering-change (ECN) impact is out of scope — no ECN report ships; say so if asked.

Workflow

  1. Extract the BOM structures for the scope and the WIP evidence for the window (one call per report).
  2. Score each BOM component against the evidence:
    • DEAD — on the bill, never required/issued by any job in the window (candidate to remove or end-date).
    • UNDER-QUANTITY — jobs consistently issue/require more than the bill quantity, or the part recurs on shortages across jobs (candidate to raise qty or fix yield).
    • OVER-QUANTITY — jobs consistently consume less (candidate to lower qty; scrap-factor suspects called out).
    • OFF-BOM USAGE — components jobs issue that are NOT on the bill (candidate to add).
    • OK — evidence matches the bill. Every non-OK class carries its evidence inline: jobs counted, average actual vs bill quantity.
  3. Rank by financial effect (quantity drift × component cost × annual build volume) so the cleanup list starts where it pays.
  4. Deliverable: per-assembly validation sheet + the ranked correction candidates + dashboard (br-data-dashboard).
  5. Correct (optional, gated): only for corrections the user explicitly approves — download the BOM Bill of Materials Upload for the assemblies, apply ONLY the approved changes (quantity updates, end-dates, additions), validate, show assembly/component count and before/after values, submit on a second explicit confirmation. Remind the user a changed bill affects future jobs and cost rollups — existing jobs keep their snapshots.

Hard rules

  • Evidence below a minimum job count (default 5 jobs — CONFIG, label it) → the component is INSUFFICIENT-EVIDENCE, never a candidate.
  • Alternate/option-class structures: validate only the standard bill unless the user names an alternate; say which bill was judged.
  • Never propose removing a component that appears on open jobs' requirements.

Degradation rules

  • No WIP history for an assembly (never built in the window) → the bill is UNVERIFIABLE, listed separately — absence of evidence is not accuracy.

Talk in the user's language

Assemblies, components, quantities, jobs — never br_* functions or helper sheets.