客户无需盲目等待任何构建阶段。每个工作会话都遵循相同的流程，在客户自己的租户环境中，使用客户提供的示例数据在真实屏幕上进行：显示 Fit Ledger 行，实时无代码配置，客户驱动更改，使用示例数据进行验证，记录更改并勾选该行。
如果客户不在会话中，则会话不会进行。关键用户应在 T-14 之前完成操作；如果 TRANXACT 在 T-13 时仍在键盘前，则应在站会上将其作为采用风险提出。
交易前七天的结构（拟议默认值）
| 感恩节 | 重点 | 已配置 |
|---|---|---|
| T-17 | 结构 | 实体、会计科目表、会计日历、维度 |
| T-16 | 资金与合规 | 货币和外汇、税码、文件编号、银行 |
| T-15 | 人员与通道 | 角色和权限、SSO 组、审批层级 |
| T-14 | 主数据 | 客户、供应商、物品、员工——ASK 从提取物中批量创建 |
| T-13 | 流程与规则 | 审批流程、发布、匹配和定价规则 |
| T-12 | 模块详情 | CRM流程、供应链成本核算、人力资源薪酬要素、模块切换 |
| T-11 | 集成与队列 | API客户端、银行/税务/工资单端点、按角色划分的队列 |
即使 Fit Ledger 的顺序不同，也要保持顺序：结构优先意味着迁移映射可以从 T-15 开始，并且所有其他内容都依赖于 GL 映射，而 GL 映射在主数据之前就存在。
ASK 负责繁重体力劳动
从数据提取中批量创建 2400 个客户，并按客户细分划分付款条款；制定按收货仓库成本中心拆分运费的过账规则；生成一个应付账款文员，该文员可以录入但无权审批超过 10000 张发票；列出所有审批流程，无需备用审批人。ASK 在与人工点击相同的权限和审计日志下完成这些操作，并且关键用户会在选中该行之前审核每个结果。
听起来像代码的请求
| 我们需要…… | 回答这个问题的配置 |
|---|---|
| 我们独特的审批流程 | 包含金额、实体和维度规则的多步骤审批流程 |
| 自定义发票布局 | 每个实体包含字段、徽标和语言的文档模板 |
| 不存在的字段 | 无需编写代码的自定义字段，可在报表和规则中使用 |
| 我们的原稿报告与原稿完全一致 | 报表生成器或仪表板——质疑布局；通常“不需要” |
| 与银行或MES的接口 | 具有特定作用域角色的 API 客户端；必要时可进行文件交换。 |
| 当 X 发生时发出警报 | 角色感知操作队列规则 |
时钟上的集成（建议默认值）
列表和所有者在 T-18 之前完成；API 客户端和合作伙伴测试端点在 T-13 之前完成；集成测试在 T-10 之前完成（工资单在 T-9 之前完成，BI 在 T-6 之前完成；SSO 在 T-17 之前完成，因为彩排需要它）；端到端测试在 T-3 之前完成；生产切换在 T-0 之前完成。
如果合作伙伴无法在 T-13 之前提供测试端点，则需通过手动过渡步骤将该集成迁移到 T-Plus 系统——包括手动上传银行文件、财务部门上传门户网站数据以及在旧系统中运行工资核算并导入日记账。单点登录 (SSO) 没有过渡步骤：它是演练的必要条件。
卡尔德伍德的银行按时提供了测试终端；但其税务门户网站的沙盒环境在 T-13 时仍未发布。税务整合成为 T-Plus 流程的一部分，财务部门在前几周需要手动将电子发票上传到门户网站——就像其他所有环节一样，在 T-1 时进行了演练。
试试看 在 T-12 系统中，一位关键用户要求供应商发票界面显示旧系统中存在的一个字段。这是代码吗？
不，它是表单上的一个无需编写代码的自定义字段，可用于报表和规则。它会获取一个 Fit Ledger 行，在由关键用户驱动的会话中进行配置，使用示例数据进行验证，记录在配置工作簿中，并在测试计划中进行配置检查。