# Cancelling a Service

https://docs.wisecp.com/es/cancelling-a-service

Close a service down and settle the unused part of the period it was sold for in one step, so the cancellation and the money that goes back to the client are never decided separately.

## Opening the Screen

Open the service from **Orders › Services** and pick the **Cancellation** tab: `{admin}/services/detail?id={service}&content=cancel`

One condition decides whether the tab exists: the service must not already be cancelled. Every other service carries it, hosting, server, software and domain alike, and it leaves the strip as soon as the status reads **Cancelled**.

## What Is on the Screen

Three blocks make up the tab and only one is always present. The lower half is a two column row: record left, decision right.

| Block | What it carries | When it appears |
| --- | --- | --- |
| Client Cancellation Request | The client's own request, with its urgency, reason and arrival time. | Only when a cancellation request is recorded for this service. |
| Service card | What is being closed, the billing period with today on it, and the record's coordinates. | Always. |
| Refund Decision | The three settlement options, the consequences and the button behind them. | Only with the service operation privilege. |

### Client Cancellation Request

A strip headed **Client Cancellation Request** opens the tab when the client has asked for the closure. Two badges follow the heading: the urgency, **Immediately** or **End of Period**, and the state, **Pending Approval** or **Approved**. A line under them says what approving would do, naming the due date for an end of period request, and the client's wording sits beside the **Reason** label.

The strip carries no buttons: approving or deleting is done from the red card that sits under the tab names and above the tab contents, and the request shown is always the latest recorded.

### What Is Being Closed

An identity band on a sunken background opens the card: the product name as a link opening in a new tab, with the status badge beside it. The meta line carries the billing cycle and recurring amount (or the amount alone for a product that never renews), the module and its server when there is one, and the domain when the record has one.

### The Billing Period Bar

The middle band is the lead of this screen, because what is cancelled is time already sold. It is headed **Billing Period** with the length on the right in **Days**; the bar fills to the consumed share and a tick marks where the current day falls. The tick carries its **Today** label only when there is room for the word, so very close to either end of the period it stands unlabelled, and on a period that has run out it is not drawn at all. The **Renewal Date** and **Due Date** sit at either end below it, and two figures split the money paid: **Used** and **Refundable**, each with its own day count.

The band rests on the two dates and the recurring amount. A missing date, a zero amount, or a due date not later than the renewal date gives zeros over a full bar; an overdue service runs the bar to full while the figures keep telling the truth.

### Record Facts

The last band identifies the record rather than driving the decision. **Client** links to the owner and adds the company name, **Order** links to the order and prints its order number, not an internal identifier, **Set Up** is the creation date and **Add-ons** counts what is attached; each prints a dash when empty.

### Refund Decision and What Happens

The right column is one decision with three outcomes. Each option under **Refund Decision** carries a title, one explanatory line and the amount it would move in the currency of the service. **No Refund** is selected on opening and always shows zero; **Add to Balance** and **Manual Refund** show the refundable amount and are greyed out when there is nothing to give back.

**What Happens** lists the consequences: the status change to **Cancelled**, then two lines printed only when they apply, the cancel command to the module (only for a module-bound service, carrying an information mark that reads **Can be turned off at the confirmation step.**) and the add-ons going with it (only when the service has any), and last the settlement, rewritten the instant another option is picked. A red **This action cannot be undone.** closes the band and the **Cancel Service** button opens the confirmation window rather than acting.

## Fields

- **Refund Decision**: The three options are one choice and one is always selected. It opens on No Refund, so a cancellation confirmed without touching this block moves no money.
- **No Refund**: The default, priced at zero: **Nothing is paid back for the unused period.** No financial record is written.
- **Add to Balance**: Turns the refundable amount into credit on the client account, converted into that account's own currency. Disabled while the figure is zero.
- **Manual Refund**: Records an expense and leaves the payment to you: **An expense record is created. You send the payment yourself.** Disabled while the figure is zero.
- **Used**: The consumed share of the period in money, with the days under it. Kept neutral: nothing here can act on it.
- **Refundable**: The remaining days at the same daily rate: the ceiling of what the refund options can move, and what decides whether they can be picked.
- **Apply on API**: In the confirmation window, only for a module-bound service and starting on. On, the command travels to the server; off, only the record in this system changes.
- **Cancel Service**: The same wording carries the tab button and the confirming button in the window, so the act is completed only by the second.

