Catalog and customer services

Catalog items and customer service instances

The catalog stores commercial templates prepared by the ISP: offer name, type, reference price, billing cycle, tax rate, and required configuration. Assigning one of these templates to a customer creates a service instance.

The instance stores the actual values for that customer, including operational status, address, quantity, price, discount, tax, payment mode, contract, and module-specific data.

Configure the customer instance

A customer service instance combines the selected catalog offer with customer-specific cycle, quantity, recurring price, VAT, payment method, address, dates, and operational state. Review every inherited default and change only values justified by the customer agreement.

A newly created instance can remain Processing until technical and administrative prerequisites are complete. Commercial creation does not equal activation, and billing must not start before the intended readiness conditions have been met.

Open customer services

From the customer record select Services. Counters separate Processing, Active, Suspended, Billing suspended, and Terminated services. The page also provides an estimated annual value and cycle summaries.

The table includes instance code, service, address, status, fee, cycle, next invoice, payment mode and method, quantity, net amount, discount, VAT, total, contract, and relevant dates.

Create a new service

Select Create new service. You can choose a bundle or add one or more services using tabs. Each tab represents a service that must be configured before saving.

Select an offer that matches both the commercial agreement and available technical prerequisites.

Module prerequisites and validation

The first attempt used 1 Gbps Fiber Subscription. Its module required a Radius account. Because no account was available for the customer, ISP Billing correctly prevented saving.

This is not a system error and must not be bypassed. Create or attach the required prerequisite, or select a service compatible with the real use case. The guide therefore continued with Example Subscription.

Payment mode

The form can offer Credit card (Stripe), Bank transfer, Card debit (Stripe), Direct debit (SEPA), SEPA debit (Stripe), Cash, Postal payment slip, and other methods configured by the ISP.

A listed mode does not mean that the customer has already authorized automatic collection. Saved cards, mandates, provider-customer association, or additional setup may still be required. Verify the method in the customer profile and payment gateway before enabling automated billing.

Service address

Attach the correct service address and enable Show this address on invoices when the installation location must appear in documents. Use Add a new address when the service is delivered at another location.

Give additional addresses recognizable labels and verify street, number, postcode, city, province, country, and any coordinates or coverage information required by the selected service.

Cycle, quantity, renewals, and activation fee

Cycle sets recurrence. Available values depend on the offer; the example is Monthly. A maximum renewal value of 0 means unlimited renewals. Quantity multiplies the single amount.

The optional Activation price is separate from the recurring fee. Verify whether it should be billed once and which tax treatment applies.

Price, discount, and VAT

The interface shows the single net amount, VAT rate, and recurring gross amount. The documented case uses €40.00 net, €8.80 VAT at 22%, and a €48.80 recurring total.

The discount applies to the single net amount. Recalculate after changes and verify net and gross values together with quantity and VAT.

Save the service

1. Select the correct service.
2. Set payment mode and address.
3. Review cycle, renewals, quantity, and activation fee.
4. Verify net amount, VAT, total, and discount.
5. Complete module-specific data.
6. Select Save and continue.
7. Resolve validation messages without bypassing them.

ISP Billing displayed Service activated successfully and returned to the list. The new instance received code #51459 and Processing status.

Read the list and summaries

The Services counter changed from 0 to 1 and the summary reported one Processing service. The annual estimate is €585.60, equal to twelve monthly charges of €48.80.

The bottom summary separates net, VAT, and gross totals by status and billing cycle.

Service details and status

Open View to access instance details. The header shows code, name, status, contract expiration, contract reference, service group, and reference account. The documented service states that it has never been activated.

Activate service explicitly activates both the service and billing. Use it only after provisioning, technical checks, effective date, and contract terms are complete.

Service billing rules

Details allow you to review revenue account, cycle, quantity, discount, activation amount, net price, tax rate, recurring total, and payment mode.

Additional options include prorated billing, billing in arrears, billing group, contract reference, and service address. These affect when and how charges are generated and must follow the ISP’s agreement and accounting rules.

Additional detail functions

The page can associate a referrer and bonuses, save a migration code, assign a reseller, link products, check coverage, and manage contract or service-group references.

Delete service is a permanent deletion and is different from suspension or termination. Do not use deletion to represent a commercial termination that must remain in history.

Statuses and operational consequences

• Processing: created but not yet operational; the Dashboard warns that it will not be billed.
• Active: operational and billed according to its rules.
• Billing suspended: an administrative billing block.
• Suspended: service delivery is suspended according to the configured workflow.
• Terminated: retains the history of a completed service.

Read the action description and billing consequence before changing status.

Configure a rechargeable catalog service

Open Services module → Settings → Services and create a dedicated model. Enter a customer-facing name and an internal code for invoice lines. Keep the catalog item Active; enable reseller or bundle availability only when those sales processes actually use it.

A linked module is unnecessary for a purely administrative recharge. Selecting Radius, VoIP, or another module may make the corresponding technical account mandatory during assignment. The verified model therefore used No selection. Enable invoice-period display when the purchased date range must appear on the document.

