SAP S/4HANA 迁移常见问题

这是 S/4HANA 迁移的两种根本不同的方式：

System Conversion（Brownfield，棕地）：在现有 ECC 系统上直接升级转换，保留所有历史数据、配置和自定义开发。系统经历的技术步骤是：ECC → 数据库迁移到 HANA → 升级到 S/4HANA（SUM 工具执行）。

Landscape Transformation（选择性数据迁移）：使用 SAP DT（Data Transfer and Replication）工具，从 ECC 系统中选择性地迁移数据到全新的 S/4HANA 系统。可以只迁移必要的历史数据，同时重新设计业务流程。

New Implementation（Greenfield，绿地）：全新实施 S/4HANA，不迁移历史数据，重新设计业务流程和系统架构。

选择建议：如果现有系统使用良好、历史数据需要保留，选择 Brownfield；如果希望业务流程重构、清理历史包袱，选择 Greenfield；如果希望保留部分数据同时优化流程，考虑 Bluefield（选择性迁移方案）。

迁移周期取决于多种因素：

注意：以上为整个项目周期，包括准备、实施、测试和上线。实际的技术迁移（SUM DMO 运行）通常在周末完成，对于大型系统可能需要 24-48 小时的停机时间。

在启动 S/4HANA 迁移前，必须满足以下前提条件：

• 源系统版本：ECC 6.0 EhP0 及以上版本均可转换，但建议至少升级到 EhP5+。EhP7/EhP8 最佳。
• Unicode：源系统必须是 Unicode 系统（非 Unicode 系统需先完成 Unicode 转换）。
• 数据库：支持从 AnyDB（Oracle、DB2、SQL Server、MaxDB）和 SAP HANA 转换。
• SUM 版本：使用最新版本的 SUM（Software Update Manager），支持 DMO（Database Migration Option）。
• SAP Solution Manager：建议 7.2 SP10+，用于 Readiness Check 和项目文档管理。
• 自定义代码清理：在迁移前完成自定义代码评估和清理，减少迁移风险。
• 数据量管理：评估并清理不必要的历史数据，减少迁移时间和存储需求。
• 增强包状态：源系统应处于一致的增强包状态，无未完成的传输。

Readiness Check 是 SAP 提供的免费自助服务工具，用于评估现有 ECC 系统向 S/4HANA 迁移的可行性：

• 访问方式：通过 SAP ONE Support Launchpad（support.sap.com/readinesscheck）访问。
• 工作原理：从 SAP Solution Manager 收集系统数据，上传到 SAP 云端进行分析，生成详细的评估报告。

报告内容包括：

• 简化项（Simplification Items）适配工作量评估
• 自定义代码的 S/4HANA 兼容性分析（使用 ATC 检查）
• 数据量和增长趋势分析
• 已安装的附加组件（Add-on）兼容性
• 业务伙伴（CVI）转换状态
• 推荐的迁移路径和时间估算
• 活跃业务功能（Business Functions）列表

建议在项目启动前 3-6 个月运行 Readiness Check，为项目规划提供数据支撑。

数据准备是迁移成功的关键，主要包括：

1. 数据量分析：使用 TAANA（Table Analysis）或自定义程序分析各表的数据量，重点排查超大表。
2. 数据归档：对 FI、MM、SD 等模块的历史数据进行归档，减少迁移数据量。使用 SARA 事务码执行归档。
3. 数据一致性检查：运行 SDCCN 检查系统一致性，修复已知的数据库不一致问题。
4. 清理无用数据：删除临时表数据、清理旧的后台作业日志、删除未使用的客户端。
5. 业务伙伴准备：提前完成 CVI（客户/供应商集成）转换，确保所有客户和供应商已创建对应的 Business Partner。
6. 自定义代码清理：删除不再使用的自定义程序，减少 ATC 检查的工作量。

Simplification List 是 SAP 发布的文档，列出了 S/4HANA 中所有与 ECC 相比的功能简化项和变更项：

