我不是开发者，我是财务运营。我仍然在浏览器中构建了一个符合 KoSIT 标准的 XRechnung 生成器

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文。

Background

我的日常工作是财务运营和会计，而不是软件工程。在 DACH 区域，会计师需要的东西 与 开发者构建的东西 之间的差距是真实且昂贵的——于是我决定亲自弥合这一差距。

法规背景

德国的 E‑Rechnungspflicht 已不再是理论上的要求。

• B2G（企业对政府）发票多年来一直要求使用有效的 XRechnung。
• B2B 推广分阶段进行：自 2025 年起接收，自 2027 年起对年收入超过 €800 k 的企业强制开具，自 2028 年起广泛采用。

即使是完美的 PDF 也不足够。

现有解决方案

缺失的中间

需要每季度向公共机构（例如汉堡市政府）开具发票的自由职业者、单人咨询公司以及 Kleinunternehmer 缺乏合适且低成本的解决方案。这正是我为之构建此工具的对象——也为我自己。

Solution: Browser‑Native XRechnung Generator

• Zero‑server, zero‑account: 所有处理均在浏览器本地完成；数据不会离开您的机器。
• Live demo: (local‑first, zero tracking)
• Validation: KoSIT Validator v1.6.2 (Config v3.0.2) + EN 16931。支持 UBL 2.1 和 UN/CEFACT CII 两种语法。
• Source code: (MIT license)

Key Characteristics

• Invoice data（客户名称、项目描述、金额、IBAN）是高价值数据。
• XML generation、PDF rendering 和 pre‑validation 完全在浏览器中运行。
• Network traffic: 零出站请求（已通过 DevTools 网络面板验证）。

开发方法

我的角色更像是架构师/协调者，而不是“整天写代码”的开发者。工作流程：

1. 阅读 EN 16931 规范，并将领域模型映射为 TypeScript 类型。
2. 根据规范定义验证规则。
3. 实现生成器，保持领域模型 语法无关（同一个 Invoice 对象可以生成 UBL 2.1 和 CII 两种格式）。

AI 辅助

实现的部分工作在我的架构下由 AI（Claude Code / Codex）协助完成，随后进行人工审查和验证循环。这迫使我对标准有深入理解，因为你无法通过“提示”来绕过你不懂的 KoSIT 架构验证错误。

最难的挑战

构建一个能够同时输出 UBL 2.1 和 CII 的强类型领域模型，而不在各处加入分支逻辑。相同的发票对象能够产生两种语法输出，保持核心模型的简洁。

部署

• 每次推送到 master 都会触发一个 GitHub Actions 工作流，构建并部署到 Cloudflare Pages。
• 不涉及服务器、容器或数据库。
• 静态资源会被缓存于 Cloudflare 边缘节点，带来几乎为零的延迟（“文件已经在那儿”）。

经验教训

• 在动手写代码前先阅读完整的 EN 16931 + CIUS 背景。
• XRechnung 并非“只是带有德国特性的 XML”。它在 EN 16931 Core、CIUS 和 KoSIT 配置文件要求之上叠加。
• 仅 URN 标识符就花了两天时间才弄对，即使发票数据正确，也常导致验证失败。
• 类型化常量（const values in TypeScript）消除了整类错误——值得提前了解。

征求反馈

如果您使用过 XRechnung、EN 16931 或 Peppol：

• 在生产环境中，您最常看到哪些验证错误？
• 您的客户的 ERP 系统是使用 UBL 还是 CII？
• 哪一个缺失的功能能让此生成器对您更有用？

技术拆解

完整的架构和代码演练可在以下位置获取：