Wholesale: catalog, customers, orders, and price lists
Operate as wholesale customer or provider, publish services and networks, and manage orders, options, tickets, and billing.
Last updated: 2026-09-07
Marketplace B2B: activation and permissions
Marketplace B2B lets enabled ISPs browse providers, request a commercial relationship and manage their own orders and tickets. Wholesale is the provider module for publishing offers, enabling customers and managing received orders. An ISP may have either module or both.
Open Marketplace B2B in the menu. The module is free. A full administrator can open Settings → Telecommunications → Marketplace B2B and select Activate module. Once active, Open Marketplace opens the catalog; Deactivate removes access while retaining data. SuperAdmin activation is also available. The user role needs Marketplace B2B read permission; sending requests, orders, options and messages also requires write permission. Publishing your own offers requires Wholesale.
If the menu entry is missing, check module activation and role permissions. If no providers appear, ask the supplier to check profile publication and visibility. B2B does not automatically approve commercial relationships: price lists and orders remain subject to provider authorization. For example, an ISP with B2B alone can order authorized services from a provider without publishing its own catalog.
Disabling B2B blocks customer features without deleting relationships, orders or tickets. An ISP with Wholesale alone retains its own provider features; browsing other operators also requires B2B activation.
Two distinct roles
The provider publishes a catalog, enables customers, receives orders, and manages progress. The customer browses enabled offers, places orders, and follows tickets and states. Every query and action must respect both tenants and relationship role.
Dashboard and starting sequence
The Orders page breadcrumb shows the configured Wholesale name; if it is missing or empty, the ISP name is used.
The dashboard changes perspective by role. Providers see received-order summaries, active or pending customers, and recent work; customers see their orders and related providers. Counters are navigation aids, not a substitute for filtered lists.
Configure identity, visibility, notifications, services, and price lists first; then approve one customer and simulate a complete order. This makes an empty KPI meaningful rather than a symptom of incomplete setup.
Provider identity and notifications
Configure provider name, payoff, color, logo, SMTP account, and order recipients. These values build the customer-facing wholesale experience and must match the commercial agreement.
General setup, step by step
Open Settings → Wholesale → General. Enter a recognizable trading name, short payoff, primary colour, and a logo that remains clear in documents; very wide images are optimized to a maximum width of 600 pixels. The Wholesale description should explain served networks, delivery model, prerequisites, and contacts without replacing contractual terms.
Select a working SMTP account and enable email, SMS, WhatsApp, and ISP App independently. Enabling a switch does not configure the underlying channel or create valid recipients. Finally select the department for automatic order tickets; with no department selected, that automatic ticket is not created.
Provider visibility and public catalog
To appear in Marketplace B2B, first save all required profile fields in General: Name, Payoff, Primary color, Description and Logo. If any field is missing, the profile is hidden even from selected ISPs. The Visibility page lists missing fields, links to General and marks the profile as incomplete.
The recipient ISP must have Marketplace B2B enabled; the module is free and can be activated from Settings. The public catalog is optional: it is not required to appear in the marketplace and does not allow ordering before the commercial relationship is approved.
Under Settings → Wholesale → Visibility, publish the provider only after catalog, contacts, and handling process are ready. All exposes it to eligible ISPs; Selected ISPs restricts discovery to the comma-separated ISP IDs entered. Review every ID before saving.
Public catalog is independent from provider visibility. Enable it only for offers and prices intended for unauthenticated consultation; otherwise keep the catalog inside the authorized customer relationship and verify it with an eligible customer account.
Status templates and channels
Message Templates provides one template per order status and supported channel. Email accepts formatted content, SMS and WhatsApp should remain concise, and ISP App uses a title and body. A template does not make an unconfigured channel operational.
Available tags include client name, customer/company name, service, order number, order details, previous status, new status, and email signature. Use only listed tags, save channels separately, and test the rendered message with fictitious data for length, signature, and sensitive content.
Publish a service
Set visibility, technologies, prices/cycles, and access networks: Any, proprietary, FiberCop, OpenFiber, Fastweb, OPNet, or Pianeta Fibra. Choosing Any normalizes the network rule but never bypasses technology compatibility.
Configure per-order-type fields as text, number, date, selection, checkbox, or protected PDF/JPG/PNG upload up to 10 MB. Use explanatory labels, require only necessary evidence, and test Activation, Migration, and Termination separately.
Relationship requests and customer states
A customer ISP finds a visible provider and submits a relationship request. The provider reviews it in customers/requests and can move it from Pending to Active or Rejected; an active relationship may be Disabled and later reactivated. Validated transitions remain in history with operator and date.
Activation may create the ticket selected in settings. Verify organization, requesting account, commercial agreement, and service scope before approval. Disabling access hides the usable catalog but does not erase existing orders or history.
Customers and access
Approve the relationship, associate CRM identity where required, and grant services or a shared price list. A relationship alone does not expose every offer. Without an assigned price list, historical per-customer access remains effective.
Customer detail, CRM, and service scope
The customer ISP detail combines Wholesale profile, relationship state, accounts, order summary, recent activity, and CRM link. Search for an existing CRM record before creating one, associate only the correct legal entity, and remove an incorrect link without deleting the Wholesale relationship.
Customer Services assigns a price list or manages individual offers. Toggling access changes only the provider-customer scope, not the provider’s global catalog. After every change, inspect the catalog from the customer side to confirm what is actually orderable.
Catalog and filters
The catalog displays only relationship-, visibility-, technology-, and network-compatible offers. Search, category, technology, network, and billing filters are derived from those visible offers. Do not bypass compatibility through a direct URL.
Create an order
Select service, order type, customer, installation address, and billing cycle. Provisioning-prefilled orders still let the operator choose Activation or Migration. Complete dynamic fields, protected files, compatible options, and provider notes before submission.
Options and billing
An option may support all primary services or a selected set and appears only when enabled for that customer. Primary and option services create separate billing instances with WH-#{order} reference and independent progress.
Provider handling and state
The provider reviews technical data, files, notes, and options, creates the in-progress billing instance, and communicates state. Rejection/cancellation applies before service creation. Internal state, customer-facing state, and message must remain coherent.
Order types and state meaning
Activation requests a new resource, Migration transfers an existing one, and Termination requests closure. Do not use one type as a shortcut for another because required fields, evidence, and commercial consequences differ.
Order states include Pending request, Processing, Completed, Executed, Rejected, and Terminated/Cancelled according to order type. Update them only after the real event, communicate a clear explanation, and confirm that billing services and option states agree.
Order tickets and history
Order tickets keep customer and provider communication inside the authorized order context. Open or continue the linked ticket rather than moving technical decisions to unrelated conversations.
Compare ticket chronology with order history, operator changes, attachments, status messages, and billing-service state. A ticket reply can explain progress but does not change the provider order state unless the supported workflow performs that action explicitly.
Provisioning and coverage
Coverage-driven provisioning proposes a wholesale provider only when the active relationship, access network, technology, customer eligibility, and published offer all match, and no conflicting active order already exists.
Review the installation address, coverage evidence, service, billing cycle, activation or migration type, required custom fields, and options before creating the order. A suggested provider is not proof of reservation, acceptance, or technical delivery.
Tickets, attachments, and automated communication
From an order, users can open a dedicated ticket, browse linked tickets, and continue the conversation. Subject, department, message, attachments, and recipients must stay within that order. Technical custom-field uploads and ticket attachments serve different purposes.
A status change or provider message may create or append to the order ticket and notify configured recipients. Review the status template, linked CRM contact, authorized accounts, and CC addresses before sending. Order history, ticket history, and billing-service state should tell the same story.
Checklist
- Configure provider identity and alerts
- Publish correct networks and technologies
- Configure order fields/files
- Approve customer relationship
- Assign price list or access
- Verify visible catalog
- Review service, address, and cycle
- Select compatible options
- Create primary and option instances
- Update state and message
- Use order tickets