Overweight Refund UI

Frontend behavior for accepting or rejecting overweight refund tickets from the Overweights screen, including the optional editable refund amount.

Where It Lives

The Overweights screen (table and modals) is the only UI for this flow. There is no dedicated “Overweight Refund” route; the refund accept/reject is done from the same table where overweight records are listed.

Accept Modal (single and mass)

When the user chooses to accept an overweight refund (single row or mass selection):

• A confirmation modal is shown (e.g. Swal or similar).
• Required: Comment field (review comment).
• Optional: “Monto a reembolsar” (refund amount):
  • Single action: Pre-filled with the row’s surcharge amount; user can edit.
  • Mass action: One global editable amount (e.g. pre-filled with the first selected row’s amount or left empty so the backend uses each row’s surcharge amount).

Payload Sent

On confirm, the frontend sends to PUT /overweights/ticket/:id (or the equivalent tickets/overweights API):

• ticket_id, status_id, comments (required).
• approved_amount (optional). Omitted when the field is empty so the backend keeps current behavior (use surcharge amount per row).

Validation (client-side, optional)

If “Monto a reembolsar” is filled:

• approved_amount must be > 0 and ≤ the displayed surcharge amount (per row for single; for mass, same rule for the global amount if used).
• Show a validation message and block confirm if invalid. Backend remains the source of truth.

User Flows

1. Accept with default amount — User leaves “Monto a reembolsar” empty and confirms. Backend uses the surcharge amount. Compensation and notification are created as usual.
2. Accept with edited amount — User enters a lower amount in “Monto a reembolsar” and confirms. Backend validates and uses that amount for balance, surcharge, and compensation; notification is sent.
3. Reject — No compensation, no notification, no refund amount; only ticket status and comment/history are updated.

Components and Stores

• Overweights table — Main view that lists overweight records and triggers accept/reject (e.g. Table.vue or equivalent in the overweights/contacts-carriers or overweights area).
• API — api.tickets.updateStatus (or direct call to PUT /overweights/ticket/:id) with payload including optional approved_amount.