Items and Accounts

The procurement item and account sources provide separate, source-defined retrieval and presentation surfaces for account reporting, consolidation, PPMP management, and purchase requests. Their selectors narrow the returned data, but the inspected code does not establish authorization, ownership, tenant scope, route registration, API exposure, or successful runtime execution.

[!WARNING] Treat these as implementation surfaces, not a guaranteed live workflow. Account code, department, year, category, subcategory, keyword, and database-mode values are used as selectors but are not proven authorization boundaries. The consolidation item query interpolates posted field data into SUM expressions without an established validation or allowlist boundary. The supporting GSO account-list response call is commented out, and the purchase-request procurement-mode check only changes rendered output; it does not prove server-side enforcement or persistence rejection.

Retrieval surfaces

[
    {
        "title": "Account reporting",
        "body": "The source in `imspr/novusoft/include/account-report/custom/get-account.php` defines an account aggregation query joining `tbl_bmct_pr_item_catalog` to `tbl_bmct_pr_catalog`. It selects account description, the sum of approved item price as `total`, and account code. The query fixes the year to `2023`, requires `pr_status = 'APPROVED'` and `checked = 1`, groups by account code, and orders by account description. The result is assigned to `data['results']` and used to build a table through the account-report view."
    },
    {
        "title": "Consolidation items",
        "body": "The source in `imspr/novusoft/include/consolidation/custom/get-item.php` retrieves unconsolidated rows for one account code. The account code is passed as a bound query parameter, while the posted `field` value is inserted into quantity expressions for total quantity and approved quantity. Results are grouped by item code and include unit, item code, item description, unit price, and summed approved total price. The script formats rows for a month heading and includes item-selection checkboxes, then looks up `account_desc` from `items` using the account code as a bound parameter."
    },
    {
        "title": "PPMP-management item search",
        "body": "The source in `imspr/novusoft/include/ppmp-management/custom/search-item.php` passes account code, keyword, category, subcategory, and year from arranged POST data to **cataloglocal** with offset set to `false`. For each result, it copies the record, creates generated month quantity fields using the result quantity, and stores the transformed record in `itemlist` keyed by item code. The rendered labels cover item code, description, account description, procurement mode, unit, unit price, total price, and month columns; configured continuation fields are omitted. A truthy rendered list is passed to **tableGenerator** as `data['table']`; otherwise the source assigns `No Item Found`."
    },
    {
        "title": "Purchase-request item search",
        "body": "The source in `imspr/novusoft/include/pr/custom/search-item.php` selects **ppmp** when the posted year equals `2023` and **newppmp** for other years. The legacy call receives department, account code, keyword, year, and `[1, dbm]`; the other-year call receives department, account code, keyword, year, and `dbm`. Each result is copied into generated month quantity fields and stored in `itemlist` under a key composed of item code and unit price. The rendered labels cover item code, description, account description, procurement mode, unit, unit price, total price, and month columns. For each month quantity, matching posted and result `mode_proc` values emit a quantity input; otherwise the source emits `This Item not Allow because of mode of procurement mismatch|colspan|12` and breaks the month-quantity rendering loop. A truthy list becomes `data['table']`; otherwise the source assigns `No Item Found`. This is a rendering branch and does not prove server-side enforcement or persistence rejection."
    },
    {
        "title": "Supporting GSO account options",
        "body": "The supporting source in `imspr/novusoft/include/gso/custom/get-account-list.php` builds account options from distinct account descriptions and account codes in `annual-procurement`, filtered by posted year and department and ordered by account description. It constructs an initial `- Select Account -` option and appends returned accounts. However, its final `$_includeHelper::jsonexit($d);` call is commented out, so this source does not prove that the option data is emitted as a response."
    }
]

Account totals and item-table shapes

• Purchase-request account total — getearmar in imspr/novusoft/include/pr/custom/account-table.php sums approved item prices for one year, department, and account code. It restricts rows to consolidated = 1 and binds all three lookup values as query parameters.
• PPMP-management items view — imspr/novusoft/include/ppmp-management/view/items.php declares columns for delete, type, remarks, item code, description, account description, procurement mode, unit, unit price, total price, total quantity, and generated month fields. Its footer contains a total value and hidden account_desc, created_id, and ap_plan_total fields.
• Purchase-request items view — imspr/novusoft/include/pr/view/items.php declares columns for delete, item code, description, account description, unit, unit price, total price, total quantity, and generated month fields. Its footer contains a total value and hidden account_desc, created_id, and ap_plan_total fields.
• Catalog items view — imspr/novusoft/include/catalog/view/items.php declares a compact table for quantity, unit, item code, description, unit price, and total price.

The PPMP-management and purchase-request searches produce data['table'] and data['itemlist'], while their corresponding views declare a .pr-list body and hidden account/item-related fields. The inspected evidence marks both producer-to-view relationships as different and unbridged, so these declarations do not prove that either search result is transferred into or rendered by its view.