• 获取方式：通过 SAP ONE Support Launchpad 下载，或从 SAP Help Portal 获取。每个 S/4HANA 版本都有对应的简化列表。
• 简化项类型：
  • 功能删除：ECC 中存在但 S/4HANA 中已移除的功能
  • 功能替代：用新的解决方案替代旧功能
  • 数据模型变更：表结构的变化（如合并、拆分、新增）
  • 流程变更：业务流程的调整
• 影响评估：每个简化项标注了影响范围（如影响自定义代码、影响业务流程、影响配置等）。
• 典型简化项：特别总账标识的变更（S/4HANA 中不再支持部分标识）、物料号长度扩展（从 18 位到 40 位）、FI/CO 统一凭证（Universal Journal）、客户/供应商集成为 Business Partner 等。

S/4HANA 引入了多项重大数据模型变更，以下是核心新表：

重要提示：S/4HANA 为许多被替代的旧表提供了兼容性视图（Compatibility View），使得部分旧代码仍可运行，但建议在迁移过程中逐步迁移到新数据模型。

ACDOCA 是 S/4HANA 最核心的数据模型变更，将 FI 和 CO 的行项目数据合并到一张表中：

主要变化：

• FI 凭证和 CO 凭证不再分别存储，统一在 ACDOCA 中
• 不再需要 FI/CO 对账（因为只有一套数据源）
• 支持实时利润中心会计（无需单独执行利润中心分配）
• 科目余额可直接从 ACDOCA 汇总，不再需要余额表

对开发的影响：

• 直接读取 BSEG 的程序需要评估是否可以改为读取 ACDOCA
• 自定义的 FI/CO 报表需要重写查询逻辑
• 使用 COEP/COEP_CA 的程序需迁移到 ACDOCA
• BSEG 表仍然存在但为兼容性视图，读取性能可能下降

在 S/4HANA 中，Business Partner（BP）是客户和供应商主数据的唯一入口。这意味着：

• 强制要求：所有客户和供应商必须先创建 Business Partner，再扩展客户/供应商角色。不能再通过 FD01/FK01 直接创建。
• 迁移影响：ECC 中已有的客户和供应商必须转换为 BP，这个过程称为 CVI（Customer Vendor Integration）。
• 转换工具：使用事务码 CVI_ECC_VENDOR_LINK 和 CVI_ECC_CUSTOMER_LINK 进行转换。也可以使用 report CVI_COCKPIT 统一管理。
• 数据映射：KNA1（客户常规数据）→ BUT000（BP 常规数据）；LFA1（供应商常规数据）→ BUT000。
• 编号策略：可选择 BP 编号与客户/供应商编号一致（内部/外部编号），或使用独立的编号范围。

CVI 转换是 S/4HANA 迁移中最复杂的步骤之一，建议提前规划和执行：

1. 前置检查：使用 CVI_COCKPIT 中的"一致性检查"功能，检查客户和供应商数据的完整性（如缺少地址、税务信息等）。
2. 数据清理：修复重复的客户/供应商记录、缺失的必填字段、不一致的组织级别数据。
3. 配置准备：定义 BP 编号范围、BP 角色映射、BP 分组策略。
4. 执行转换：在迁移的预处理阶段（SUM 工具的 DOWNTIME 前或期间），运行 CVI 转换程序。
5. 验证结果：检查 BP 与客户/供应商的关联关系，确认所有记录已成功转换。

注意事项：CVI 转换不可逆！务必在测试系统中多次演练，确认数据质量后再在生产系统中执行。

自定义代码的适配是 S/4HANA 迁移中工作量最大的部分之一。主要影响包括：

推荐使用 SAP 提供的 ATC（ABAP Test Cockpit）工具进行批量检查：

1. 配置 ATC 检查：在事务码 ATC 中配置 S/4HANA 专属检查变体（Check Variant），包含 S/4HANA 相关的检查规则。
2. 执行批量检查：使用事务码 SAT 或 SE80 中的 ATC 批量检查功能，扫描所有自定义代码。
3. 分析检查结果：ATC 会按严重程度分类报告问题，包括必须修复（红色）和建议修改（黄色）。
4. 优先级排序：
   • 优先修复访问被废弃表的代码
   • 然后修复字段长度不兼容的代码
   • 最后处理性能优化建议

