lambda-erp 0.2.1__tar.gz → 0.2.3__tar.gz

{lambda_erp-0.2.1 → lambda_erp-0.2.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: lambda-erp
-Version: 0.2.1
+Version: 0.2.3
 Summary: Core ERP logic - accounting, sales, purchasing, inventory
 Author: TORUS INVESTMENTS AG
 License-Expression: MIT
@@ -141,7 +141,7 @@ Standing up a new company usually means an accountant hand-building a chart of a
 
 Two dimensions shape the chart, and they compose:
 
-- **Localization packs** bring a country's real chart and tax setup. Today: a **generic / international** chart (also the permanent fallback for anywhere not yet localized) and **Switzerland** — the *Kontenrahmen KMU*, in German, in CHF, with MWST tax templates at the current rates. Each country is a self-contained pack, so more can land without disturbing the ones already there — that's the roadmap, one jurisdiction at a time.
+- **Localization packs** bring a country's real chart and tax setup. Today: a **generic / international** chart (also the permanent fallback for anywhere not yet localized); **Switzerland** — the *Kontenrahmen KMU*, in German, in CHF, with MWST tax templates at the current rates; and **Germany** — the DATEV standard in both common variants, **SKR03** and **SKR04**, in German, in EUR, with Umsatzsteuer/Vorsteuer templates at 19 % and 7 %. Where a country ships more than one standard chart (Germany's SKR03 vs SKR04), you pick the variant; a bare "Germany" defaults to the more widely used SKR03. Each country is a self-contained pack, so more can land without disturbing the ones already there — that's the roadmap, one jurisdiction at a time.
 - **Sector profiles** tailor the chart to how you operate — **services, retail / POS, hospitality, wholesale / distribution, import / export, manufacturing, construction** — adding the accounts that model actually needs (work-in-progress and retention for construction, food-vs-beverage cost lines for hospitality, landed-cost accounts for import/export, and so on). Profiles are country-independent: the same seven apply on top of every localization.
 
 The result is booked in one step — chart of accounts, sensible default accounts, tax templates, and a cost center — ready for opening balances. New here? The in-app **Tutorial** has a one-click **Get started** that opens the wizard in chat.
@@ -150,7 +150,7 @@ The result is booked in one step — chart of accounts, sensible default account
 
 ## What works today
 
-- **Guided company setup through chat** — pick a country (generic or Switzerland, more coming) and business type, preview the exact chart of accounts, confirm, and it's booked
+- **Guided company setup through chat** — pick a country (generic, Switzerland, or Germany SKR03/SKR04, more coming) and business type, preview the exact chart of accounts, confirm, and it's booked
 - Full sales and purchase cycles (Quotation → Sales Order → Delivery Note → Sales Invoice → Payment Entry, and the buying equivalents)
 - Returns / credit notes / debit notes with proper GL and stock reversal
 - Moving-average stock ledger with negative-stock protection
@@ -190,7 +190,7 @@ Four things had to be true for this to work, and they all became true in the las
 
 Every company configuring an ERP runs into the same problems: local tax rules, common workflow patterns, industry-specific accounting quirks. Most of that knowledge isn't a competitive advantage — it's the same ground being re-covered separately at every implementation, by every team, in slightly different ways.
 
