Ana içeriğe atla
Ürün ayrıntıları İngilizce olarak görüntülenir. Çeviriler yakında gelecek.
Telecom Billing & OSS Operations for ERPNext — A build-to-order ERPNext application that adds telecom plan and subscription m — 1/1Örnek önizleme

A build-to-order ERPNext application that adds telecom plan and subscription management,

usage rating, service provisioning workflows, trouble-ticket operations and dealer collection channels on top of your existing ERPNext accounting.

ECOSIRE scopes, builds, installs and supports it for your Frappe/ERPNext v15 or v16 site.

Telecom Billing & OSS Operations for ERPNext nedir?

A build-to-order ERPNext application that adds telecom plan and subscription management, usage rating, service provisioning workflows, trouble-ticket operations and dealer collection channels on top of your existing ERPNext accounting. ECOSIRE scopes, builds, installs and supports it for your Frappe/ERPNext v15 or v16 site. Built to order by ECOSIRE for ERPNext v15, v16 — indicative price from $999.00 USD; request a quote for a scoped proposal.

Temel Özellikler

Custom `Telecom Plan` DocType with rental, included quota, tiered overage tariff bands, contract term, notice period and ERPNext tax template linkage
`Service Subscription` DocType binding Customer, plan, service address and real network identifiers — circuit ID, ONU/CPE serial, MSISDN, RADIUS username
Usage rating engine ingesting CDR, RADIUS accounting or NetFlow exports into a `Usage Record` ledger, deduplicated by source record ID so a re-import can never double-bill
Nightly rating job registered in `scheduler_events` that aggregates unrated usage and applies tariff bands as tested Python, not database-resident Server Scripts
Billing run generating standard ERPNext Sales Invoices through the framework API, preserving tax templates, cost centers and accounting dimensions so the GL stays authoritative
Proration for mid-cycle activation, plan upgrade or downgrade, suspension and reconnection, with a computed audit line on the invoice explaining every partial charge
`Service Order` provisioning workflow (new connection, upgrade, relocation, suspension, disconnection) built on Frappe Workflow with role-gated state transitions
`hooks.py` doc events dispatching provisioning calls to your OLT, BNG or RADIUS as queued background jobs with retry, timeout handling and timeline logging
Policy-driven dunning ladder — grace, throttle, suspend, reconnect — executed by a scheduler job against overdue balances, with every state change recorded on the subscription
Trouble-ticket operations extending the ERPNext Issue DocType with fault category, affected service instance, outage window, SLA response and resolution clocks, and escalation
Automatic outage credit notes: an SLA-breaching ticket raises a pre-approved ERPNext Credit Note against the interrupted subscription for the qualifying downtime
Dealer and collection channel management via `Dealer` and `Collection Receipt` DocTypes, commission rules, running dealer ledger and reconciliation against Payment Entries
Server-side row-level isolation for dealers using role profiles, User Permissions and a `permission_query_conditions` hook, enforced on list views, reports and API queries alike
Whitelisted REST endpoints for NMS usage push, mobile collection apps and payment-aggregator callbacks, with API-key auth and idempotent request handling
Client Scripts for counter and field staff — serial/barcode capture, one-click reconnect, live balance and last-payment display directly on the subscription form
Operational reports: ARPU by plan, churn with disconnection reasons, unrated usage backlog, aged subscriber receivables, dealer commission statement and SLA compliance

Siparişe özel, sizin için baştan sona

Kendiniz kurmanıza gerek yok — ECOSIRE tarafından geliştirilen, kurulan ve desteklenen çalışır bir uygulama.

  1. 1

    Sipariş verirsiniz

    Tek seferlik geliştirme fiyatıyla başlayın. Kapsamı başlangıçta sizinle birlikte belirleriz.

  2. 2

    Geliştirir ve kurarız

    ECOSIRE, ERPNext ortamınızda geliştirir, yapılandırır ve kurar.

  3. 3

    Yayına alma + destek

    Yaklaşık bir iş haftasında yayına alırsınız; canlıya geçiş sonrası iki hafta destek dahildir. Teslim ettiğimiz koddaki hatalar ücretsiz düzeltilir.

Teknik Özellikler

ERPNext Uyumluluğu
—
Lisans
Lisansın doğrulanması gerekiyor
Python Gereksinimi
Python 3.10+
Veritabanı
MariaDB 10.6+

Bu Ürün Hakkında