Payment type, VAT, and purchasable cuts

Under Pricing settings, select Rechargeable, choose the VAT rate, and enable only the billing cycles customers are allowed to buy. Each active cycle becomes a separate cut in the Customer Area.

The example exposes only a monthly cut at €10.00 net and 22% VAT, producing a €12.20 customer price. A disabled cycle is not purchasable. A reseller percentage of -1 inherits the reseller default, while 0 disables it; verify this before partner sales are enabled.

Assign and activate the customer recharge

From the customer record select Services → Create new service, choose the rechargeable model, and set a payment mode supported by the generated document. The new instance begins in Processing with a current value of €0.00: the catalog price is the purchasable cut, not an amount already accrued.

Open the instance and activate it only when the customer should be able to recharge. The administrative panel then shows duration, net and gross price, VAT, payment mode, and period dates. Generate recharge creates the document administratively; Continue in Customer Area opens the self-service path.

Recharge dates and generated documents

The first purchase starts on the chosen date and ends at the end of its cut. Once a paid period exists, the next recharge must start on the following day; the customer cannot overlap periods or backdate the purchase. The verified 19 August–18 September 2026 period caused 19 September–18 October to be proposed next.

Confirmation first creates a recharge proforma. A pending recharge document must be completed or cancelled before another is generated. Creating the proforma alone does not extend service: the payment must be recorded and the service end date must change.

General module settings

Before building the catalog, open Services module → Settings → General. Review the shared billing, suspension, termination, and alert rules because they can affect many customer instances. Record who may change them and validate every change on a sample service.

Service types and categories

Types classify the technical or commercial nature of a service and may determine which data, provider, provisioning path, or controls are required. Categories organize the catalog for operators and help separate connectivity, voice, managed services, equipment, and other offer families.

Create stable, clearly named, non-duplicated classifications before building offers. Review every referenced catalog item and customer instance before renaming, merging, or deleting them; a classification change can alter filters and operator interpretation without changing the underlying service.

Service bundles

A bundle groups several catalog services into one commercial proposal while preserving the configuration needs of each component. Define a clear bundle name and select only compatible items whose linked modules, prices, VAT rates, cycles, quantities, addresses, and prerequisites have already been configured.

During customer assignment, complete every component tab rather than assuming the bundle supplies missing technical data automatically. Verify the combined recurring and one-off price, discount behavior, payment method, activation dates, billing alignment, provisioning result, and how suspension or termination of one component affects the others.

Automation settings and configuration test

The linked module and its fields define technical automation. Configure the provider first, attach only the required fields, and use Test automation in the sample environment before publishing the offer. A successful catalog test does not replace checking the customer instance, remote account, profile, address, credentials, and identifiers.

Bulk wholesale-availability updates can change many sellable offers. Apply narrow filters and review the affected count first.

Inventory, forecasts, and exports

The Instances page is the cross-customer service inventory. Filters and aggregates cover status, offer, cycle, payment mode, amounts, and upcoming dates. Revenue forecasts and next-billing summaries are management aids; reconcile services that are processing, suspended, terminated, or excluded from billing.

Exports are prepared in the background as temporary files. Preserve the filters and verify row count and filename before downloading.

Margins and unbilled services

Margin reports analyze revenue and cost by supplier, service, and instance. Validate sales price, wholesale cost, quantity, discount, VAT, and period before using the result commercially.

The Unbilled services view highlights instances that did not produce the expected document. Check status, activation date, next invoice, billing suspension, cycle, renewals, group, and already-prepared documents. Do not create a manual invoice until the cause is known.

Suspension and termination widgets

Upcoming-suspension and upcoming-termination widgets are control queues. Open each service and verify contract, collections, and tickets before the deadline. After processing, reconcile the local status, technical provider, and communications; appearing in a widget does not prove that a remote action succeeded.

Scheduled service lifecycle

Scheduled processes cover invoice generation, suspension, Radius suspension retries, termination, termination-ticket creation, and rechargeable-expiration alerts. Configure the required schedule and monitor outcomes, logs, and working queues.

A Radius retry only completes a failed technical action. A termination ticket creates operator work and is not proof of decommissioning. A recharge alert warns the customer but never extends the period without a valid payment.

Catalog and instance APIs

APIs expose authorized catalog reads and service-instance operations, including the supported simplified creation flow. Use least-privilege keys, same-ISP identifiers, and catalog-consistent values.

Test duplicate requests, missing fields, unknown customers or services, and insufficient permission. Store the returned identifier and make the calling system idempotent because retrying after a timeout can otherwise create duplicate commercial instances.

Best practices and checklist

• Start from the correct customer record
• Select an offer matching the contract
• Complete module-specific technical prerequisites
• Leave an unnecessary technical module unlinked for a simple recharge
• Enable only the cuts actually sold
• Verify payment mode and authorization
• Review cycle, quantity, renewals, and activation fee
• Recalculate net, VAT, discount, and total
• Activate only after operational verification
• Confirm both the paid document and the new recharge end date
• Use suspension or termination instead of deletion when history must be preserved