SAP 也提供了 Custom Code Migration app（Fiori 应用），以可视化方式展示自定义代码迁移的影响评估。

S/4HANA 支持物料号长度从 18 位扩展到 40 位，这是一个可选但影响深远的变更：

• 数据元素变更：MATNR 数据元素从 18 位变为 40 位，所有引用 MATNR 的字段自动扩展。
• 自定义代码影响：
  • 硬编码 18 位长度的变量需要扩展
  • 与物料号相关的 ALV 字段目录需要调整
  • 接口程序中物料号字段的长度需要同步修改
  • 与外部系统交换的文件格式需要调整
• 不启用 40 位的后果：如果选择保持 18 位，部分 S/4HANA 新功能可能不可用，且未来版本可能强制 40 位。
• 建议：新实施的项目直接启用 40 位；迁移项目可在迁移时暂不启用，但应规划后续扩展。

SUM（Software Update Manager）with DMO（Database Migration Option）是 Brownfield 迁移的核心工具，主要步骤如下：

1. 准备阶段（Preprocessing）：
   • 下载 S/4HANA 安装包和 SUM 工具
   • 配置 SUM 参数（profile 文件）
   • 执行 Readiness Check，确认前提条件
2. 初始化阶段（Initialization）：
   • SUM 读取源系统信息，计算所需空间
   • 创建 shadow repository（影子仓库）
   • 开始导入 S/4HANA 软件
3. 停机阶段（Downtime）：
   • 锁定源系统，阻止用户访问
   • 执行数据库迁移（AnyDB → HANA）
   • 应用 S/4HANA 升级
   • 执行 CVI 转换
   • 运行数据模型转换（如 ACDOCA 迁移）
4. 后处理阶段（Postprocessing）：
   • 清理影子仓库
   • 更新统计信息和索引
   • 执行 S/4HANA 特有的配置步骤
   • 解锁系统，开放用户访问

减少停机时间是迁移项目的核心关注点，以下策略可显著缩短停机窗口：

• DMO with System Move：在新的 HANA 服务器上执行迁移，源系统在迁移期间仍可使用，仅在最终切换时停机。
• 预加载（Preload）：SUM 支持在停机前预先导入部分数据到 HANA，减少停机期间的数据迁移量。
• 数据量优化：在迁移前归档和清理不必要的数据，减少需要迁移的数据量。
• 硬件准备：确保 HANA 服务器有足够的 CPU 和内存，使用 SSD 存储提升 I/O 性能。
• 多次演练：在测试环境中进行至少 2-3 次完整迁移演练，优化每个步骤的耗时。
• 自定义代码预处理：在迁移前完成所有必须的代码修改，避免迁移后因代码不兼容导致系统无法使用。

迁移上线只是开始，迁移后的优化和适应工作同样重要：

• 性能优化：S/4HANA 的数据模型和 HANA 数据库带来了全新的性能特征，需要重新评估和优化：
  • 利用 HANA 的列存储特性，将频繁读取的表转为列存储
  • 使用 CDS View 替代传统的 ABAP 报表
  • 调整 HANA 内存参数和索引策略
• 自定义代码重构：迁移后的临时适配代码需要逐步重构：
  • 将访问兼容性视图的代码迁移到新数据模型
  • 使用 CDS View 和 OData 替代传统 ALV 报表
  • 利用 S/4HANA 新语法和 API 重构旧代码
• Fiori 启用：配置和部署 Fiori Launchpad，将关键业务场景迁移到 Fiori 应用。
• 用户培训：S/4HANA 的界面和操作逻辑与 ECC 有显著差异，需要进行系统性的用户培训。
• 持续监控：使用 SAP Solution Manager 监控系统性能和稳定性，及时发现和解决问题。
• 功能激活：S/4HANA 提供了大量新的最佳业务实践（Best Practices），根据业务需求逐步激活和实施。