# How Should LGUs Validate Item Master Data Before Procurement Tracking Begins? Philippine local government units (LGUs) need procurement item master validation before staff encode requests or migrate procurement records. Give each item one usable identity, one controlled description, the correct unit of measure, an appropriate classification, a clear status, and a named change authority. These decisions help produce [connected LGU procurement records](https://golgu.ph/service/erp-system) without carrying ambiguous entries into the new process. The item master is the controlled list that identifies goods used in purchasing and related records. It is not the Project Procurement Management Plan (PPMP), a purchase request, a bid document, a purchase order, or an inventory balance. Validation prepares reference data so those later records point to the intended item. ## Why must item data be checked before procurement tracking starts? A procurement system follows the data supplied to it. If toner appears under three descriptions and two units, separate offices might request the same product under different entries. Reports could then split demand, comparisons could mix unlike quantities, and staff could spend time deciding which record represents the intended supply. Republic Act No. 12009, or the New Government Procurement Act, identifies the End-User or Implementing Unit as the employee or organic office that identifies, plans, prepares, designs, and implements a procurement project based on agency requirements. Its Implementing Rules and Regulations also place responsibility for procurement documents, including technical specifications, with the End-User or Implementing Unit. These rules support careful preparation, but they do not prescribe one universal item-master form for every LGU. The Government Procurement Policy Board PPMP guide separates the procurement-project description, supporting technical specifications, and quantity or size. This offers a useful control principle: the item label identifies the object, while detailed specifications describe the procurement requirement. Keep entire specifications out of names in the LGU item catalog. ## What scope should procurement item master validation cover? Cover the reference fields that help users select, group, and maintain an item. Do not use this review to approve a purchase, choose a procurement mode, establish an Approved Budget for the Contract, or certify that stock exists. Those decisions belong to separate records and authorized processes. A practical scope has six control areas: 1. **Identity:** one persistent code or other locally authorized identifier for one defined item record. 2. **Description:** a concise name that distinguishes the item without inserting supplier-specific language unless an applicable procurement rule permits it. 3. **Unit:** the unit used when the item is requested and compared, together with any locally authorized conversion rule. 4. **Classification:** the category needed for search, reporting, responsibility, or other legitimate local use. 5. **Status:** whether the entry is available for new use, temporarily restricted, or retired from future selection. 6. **Stewardship:** the office or role that reviews requests for new entries and changes. This scope keeps procurement data setup narrow enough to finish and detailed enough to prevent obvious confusion. It also keeps the LGU item catalog focused on reusable reference values. Technical requirements that vary by purchase remain with the PPMP, technical specifications, scope of work, terms of reference, or other applicable procurement document. ## How should an LGU find duplicate and ambiguous entries? Begin with a working export of item references from forms, spreadsheets, databases, and systems. Preserve source files under local records rules. Compare normalized descriptions, units, categories, and known codes while retaining original values for traceability. Use several passes instead of relying on an exact-text search: * Group entries that differ only in capitalization, spacing, punctuation, abbreviations, or word order. * Compare descriptions that share a core noun but use different packaging terms, sizes, or technical qualifiers. * Flag the same description when the recorded units differ. * Look for discontinued names, local nicknames, brand-led descriptions, and temporary codes. * Ask end-user offices whether similar entries represent one item, valid variants, or genuinely different requirements. A duplicate item description is a review signal, not proof that two records belong together. Similar supplies might differ in size, material, compatibility, or use. Very different labels might refer to the same object. Base the decision on operational meaning and supporting records, not spelling alone. ## How should descriptions and technical specifications be separated? A controlled name helps staff recognize the object without deciding the purchase in advance. Start with the item type, then add only stable qualifiers that distinguish another authorized entry. Put variable requirements, performance details, delivery conditions, and project-specific quantities in the relevant procurement documents. For example, an office might hold these entries: * Printer Toner Black * Black Toner Cartridge for Office Printer * Toner, Model-Specific, Black, One Box Do not simply select the shortest wording. Determine whether the records describe the same consumable, separate compatible products, or one generic need with purchase-specific details. Keep the final name clear for users, while the PPMP and technical specifications carry the exact procurement requirements. The official Procurement Service–Philippine Government Electronic Procurement System list of Common-Use Supplies and Equipment separates product code, description, unit of measure, price, and remarks. LGUs may study that pattern for applicable common-use supplies. Do not copy it as a universal local template. ## How should the unit of measure review be performed? A unit of measure review tests whether users request, compare, receive, and issue the item in understandable quantities. “Piece,” “box,” “pack,” “bottle,” and “ream” are not interchangeable merely because staff uses them casually. The unit affects quantity interpretation and later records. For each item, identify the standard requesting unit and check historical alternatives. If a box contains several pieces, decide whether a documented conversion is needed and who maintains it. Do not invent a conversion when packaging varies by supplier or procurement. The Philippine Government Electronic Procurement System catalog displays a unit of measure beside each listed product. This shows why the unit belongs in a distinct field, but it does not establish a mandatory unit for every local purchase. End-user and procurement personnel confirm the unit that matches the defined requirement and applicable guidance. ## Who should own the catalog and authorize changes? Divide ownership between operational knowledge and data control. End-user units understand their needs. The General Services Office and procurement personnel understand how item references affect records. A system administrator manages configuration but does not decide an item’s operational meaning alone. Name a catalog steward or responsible group under local authority. Document who evaluates a proposed entry, confirms its meaning, checks for matches, authorizes activation or retirement, and applies the system change. Local delegations, office mandates, and internal controls determine the arrangement. A change record should focus on the decision, not duplicate every detail. Identify the action, affected entry, reason, reviewer, authority, effective date, and result. Match access to add, edit, retire, or restore entries with assigned duties. ## What validation sequence should the implementation team follow? Use a procurement data setup sequence that produces evidence at each decision point: 1. **Set the boundary:** Identify the offices, sources, item classes, and cut-off date included in the review. 2. **Collect source values:** Keep the original code, wording, unit, category, status, and source location available for comparison. 3. **Identify candidate matches:** Group possible duplicates and unclear variants without merging them automatically. 4. **Resolve meaning:** Ask the relevant end-user office to explain whether each candidate represents the same need, a valid variant, or a separate item. 5. **Confirm controlled values:** Set the authorized identity, description, unit, classification, and status. 6. **Record ownership:** Assign the steward and the route for requesting, reviewing, authorizing, and applying later changes. 7. **Test selection:** Let representative users search for and select items using realistic request scenarios. 8. **Freeze the initial load:** Resolve critical exceptions, authorize the baseline, and control changes between approval and import. Before loading the baseline, teams also need to [protect migration test data before loading item records](https://blog-golgu.hashnode.dev/protect-erp-migration-test-data). Use only the information needed, restrict access, and separate test output from official transactions. ## What evidence shows that the catalog is ready? A completed spreadsheet alone does not prove procurement system readiness. The responsible group needs evidence of resolved candidate duplicates, confirmed units, remaining exceptions, baseline authority, and control over later changes. A procurement system readiness review samples high-use items, high-value items where relevant, multiple historical units, and several end-user offices. Test users need to find the intended item without private notes or personal memory. Repeated wrong selections point to description, classification, search, or training problems. Keep inventory reconciliation outside this test. After transactions start, a separate control is needed to [review units of measure after inventory adjustments](https://blog-golgu.hashnode.dev/veterinary-inventory-adjustment-validation) and explain recorded balances. That later activity does not replace the pre-setup catalog decision. ## How should GoLGU discussions use the validated baseline? GoLGU describes standardized and centralized master data, traceability, role-based permissions, and procurement status visibility within its enterprise resource planning approach. An LGU still needs to decide the local catalog rules, responsible roles, and evidence before configuration. Software does not create legal authority or settle an unresolved item definition. Bring a small sample of duplicate descriptions, competing units, and proposed ownership rules when evaluating the setup. Teams may then [request a GoLGU demo](https://golgu.ph/get-demo) to discuss how the baseline, access roles, and change process fit the intended implementation. ## What decision should LGU leaders require before launch? Leaders need a clear baseline decision: which records are active, who owns their meaning, how changes receive authority, and which unresolved entries stay outside the initial load. Procurement item master validation is complete only when representative users distinguish the intended items and responsible offices accept the controlled values. That result gives procurement tracking a dependable starting point. It does not guarantee the correctness of every later transaction. It does make errors easier to identify because requests begin with shared item identities instead of competing names and units. ## Frequently Asked Questions ### Is an item master the same as a PPMP? No. The item master is controlled reference data used to identify items. A Project Procurement Management Plan records planned procurement information for an end-user or implementing unit under applicable rules. The two records serve different purposes. ### Should every historical item remain active? No. The responsible office reviews whether an entry remains valid for new use. Retirement stops future selection without erasing authorized historical transactions that already reference it. ### Does a duplicate item description always mean the records are identical? No. Similar wording could hide different technical requirements, while different wording could describe one item. Review operational meaning, unit, stable qualifiers, and supporting records before deciding. ### Who decides the final unit of measure? The LGU assigns that decision through local authority and office responsibilities. Consider end-user knowledge, procurement requirements, General Services controls, and system implications. A software administrator does not make the operational decision alone. ### Should brand names appear in the item catalog? Use descriptions consistent with applicable procurement rules and the LGU’s authorized needs. Do not place a brand in a generic item name merely for convenience. Seek procurement and legal guidance when a brand-related specification is being considered. ### When should procurement tracking begin? Finish procurement item master validation before tracking begins. Start only after accountable offices authorize the initial baseline, resolve critical duplicate and unit issues, complete representative selection tests, and establish a controlled route for later changes. ## References * [Lawphil: Implementing Rules and Regulations of Republic Act No. 12009](https://www.lawphil.net/statutes/repacts/ra2025/irr_12009_2025.html) * [Government Procurement Policy Board: Project Procurement Management Plan Guide](https://www.gppb.gov.ph/wp-content/uploads/2025/08/NGPA_PPMP.pdf) * [Procurement Service–PhilGEPS: List of Common-Use Supplies and Equipment](https://sys.ps-philgeps.gov.ph/catalogue/cse-list/) ## Disclaimer This guide provides general operational information. LGUs should follow Republic Act No. 12009, its current implementing rules, applicable issuances, local authorities, approved delegations, records policies, and legal advice for their circumstances.