1. Business Use Case Examples

As part of the standard after-sales process, customers may initiate refund requests due to returns or other reasons. Upon receiving such requests, sales personnel must seek approval from the finance department before processing the refund.

Corresponding to sales revenue, the system records refund amounts as critical operational data, providing valuable insights for business decision-making.

2. Refund Details

2.1 Preset Refund Scenarios

• All:

  • Records where the owner is the current user or their subordinates.

  • Or records where the current user or their subordinates are part of the related team.

  • Or records where the current user, as a finance approver (e.g., holding the “Refund Finance” Role), is responsible for approving refunds submitted by specific Departments (e.g., User A with the “Refund Finance” Role can view all refund records owned by Department B).

  • Or records shared with the current user, their Department, or user group via “Data Permission Management” settings.

  • Or records under “My Responsible Departments.”

• My Responsibilities: Refund owner is the current user.

• Participated by Me: The current user is part of the related team.

• Responsible by My Subordinates: Refund owner is a subordinate of the current user.

• Participated by My Subordinates: A subordinate of the current user is part of the related team.

• Shared With Me: Records shared via “Data Permission Management” with the current user, their Department, or user group.

• My Responsible Departments:

  • The current user is the head of their primary Department.

  • And the record’s related team member belongs to that Department.

  • Note: Whether data visibility includes subordinate Departments depends on “CRM Management > Rule Settings > Basic Settings > Superior’s Data Visibility Scope.”

Notes:
- “CRM Administrators” can view all data.
- Records marked as “Voided” are only visible to “CRM Administrators.”

2.2 Refund Operations

2.2.1 Creating a Refund

• Methods to create a refund:

  • Manual creation:

    • Entry points:

      • [Refund] list page.

      • [Refund] section under the associated [Account] detail page.

      • [Refund] section under the associated [Sales Order] detail page.

  • Import: Refer to Import Guide.

• Additional business notes:

  • Approval workflow: Refunds involve financial transactions and require approval from finance personnel. After creation, the workflow automatically routes to the user with the “Refund Finance” Role for confirmation.

2.2.2 Refund Approval Workflow

• Business context: Refunds involve financial transactions and require finance approval.

• Workflow definition: The system presets the workflow to route refunds from the creator to the “Refund Finance” approver.

• Workflow handling: After saving a refund, pending approvals can be viewed in “CRM Alerts > Pending Refund Confirmations” or directly in the refund detail page.

  • Approve: Completes the approval process.

  • Reject: Marks the refund as “Rejected,” requiring modifications before resubmission.

• Notes:

  • Only refunds with “Refunded” status are included in “Total Refund Amount” calculations.

  • Refunds can be referenced by related objects regardless of approval status.

2.2.3 General Refund Operations

• List page operations (see Common List Operations)

• Adding sales records (see Sales Records)

• Standard actions: reassigning ownership, adding Related Teams, printing, importing/exporting, editing, voiding, deleting (see Common Operations)

• Collaboration tools: forwarding, Calendar events, reminders, calls, emails (see Common Operations)