An ISP or telecom operator runs two businesses at once: a network that must be provisioned, monitored and repaired, and a subscription book that must be rated, invoiced and collected every month across thousands of accounts. ERPNext already does the second half well at the accounting layer — Customer, Sales Invoice, Payment Entry, the GL, and the built-in Subscription DocType handle recurring billing against a Subscription Plan. Where ERPNext runs out of road is everything specific to telecom: it has no concept of a service instance tied to a circuit ID, ONU serial or MSISDN; no usage rating engine that turns CDRs or RADIUS accounting records into billable quantities; no proration rules for mid-cycle upgrades, suspensions and reconnections; no provisioning state machine that separates "invoice raised" from "service actually live on the network"; and no dealer or franchise ledger for the collection channels most regional operators depend on. Operators usually bridge that gap with spreadsheets, a separate billing box that never reconciles to the GL, and a WhatsApp group standing in for trouble-ticket operations.

ECOSIRE builds this as a first-class Frappe application — its own app in apps/, with a telecom module, versioned fixtures and a clean hooks.py — never as a pile of Customize Form overrides that break on the next bench update. The core model introduces a Telecom Plan DocType (rental, included quota, tiered overage tariff bands, contract term, tax template) and a Service Subscription DocType linking Customer, plan, service address and the network identifiers your OSS actually uses. Rating runs off a Usage Record ledger fed either by scheduled import of CDR/RADIUS/NetFlow exports or by an authenticated push from your NMS into a @frappe.whitelist() endpoint. A nightly job registered in scheduler_events aggregates unrated usage, applies the plan's tariff bands in testable Python — not a Server Script buried in the database — and stamps rated quantities back onto the subscription. The billing run then generates ERPNext Sales Invoices through the framework API, so tax templates, cost centers, accounting dimensions and the GL behave exactly as your accountants expect; proration, outage credit notes and one-off installation charges all post as ordinary ERPNext documents you can audit.

Operations sit on the same spine. A Service Order DocType covers new connection, upgrade, relocation, suspension and disconnection, driven by a Frappe Workflow with role-gated transitions and on_submit / on_update_after_submit doc events in hooks.py that fire the real provisioning action — a webhook to your OLT or BNG controller, a RADIUS profile change, or a queued background job with retry and a written audit trail on the document timeline. Dunning becomes policy rather than memory: a scheduler job walks overdue subscriptions through grace, throttle, suspend and reconnect, so nobody is suspended by a manual mistake or left live after ninety unpaid days. Trouble tickets extend the ERPNext Issue DocType with fault category, affected service instance, outage window and SLA clocks, so a fault is linked to the subscription it interrupted and can justify a credit note automatically. Dealer and collection channels get Dealer and Collection Receipt DocTypes with commission rules, a running ledger, and a permission model — role profiles plus User Permissions and, where tenancy demands it, a permission_query_conditions hook — so a dealer sees only their own subscribers on the desk, the portal and the REST API alike. Client Scripts add the field conveniences: serial and barcode capture, one-click reconnect, live balance on the subscription form.

Every integration point is designed to be operated, not merely demonstrated. The Frappe REST API plus a small set of whitelisted methods gives your NMS, payment aggregator and mobile collection app a documented contract with API-key authentication, idempotent handling and rate limiting. Failed provisioning calls land in an error log with a retry action instead of vanishing. The rating engine ships with unit tests you can run under bench run-tests, so a tariff change is verified before it touches a live cycle. The app targets Frappe/ERPNext v15 and v16 and is built for the version you actually run, on your hosting — Frappe Cloud private bench, your own VPS, or the Docker stack.

This is a build-to-order engagement, not an instant download. It begins with a scoping call covering your plans, tariff bands, usage source format, provisioning targets and dealer structure. We return a written scope and a fixed quotation; once you confirm it, typical delivery is one working week. We build against a staging copy of your site, run UAT with your billing and NOC teams over a real cycle, then install to production with a documented rollback. You receive the complete source in a Git repository you own, so nothing here is a black box.

