TIP

通常业务的数据操作都是非常复杂的，简单的Instant API基于单表数据的写入和更新无法满足复杂业务的流程编排，尤其是涉及到金融计算、多表数据一致性甚至事务的保障等，需要100%确定的工程体系中确保业务流程的确定性。

让业务动作稳定写回系统

本页用 CRM 里的「报价单生成订单」说明什么时候不能只做单表写入。这个动作要同时写订单主表、订单明细，并更新报价单和销售机会。为了保证数据 100% 准确，执行过程要么全部成功，要么全部失败，所以需要用 Backend Function 封装成一个稳定服务。

CRM 里的具体需求：报价单生成订单

销售已经给客户出过报价，客户确认接受报价。销售在 CRM 里执行「生成订单」时，系统不能只新增一条订单记录，因为订单金额、商品明细、报价单状态和商机阶段必须一起变化。

在本教程的 CRM 示例里，这个需求可以这样描述：

基于一个已确认的报价单生成订单：创建订单主表，复制报价单明细为订单明细，更新报价单状态为已转订单，同步销售机会阶段为已成交或待履约；执行前展示将写入哪些表，执行后返回订单 ID、明细条数、订单金额和每张表的更新结果。

业务要求	CRM 里的具体动作	为什么单表不够
生成订单	写入订单主表	只有订单主表没有商品明细，后续履约、发货、对账都无法使用
保留购买明细	从报价单明细复制商品、数量、单价、折扣到订单明细	明细漏写或少写会导致金额、商品和客户实际购买内容不准确
防止重复转单	更新报价单状态为已转订单	不更新报价状态，同一张报价单可能被再次生成订单
同步销售阶段	更新销售机会阶段和成交时间	不同步会让销售漏斗、主管看板和实际成交情况不一致
失败可回滚	任一步失败都不保留半成功数据	客户、销售、财务必须看到同一个业务事实

操作人

实施人员、管理员、技术负责人。

先确认一次动作影响哪些数据

本教程使用的 CRM 示例里，一次「报价单生成订单」至少会碰到这些数据集和字段：

数据集	物理表	关键字段	用途
报价单主表	crm_quotation	id、customer_id、opportunity_id、status、total_amount	校验报价单是否可转订单，并更新报价状态
报价单明细	crm_quotation_item	quotation_id、product_id、quantity、unit_price、discount	读取需要复制到订单里的商品明细
订单主表	crm_order	id、customer_id、quotation_id、total_amount、status	创建订单主体记录
订单明细	crm_order_item	order_id、product_id、quantity、unit_price、discount	写入订单商品明细
销售机会	crm_opportunity	id、stage、won_time、order_id	同步商机阶段和成交信息
客户信息	crm_customer	id、owner_id	校验客户和负责人

如果客户自己的系统里是工单、合同或项目结算，也按同样方式列出「本次动作会新增哪些记录、更新哪些状态、写入哪些日志」。

方式一：在 Claude Code 里用 rabetbase 实现

把下面 prompt 粘贴到 Claude Code。prompt 只描述业务需求和交付约束，不需要逐条写 rabetbase 命令；Claude Code 会自行拆解任务，并用 rabetbase 完成应用、数据集、Backend Function、dry-run 和推送检查。

请帮我在当前 Lovrabet 应用中实现一个 Backend Function：createOrderFromQuotation。

业务场景：
我们以 CRM 为案例。销售已经给客户出过报价，客户确认接受报价后，需要把这张报价单生成正式订单。

需要实现的业务动作：
1. 基于一张已确认的报价单创建订单主表。
2. 把报价单明细复制为订单明细。
3. 把报价单状态更新为已转订单。
4. 同步销售机会阶段和成交信息。
5. 防止同一张报价单被重复生成订单。
6. 任一步失败时，不留下半成功数据。

实现要求：
- 先识别当前应用里的真实数据集、字段、必填项、枚举值和关联关系，不要猜字段名。
- 先检查是否已经存在同名函数或可复用的公共函数。
- 函数需要支持 preview。preview 为 true 时，只返回将要写入和更新的计划，不修改业务数据。
- 正式写入前必须做字段校验、状态校验、金额校验和重复提交校验。
- 写入过程要保证订单主表、订单明细、报价单状态、销售机会阶段的数据一致性。
- 返回结果要包含 orderId、detailCount、totalAmount、updatedTables、operator、executeTime。
- 推送到平台前，先给出 dry-run 预览和影响范围。
- 未经我确认，不要正式推送或执行真实写入。

请最后输出：
1. 你识别到的数据集、字段和关联关系。
2. createOrderFromQuotation 的入参和返回结构。
3. preview 模式会返回的写入计划。
4. 正式写入时的执行顺序。
5. 一致性、防重复提交和失败处理方式。
6. dry-run 结果摘要。
7. 需要我确认后才能继续的操作。

rabetbase 正常会经历哪些步骤

flowchart TD
  A[确认应用和认证] --> B[读取数据集清单]
  B --> C[读取字段和关联关系]
  C --> D[检查已有 BFF / COMMON]
  D --> E[创建或同步本地 BFF 脚本]
  E --> F[编辑 createOrderFromQuotation]
  F --> G[自检字段、事务、幂等、返回结构]
  G --> H[查看 bff status]
  H --> I[push --dry-run 预览]
  I --> J{用户确认}
  J -->|否| K[继续修改本地脚本]
  J -->|是| L[bff push --yes 推送]
  L --> M[回平台核对 Backend Function]
  M --> N[按需运行态验证]

阶段	rabetbase 会做什么	查看重点
确认环境	读取命令契约、认证状态和当前应用	本机能运行 rabetbase，当前应用正确
读取数据模型	拉取数据集清单、字段、操作和关联关系	不猜字段名，以真实数据集为准
检查已有服务	查看 ENDPOINT 和 COMMON 函数	避免重复创建同名服务
生成本地脚本	在本地生成 Backend Function 脚手架	函数名、类型、脚本路径正确
编写服务逻辑	实现预览、校验、多表写入、状态同步、防重复提交	任一步失败时能返回失败原因
本地状态检查	查看脚本是新增、修改还是已同步	推送前知道会影响哪个函数
dry-run 预览	只输出将 create 或 update 的函数，不写入平台	确认推送范围和风险点
正式推送	用户确认后把脚本同步到平台	平台 Backend Function 能看到同名服务
运行态验证	用页面、Skill 或运行态 CLI 调用服务	返回订单 ID、明细条数和更新结果

方式二：在平台手动完成

不使用 Claude Code 时，也可以在平台完成同一件事。平台操作适合少量人工调整；复杂写入服务建议先用 rabetbase 生成和检查脚本。

1. 打开 App Management。
2. 点击 Dataset Overview，确认报价单、报价单明细、订单主表、订单明细、销售机会、客户信息等数据集已经识别。
3. 记录每个数据集的主键、外键、必填字段、枚举值和金额字段。
4. 点击 Backend Function。
5. 新建或编辑一个写入服务。CRM 示例可以命名为 createOrderFromQuotation。
6. 在函数里先做预览：返回将要创建的订单主表、订单明细条数、订单金额，以及将要更新的报价单和销售机会字段。
7. 用户确认后再执行写入。
8. 写入完成后返回订单 ID、明细条数、订单金额、更新过的数据集、失败原因或回滚结果。

截图指引：Backend Function 入口如下。多表写入、事务控制、预览和回滚逻辑从这里配置。

下一步

继续《把 SQL、BFF、Backend Function 接到 Skill》。