-We want Lambda ERP to be where that knowledge lives in public. The base system is MIT-licensed, and the repo has real seams for that knowledge to slot into: a new country's chart of accounts and tax rules is a self-contained **localization pack**, and an industry's way of operating is a **sector profile** — both live in `lambda_erp/accounting/setup/` and are documented for contributors in [`docs/agents/company_setup.md`](docs/agents/company_setup.md). A German VAT pack, a U.S. sales-tax-by-state module, a template for professional services — each is an additive contribution that every deployment picks up. The goal is a true community where running an ERP gets cheaper, faster, and more flexible for everyone, not just the implementer.
+We want Lambda ERP to be where that knowledge lives in public. The base system is MIT-licensed, and the repo has real seams for that knowledge to slot into: a new country's chart of accounts and tax rules is a self-contained **localization pack**, and an industry's way of operating is a **sector profile** — both live in `lambda_erp/accounting/setup/` and are documented for contributors in [`docs/agents/company_setup.md`](docs/agents/company_setup.md). An Austrian or French chart, a U.S. sales-tax-by-state module, a template for professional services — each is an additive contribution that every deployment picks up (the Swiss KMU and German DATEV packs already in the tree are the worked examples). The goal is a true community where running an ERP gets cheaper, faster, and more flexible for everyone, not just the implementer.
 
 ---
 

{lambda_erp-0.2.1 → lambda_erp-0.2.3}/README.md

@@ -114,7 +114,7 @@ Standing up a new company usually means an accountant hand-building a chart of a
 
 Two dimensions shape the chart, and they compose:
 
-- **Localization packs** bring a country's real chart and tax setup. Today: a **generic / international** chart (also the permanent fallback for anywhere not yet localized) and **Switzerland** — the *Kontenrahmen KMU*, in German, in CHF, with MWST tax templates at the current rates. Each country is a self-contained pack, so more can land without disturbing the ones already there — that's the roadmap, one jurisdiction at a time.
+- **Localization packs** bring a country's real chart and tax setup. Today: a **generic / international** chart (also the permanent fallback for anywhere not yet localized); **Switzerland** — the *Kontenrahmen KMU*, in German, in CHF, with MWST tax templates at the current rates; and **Germany** — the DATEV standard in both common variants, **SKR03** and **SKR04**, in German, in EUR, with Umsatzsteuer/Vorsteuer templates at 19 % and 7 %. Where a country ships more than one standard chart (Germany's SKR03 vs SKR04), you pick the variant; a bare "Germany" defaults to the more widely used SKR03. Each country is a self-contained pack, so more can land without disturbing the ones already there — that's the roadmap, one jurisdiction at a time.
 - **Sector profiles** tailor the chart to how you operate — **services, retail / POS, hospitality, wholesale / distribution, import / export, manufacturing, construction** — adding the accounts that model actually needs (work-in-progress and retention for construction, food-vs-beverage cost lines for hospitality, landed-cost accounts for import/export, and so on). Profiles are country-independent: the same seven apply on top of every localization.
 
 The result is booked in one step — chart of accounts, sensible default accounts, tax templates, and a cost center — ready for opening balances. New here? The in-app **Tutorial** has a one-click **Get started** that opens the wizard in chat.
@@ -123,7 +123,7 @@ The result is booked in one step — chart of accounts, sensible default account
 
 ## What works today
 
-- **Guided company setup through chat** — pick a country (generic or Switzerland, more coming) and business type, preview the exact chart of accounts, confirm, and it's booked
+- **Guided company setup through chat** — pick a country (generic, Switzerland, or Germany SKR03/SKR04, more coming) and business type, preview the exact chart of accounts, confirm, and it's booked
 - Full sales and purchase cycles (Quotation → Sales Order → Delivery Note → Sales Invoice → Payment Entry, and the buying equivalents)
 - Returns / credit notes / debit notes with proper GL and stock reversal
 - Moving-average stock ledger with negative-stock protection
@@ -163,7 +163,7 @@ Four things had to be true for this to work, and they all became true in the las
 
 Every company configuring an ERP runs into the same problems: local tax rules, common workflow patterns, industry-specific accounting quirks. Most of that knowledge isn't a competitive advantage — it's the same ground being re-covered separately at every implementation, by every team, in slightly different ways.
 
