Service Catalog, Fault Codes, Grading Rules: Reference Data With a Starter Kit
Where the services you sell, the defects your testers pick and the bands that turn defects into a grade live — and why a new tenant does not start from an empty shelf.
Some reference data is universal (currencies, country codes). Some is platform-managed but visible (the certification catalog, the stock fault codes). Some is genuinely tenant-specific: the services you actually sell, the custom defects for the niche devices you handle, the grade thresholds your buyers have learned to trust. The settings pages organize each according to its scope, and a fresh tenant receives a starter kit so the first day is spent receiving pallets, not typing catalogs.
Service catalog
/settings/services holds the services the tenant can perform or charge for. New tenants land with 44 system services in six categories: logistics, processing, destruction, remarketing, compliance and financial. Each has a code, a default rate and a pricing unit. Your team can search, filter by category, activate or deactivate, reorder within a category, and add custom services. A custom service is a four-character code, a name, a description, a pricing unit — per unit, per kilogram, per hour or fixed — and a default rate. System services can be deactivated but not deleted, because contracts, bids, settlements and invoices expect them to exist; deactivating a service that something still depends on shows a dependency warning first. Read it. A quiet row in Settings can be holding up a loud invoice.
Fault codes
/settings/core/fault-codes is the catalog of structured defects. The platform ships 38 stock fault codes across cosmetic, functional, battery and missing-part categories; stock rows are read-only. Each code carries a description, a category (cosmetic, functional, battery, data or missing part), a severity of minor, moderate, major or critical, a weight, the body zones it can be pinned to, whether a photo is required, and an active flag. Tenants add custom codes for the device types they specialize in — an industrial-printer specialist needs defects the stock list does not know — and a “seed default custom codes” action gives a starting set when no custom codes exist yet. A code, once active, appears in the tester’s defect picker. Free-text fault notes are useful; dashboards hate them.
Grading rules
/settings/core/grading-rules is where defect weights become a grade. The rules are grade bands: for the functional, cosmetic and battery dimensions, each grade owns a minimum and maximum weight range. In the defaults, a battery with an accumulated weight of 1–20 is B2 Acceptable, 21–50 is B1 Low Health, and anything above is B0. There are no percentage weightings between dimensions and no hidden floor rule; the bands are the whole story, which is exactly why a buyer can read them. Auto-grade rules — the ordered, first-match suggestions the engine makes from test results and battery health — live on the testing templates page next to the checklists. The page shows whether the tenant is on the inherited defaults or a tenant override, with links to templates and categories. Changing bands halfway through a batch is technically allowed; explaining to the floor why today’s B looks like yesterday’s C is on you.
Categories
/settings/core/categories defines how each device category behaves. Category defaults cover traceability, whether a serial number is required, the unit, the data-bearing flag, the battery flag and IMEI or MAC expectations where relevant. A tenant can enable or disable a category, give it a custom label, save an override or reset it to the default. Override a category when your operational vocabulary genuinely differs. Not because someone wants a prettier label on a report.