Skip to main content

Overview

What it is​

Insurance Broker Core adds broker-specific DocTypes, permissions, lifecycle rules, versioned contracts, reports, and event surfaces to an ERPNext site. It is deliberately centred on domain truth and controlled workflows. ERPNext's own master and accounting objects (Customer, Contact, Address, Supplier, Company, Currency, accounting documents) remain authoritative; the app links to them instead of keeping a shadow copy.

Positioning​

  • Standalone. The app is usable on a normal ERPNext site without a Helpifyr account, Helpifyr runtime, Fabric, Spindle, Loom, Heddle, Advice Boost, BiPRO, OMDS, or any other external provider. Installation, activation, privacy workflows, backup, restore, import, and local operations do not call Helpifyr services.
  • No ERPNext fork. It installs like any Frappe app and makes no core-file overrides.
  • Helpifyr is optional. An adapter can add governed cross-system workflows, but it is not bundled and never becomes the source of truth for policies, claims, advice, mandates, or commissions. See Optional Helpifyr integration.
  • Open source. AGPL-3.0-or-later, owned and maintained by ANYFER GmbH.

The data flow in words: the ERPNext site hosts the app; the app stores its data in the site database and files and writes a persistent outbox. The outbox feeds an optional adapter, which in turn can talk to Helpifyr. If the adapter or an external provider is unavailable, the app keeps operating according to its local policy.

Design principles​

  1. ERPNext remains authoritative for ERPNext objects. No second person or accounting database.
  2. Policy terms are immutable evidence. A new policy state is a new version with effective_at and recorded_at; history is not rewritten.
  3. Every side effect is explicit. Approval, posting, payment, tax filing, and external delivery are gated operations, not hidden consequences of a read or an import.
  4. Events are durable and replayable. The outbox entry is written after the local commit; delivery state, retries, dead letters, and consumer cursors are tracked independently.
  5. Untrusted input stays untrusted. Documents, OCR, model output, and provider payloads are proposals until a human or an admitted policy accepts them.
  6. Claims are evidence-bound. A model that can store a record is not automatically a validated advice or placement capability.

Capability status and honest scope​

The existence of a DocType does not mean that every process is validated for every insurance class or country. Each capability carries an explicit status:

StatusMeaning
validatedEvidence-backed and permitted for a productive claim
supportedImplemented, but not sufficient for a public productive claim
manual_onlySupported with explicit human handling and no automation claim
model_onlyRepresented for inventory or future extension only
blockedDeliberately unavailable until a gate is passed
not_applicableNot meaningful for the product and process combination

The binding rule is that only validated capabilities may be claimed as productively validated. A claim needs a verifier, a CI result, and an evidence record; a claim without evidence is not a valid claim. Do not repeat a capability in customer-facing material unless it is validated for the exact product class, country, process, and release. The project describes this rule in its capability claims guide.

Two concrete boundaries:

  • 51 product classes can be modelled for lossless inventory imports. Servicing, advice, placement, claims, and commission capabilities are admitted separately per class, country, process, and release evidence.
  • Funds and Diverse stay modelled so portfolio imports remain lossless, but their process capabilities are blocked or not applicable. This is a boundary, not a promise of investment-product support.

The accounting posture defaults to None: no function submits invoices, executes payments, or processes client money automatically. A posting strategy has to be admitted explicitly per company and country.

Language​

The Desk source language is English. The current release scope ships a German translation for the core cockpit, navigation, validation messages, and the supported broker DocTypes. French and Italian are not complete release languages; untranslated labels fall back to the English source string.

Distribution status​

The source tree carries version 1.0.0. Release status and distribution channels are described in the release notes. The app is not listed on the Frappe Marketplace; the repository only holds prepared listing and publish-readiness material.

Next step​

Check the requirements.