-We want Lambda ERP to be where that knowledge lives in public. The base system is MIT-licensed, and the repo has real seams for that knowledge to slot into: a new country's chart of accounts and tax rules is a self-contained **localization pack**, and an industry's way of operating is a **sector profile** — both live in `lambda_erp/accounting/setup/` and are documented for contributors in [`docs/agents/company_setup.md`](docs/agents/company_setup.md). A German VAT pack, a U.S. sales-tax-by-state module, a template for professional services — each is an additive contribution that every deployment picks up. The goal is a true community where running an ERP gets cheaper, faster, and more flexible for everyone, not just the implementer.
+We want Lambda ERP to be where that knowledge lives in public. The base system is MIT-licensed, and the repo has real seams for that knowledge to slot into: a new country's chart of accounts and tax rules is a self-contained **localization pack**, and an industry's way of operating is a **sector profile** — both live in `lambda_erp/accounting/setup/` and are documented for contributors in [`docs/agents/company_setup.md`](docs/agents/company_setup.md). An Austrian or French chart, a U.S. sales-tax-by-state module, a template for professional services — each is an additive contribution that every deployment picks up (the Swiss KMU and German DATEV packs already in the tree are the worked examples). The goal is a true community where running an ERP gets cheaper, faster, and more flexible for everyone, not just the implementer.
 
 ---
 

{lambda_erp-0.2.1 → lambda_erp-0.2.3}/api/chat.py

@@ -1081,13 +1081,22 @@ TOOLS = [
                 "applying). Call this first, walk the user through the plan and the big "
                 "decisions in plain language, and only call `apply_company_setup` once they "
                 "confirm.\n\n"
+                "It also returns an `existing` block: if `existing.company_exists` is true, tell "
+                "the user up front that the company already exists — setup will only add what's "
+                "missing and leave the rest. If `existing.needs_confirmation` is true (already "
+                "configured, or a currency/jurisdiction mismatch), surface `existing.advisory` as "
+                "a clear warning before proceeding.\n\n"
                 "`sector` is one of: services, retail_pos, hospitality, distribution, "
                 "import_export, manufacturing, construction. If you're unsure which fits, "
                 "ASK the user about their business rather than guessing. `country` selects "
-                "the jurisdiction chart. Available: 'generic' (international, USD) and 'CH' "
+                "the jurisdiction chart. Available: 'generic' (international, USD); 'CH' "
                 "(Switzerland — Kontenrahmen KMU, German account names, CHF, with MWST tax "
-                "templates). Any other country falls back to the generic chart — tell the "
-                "user when `jurisdiction.is_fallback` is true."
+                "templates); and 'DE' (Germany — DATEV chart, German account names, EUR, with "
+                "Umsatzsteuer/Vorsteuer tax templates at 19 %/7 %). Germany has two chart "
+                "`variant`s: 'skr03' (process-ordered, the most common — the default for a bare "
+                "'DE') and 'skr04' (balance-sheet-ordered, DATEV's recommendation for newly "
+                "founded companies); ask which they use if it matters. Any other country falls "
+                "back to the generic chart — tell the user when `jurisdiction.is_fallback` is true."
             ),
             "parameters": {
                 "type": "object",
@@ -1099,8 +1108,8 @@ TOOLS = [
                                  "import_export", "manufacturing", "construction"],
                         "description": "Operating-mode profile. Omit if the business is generic/unknown.",
                     },
-                    "country": {"type": "string", "description": "Jurisdiction code, e.g. 'CH'. Defaults to generic."},
-                    "variant": {"type": "string", "description": "Sub-chart variant, e.g. 'skr03' (rarely needed)."},
+                    "country": {"type": "string", "description": "Jurisdiction code, e.g. 'CH' or 'DE'. Defaults to generic."},
+                    "variant": {"type": "string", "description": "Sub-chart variant. For 'DE': 'skr03' (default) or 'skr04'. Omit otherwise."},
                     "currency": {"type": "string", "description": "Base currency, e.g. 'USD', 'CHF'. Defaults to the pack currency."},
                 },
                 "required": ["name"],
