Four parallel read-only analyses of maptara_302 — every model, view, ACL, seed file and both accompanying documents — with file:line on every claim. It will not install. After the one-line fix, it is a well-wired set of data-entry forms in which no billing process ever runs.
evidence/ticket-1319/analysis/ ·
07 how it lands on the architecture · hubfirst data file, line 10 — one fix
true · partial · false · stub
have real branching · 2 of those never called
22 identical + 21 renamed
1. It does not install. security/maptara_302_groups.xml:10 writes category_id on res.groups. Odoo 19 removed that field. create() raises ValueError("Invalid field 'category_id' on model 'res.groups'"). Four lines to fix.
2. After that, the wiring is clean — genuinely. 48 views, 23 actions, 25 menus, 113 ACL rows: 0 dangling fields, 0 dangling methods, 0 dangling XML-IDs, 0 forward references, 0 deprecated view syntax, verified by a cross-reference script that was itself shown to catch six injected defects. The schema is the part Lovable is good at.
3. No billing process runs. No bundling ever executes. No account.move is ever posted. No file touches a directory. No cron exists. DAVASO and encryption are hard-coded mocks. Eight of 23 action methods have no button. Cases enter a run only after a human types them into a paper line by hand.
4. The docs describe the schema accurately and the process aspirationally. 46 of 142 claims are true; almost all of them are about fields and state names. The 44 false-or-stub claims are almost all about things happening.
maptara.claim.request wearing a German name. Bottom: the process code is nine methods, and the one that claims to post invoices posts nothing.provider_id is a bare Many2one read by nothing in the slice (fall.py:47, lauf.py:70). account.move is never created — the only hit is the field declaration at fall.py:57, despite depends: account.papier.py:119, after a human has typed the case into a paper line by hand. Filter domains are stored as text and never evaluated — zero hits for safe_eval / literal_eval.maptara.302.sammelgruppe cannot be created. No code creates it; the form cannot satisfy signatur — required, readonly, no default (lauf.py:221). So bundling never happens, pruefe_signatur (:238) has zero callers, the six seeded rules are never read, and whatever cases land on one export go into one flat ESOL regardless of DAS, Rechnungsart or Pflegehilfsmittel. The TA21 minimum separations are unenforced, silently.lauf.py:116-117), write() raises (:48-49) — but unlink is open and cascades from the run (:35), and the run's guard checks for finalisiert / abgeschlossen (:200), which no method in the module ever assigns.claim.request / claim.batch / account.move(.line), 21 the same concept renamed, 22 new — of which LEGS, Abrechnungscode and Vertrag already exist elsewhere in the repo.UNB, UNH, SLLA, UNZ) joined by \n; no ' terminators, no UNA/UNT, no SLGA at all, none of the 14 SLLA body segments the spec lists. The "format profile" is never read (export.py:178-198).return b"-----MAPTARA-CMS-----\n" + inhalt (:209). groesse_krypt is therefore always groesse_klar + 22; verschluesselungsstatus = "verschluesselt" is set unconditionally (:196). The non-mock branch calls self.env["maptara.302.krypto"] — a model defined nowhere (:210).ok (davaso.py:80-81). Endpoint set → raise UserError (:82). That is the whole adapter. The status values nicht_erreichbar / auth exist and can never be emitted.action_bereitstellen is three field writes and an audit row (dakota.py:39-53); zero filesystem calls; and the view has no button for it. duplikat_hash has zero writers and its "unique constraint" is a _sql_constraints tuple Odoo 19 ignores.ruecklauf.py has zero methods. Nothing imports, matches, parses or escalates a return.export.py:307). state, all IKs, the case set and zahlungsstatus remain writable after finalisation; the DAVASO button can re-state a finalised export; unlink() is two field writes away (:316).aufloesen() raise on no-hit and on ties (parametersatz.py:112-119, ik_umlenkung.py:49-53). But "rank" is the bare integer prioritaet: a global rule and an LE-specific rule at equal priority is a hard error, not a specificity win, and version is never consulted. Worth stealing the pattern, not the code.unique(version), Produktbereich unique(code), Dakota unique(duplikat_hash) — all _sql_constraints, all logged-and-ignored by Odoo 19. IK-Umlenkung has no constraint of any kind.if not (datei.hash_wert and datei.signatur) (kotr.py:48) — a non-empty-string test. 3 of 8 lokaler_status values are never written; parser_version is never compared.create/write hook — editing a parameter set or an IK rule writes nothing. Systemadmin has 1,1,1,1 on the audit table, including unlink.company_id on 3 of 28 models; 0 restrict by service provider. Credentials are neither masked nor shown — api_key / client_id / client_secret carry groups= and appear in no view; benutzername, api_url, sftp_host are readable by every group.330100112 fails the check digit (computed 4, actual 2). The other two pass.security/maptara_302_groups.xml:10 sets category_id on res.groups; in Odoo 19 that field lives on res.groups.privilege. create() raises ValueError. It is the first data file in the manifest. Four lines to fix.attrs=/states=/<tree> across 48 views, 23 actions, 25 menus, 113 ACL rows. Verified by a cross-reference script that caught 6 of 6 injected defects. Remaining install is a static expectation — a real -i on a scratch DB is the next step, not this report.ir.cron at all (§1.1, §8.1); logical recipient never routed via KOTR (empfaenger_ik is a plain Char, never assigned); sammelrechnungsnummer does not exist as a field; no "ready for Dakota" flag; no temp-name-then-rename; no tests/ directory; no cockpit; no service-provider menu.action_bereitstellen and action_verbindung_testen.| From the module | Take as |
|---|---|
| The field list — 6 IK kinds, DAS, Rechnungsart, route, bundling signature, Klärstatus | Column names on maptara.claim.submission. ~19 genuinely new concepts. |
| The state names — paper 14, export 9, Dakota 8 | Vocabulary for the submission lifecycle. Trim before adopting: several are never set by anything. |
| Unique-or-lock resolution — refuse on ambiguity | The pattern. Same as the design's "never default an endpoint". Re-implement with specificity, not bare priority. |
| The four-role model and a consistent 112-row ACL matrix | Reference when the §302 groups are defined. Fix the audit-table unlink first. |
| Spec §7, §8, §24 — EDIFACT structure, segments, TA21 separations | The actual requirements for the DTA plugin. This is the part Lovable was fed, and it is fine. |
Nothing structural — 07's four issues stand and get sharper numbers. Issue 4 ("the scaffold will be mistaken for progress") now has its evidence: 46 true claims out of 142, and the true ones are field names. The one-line message to Volker is unchanged: the workflow and the concepts are adopted; the code is reference; direct DTA is Release 2 on the existing contract.
Method: four parallel read-only analyses, each with an explicit stop condition, each writing its own report with file:line on every claim. Two of B's sharpest claims (maptara.302.krypto undefined; _sql_constraints form) were re-verified against source before publication. D's cross-reference script was validated against six injected defects. Reports: evidence/ticket-1319/analysis/{A,B,C,D}-*.md, 1 054 lines total.
Internal. Nothing here is implemented; nothing in the analysed module was modified.