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 $499.00 USD; request a quote for a scoped proposal.
示意预览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.
无需自行搭建——由 ECOSIRE 构建、安装并提供支持的可用应用。
以一次性构建价格开始。我们在启动时与您共同确定范围。
ECOSIRE 在您的 ERPNext 上构建、配置并安装。
约 2–4 周内上线,并提供上线后的支持期。
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 2-4 weeks. 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.
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.
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.
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.
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.
| 标准 | 伊科西尔 | 定制建造 | 竞争对手 | ERPNext 原生 |
|---|---|---|---|---|
| Telecom domain model (plans, service instances, usage) | Purpose-built `Telecom Plan`, `Service Subscription` and `Usage Record` DocTypes designed around your tariffs | Achievable, but the model is designed once by a contractor who may not know telecom billing edge cases | A fixed generic subscription model; telecom identifiers and tariff bands get forced into custom fields | Subscription and Subscription Plan only — no service instance, no network identifiers, no usage concept |
| Usage rating from CDR / RADIUS | Adapter built for your actual source, deduplicated ledger, tiered tariff bands, nightly scheduler job | Written from scratch each time; dedupe and re-run safety are the first things dropped under deadline | Rarely included — marketplace subscription apps bill a flat recurring amount, not metered usage | Not available; ERPNext has no rating engine |
| Provisioning and service lifecycle | Frappe Workflow service orders with `hooks.py` doc events dispatching queued, retryable provisioning calls | Often a direct API call inside a Server Script with no retry, so a failed provision is invisible | Generally out of scope; billing apps stop at the invoice | No provisioning concept — status is whatever someone types into a field |
| Dunning, suspension and reconnection | Policy ladder (grace, throttle, suspend, reconnect) run by a scheduler job with a full state audit trail | Usually a manual report plus staff judgement, which is exactly where revenue and goodwill leak | Basic overdue reminder emails at most | Payment reminders exist, but no service-state consequence is tied to them |
| Dealer and collection channel isolation | Dealer 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 past | Multi-dealer tenancy is uncommon in generic marketplace apps | Standard role and User Permission model, with no dealer entity or commission logic |
| Accounting integrity | Invoices, credit notes and receipts posted through the ERPNext API — tax templates, dimensions and GL untouched | Varies with the developer; hand-written GL entries are a common and expensive shortcut | Usually correct within its own scope, but a separate billing box leaves a permanent reconciliation task | Fully 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 target | Depends entirely on discipline; Customize Form-heavy builds break on major upgrades | Depends on the publisher's cadence — an abandoned marketplace app blocks your ERPNext upgrades | Always upgrade-safe, because there is nothing custom to break |
| Ownership and handover | Full Git repository transferred to you, with technical docs, tests and a tagged release | Usually yours, but often undocumented and untested, so the next developer rewrites it | Licensed, not owned — you cannot change the rating logic when your tariffs change | Not applicable; no custom code exists |
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 2-4 weeks, including UAT on a staging copy of your site before we install to production.
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.
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.
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.
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.
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.
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.
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.