Customer Classes

Customer Classes

Purpose and when to use this record

Group customers so pricing, terms, reporting, or operating policies can be applied consistently.

At a glance

• Identify it by: Name.

• Why care: These master records supply defaults and choices to later transactions. Correct duplicates and inactive records before staff build more activity on the wrong record.

Before you begin

You need the Brisk storespermission for the action you are taking on customer classesclasses. asIf parta ofCreate, theEdit, managementor module.Delete This generated referencecontrol is awaitingabsent, workflowdo review.not work around it with another user’s account; ask an administrator to review your role.

Create a recordcustomer class

TheCreate evidencea packetcustomer identifiesclass only when the viewexisting choices do not represent the policy or classification you need. Near-duplicate setup values split reporting and sourcemake locationlater selection harder.

1. Select the business context first.

2. Enter the required identifying and operational values: Name.

3. Review Fallback deliberately; these choices control availability or workflow rather than merely describing the record.

4. Save the customer class, then confirm Name on its detail page before continuing.

After saving: Open Customers, Price Rules, Price Schedule Items, and Price Schedules, plus the remaining screen fields and confirm the customer class appears with the intended label and availability. Keep the old value for thishistorical action.records Confirmwhen user-facingchanging stepsit beforewould approvingsplit or relabel prior reporting.

Delete a customer class

Delete this page.customer class only if it is an unused duplicate or setup mistake. Once other records refer to it, preserve that history and make the value inactive when the screen provides that option.

Before confirming, check for related Customers, Price Rules, Price Schedule Items, Price Schedules, and Stores. Brisk may refuse deletion when another record depends on this one; resolve the duplicate or use the supported correction workflow instead of breaking the trail.

On the confirmation page, verify Name. After confirmation, return to the Customer Classes list and make sure only the intended customer class was removed.

ViewReview recordcustomer class details

The evidence packet identifiesUse the viewdetail page as the shared record of what this customer class currently means. Verify Name, Fallback, and sourceDefault locationMarkup % before relying on it for thisa action.decision.

Confirm

Compare user-facingthe stepscustomer class with its source document or approved setup request before approvingdeciding that it needs correction.

Next check: Open Customers, Price Rules, Price Schedule Items, and Price Schedules, plus the remaining screen fields and confirm the customer class appears with the intended label and availability. Keep the old value for historical records when changing it would split or relabel prior reporting.

Edit an existing customer class

Edit this customer class when the underlying policy or classification changed. First determine whether historical transactions should retain the old value; if so, deactivate the old choice and create a new one.

1. Open the detail page. Compare Name with the supporting document or approved request.

2. Recheck Fallback. These values are most likely to change future transactions, defaults, assignment, pricing, and reporting.

3. Save the change, return to the list, and confirm that the customer class now appears under the expected Name.

After the change: Open Customers, Price Rules, Price Schedule Items, and Price Schedules, plus the remaining screen fields and confirm the customer class appears with the intended label and availability. Keep the old value for historical records when changing it would split or relabel prior reporting.

Find and review recordscustomer classes

The evidence packet identifiesUse the viewCustomer Classes list to find the correct record before opening or changing it. Compare Name. Compare the full identifier rather than relying on a similar name.

• The initial order emphasizes Name. Select a column heading when you need a different comparison.

Open the customer class whose Name match the task. If it is missing, clear the list filters and sourcerecheck locationthe identifying information shown on the screen rather than creating a replacement immediately.

Fields and business rules

Brisk stores 3 user-relevant fields for this action.customer Confirmclass, user-facingincluding steps0 beforelinked-record approvingselections and 0 controlled-choice fields. Create and edit screens may hide calculated or workflow-managed values from this page.full reference.

Editanexistingrecord

The

evidencetheviewandsourcelocation user-facingstepsbeforeapproving user-facingstepsbefore

Field	Required	What packetit identifiescontrols
Name	Yes	Human-readable name for this action.customer Confirmclass.
Fallback	No	If this page. option Deleteis aselected, record item Theprices evidencewill packetautomatically identifiesbe overwritten by price rules associated with this customer class. This should be enabled for your primary customer class to avoid potential pricing issues. Only one class may be configured as the viewpricing fallback.
Default Markup %	No	If the system is enabled to use price rules and sourceallows locationautomatic creation of them, this setting determines how much the markup will be for this action.customer Confirmclass.

approving

What happens next

Open Customers, Price Rules, Price Schedule Items, and Price Schedules, plus the remaining screen fields and confirm the customer class appears with the intended label and availability. Keep the old value for historical records when changing it would split or relabel prior reporting.

Common mistakes and troubleshooting

• The record will not save: Recheck Name and any message beside the field. A required related record may also be inactive or unavailable to your role.

• The values look right but the result is wrong: Compare this page.customer class with the source document or approved setup decision, then check the downstream screen where it is used.