Upgrades and Downgrades

88 Aufrufe Markdown

Watch every plan change in one queue, so a request waiting for payment, a downgrade parked until the end of the term and a change whose module step failed are all visible and actionable from a single list instead of being hunted service by service.

Reaching the Screen

Go to Orders › Upgrades/Downgrades: {admin}/services/updowngrades

The menu entry carries a counter of the requests still open: those waiting for approval and those being applied. Scheduled and completed requests are not counted, so the number is a work queue and not a total. It is also a raw record count: a request whose client record has since been deleted keeps adding to it while the list leaves that row out entirely, so the badge can read higher than the rows in front of you and no filter closes the gap. The page opens for staff who may view services or operate on them, and its title reads Upgrades & Downgrades.

Where the Requests Come From

Nothing is created here. A row appears when a plan change is submitted elsewhere: from the Upgrade/Downgrade tab of a service, from the customer's own panel, or through the administration API. This list is the shared queue those three roads feed, so a request raised by a customer and one raised by an operator are handled with the same actions.

The state a row is born with follows the way it was submitted. A downgrade scheduled for the end of the billing period starts as Scheduled; everything else starts as Pending Approval and, when an unpaid invoice was generated with it, stays there until that invoice is paid. A change submitted for immediate application goes straight to In Progress.

What Is on the Screen

One toolbar and one table. There is no add button and no form: the screen exists to watch, approve, retry and clean up. Rows are ordered by state, so everything still needing a decision floats to the top.

Column	What it shows	Empty or hidden when
Tick box	Selects the row for the bulk actions.	Dropped without operate rights on services.
Client	The customer, with the company underneath.	Linked to the client record only with view rights on clients.
Old Service	Today's plan, with its price and billing cycle.	No price line when no amount was stored.
New Service	The plan it moves to, with the new price and cycle.	A cycle-only change repeats the same plan.
Difference	The amount to collect, or to return on a downgrade with a minus sign.	Always filled; no money reads as zero.
Type	Upgrade or Downgrade.	Always filled.
Invoice	The linked invoice number and its payment state.	A dash when submitted without an invoice.
Status	Where the request stands in its lifecycle.	Always filled.
Row menu	Per-row actions, behind the three-dot button.	No header; contents follow state and permission.

Three of those columns are also ways out of the list: either plan name opens the service's own detail page, and the invoice number opens the invoice, each in a new tab.

Apply to Selected sits on the left with Approve and Delete. Two dropdowns follow on the right, Type and Status, each narrowing the list as soon as a value is chosen. The table brings its own Search... box and a download button drawn as a downward arrow. On a narrow screen the strip folds behind Show Options under the page title.

The dropdowns are also read from the address on page load, so a link carrying a filter opens the list narrowed. The download button is rendered only for staff whose permissions include Download Listed Data (CSV / JSON / XML).

The States a Request Passes Through

Pending ApprovalRecorded, nothing sent anywhere yet. It waits for the linked invoice to be paid or for an operator to approve it.

ScheduledA downgrade parked until the service reaches its due date. The automation job takes it then, settles the refund and starts applying it.

In ProgressHanded to the automation job; the module step runs on the next tick, normally within a minute.

CompletedWritten onto the service: product, price, cycle, renewal date and due date now hold the new values.

FailedNot a state of its own. A request still In Progress but carrying a message from its last attempt wears this badge, so a stuck row is visible while scanning.

CancelledA scheduled downgrade that was called off, from the service detail screen, by the client, or through the API. It stays in the list as a record; nothing is charged or applied.

Status Column

When the last attempt returned a message the badge becomes a button: click it and a panel titled Status Message opens with the text the module or the engine returned, and clicking outside closes it again. This is the only place that message appears in the list. Beside it, for staff who may operate on services and only while the request is In Progress, sits a circular-arrow button with the tooltip Retry. Retrying cannot pay a downgrade refund twice: the refund is stamped as settled the first time and never repeated.

The three-dot button at the end of a row opens its actions, and which appear depends on the state and on the permission.