## Tasks

### Closing a service with no refund

1. Open the service from **Orders › Services** and pick the **Cancellation** tab.
2. Leave **No Refund** selected in **Refund Decision** and read the **What Happens** list once.
3. Press **Cancel Service**, then confirm with the **Cancel Service** button at the bottom of the **Cancel Service & Refund** window.
4. The page reloads with the status on **Cancelled** and the tab gone; the change reaches the service history and the activity log under your name.

### Giving the unused period back as credit

1. On the **Cancellation** tab, read the **Refundable** figure: it is the amount that will move, and the option is unavailable while it is zero.
2. Pick **Add to Balance**; the last line of **What Happens** restates the amount added to the client balance.
3. Press **Cancel Service** and confirm in the window, where the settlement you picked is restated in one line under **Important Warning**.
4. The amount lands on the client account as credit in that account currency, with an entry naming the service, and is written as an expense too.

### Recording a refund you will pay yourself

1. Pick **Manual Refund** in the **Refund Decision** block.
2. Press **Cancel Service** and confirm in the window that follows.
3. An expense record is created for the refundable amount in the service currency; nothing is added to the client balance.
4. Send the money through your own channel afterwards; that record is the only trace this screen leaves, visible under Cash Management.

### Closing the record without touching the server

1. Press **Cancel Service** on the tab to open the confirmation window.
2. Turn the **Apply on API** switch off. It is only there for a module-bound service, and it starts on.
3. Confirm with the **Cancel Service** button under the switch.
4. The record moves to **Cancelled** and the billing stops, but the account keeps running on the server. Closing it there is now your own job.

## Things to Watch

> **The Cancellation Takes the Whole Record With It**
> 
> Every add-on is cancelled in the same pass and the parent order follows once every service under it is closed. The tab disappears afterwards; putting the record back into service means setting its status again, and for a module-bound service that sends a fresh create command rather than restoring the account that was closed.

> **The API Switch Decides in Both Directions**
> 
> Left on, the cancellation is written only after the server accepts the command: if the provider refuses, the action fails and the status stays. Turned off, the record closes instantly while the account stays alive on the server, the more expensive mistake.

> **The Money Is Recorded, the Client Is Not Told**
> 
> A refund writes an expense entry and the credit option also raises the client balance. Neither sends an email from this screen, so a client who should hear about the closure is told by hand.

> **A Paid Renewal Reopens a Cancelled Service**
> 
> A renewal invoice created for a cancelled service (from the Renewal tab or the client's renewal picker) brings the record back once it is paid: the due date moves forward and the status returns to Active, with a "status changed" entry in the History tab. A module-bound service is parked as In Process while a fresh create command rebuilds the account. Invoices that were still open at the moment of cancellation are closed by the cancellation itself and cannot trigger this.

## Required Privileges

Reading this tab is covered by `SERVICES_LOOK`. The cancellation requires `SERVICES_OPERATION`; without it the decision column is never rendered and a request to the server is refused.

## Related Articles

- [Service Detail Overview](https://docs.wisecp.com/en/service-detail-overview)
- [Cancellation Requests](https://docs.wisecp.com/en/cancellation-requests)
- [Addons of a Service](https://docs.wisecp.com/en/addons-of-a-service)
- [Cash Management](https://docs.wisecp.com/en/cash-management)
- [Client Detail Overview](https://docs.wisecp.com/en/client-detail-overview)
- [Activity Logs](https://docs.wisecp.com/en/action-logs)