@@ -1112,12 +1121,21 @@ TOOLS = [
         "function": {
             "name": "apply_company_setup",
             "description": (
-                "CREATE the company, its chart of accounts (base + sector overlay), the "
-                "company default accounts, any jurisdiction tax accounts, and the default "
-                "cost center — in one step. Only call this AFTER `plan_company_setup` and "
-                "AFTER the user has explicitly confirmed the plan and any big decisions. "
-                "Refuses if the company already has accounts (admin-only). Pass the SAME "
-                "arguments you used for the plan the user approved."
+                "CREATE/converge the company, its chart of accounts (base + sector overlay), "
+                "the company default accounts, any jurisdiction tax templates, and the default "
+                "cost center — in one step. Only call AFTER `plan_company_setup` and AFTER the "
+                "user has confirmed the plan and any big decisions. Pass the SAME arguments you "
+                "used for the approved plan.\n\n"
+                "This is idempotent and safe to run alongside an existing deployment: it only "
+                "adds accounts that are missing, fills only empty defaults, and never modifies "
+                "or deletes existing data. The result is a reconciliation report "
+                "(accounts_created vs accounts_skipped, defaults_set vs defaults_left_untouched) "
+                "— relay it plainly.\n\n"
+                "GUARDRAIL: if the company is already configured, or its currency differs from "
+                "this setup, the call returns `{ok:false, needs_confirmation:true, advisory}` "
+                "instead of proceeding. In that case, WARN the user clearly using the advisory "
+                "(especially a currency/jurisdiction mismatch, which mixes two charts), and only "
+                "re-call with `confirm_existing=true` if the user explicitly insists."
             ),
             "parameters": {
                 "type": "object",
@@ -1131,6 +1149,11 @@ TOOLS = [
                     "country": {"type": "string"},
                     "variant": {"type": "string"},
                     "currency": {"type": "string"},
+                    "confirm_existing": {
+                        "type": "boolean",
+                        "description": "Set true ONLY to proceed after a needs_confirmation "
+                                       "response and the user has insisted despite the warning.",
+                    },
                 },
                 "required": ["name"],
             },
@@ -1677,6 +1700,7 @@ def _handle_apply_company_setup(args):
         variant=(args.get("variant") or None),
         sector=(args.get("sector") or None),
         currency=(args.get("currency") or None),
+        confirm_existing=bool(args.get("confirm_existing")),
     )
 
 
@@ -1857,6 +1881,8 @@ When the user wants to **set up a new company**, get started, or create their bo
 3. **Walk them through the plan** in plain language: the sector-specific accounts (`sector_added_accounts`) and the `sector.guidance` (why the chart is shaped this way). Present every item in `sector.big_decisions` and get an explicit yes/no on each — these are the decisions you must not make for them.
 4. **Only after they confirm, call `apply_company_setup`** with the SAME arguments to create the company, accounts, defaults, and cost center.
 If `jurisdiction.is_fallback` is true, tell the user their country isn't localized yet and you're using the generic international chart for now.
+
+**Existing companies.** Setup is idempotent — it adds only missing accounts, fills only empty defaults, and never modifies or deletes existing data, so it runs safely alongside an existing deployment. Use the `existing` block the plan returns: if the company already exists, say so up front ("it already exists — I'll add what's missing and leave the rest"). If `apply_company_setup` returns `needs_confirmation` (the company is already configured, or the currency/jurisdiction differs and would mix two charts), do NOT force it — relay the `advisory` as a clear warning and re-call with `confirm_existing: true` only if the user explicitly insists. After applying, relay the reconciliation report plainly (how many accounts were created vs already present).
 """
     else:
         company_setup_section = ""

{lambda_erp-0.2.1 → lambda_erp-0.2.3}/lambda_erp/accounting/chart_of_accounts.py

@@ -147,6 +147,8 @@ def create_accounts_from_tree(company_name, tree, currency="USD"):
     Does NOT commit — the caller owns the transaction boundary.
     """
     db = get_db()
+    created: list[str] = []
+    skipped: list[str] = []
 
     def _create(subtree, parent=None, root_type=None, report_type=None):
         for account_name, details in subtree.items():
@@ -156,36 +158,59 @@ def create_accounts_from_tree(company_name, tree, currency="USD"):
 
             name = f"{account_name} - {account_abbr(company_name)}"
 
-            account = _dict(
-                name=name,
-                account_name=account_name,
-                parent_account=parent,
-                company=company_name,
-                root_type=rt,
-                report_type=rpt,
-                account_type=details.get("account_type", ""),
-                account_currency=currency,
-                is_group=1 if has_children else 0,
-            )
-            db.insert("Account", account)
+            # Idempotent: skip an account that already exists rather than failing
+            # on the primary key. Lets setup run alongside an existing deployment
+            # and fill in only what's missing. Recursion into children still runs
+            # so a partially-built chart converges to complete.
+            if db.exists("Account", name):
+                skipped.append(name)
+            else:
+                db.insert("Account", _dict(
+                    name=name,
+                    account_name=account_name,
+                    parent_account=parent,
+                    company=company_name,
+                    root_type=rt,
+                    report_type=rpt,
+                    account_type=details.get("account_type", ""),
+                    account_currency=currency,
+                    is_group=1 if has_children else 0,
+                ))
+                created.append(name)
 
             if has_children:
                 _create(details["children"], parent=name, root_type=rt, report_type=rpt)
 
     _create(tree)
+    return {"created": created, "skipped": skipped}
 
 
 def apply_company_defaults(company_name, defaults):
-    """Point Company default-account fields at the created leaf accounts.
+    """Point Company default-account fields at their leaf accounts.
 
     ``defaults`` is ``{company_field: leaf_account_name}`` (un-suffixed); the
-    company suffix is appended here. Does NOT commit.
+    company suffix is appended here. **Fill-only-empty:** a field already set is
+    left untouched (never clobber a configured company). A target account that
+    doesn't exist is skipped (never point a default at a missing account). Does
+    NOT commit. Returns ``{"set", "left", "missing"}``.
     """
     abbr = account_abbr(company_name)
-    resolved = {field: f"{leaf} - {abbr}" for field, leaf in defaults.items()}
-    if resolved:
-        db = get_db()
-        db.set_value("Company", company_name, resolved)
+    db = get_db()
+    to_set: dict[str, str] = {}
+    result = {"set": [], "left": [], "missing": []}
+    for field, leaf in defaults.items():
+        if db.get_value("Company", company_name, field):
+            result["left"].append(field)          # already configured — keep it
+            continue
+        target = f"{leaf} - {abbr}"
+        if not db.exists("Account", target):
+            result["missing"].append((field, target))
+            continue
+        to_set[field] = target
+        result["set"].append(field)
+    if to_set:
+        db.set_value("Company", company_name, to_set)
+    return result
 
 
 def setup_chart_of_accounts(company_name, currency="USD"):
@@ -204,16 +229,23 @@ def setup_chart_of_accounts(company_name, currency="USD"):
 
 
 def setup_cost_center(company_name):
-    """Create default cost center for a company."""
+    """Create the default cost center for a company (idempotent).
+
+    Skips creation if it already exists, and fills the cost-center company
+    defaults only when empty, so it is safe to run alongside an existing setup.
+    """
     db = get_db()
     name = f"Main - {company_name[:4].upper()}"
-    db.insert("Cost Center", _dict(
-        name=name,
-        cost_center_name="Main",
-        company=company_name,
-        is_group=0,
-    ))
-    db.set_value("Company", company_name, "default_cost_center", name)
-    db.set_value("Company", company_name, "round_off_cost_center", name)
+    if not db.exists("Cost Center", name):
+        db.insert("Cost Center", _dict(
+            name=name,
+            cost_center_name="Main",
+            company=company_name,
+            is_group=0,
+        ))
+    if not db.get_value("Company", company_name, "default_cost_center"):
+        db.set_value("Company", company_name, "default_cost_center", name)
+    if not db.get_value("Company", company_name, "round_off_cost_center"):
+        db.set_value("Company", company_name, "round_off_cost_center", name)
     db.commit()
     return name

{lambda_erp-0.2.1 → lambda_erp-0.2.3}/lambda_erp/accounting/setup/engine.py

@@ -142,6 +142,56 @@ def _resolved_defaults(company_name: str, defaults: dict) -> dict:
     return {field: f"{leaf} - {abbr}" for field, leaf in defaults.items()}
 
 
+# A company counts as "already configured" if any of its core posting defaults
+# is set — the signal that it has a real, working chart rather than a couple of
+# stray accounts from an abandoned attempt.
+_CORE_DEFAULTS = ("default_income_account", "default_receivable_account",
+                  "default_payable_account")
+
+
+def _existing_state(company_name: str, requested_currency: str) -> dict:
+    """Describe any pre-existing company so setup can warn instead of dead-end.
+
+    Setup is idempotent (it only ever adds missing accounts and fills empty
+    defaults), so an existing company is never a hard error. But two situations
+    warrant an explicit "are you sure": a company already **configured** with its
+    own chart, and a **currency mismatch** (adding a second chart in a different
+    currency mixes two charts). Those set ``needs_confirmation`` — the caller must
+    only proceed when the user insists.
+    """
+    db = get_db()
+    if not db.exists("Company", company_name):
+        return {"company_exists": False, "account_count": 0, "configured": False,
+                "existing_currency": None, "currency_mismatch": False,
+                "needs_confirmation": False, "advisory": ""}
+
+    count = len(db.get_all("Account", filters={"company": company_name}, fields=["name"]))
+    configured = any(db.get_value("Company", company_name, f) for f in _CORE_DEFAULTS)
+    existing_ccy = db.get_value("Company", company_name, "default_currency") or None
+    mismatch = bool(existing_ccy and requested_currency and existing_ccy != requested_currency)
+
+    if mismatch:
+        advisory = (
+            f"'{company_name}' already exists in {existing_ccy}, but this setup is in "
+            f"{requested_currency}. Adding a chart in a different currency mixes two "
+            "charts of accounts — warn the user clearly and proceed only if they insist.")
+    elif configured:
+        advisory = (
+            f"'{company_name}' is already configured ({count} accounts, defaults set). "
+            "Setup will only add accounts that are missing and change nothing else — "
+            "confirm the user wants to add to an already-configured company.")
+    elif count:
+        advisory = (
+            f"'{company_name}' already exists with {count} account(s) but isn't fully "
+            "configured. Setup will fill in the rest and leave the existing accounts alone.")
+    else:
+        advisory = ""
+
+    return {"company_exists": True, "account_count": count, "configured": configured,
+            "existing_currency": existing_ccy, "currency_mismatch": mismatch,
+            "needs_confirmation": bool(mismatch or configured), "advisory": advisory}
+
+
 # ---------------------------------------------------------------------------
 # Public API
 # ---------------------------------------------------------------------------
@@ -181,6 +231,7 @@ def plan_company_setup(company_name: str,
         "accounts": _tree_outline(tree),
         "sector_added_accounts": added,
         "defaults": _resolved_defaults(company_name, defaults),
+        "existing": _existing_state(company_name, ccy),
         "warnings": skipped,
     }
     if profile is not None:
@@ -199,25 +250,33 @@ def apply_company_setup(company_name: str,
                         variant: Optional[str] = None,
                         sector: Optional[str] = None,
                         currency: Optional[str] = None,
-                        force: bool = False) -> dict:
-    """Create the company's chart of accounts, defaults, tax, and cost center.
-
-    Idempotency guard: refuses if the company already has accounts unless
-    ``force=True``. Creates the Company row if it does not exist yet (so the chat
-    can drive setup end-to-end); an already-created company is left in place.
-    Runs in a single transaction.
+                        confirm_existing: bool = False) -> dict:
+    """Converge a company toward the desired chart of accounts (idempotent).
+
+    Runs *alongside* an existing deployment: it creates the company if missing,
+    creates only the accounts that don't already exist, fills only the company
+    defaults that are still empty (never clobbering a configured company), and
+    creates the tax templates / cost center only if absent. Existing data is
+    never modified or deleted, so this is safe to re-run.
+
+    Guardrail (see :func:`_existing_state`): if the company is already configured
+    or the currency mismatches, it returns ``needs_confirmation`` instead of
+    proceeding — the caller must pass ``confirm_existing=True`` (only after the
+    user insists). Runs in a single transaction; returns a reconciliation report.
     """
     db = get_db()
     pack = resolve_pack(country, variant)
     profile = get_profile(sector)
     ccy = currency or pack.currency
 
