Procurement Reference Public

Module Research Notes

Evidence gathered from the current Procurement module files — controllers, models, configs, and migrations — before writing these user guide pages.

Guide version: r1 Module version: 1.0.0 Updated: 2026-07-22 Estimated time: 2 min 2 views
Reference

Module Research Notes

Evidence gathered from the current module files before writing the user guide pages.

Slug: procurementVersion: 1.0.0Category: ProcurementReviewed: 2026-07-11

Research Sources Inspected

Source path

modules/Procurement

Feature flags marked true

  • Controllers
  • Models
  • Views
  • Language
  • Permissions
  • Left Menu
  • Routes
  • Migrations
  • Helpers
  • Default Menu
  • Api Endpoints

Evidence Summary

Manifest

module.json defines slug procurement, version 1.0.0, category Procurement, and the module capability flags used in this guide.

Runtime surface

10 controller file(s), 63 view file(s), and 29 route mapping(s) were found.

Data surface

11 model file(s), 11 declared table(s), and 14 migration file(s) were found.

Operations surface

25 permission key(s), 0 job(s), 1 seeder(s), and 0 test file(s) were found.

Detailed File Evidence

Controllers and methods

  • Goods_receipts
  • Procurement_api - vendors, vendor, purchase_orders, purchase_order
  • Procurement_euapi - vendors, vendor, purchase_orders, purchase_order
  • Procurement_settings
  • PurchaseOrders
  • PurchaseReturns
  • Tax_reports
  • Vendor_bills
  • Vendor_groups
  • Vendors

Jobs and schedules

No scheduled module jobs were found.

Routes sampled

RouteTarget
purchase_orders/(:any)PurchaseOrders/$1
mes/purchase-ordersPurchaseOrders/index
mes/PurchaseOrders/(:any)PurchaseOrders/$1
mes/PurchaseOrders/(:any)/(:any)PurchaseOrders/$1/$2
mes/PurchaseOrders/(:any)/(:any)/(:any)PurchaseOrders/$1/$2/$3
purchase_returns/(:any)PurchaseReturns/$1
mes/purchase-returnsPurchaseReturns/index
mes/PurchaseReturns/(:any)PurchaseReturns/$1
mes/PurchaseReturns/(:any)/(:any)PurchaseReturns/$1/$2
mes/PurchaseReturns/(:any)/(:any)/(:any)PurchaseReturns/$1/$2/$3
purchases/VendorsVendors/index
purchases/Vendors/(:any)Vendors/$1
purchases/Vendors/(:any)/(:any)Vendors/$1/$2
ams/vendorsVendors/index
ams/vendors/(:any)Vendors/$1
ams/vendors/(:any)/(:any)Vendors/$1/$2
purchases/Vendor_groupsVendor_groups/index
purchases/Vendor_groups/(:any)Vendor_groups/$1
purchases/Vendor_groups/(:any)/(:any)Vendor_groups/$1/$2
procurement/Tax_reportsTax_reports/index
9 additional route(s) omitted for readability.

README topics

  • Layout
  • Runtime wiring
  • Migrations
  • Dependencies
  • Demo Seeder
  • Roadmap

Operating Implications

  • Permission coverage is part of the module contract, so every workflow should be tested with a role-limited user and an administrator.
  • The module has migrations, so fresh installs and tenant databases need migration validation before go-live.
  • The module has API documentation or routes, so response examples and query filters should stay aligned with user-facing screens.
  • Seeders exist for sample or starter data; operators should know whether seeded records are demo-only or operational defaults.

Known Risks from the Manifest

No explicit known_risks list was found in the module manifest. Keep normal module controls in place and validate permissions, data, and public surfaces during QA.

Was this guide helpful?

Report a content problem