产品详细信息以英文显示。翻译即将推出。
速览
- 价格
- $499.00 USD
- ERPNext 版本
- —
- 设置时间
- 30分钟
- 许可证
- 一次永久
- 语言
- 11 语言
一次性购买
Pakistan FBR Digital Invoicing & POS for ERPNext
A build-to-order Frappe app that connects your ERPNext Sales Invoices and Point of Sale directly to Pakistan's FBR Digital Invoicing system for real-time fiscalization, invoice reference numbers, QR codes, and validated tax fields. ECOSIRE builds, installs, and supports it after we confirm scope with you.
$499.00USD
现在无需付款。此操作会向我们的团队发送报价请求——我们会通过邮件跟进价格和后续步骤。
核心功能
Custom fields on `Sales Invoice`, `POS Invoice`, `Customer`, and `Item` for seller/buyer NTN, STRN, NIC, HS code, sale type, and province, added via a fixtures-managed Frappe app so they survive migrations
`on_submit` and `on_cancel` doc events wired in `hooks.py` that build the FBR payload and post it to the Digital Invoicing API in real time
Server-side integration client that authenticates to the FBR sandbox and production endpoints with environment-switchable credentials stored in an `FBR Settings` single DocType
Scenario mapping engine that classifies each invoice into the correct FBR sale type (registered/unregistered, standard rate, reduced, exempt, 3rd-schedule, etc.) before submission
Pre-submission validation that rejects malformed STRN/NTN, missing HS codes, or unbalanced tax lines and returns a clear error before the network call is made
Invoice reference number (IRN) and fiscal number written back onto the ERPNext document and made non-editable after acceptance
FBR-compliant QR code generation embedded in a custom Print Format so the printed/PDF invoice carries the required fiscal QR and number
Real-time POS invoice push via a whitelisted method and client script so cashiers get a fiscalized receipt without leaving the POS screen
`FBR Invoice Log` DocType capturing request payload, FBR response, status, and error detail for every attempt — a full audit trail
Scheduler event (`scheduler_events` in `hooks.py`) that automatically retries invoices stuck in a transient-failure state
Role profile and permission rules so only authorized users can edit FBR credentials or force-resubmit, keeping fiscalization tamper-resistant
Frappe REST API endpoints exposed so an external POS, e-commerce, or middleware system can trigger fiscalization programmatically
Idempotent submission guard that prevents duplicate IRNs if a document is submitted twice or a webhook fires more than once
Compatible with ERPNext and Frappe v15 and v16, built as a standalone app that installs cleanly via `bench get-app` / `bench install-app`
关于此产品
If you are a sales-tax-registered retailer or business in Pakistan, the FBR Digital Invoicing mandate means every taxable Sales Invoice must be posted to FBR's system in real time and carry a valid fiscal invoice number and QR code before you hand it to the customer. ERPNext out of the box knows nothing about FBR — it has no field for the buyer's NTN/STRN, no concept of FBR's sale-type scenarios, no call to the FBR sandbox or production endpoint, and no way to stop a POS receipt from printing until FBR has accepted it. Teams try to bridge this with spreadsheets, a separate government portal, or manual re-keying, which breaks reconciliation and creates compliance exposure the moment volume rises. This is the gap the build closes.
为什么选择 Pakistan FBR Digital Invoicing & POS for ERPNext
Custom fields on `Sales Invoice`, `POS Invoice`, `Customer`, and `Item` for seller/buyer NTN, STRN, NIC, HS code, sale type, and province, added via a fixtures-managed Frappe app so they survive migrations
`on_submit` and `on_cancel` doc events wired in `hooks.py` that build the FBR payload and post it to the Digital Invoicing API in real time
Server-side integration client that authenticates to the FBR sandbox and production endpoints with environment-switchable credentials stored in an `FBR Settings` single DocType
Scenario mapping engine that classifies each invoice into the correct FBR sale type (registered/unregistered, standard rate, reduced, exempt, 3rd-schedule, etc.) before submission
Pre-submission validation that rejects malformed STRN/NTN, missing HS codes, or unbalanced tax lines and returns a clear error before the network call is made
Invoice reference number (IRN) and fiscal number written back onto the ERPNext document and made non-editable after acceptance
ECOSIRE builds a proper Frappe app — its own module, DocTypes, and hooks.py doc events — that plugs FBR fiscalization into the ERPNext documents you already use. We add the mandatory tax fields (seller and buyer NTN/STRN, NIC for unregistered buyers, HS codes, sale type, province, and FBR-specific tax rates) as custom fields on Sales Invoice, POS Invoice, Customer, and Item so the data is captured at source rather than patched afterward. A dedicated FBR Settings single DocType holds your API credentials, environment toggle (sandbox vs production), and seller registration details, encrypted using Frappe's password fieldtype.
The submission itself runs server-side. On the on_submit doc event we build the FBR JSON payload, map each line to the correct FBR scenario (SN001–SN028 style sale types), run pre-submission validation to catch a bad STRN or missing HS code before the network call, and POST it to the FBR Digital Invoicing API via a whitelisted method. When FBR returns the invoice reference number (IRN) and validation response, we write it back onto the document, generate the FBR QR code and fiscal number, and expose them in a custom Print Format so the compliant invoice prints correctly. Failed submissions are caught, logged to an FBR Invoice Log DocType, surfaced to the user, and left safely re-submittable — a scheduler event retries transient failures so a dropped connection never leaves an invoice unfiscalized. For the counter, a client script and the POS integration push the invoice the instant it is finalized so the cashier gets the QR-bearing receipt in-flow.
Because this is build-to-order, nothing is auto-downloaded. We start with a short scoping call, confirm your registration profile, sale types, POS setup, and ERPNext version (v15 or v16), then build against the FBR sandbox first. You get a documented, installable Frappe app with role-based permissions, tested end to end on a staging site with a rollback plan, and a support window after go-live. Typical delivery is 2–4 weeks from confirmed scope, depending on the number of sale-type scenarios and whether you also want automated FBR reconciliation reporting.
你得到什么
- Installable source code for your version of the FBR Digital Invoicing Frappe app, delivered as a standalone app installable via bench
- Installation and configuration on your ERPNext instance, including `FBR Settings`, credentials, and sandbox-to-production cutover
- Technical documentation covering DocTypes, hooks, whitelisted methods, scenario mapping, and the retry/scheduler design
- End-user guide plus a live training session for accounts and POS staff on the fiscalized invoicing workflow
- UAT on a staging site against the FBR sandbox, with a documented rollback plan before touching production
- Post-go-live support window for bug fixes and FBR response-handling adjustments after your first live invoices
- Handover of the private git repository with commit history so your team (or another vendor) can maintain and extend it
- FBR sale-type scenario matrix mapped to your actual product/tax setup, delivered as a reference sheet
这是给谁的
Sales-tax-registered retailer under the FBR POS mandate
Runs one or more retail counters on ERPNext POS and must issue FBR-fiscalized receipts with QR codes at the point of sale. Needs the push to happen in-flow so cashiers are not slowed down and no sale escapes fiscalization.
Finance/tax manager at a registered firm
Owns sales-tax compliance and monthly FBR reconciliation. Wants every Sales Invoice validated and posted to FBR from within ERPNext, with an auditable log of IRNs and responses instead of a parallel portal and spreadsheets.
ERPNext partner or in-house Frappe team
Already runs ERPNext for the client and needs a clean, documented FBR app with proper DocTypes, hooks, and REST endpoints they can maintain — not a pile of untracked server-script hacks bolted onto production.
Wholesale/distribution business with high invoice volume
Issues large numbers of B2B invoices across sale types and provinces. Needs reliable scenario mapping, retry on transient FBR failures, and idempotent submission so high throughput never produces duplicate or missing fiscal numbers.
安装概述
从ECOSIRE下载
在 ecosire.com 上购买许可证并从您的帐户仪表板下载 Pakistan FBR Digital Invoicing & POS for ERPNext 应用程序 ZIP。
将应用程序添加到您的工作台
将 ZIP 解压到您的 bench 的 apps 文件夹中，或者使用解压缩的应用程序的路径运行“bench get-app”。
安装在您的网站上
运行 `bench --site SITE_NAME install-app APP_NAME`，然后运行 `bench migrate` 以安装 Pakistan FBR Digital Invoicing & POS for ERPNext 并应用其架构。
激活您的许可证
打开您站点上的 ECOSIRE 许可证设置并激活您的许可证密钥。需要免费的 ecosire_connect 和 ecosire_license_client 应用程序。
Pakistan FBR Digital Invoicing & POS for ERPNext 如何比较
| 标准 | 伊科西尔 | 定制建造 | 竞争对手 | 奥杜本机 |
|---|---|---|---|---|
| FBR real-time submission | Built into `on_submit` doc events, posted live to the FBR API | Possible but you design the whole integration yourself | Varies; may only cover Sales Invoice, not POS | |
| NTN/STRN/NIC & HS code fields | Custom fields on Invoice, Customer, and Item with validation | You add and validate every field manually | Usually a fixed field set, hard to extend | |
| Sale-type scenario mapping | Scenario engine mapped to your actual products and tax setup | Hand-coded per project, easy to get wrong | Generic mapping, often not tuned to your catalog | |
| POS fiscalization | Real-time push with QR receipt in the POS flow | Extra work; POS Invoice hooks differ from Sales Invoice | Often desk-only, weak POS coverage | |
| Failure handling & retries | `FBR Invoice Log` + scheduler auto-retry + idempotency guard | You build the logging and retry logic yourself | Basic error message, manual re-submit | |
| Ownership & maintainability | Documented app, git repo handover, no lock-in | You own it but carry all the build risk and time | Closed app, dependent on vendor release cadence | |
| Delivery model | Build-to-order, sandbox-tested, 2–4 weeks from scope | Unbounded — depends on your team's availability | Instant install but generic fit and DIY config | |
| Support & compliance updates | Post-go-live window + optional ongoing FBR-change maintenance | Your team maintains it as FBR evolves | Depends on vendor; updates may lag FBR changes |
关于Pakistan FBR Digital Invoicing & POS for ERPNext的常见问题
+Is this an instant download from the Frappe marketplace?
No. It is build-to-order. ECOSIRE builds the app against your registration profile, sale types, and ERPNext version, tests it on the FBR sandbox, then installs and supports it. There is no instant download or self-serve package.
+How long does delivery take?
Typically 2–4 weeks from confirmed scope. The exact timeline depends on how many FBR sale-type scenarios you need, your POS setup, and whether you also want automated FBR reconciliation reporting. We confirm the estimate after the scoping call.
+What about support and updates after go-live?
You get a post-go-live support window for bug fixes and adjustments to FBR response handling. Because FBR changes its API and scenarios over time, we can also arrange an ongoing maintenance agreement so the app stays compliant as the specification evolves. You receive the git repo either way, so you are never locked in.
+Which ERPNext versions are supported?
The app is built for Frappe and ERPNext v15 and v16 as a standalone app. We confirm your exact version and any customizations during scoping and build against a matching staging site.
+Do you test against the FBR sandbox before going live?
Yes. We build and validate against the FBR sandbox environment first, run UAT on a staging site with sample invoices covering your real sale types, and only switch the `FBR Settings` environment toggle to production after you sign off — with a rollback plan in place.
+What happens if FBR is down or rejects an invoice?
Every attempt is written to an `FBR Invoice Log` DocType with the request, response, and error. Validation errors are surfaced to the user before submission, and transient failures are automatically retried by a Frappe scheduler event so an invoice is never silently left unfiscalized.
+Can our POS, website, or middleware trigger fiscalization programmatically?
Yes. The app exposes whitelisted methods and Frappe REST API endpoints, so an external POS, e-commerce store, or integration layer can trigger FBR submission and read back the IRN and QR code without opening the ERPNext desk.
相关模块
申请报价
Pakistan FBR Digital Invoicing & POS for ERPNext
A build-to-order Frappe app that connects your ERPNext Sales Invoices and Point of Sale directly to Pakistan's FBR Digital Invoicing system for real-time fiscalization, invoice reference numbers, QR codes, and validated tax fields. ECOSIRE builds, installs, and supports it after we confirm scope with you.
- Custom fields on `Sales Invoice`, `POS Invoice`, `Customer`, and `Item` for seller/buyer NTN, STRN, NIC, HS code, sale type, and province, added via a fixtures-managed Frappe app so they survive migrations
- `on_submit` and `on_cancel` doc events wired in `hooks.py` that build the FBR payload and post it to the Digital Invoicing API in real time
- Server-side integration client that authenticates to the FBR sandbox and production endpoints with environment-switchable credentials stored in an `FBR Settings` single DocType
- Scenario mapping engine that classifies each invoice into the correct FBR sale type (registered/unregistered, standard rate, reduced, exempt, 3rd-schedule, etc.) before submission