> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcuserp.com/llms.txt
> Use this file to discover all available pages before exploring further.
# CS Edge Cases and Advanced Scenarios
> Solutions for rare or complex customer service situations not covered in standard workflows.
These scenarios are less common but critical when they occur. Reach out to your manager if you're unsure how to proceed.
## Canceling an order with serialized items
**Scenario:** Order contains items with unique serial numbers (e.g., equipment, electronics). Customer wants to cancel after items have been picked.
**Solution:**
1. Proceed with the cancellation per [Cancel Order Decision Tree](/support/cs-rep-workflows/cancel-order-decision-tree).
2. During cancellation, the system releases the serial numbers back to your serial inventory as available.
3. Verify in **Products > Serial Numbers** that the released serials are now available (not assigned to another order).
4. Do NOT manually reassign the serials unless they need to be destroyed or repaired.
**GL Impact:** No special GL impact. Standard cancellation GL entries apply.
***
## Canceling an order with drop-ship items
**Scenario:** Order contains items marked as drop-ship (supplier ships directly to customer). Customer cancels the order.
**Solution:**
1. When you cancel the order in Arcus, the system also cancels the auto-generated purchase order to the supplier.
2. A cancellation notification is sent to the supplier (if integrated; otherwise, manual email required).
3. Contact the supplier directly to confirm the PO cancellation, especially if it was already picked/shipped.
4. If the supplier has already shipped to the customer, coordinate a return with the supplier.
**GL Impact:** Both the sales GL (order) and the purchase GL (supplier PO) are reversed.
***
## Refund amount exceeds customer payment
**Scenario:** Customer paid $500 for an order. They return most items. The refund is $750. What do you do?
**What happens:** The system enforces a cap on refund amounts per Rule 23. You cannot issue a refund greater than the original payment.
**Solution:**
1. Issue a refund for the amount paid (\$500, the maximum).
2. Create an account credit for the difference (\$250).
3. Inform customer: "We've refunded your $500 payment and credited your account $250. You can use the \$250 credit on a future order, or I can process it as a separate payment to your original card if preferred."
**GL Impact:** The refund GL entry is for $500 (reversal of original sale). The credit memo is for $250 (additional adjustment).
***
## Two CS reps editing the same order simultaneously
**Scenario:** Two team members open the same order and both make changes (one changes address, the other changes payment method).
**What happens:** Optimistic locking is used. The first rep's change is saved. The second rep's browser shows a **Conflict** warning.
**Solution:**
1. Second rep sees the warning: "This order was modified by \[other rep]. Please refresh and re-apply your changes."
2. Rep clicks **Refresh**.
3. Order reloads with the first rep's changes visible.
4. Rep re-applies their own changes (change payment method on top of the updated address).
5. Rep clicks **Save** again.
**Prevention:** Use the comment/notes feature to coordinate with team members. "I'm updating address to 123 Main St. Please don't edit this order for the next 2 minutes."
***
## Customer with no email address on file
**Scenario:** Order needs to be shipped but the customer account has no email address (rare, legacy data).
**What happens:** Arcus allows orders without emails but skips automated email notifications.
**Solution:**
1. Add an email address to the customer account:
* Click **Accounts** > select customer > **Contacts** tab.
* Click **Add Contact** or edit the primary contact.
* Enter the email address.
* Click **Save**.
2. Now proceed with order confirmation, shipment notification, etc.; emails will be sent.
**Alternative:** If customer truly has no email, use SMS (if configured) or phone call to communicate order status.
***
## Order on credit hold
**Scenario:** Customer's credit limit is $10,000. Current AR is $12,000. Order placed for \$5,000 puts them over limit. Order is on **Credit Hold**.
**What happens:** Order cannot be confirmed until credit is released. Payment or AR reduction must occur first.
**Solution:**
1. **Option A (Payment):** Customer pays $7,000 (brings AR to $5,000, under limit). Order automatically confirms.
2. **Option B (Credit memo):** Apply a credit memo for $7,000 (e.g., return refund). AR drops to $5,000. Order confirms.
3. **Option C (Override):** Manager approves a temporary credit limit increase to \$17,000. Order confirms at normal limit.
4. **Option D (Prepayment):** Customer makes a prepayment of \$5,000 before order is created. No hold triggered.
**GL Impact:** No GL impact from the hold itself. GL impact occurs when payment/credit is applied or when the order is finally confirmed.
***
## Partial-quantity return on a discounted line item
**Scenario:** Customer ordered 100 units at a \$10 discount. They return 30 units. What is their refund?
**Math:** The system allocates the discount proportionally across all units.
* Original: 100 units at $100/unit = $10,000 (before discount).
* Discount: -$10 per unit (or -$1,000 total).
* 30-unit return: 30 x $100 = $3,000, minus 30 x $10 (discount allocation) = $2,700 refund.
**Solution:**
1. You do not calculate this manually.
2. Process the return via [Request Return](/support/returns/request-return-receive-dispose).
3. The system automatically applies the discount allocation.
4. The refund is calculated correctly (\$2,700).
**GL Impact:** Return GL entry records: debit to Sales Returns (and discount return), credit to AR.
***
## Concurrent returns on discounted orders
**Scenario:** Same order, multiple customers (wholesaler reselling). Item has a tiered discount. Customer 1 returns 40 units. Customer 2 returns 20 units. Discount allocation is complex.
**Solution:**
1. Process each return separately via [Request Return](/support/returns/request-return-receive-dispose).
2. The system tracks discount allocation per return, not per customer.
3. Each return is refunded with its proportional discount.
**GL Impact:** Two separate return GL entries, each with the correct discount allocation.
***
## Order with mixed payment methods
**Scenario:** Customer pays for one order with three different methods: $2,000 credit card, $1,500 ACH, \$500 check.
**Solution:**
1. This is not typical in a single order.
2. **Best practice:** Have the customer pay via their primary method. Record a single payment.
3. **If necessary:** Record three separate payments (one per method) against the same order using [Record Payment](/support/orders/record-payment).
4. On each payment, note the method (Card, ACH, Check).
**GL Impact:** Three GL entries, each crediting the respective Cash/Payment account (Stripe Clearing, Bank, Undeposited Funds).
***
## Customer claims duplicate charge
**Scenario:** Same amount charged twice to the same customer on the same day.
**Investigation:**
1. Open the customer **Payments** tab.
2. Check **Payment History** for two identical amounts on the same date.
3. Determine if they are duplicates or legitimate (e.g., two orders placed, two lines of credit, etc.).
**Solution if actual duplicate:**
1. Investigate how it occurred (system bug, accidental retry, double-click on submit).
2. Refund one charge immediately.
3. Document in Arcus notes the reason for the duplicate and refund.
4. Notify customer: "We found a duplicate charge of \$XX. We've issued a refund to your original payment method. Please allow 3-5 business days for the refund to appear."
***
## Tips for edge cases
* **Document everything:** Add notes to the order explaining the resolution.
* **Ask your manager:** If unsure, escalate rather than guessing.
* **Follow the GL:** If the system rejected a GL entry, there's a reason (unbalanced, invalid account, etc.). Investigate before bypassing.
* **Communicate clearly:** Explain to customers why the solution is fair (e.g., "You'll receive a credit for the difference; you can use it on your next order").
* **Review after resolution:** If an edge case happened once, it may happen again. Document the process for your team.
***
## Related articles
Standard cancellation workflows.
Holds, blocks, and other order issues.
Return workflows and refund calculations.
Payment recording and reconciliation.