Ne elde edeceksin

  • Complete installable Frappe app source built and tested for your exact Frappe/ERPNext version (v15 or v16), with versioned fixtures for plans, workflows, roles and custom fields
  • Installation and configuration on your environment — Frappe Cloud private bench, your VPS or the Docker stack — including scheduler, background workers, roles and permissions
  • Technical documentation: DocType and field reference, rating-engine logic, `hooks.py` doc events and scheduler jobs, plus the REST and whitelisted-method API contract with worked examples
  • End-user guide for billing, NOC and dealer-facing staff, with a live training session covering the billing run, provisioning workflow, dunning ladder and ticket operations
  • UAT on a staging copy of your site against a real billing cycle and a real provisioning target, with a signed-off acceptance checklist before anything touches production
  • Documented production install with a tested rollback plan — database backup point, app uninstall path and fixture reversal — so go-live is reversible
  • Post-go-live support window for defect fixes on the delivered scope, covering the first full billing cycle after launch
  • Git repository handover: full source, commit history, a branch pinned to your version and a tagged release, transferred to an account you own

Bu kimin için

ISP / Broadband Operator Owner

Runs a regional fibre or wireless ISP with a few thousand to a few tens of thousands of subscribers. Currently uses a standalone billing box that never reconciles to the accounts, and wants one system where a subscriber's plan, invoice, payment, provisioning state and fault history all live together in ERPNext.

Billing & Revenue Assurance Manager

Owns the monthly cycle and answers for revenue leakage. Needs deterministic rating over an auditable usage ledger, correct proration on every mid-cycle change, dunning that runs by policy rather than by whoever remembers, and reports that tie invoiced revenue back to rated usage.

NOC / Operations Lead

Responsible for provisioning turnaround and fault resolution. Wants service orders and trouble tickets tied to the actual service instance and network identifiers, SLA clocks that are measured rather than estimated, and provisioning actions that fire from the ERPNext workflow instead of a parallel manual process.

Channel / Dealer Network Manager

Manages franchisees and field collection agents who sell connections and collect cash. Needs a dealer ledger, commission that computes automatically, receipts reconciling against ERPNext Payment Entries, and strict data isolation so one dealer can never see another's subscribers.

Telecom Billing & OSS Operations for ERPNext Nasıl Karşılaştırılır

KriterECOSIREÖzel YapıRakipERPNext Yerleşik
Telecom domain model (plans, service instances, usage)Purpose-built `Telecom Plan`, `Service Subscription` and `Usage Record` DocTypes designed around your tariffsAchievable, but the model is designed once by a contractor who may not know telecom billing edge casesA fixed generic subscription model; telecom identifiers and tariff bands get forced into custom fieldsSubscription and Subscription Plan only — no service instance, no network identifiers, no usage concept
Usage rating from CDR / RADIUSAdapter built for your actual source, deduplicated ledger, tiered tariff bands, nightly scheduler jobWritten from scratch each time; dedupe and re-run safety are the first things dropped under deadlineRarely included — marketplace subscription apps bill a flat recurring amount, not metered usageNot available; ERPNext has no rating engine
Provisioning and service lifecycleFrappe Workflow service orders with `hooks.py` doc events dispatching queued, retryable provisioning callsOften a direct API call inside a Server Script with no retry, so a failed provision is invisibleGenerally out of scope; billing apps stop at the invoiceNo provisioning concept — status is whatever someone types into a field
Dunning, suspension and reconnectionPolicy ladder (grace, throttle, suspend, reconnect) run by a scheduler job with a full state audit trailUsually a manual report plus staff judgement, which is exactly where revenue and goodwill leakBasic overdue reminder emails at mostPayment reminders exist, but no service-state consequence is tied to them
Dealer and collection channel isolationDealer ledger and commission rules plus server-side filtering via role profiles and `permission_query_conditions`Frequently implemented as UI hiding, which the REST API then walks straight pastMulti-dealer tenancy is uncommon in generic marketplace appsStandard role and User Permission model, with no dealer entity or commission logic
Accounting integrityInvoices, credit notes and receipts posted through the ERPNext API — tax templates, dimensions and GL untouchedVaries with the developer; hand-written GL entries are a common and expensive shortcutUsually correct within its own scope, but a separate billing box leaves a permanent reconciliation taskFully correct — this is precisely what ERPNext core is good at
Upgrade safety on `bench update`Standalone app, versioned fixtures, no database-resident Server Scripts, tested against your v15/v16 targetDepends entirely on discipline; Customize Form-heavy builds break on major upgradesDepends on the publisher's cadence — an abandoned marketplace app blocks your ERPNext upgradesAlways upgrade-safe, because there is nothing custom to break
Ownership and handoverFull Git repository transferred to you, with technical docs, tests and a tagged releaseUsually yours, but often undocumented and untested, so the next developer rewrites itLicensed, not owned — you cannot change the rating logic when your tariffs changeNot applicable; no custom code exists

