Warranty Admin
The back-office review queue for warranty registrations a member submits through the storefront: support fills in the warranty period and expiry date, checks the receipt photo, and approves or declines; approving writes a warranty certificate, the proof of cover you print for the customer. It posts no journal, moves no stock, and cannot create a registration itself. Check the warranty period and expiry before you approve: they are filled in from the item’s Basic Warranty only when the item has one, and the certificate copies whatever the form holds; nothing expires a certificate either, and no e-mail is sent, so print or export the certificate and send it yourself.
Your job, and the screen for it
| The job | Screen or tab | Read |
|---|---|---|
| Approve or decline a registration — check the warranty period, expiry date and receipt first, because the certificate copies the form | Product Registration, open it, Main Details › APPROVE / DECLINE (shown only while PENDING) | What SAVE, APPROVE and DECLINE actually do; Product Registration — Main Details |
| Check the receipt photo — the member can replace files, so look again if the registration has waited | Registration › Attachments tab | Screens and menus |
| Give the customer the certificate — no e-mail is sent; print or export it and send it yourself | Registration › Warranty Certificates tab (prints the registration, at any status) | What SAVE, APPROVE and DECLINE actually do |
| Look up issued cover — nothing expires a certificate, so compare the expiry date yourself | Warranty Certificate listing (read-only) | What SAVE, APPROVE and DECLINE actually do |
| Set up membership, customers, items, the certificate’s printable format and a client that creates registrations — this applet only reviews them | Settings › Printable Format Settings; the rest in their own applets and the storefront widget | Before you can use it |
Overview
Warranty Admin is the back-office review queue for warranty registrations. A member registers a
product through the storefront — serial number, purchase date, a photo of the receipt — and the
registration lands here with an approval status of PENDING. Someone in support opens it, checks
or fills in the warranty period and expiry date, checks the attachment, and clicks APPROVE or DECLINE.
Approving it writes a second record, a warranty certificate, which is the durable proof of coverage and the thing you print for the customer.
Where it fits
| Direction | What | Why |
|---|---|---|
| Upstream | The CP Commerce storefront’s warranty registration widget | Submits the registration with approval_status = PENDING, the member’s membership card, entity, serial number, purchase date and the chosen item |
| Prerequisite | A membership card for the customer | membership_hdr_guid is validated as non-null and looked up in the membership card table on every create and update — a registration cannot exist without one |
| Prerequisite | A customer/entity record | entity_hdr_guid must be non-null and must exist; entity_name must be non-null |
| Prerequisite | Items | The storefront picks the product; fi_item_guid, fi_item_code and fi_item_name are copied onto the registration |
| Downstream | Warranty certificate | Created by the applet the moment a registration is approved |
| Downstream | Printable formats | The certificate is printed with a printable format chosen in the applet’s own Printable Format Settings |
| Adjacent | RMA (Internal) | Support staff read warranty cover here by eye when handling a return. There is no link: nothing in RMA or on a service note looks up a warranty certificate |
Screens and menus
The sidebar has exactly two working entries, plus the standard settings and personalization gears.
| Menu | Route | What it does |
|---|---|---|
| Product Registration | product-registration | The review queue. Listing with advanced search and column toggles; no add button |
| Warranty Certificate | warranty-certificate | Listing of issued certificates. Read-only from this applet — the applet never PUTs or DELETEs a certificate |
Opening a registration gives three tabs:
| Tab | Contents |
|---|---|
| Main Details | The eleven fields listed under Fields, plus APPROVE, DECLINE and SAVE — which appear only while the registration is PENDING. Once it is approved or declined you can still type on the form, but nothing you type can be saved from this applet |
| Attachments | Files the member uploaded (typically a receipt photo), and any you add. The member can add and replace files too, so look at the receipt again just before you approve if the registration has waited |
| Warranty Certificates | The export pane. It prints the registration, not the certificate record, through the printable format you pick — and it works at any status, so a PENDING or DECLINED registration prints on the certificate layout too. It prints what is saved, not unsaved edits on Main Details (read, not run) |
DECLINE is a two-click button: the first click changes its label to CLICK AGAIN TO CONFIRM.
Settings (gear) contains five entries and nothing else: Application Settings, Default Selection, Printable Format Settings, Email Template, Custom Status. Personalization contains one: Default Selection.
settingItems lists only the five System
Configuration items. They are reachable by URL only.Configuration
Before you can use it
- Membership. Every registration must carry a membership card GUID that resolves. Without a membership programme in the tenant, no registration can be created at all, from any client.
- A customer entity for the member, with a name.
- Items for the products being registered.
- A printable format for the certificate — set it as the default in Settings > Printable
Format Settings, which writes the
PRINTABLEkey. - A client that creates registrations. The storefront’s warranty widget is the shipped one.
Applet settings
Settings live in two places here, and the split matters:
- Application Settings is the shared settings screen.
- Default Selection and Custom Status are the applet’s own components.
The shared screen does not recognise this applet, so it shows its default set — some 237 controls for a generic financial document: line-item price columns, contra, expenses, e-Invoice and so on. None of them does anything in this applet. Treat Application Settings here as a screen that saves values nothing in this applet uses.
Only these settings are shown, saved and actually used:
| Setting | Where it is set | What it controls | Default | Effect when changed |
|---|---|---|---|---|
PRINTABLE | Settings > Printable Format Settings (set as default) | The printable format the certificate export pane pre-selects | none | The export pane on both Product Registration and Warranty Certificate opens on the chosen format |
DEFAULT_COMPANY | Settings > Default Selection (filled automatically from the branch you pick) | Resolved by the shared session effect into the applet shell’s company | none | Changes the company shown in the shell header |
DEFAULT_BRANCH | Settings > Default Selection | Resolved by the shared session effect into the applet shell’s branch | none | Changes the branch shown in the shell header |
Saved by a real control but read by nothing:
| Setting | Where it is set | Status |
|---|---|---|
DEFAULT_LOCATION | Settings > Default Selection (auto-filled from the branch’s MAIN_LOCATION) | Written; no reader in the applet |
| Default sender e-mail | Settings > Default Selection | Written; no reader — the applet sends no e-mail (see Lifecycle). The platform’s own sender address has nothing to do with this key |
| Default approved e-mail template | Settings > Default Selection | Written; no reader |
| Default declined e-mail template | Settings > Default Selection | Written; no reader |
ENABLE_CUSTOM_STATUS_1..5, ENABLE_CUSTOM_STATUS_HDR_1..5, ENABLE_CUSTOM_STATUS_LINE_1..5, NAME_CUSTOM_STATUS_HDR/LINE_1..5, LIST_CUSTOM_STATUS_HDR/LINE_1..5 | Settings > Custom Status | Saved, and used by nothing: the Main Details form has no custom-status control, and neither a registration nor a certificate can carry one |
The applet’s other settings — the INCLUDE_* / ENABLE_* dimension, profit centre, project, segment,
SST and WHT flags, and the twenty-odd HIDE_* price and quantity column flags — have no control here
and do nothing.
Both Default Selection screens (applet and personal) save by merging into the existing applet settings rather than replacing them, so saving one screen does not wipe another’s keys.
Feature visibility / permissions
The applet declares no client-side permission codes of its own and its Client-Side Permission screen has no menu entry. Access is enforced server-side, by two permission families:
| Family | Gates |
|---|---|
API_TNT_DM_ERP_WRTY_PRODUCT_REGISTRATION_* (OWNER, ADMIN, MEMBER, CREATE, READ, UPDATE, DELETE, SEND_EMAIL) | Every back-office registration endpoint — and every attachment endpoint, which reuses the registration family rather than having one of its own |
API_TNT_DM_ERP_WRTY_WARRANTY_CERTIFICATE_* (OWNER, ADMIN, MEMBER, CREATE, READ, UPDATE, DELETE) | The certificate endpoints |
API_TNT_DM_ERP_WRTY_PRODUCT_REGISTRATION_SEND_EMAIL gates a rejection-e-mail endpoint that the
applet never calls.
A read the caller is not entitled to does not fail — the record comes back with its status shown as
PERMISSION_DENIED and every other field blank.
Fields
Product Registration — Main Details
Every control on this form is an unvalidated UntypedFormControl; the applet enforces nothing.
The “Required” column below is the backend validator.
| Field | Meaning | Required | Notes |
|---|---|---|---|
| Customer Name | The registered owner | Yes (entity_name) | Free text, copied onto the certificate when you approve. Changing it here changes the name the certificate carries, not the customer record |
| Customer Email, Customer Mobile | Owner’s contact details | No | Kept on the registration only: approval does not copy either onto the certificate, and nothing sends to the e-mail (see Lifecycle) |
| Product Name | The item | No on the form; fi_item_name is copied from the storefront’s selection | |
| Serial No. | The unit’s serial number(s) | No | Stored as JSON: { "serialNumbers": [ … ] }. The storefront submits exactly one |
| Purchase Date | Date of purchase | No | The start date an expiry is counted from when the form fills one in for you (see Warranty Expiry Date) |
| Purchased From | Dealer or channel | No | Not set by the storefront — someone in the back office types it |
| Warranty Period | Coverage duration | No | Filled in for you on opening when this or the expiry date is empty and the item has a Basic Warranty in Doc Item Maintenance — for example 1 year(s) — replacing whatever this box held. Otherwise free text: nothing parses what you type |
| Warranty Expiry Date | Last day of coverage | No | Filled in at the same moment as Purchase Date plus the item’s Basic Warranty years, months and days — with Purchase Date empty it gives no usable date (read, not run). An item with no Basic Warranty leaves both boxes for you to type. The filled-in values are saved on the next SAVE or APPROVE |
The form also shows Created Date — when the registration was submitted — and Remarks, which is copied onto the certificate with everything above except the e-mail and mobile.
Not on the form but on the record: membership_hdr_guid (required, must exist),
entity_hdr_guid (required, must exist), fi_item_guid, fi_item_code, qty, approval_status,
property_json.
Warranty Certificate
The certificate has the same columns as the registration, minus approval_status and plus
prod_registration_guid (required, must exist). The applet has no edit form for it — the record is
composed entirely by the approve action.
Lifecycle and effects
Warranty Admin writes no journal, no stock movement and no document. It maintains product registrations, warranty certificates and registration attachments.
Approval status
The approval status is a plain text value on the registration. The values in use are PENDING (set
by the storefront on submit), APPROVED and DECLINED (set by this applet’s buttons).
What SAVE, APPROVE and DECLINE actually do
| Action | Effect |
|---|---|
| SAVE | Saves the registration. Nothing else |
| APPROVE | Sets the registration APPROVED, saves it, then creates a new ACTIVE warranty certificate for it, copying membership, customer, item, quantity, serial numbers, purchase date, purchased-from, warranty period, expiry date and remarks across. Then a success toast |
| DECLINE | Sets the registration DECLINED and saves it. Nothing else |
No e-mail is sent by either action, although the applet has an Email Template screen and three e-mail settings. If your process depends on customers receiving their certificate automatically, it does not happen; print or export it instead.
Nothing expires a certificate, either. A certificate’s status is the platform’s standard
status column, whose values are ACTIVE, INACTIVE, DELETED, DRAFT, PENDING and so on —
there is no EXPIRED value, and no job compares warranty_expiry_date to today. A certificate
stays ACTIVE for ever unless somebody changes it through the API.
Approving the same registration twice creates a second certificate: nothing checks whether one
already exists for that prod_registration_guid.
Attachments
Attachments are separate rows with their own multipart endpoints. The back office can add and
replace files; so can the customer, signed in to the storefront. Deleting an attachment
is gated by the registration DELETE permission.
Related applets
- RMA (Internal) — where a warranty claim is actually processed. The link is human, not automated: nothing in RMA reads a warranty certificate.
- Doc Item Maintenance — the items being registered, where serial-number tracking is configured, and the Basic Warranty the review form fills the period and expiry from.
- Entity and Customer Maintenance — the owner record every registration must point at.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Save refused: the membership card is missing or not found | Every registration must carry a membership card that resolves in the membership card table. The back-office form has no control for it, so a record that arrived without one can never be saved again | Fix the membership link through the API, or resubmit from the storefront while signed in as a member |
| Save refused: the customer is not found | The customer entity was deleted after the registration was submitted | Restore or repoint the entity |
| Warranty Period and Expiry Date are blank when you open a registration | The storefront submits only membership, entity, item, quantity, serial number, purchase date and PENDING. The form fills the two in from the item’s Basic Warranty, and this item has none | Type them during review, before approving — the certificate copies whatever is there at that moment. To have them filled in next time, tick Basic Warranty and set its years, months and days on the item in Doc Item Maintenance |
| The customer says they never got the certificate e-mail | The applet sends no e-mail on approve or decline | Open the registration’s Warranty Certificates tab, print or export the PDF, and send it yourself |
| Two certificates for one registration | Nothing stops a second certificate for the same registration. This applet offers APPROVE only while a registration is PENDING, so the second one was written outside it | Delete the duplicate through the certificate API — the applet has no delete |
A registration shows APPROVED but has no certificate | APPROVE saves the registration first and writes the certificate second. If the second step fails you see an error toast, and the registration — now APPROVED — no longer offers APPROVE, so the applet cannot retry it | Create the certificate through the certificate API, copying the registration |
An expired warranty still shows as ACTIVE | There is no expiry job and no EXPIRED status | Compare the warranty expiry date yourself; do not rely on the status column |
| Application Settings changes have no effect | The shared settings screen shows the generic document set, and the applet uses none of them | Only Default Selection, Printable Format Settings and Email Template hold keys this applet reads |
| A settings entry you remember (Permission Wizard, Audit Trail, Release Notes) is missing from the gear | The gear lists only the five System Configuration entries; the permission screens exist but have no link | Reach them by URL, or use tenant-level permission administration |
A record shows PERMISSION_DENIED and nothing else | The caller lacks API_TNT_DM_ERP_WRTY_*, and the record is blanked instead of the request failing | Grant the relevant READ/ADMIN/OWNER code |
A registration appears already APPROVED, or has a certificate, that nobody here approved | It did not come through this applet’s APPROVE | Treat a registration’s status and certificate as unverified unless the applet’s audit trail shows it was approved here; reported as a product defect |