Why do duplicate part records keep appearing even when teams try to prevent them?

How does the app serve as the single lookup source for every procurement transaction?

What does Materials & Parts List give your team?

• Vendor-backed part master records with multiple vendors per item. A critical component with a primary supplier plus two approved alternates carries all three vendor numbers, their individual price histories, plus preferred vendor designation in one record rather than three separate entries that diverge over time.
• Vendor part numbers, preferred vendor tags, plus price history per item. The buyer who opens a PO line sees the vendor's own part number alongside the internal number, the default supplier already tagged, plus the last price paid. None of that requires manual lookup or memory.
• Unit of Measure setup with conversion logic per part. A component purchased by the box but consumed by the unit carries both UoMs in the same record with the conversion defined. Requisitions and POs use the purchasing UoM. Inventory and BOM references use the consumption UoM. The conversion happens in the system rather than in a buyer's head.
• Category-based classification plus search filters. Parts are findable by category, by vendor, by purchasing type, plus by keyword against description or vendor part number. A buyer who does not know the internal part number can still locate the correct record in a catalog of thousands by narrowing with two filter selections.
• Attached spec sheets, MSDS files, plus supplier documents per part record. The technical documentation for a part lives on the part record itself. An engineer pulling a spec sheet and a buyer creating a PO both access the same document from the same place rather than from separate shared drives that may or may not have the current version.
• Purchasing type tags: stocked, non-stocked, consignment, plus specialty order. The tag tells the purchasing system how this item typically moves. Stocked items feed into reorder point calculations. Non-stocked items generate one-time requisitions. The distinction is in the master record rather than in the buyer's knowledge of which items are stocked.
• Obsolescence flags with replacement pointers. A discontinued part does not disappear from the catalog. It gets flagged as obsolete plus points to its replacement. Any buyer who searches for the old number sees both the flag and the current replacement immediately, with the original record's price history preserved for cost comparison.
• Authoritative lookup source for every PO and requisition in FireFlight. Purchase Orders plus Purchase Requisitions pull part data from this catalog rather than from locally maintained lists. One update to a part record propagates to every future transaction that references it. There is no secondary list to keep in sync.

What changes operationally after deploying this app?

• Duplicate part records stop accumulating because every buyer searches the same catalog before creating anything new. A part that already exists surfaces in the search rather than triggering a duplicate entry from a buyer who could not find it fast enough.
• PO accuracy improves because vendor part numbers, preferred supplier designations, plus current unit pricing populate from the master record rather than from a buyer's memory or a local spreadsheet that may not reflect the latest negotiated price.
• Spec sheet version control stops being a manual process. The document attached to the part record is the current version. Engineers plus buyers both pull from the same source rather than from separate shared drives that drift out of sync.
• Obsolete part numbers stop generating bad POs. The obsolescence flag plus replacement pointer intercept the order before it goes to a discontinued item, directing the buyer to the current replacement without requiring anyone to maintain a separate crosswalk list.
• New procurement staff reach full accuracy faster because the catalog carries the institutional knowledge that experienced buyers hold in memory: approved vendors, correct units, preferred sources, plus relevant compliance documentation, all accessible from one search.

Frequently Asked Questions

How is the Materials & Parts List different from an inventory or stock record?

+

Inventory records track what quantity is physically on hand at a location. The Materials & Parts List is a procurement master: it defines what the item is, where it comes from, what it costs, plus how it is ordered. A part can exist in the catalog without any inventory on hand, which is normal for non-stocked or specialty order items that are purchased per project rather than held in stock. The two records are linked but serve different purposes. Inventory Control references the parts catalog to confirm item identity plus unit setup. The parts catalog does not track quantities.

Can a single part record carry multiple vendor assignments with different part numbers and pricing?

+

Yes. Each part record supports multiple vendor assignments. Every vendor assignment carries that supplier's own part number plus that supplier's price history independently. A preferred vendor tag designates the default supplier so POs route to the right source automatically. When a buyer needs to use an alternate supplier, they select from the other approved vendors on the same record rather than searching a separate vendor file. All price histories remain available for cost comparison regardless of which vendor is selected on any given order.

What types of documents can be attached to a part record?

+

Part records support links to spec sheets, Material Safety Data Sheets, supplier quality certificates, approved drawings, plus any other document type relevant to the part. Documents attach as links to files stored in the Manual Library rather than as embedded files in the part record itself, which means updating a document in the library updates it for every part record that references it simultaneously. A spec sheet revision does not require updating dozens of individual part records. The library update propagates automatically.

How does the obsolescence flag work when a part is discontinued?

+

Setting the obsolescence flag on a part record marks it as no longer active for new purchases without deleting the record or its history. A buyer who searches for the obsolete part number sees the flag immediately plus a pointer to the designated replacement part. The old record retains its full price history, vendor assignments, plus attached documents for cost auditing and historical reference. The replacement record becomes the active source for new requisitions. No procurement history is lost when a part transitions out of active use.

Can we migrate an existing parts list from a spreadsheet into FireFlight?

+

Yes. PCG handles the data migration from your existing parts spreadsheet or legacy system during deployment. The migration maps your current columns to the FireFlight parts master fields, resolves duplicate records where they exist, plus flags records with missing required fields for review before they go live. Most organizations use the migration process as an opportunity to clean up duplicates and outdated vendor assignments that have accumulated in their spreadsheet over time. PCG has migrated parts catalogs ranging from a few hundred items to tens of thousands of active part numbers.

Who can add or edit part records, and how is that access controlled?

+

PCG configures role-based access during deployment to match your procurement structure. A typical configuration allows buyers to search the catalog plus create requisitions, while adding or editing part master records requires a procurement manager or catalog administrator role. Updates to vendor assignments plus pricing may require a separate approval step depending on your internal controls. Every change to a master record is logged with the user identity plus the prior value so no edit is anonymous and the full change history is visible on any record.

How long does it take to migrate and go live with an existing parts catalog?

+

For organizations migrating from spreadsheets, PCG typically completes the data mapping, deduplication review, plus initial catalog load within the first two to three weeks of deployment. Connecting the catalog to Purchase Orders plus Purchase Requisitions for live lookup happens in the same period. The full go-live, including buyer training via Ikhana's on-screen guidance plus the first live POs pulling from the catalog, typically lands in weeks rather than months. Larger catalogs with complex vendor assignment structures take longer on the initial load but the process is incremental: buyers can start using clean records before the full catalog migration is complete.