Approve only while the request is Pending Approval or Scheduled, and only for staff who may operate on services.
Mark as Completed only while the request is In Progress, under the same permission.
View always, opening the read-only window below.
Delete for staff who may operate on services.

Detail Window

View opens a window titled Details. A four-part strip repeats Type, Difference, Invoice and Status; the customer is named below it; below that the two plans stand side by side with their category and price per cycle. Its footer carries Delete and Approve for every request that is not yet Completed, including one already In Progress, where the row menu deliberately hides Approve.

Fields

Apply to SelectedNot a stored setting. Approve or Delete opens the confirmation window for the rows currently ticked, then the box returns to its placeholder. With no row ticked nothing happens. Rendered only for staff who may operate on services.

TypeEmpty by default, so both directions are listed. Upgrade and Downgrade are the only values.

StatusEmpty by default. Offers Pending Approval, In Progress, Scheduled, Completed and Cancelled. There is no entry for a failed attempt: a failure is stored as In Progress and matched by that value.

Search...Empty by default. Matches the customer name, e-mail and company, the linked invoice number, and the plan names stored on the request.

ExportDownloads the list as CSV, JSON or XML. The file follows the filters, search and sort in force and ignores paging, so it holds the whole filtered set.

Tasks

Approving a request

Set the Status dropdown above the table to Pending Approval.
Open the three-dot menu at the end of the row and choose Approve.
Check the service and customer named at the top of the Approve Selected window, then press Approve in its footer.
The list reloads and the row moves to In Progress, with the notice Queued for processing. The change will be applied within a few minutes.

Approving several requests at once

Tick the box at the start of each row, or use the box in the column header to take the whole page.
Open the Apply to Selected list above the table and choose Approve.
Press Approve in the footer of the Approve Selected window. Requests already Completed are skipped in silence; the rest move to In Progress and the list reloads.

Retrying a change that failed

Set the Status dropdown to In Progress and look for the red Failed badge.
Click the badge, read Status Message, and decide whether the cause has been removed.
Press the circular-arrow Retry button beside the badge. The message is cleared, the request is queued again and the list reloads with the badge back to In Progress.

Closing a change by hand

Open the three-dot menu of an In Progress request and choose Mark as Completed.
Read the warning in the Mark Upgrade/Downgrade as Completed window: the contract fields of the service are rewritten and nothing is sent to a module.
Press Mark as Completed in that window's footer. The row becomes Completed, the service carries the new product, price, cycle and due date, and the list reloads.

Removing a request from the queue

Open the three-dot menu and choose Delete, or tick several rows and pick Delete in Apply to Selected.
Read the two notes in the Delete Request window, titled Delete Selected when more than one row is taken: the records go for good, and a linked unpaid invoice is cancelled with them.
Press Delete in the footer. The rows leave the list without a page reload and any automation job still queued for them is cancelled.

Things to Watch

Deleting a request does not undo it

A request already applied has changed the service. Removing its row removes only the record: the plan, the price and the due date stay where the change left them, a linked unpaid invoice is cancelled on the way out and any queued automation job is dropped. None of that can be restored, and the only way back is a fresh change in the opposite direction.

Mark as Completed skips the module step

It writes the new product, price, cycle and due date onto the service and closes the request, but sends nothing to the server or the provider. Use it only when the account has already been rebuilt outside the panel; on an untouched account it leaves the billing record and the real service describing two different things.

Approving a scheduled downgrade brings it forward

The downgrade was scheduled so the customer could use the term already paid for. Approving it applies it now: the refund is settled at that moment and the remaining days of the term are consumed by the change instead of being served.

Required Privileges

Opening the list needs SERVICES_LOOK or SERVICES_OPERATION, and so does the detail window. Approving, retrying, marking completed and deleting all need SERVICES_OPERATION, which also decides whether the tick boxes and Apply to Selected are rendered at all.

War das hilfreich?

Vielen Dank für Ihre Rückmeldung!

Brauchen Sie weitere Hilfe?

Unser Support-Team ist rund um die Uhr für Sie da, wenn Sie oben nicht fündig werden.

Kontakt aufnehmen Ticket eröffnen