Telecom Billing & OSS Operations hakkında Sıkça Sorulan Sorular

How long does delivery take, and what happens first?

This is a build-to-order application, not a marketplace download. We start with a short scoping call covering your plans and tariff bands, your usage source format (CDR, RADIUS accounting, NMS export), your provisioning targets and your dealer structure. You then receive a written scope and a fixed quotation. Once you confirm that scope, typical delivery is one working week, including UAT on a staging copy of your site before we install to production.

Which ERPNext versions do you support, and will this survive a bench update?

We build for Frappe/ERPNext v15 and v16, targeting the exact version your site runs. The work ships as a proper Frappe app with its own module, DocTypes, fixtures and `hooks.py` — not as Customize Form overrides or database-resident Server Scripts, which are the things that break or get silently reverted on `bench update`. Custom fields on standard DocTypes such as Customer and Issue are delivered as versioned fixtures so they are reproducible across every environment.

What support and updates do I get after go-live?

Every engagement includes a post-go-live support window covering defect fixes on the delivered scope through the first full billing cycle — the period when rating edge cases actually surface. After that you can continue on an ongoing support and maintenance agreement covering ERPNext major-version compatibility work, tariff and plan changes, and new integrations. Because you own the Git repository, your own developers can also maintain it independently.

Can it rate usage from our existing network gear, or does it assume a specific vendor?

The rating engine is deliberately source-agnostic. It consumes a normalised `Usage Record` ledger, and we build the adapter for your actual source: scheduled import of CDR or RADIUS accounting exports, a pull from your NMS API, or an authenticated push into a whitelisted endpoint. Records are deduplicated by source record ID so a re-run or a re-sent batch cannot double-bill. If your gear changes later, only the adapter is replaced — the rating logic stays put.

Does this replace ERPNext accounting or sit on top of it?

It sits on top. Every billing run produces standard ERPNext Sales Invoices, Credit Notes and Payment Entries through the framework API, so tax templates, cost centers, accounting dimensions, the GL and your existing financial reports behave exactly as before. The telecom layer adds the subscriber, plan, usage and provisioning model that ERPNext core lacks; it never forks your books into a second ledger.

How do you stop dealers from seeing each other's subscribers?

Access is enforced at the data layer, not hidden in the UI. Dealers get a dedicated role profile, User Permissions scoped to their Dealer record, and a `permission_query_conditions` hook so list views, reports and API queries are filtered server-side. A dealer authenticating against the REST API is restricted exactly as one using the desk or the portal.

Can we see something before committing?

Yes. During the scoping call we walk the model — plans, subscriptions, the rating flow, the provisioning workflow and dealer collections — against your own scenarios, and we can demonstrate the equivalent patterns on a reference ERPNext site. We will also tell you plainly where a requirement is better solved by ERPNext core or an existing app than by custom work.

Teklif isteyin

Telecom Billing & OSS Operations

A build-to-order ERPNext application that adds telecom plan and subscription management, usage rating, service provisioning workflows, trouble-ticket operations and dealer collection channels on top of your existing ERPNext accounting. ECOSIRE scopes, builds, installs and supports it for your Frappe/ERPNext v15 or v16 site.

  • Custom `Telecom Plan` DocType with rental, included quota, tiered overage tariff bands, contract term, notice period and ERPNext tax template linkage
  • `Service Subscription` DocType binding Customer, plan, service address and real network identifiers — circuit ID, ONU/CPE serial, MSISDN, RADIUS username
  • Usage rating engine ingesting CDR, RADIUS accounting or NetFlow exports into a `Usage Record` ledger, deduplicated by source record ID so a re-import can never double-bill
  • Nightly rating job registered in `scheduler_events` that aggregates unrated usage and applies tariff bands as tested Python, not database-resident Server Scripts

Teklif isteyin

Telecom Billing & OSS Operations ihtiyaçlarınızı bize anlatın; fiyatları, lisans seçeneklerini ve size özel bir teklifi genellikle bir iş günü içinde gönderelim.

Şimdi ödeme yok. Bu, ekibimize bir teklif talebi gönderir — fiyat ve sonraki adımlarla e-posta ile dönüş yapacağız.