-    existing = db.get_all("Account", filters={"company": company_name}, fields=["name"])
-    if existing and not force:
+    state = _existing_state(company_name, ccy)
+    if state["needs_confirmation"] and not confirm_existing:
         return {
             "ok": False,
-            "error": f"{company_name} already has {len(existing)} accounts. "
-                     "Pass force=True to rebuild (this does not delete the old ones).",
+            "needs_confirmation": True,
+            "existing": state,
+            "advisory": state["advisory"],
+            "hint": "Warn the user, then re-call with confirm_existing=True only if they insist.",
         }
 
     if not db.exists("Company", company_name):
@@ -230,34 +289,29 @@ def apply_company_setup(company_name: str,
 
     tree, defaults, added, skipped = _merge(pack, profile)
 
-    create_accounts_from_tree(company_name, tree, ccy)
-    apply_company_defaults(company_name, defaults)
+    acct = create_accounts_from_tree(company_name, tree, ccy)          # {created, skipped}
+    dflt = apply_company_defaults(company_name, defaults)              # {set, left, missing}
 
     tax_summary = []
     if pack.setup_tax is not None:
         tax_summary = pack.setup_tax(company_name, ccy) or []
 
-    cost_center = setup_cost_center(company_name)  # commits internally
+    cost_center = setup_cost_center(company_name)  # idempotent, commits internally
     db.commit()
 
-    def _count(nodes):
-        n = 0
-        for _name, d in nodes.items():
-            children = d.get("children")
-            if children:
-                n += _count(children)
-            else:
-                n += 1
-        return n
-
     return {
         "ok": True,
         "company": company_name,
         "currency": ccy,
         "jurisdiction": pack.key,
         "sector": profile.key if profile else None,
-        "accounts_created": _count(tree),
+        "added_to_existing": state["company_exists"],
+        "accounts_created": len(acct["created"]),
+        "accounts_skipped": len(acct["skipped"]),   # already present, left alone
         "sector_added_accounts": added,
+        "defaults_set": dflt["set"],
+        "defaults_left_untouched": dflt["left"],     # already configured, kept
+        "defaults_unresolved": dflt["missing"],
         "cost_center": cost_center,
         "tax_summary": tax_summary,
         "warnings": skipped,

{lambda_erp-0.2.1 → lambda_erp-0.2.3}/lambda_erp/accounting/setup/packs/__init__.py

@@ -6,11 +6,11 @@ imported. Adding a jurisdiction = drop a module here and import it below.
 
     generic   the jurisdiction-neutral / international pack (and fallback)
     ch        Switzerland (Kontenrahmen KMU)
-    # de      Germany (SKR03/04)   — later
+    de.skr03  Germany, DATEV SKR03 (process-ordered) — default for a bare `de`
+    de.skr04  Germany, DATEV SKR04 (balance-sheet-ordered)
 """
 
 from lambda_erp.accounting.setup.packs import generic  # noqa: F401
 from lambda_erp.accounting.setup.packs import ch  # noqa: F401
-
-# Future packs register on import — add them here, e.g.:
-# from lambda_erp.accounting.setup.packs import de_skr03  # noqa: F401
+from lambda_erp.accounting.setup.packs import de_skr03  # noqa: F401
+from lambda_erp.accounting.setup.packs import de_skr04  # noqa: F401

{lambda_erp-0.2.1 → lambda_erp-0.2.3}/lambda_erp/accounting/setup/packs/ch.py

@@ -217,6 +217,8 @@ def ch_setup_tax(company_name, currency):
 
     def _template(title, tax_type, rate, account_leaf):
         name = f"{title} - {abbr}"
+        if db.exists("Tax Template", name):
+            return                      # idempotent: leave an existing template
         db.insert("Tax Template", _dict(
             name=name, title=title, company=company_name, tax_type=tax_type,
         ))

lambda_erp-0.2.3/lambda_erp/accounting/setup/packs/de_common.py

@@ -0,0 +1,67 @@
+"""Shared German (DATEV) helpers for the SKR03 / SKR04 packs.
+
+The two German charts differ only in their *numbering scheme* — SKR03 is
+process-ordered (Prozessgliederung), SKR04 balance-sheet-ordered
+(Abschlussgliederung) — but the tax mechanics are identical: the same German
+VAT (Umsatzsteuer / Vorsteuer) at the same two federal rates. Rather than copy
+the ~30-line tax-template builder into both variant modules, the shared factory
+lives here and each variant passes in its own tax-account leaf names.
+
+German VAT rates (federal, unchanged since 2007; the 2020 COVID cut reverted
+2021-01-01):
+  * **19 %** Regelsteuersatz (standard rate)
+  * **7 %**  ermäßigter Steuersatz (reduced rate — food, books, transit, …)
+
+Output tax = *Umsatzsteuer* (a liability), input tax = *Vorsteuer* (recoverable).
+"""
+
+from lambda_erp.utils import _dict
+from lambda_erp.database import get_db
+from lambda_erp.accounting.chart_of_accounts import account_abbr
+
+# The two federal rates, shared by both charts.
+STANDARD_RATE = 19.0
+REDUCED_RATE = 7.0
+
+
+def make_de_setup_tax(sales_taxes, purchase_taxes):
+    """Build a pack ``setup_tax(company, currency)`` hook for a German chart.
+
+    ``sales_taxes`` / ``purchase_taxes`` are lists of ``(title, rate,
+    account_leaf)`` where ``account_leaf`` is the tax account's name *within this
+    variant's chart* (the ``- <abbr>`` company suffix is appended here). Mirrors
+    ``ch.ch_setup_tax``: idempotent, does not commit (the engine owns the
+    transaction), returns a short human summary.
+    """
+
+    def de_setup_tax(company_name, currency):
+        db = get_db()
+        abbr = account_abbr(company_name)
+        summary = []
+
+        def _template(title, tax_type, rate, account_leaf):
+            name = f"{title} - {abbr}"
+            if db.exists("Tax Template", name):
+                return                  # idempotent: leave an existing template
+            db.insert("Tax Template", _dict(
+                name=name, title=title, company=company_name, tax_type=tax_type,
+            ))
+            db.insert("Tax Template Detail", _dict(
+                name=f"{name}-1",
+                parent=name,
+                charge_type="On Net Total",
+                account_head=f"{account_leaf} - {abbr}",
+                rate=rate,
+                description=title,
+                idx=1,
+            ))
+            summary.append(f"{tax_type}: {title} @ {rate}%")
+
+        for title, rate, leaf in sales_taxes:
+            _template(title, "Sales", rate, leaf)
+        for title, rate, leaf in purchase_taxes:
+            _template(title, "Purchase", rate, leaf)
+
+        return summary
+
+    return de_setup_tax