交易方合并与客户合并

Oracle TCA 交易方合并（Party Merge）与客户合并（Customer Merge）

本文档基于 Oracle Trading Community Architecture User Guide Release 12.1 (Part No. E13570-04) 第8章和第9章整理。

核心概念速览
第一部分：交易方合并（Party Merge）
- 2.1 概述
- 2.2 关键术语
- 2.3 合并流程
- 2.4 重复检查规则（各实体处理方式）
- 2.5 对 Source ID 和 D&B 数据的影响
- 2.6 操作步骤（界面级）
- 2.7 日志与错误处理
第二部分：客户合并（Customer Merge）
- 3.1 概述
- 3.2 税务验证
- 3.3 同一客户不同站点的合并
- 3.4 不同客户之间的合并
- 3.5 提交与执行报告
第三部分：Party Merge 与 Customer Merge 的关系
- 4.1 异同对比表
- 4.2 先后顺序场景示例
常见问题与避坑指南

核心概念速览

概念	英文	说明
交易方	Party	TCA Registry 中的实体（可以是组织或个人），是业务往来的基本主体
交易方合并	Party Merge	合并重复的交易方（Party层），处理Party Sites/Relationship等子实体
客户账户	Customer Account	挂在Party下的客户账户，包含AR应收模块的交易信息
客户合并	Customer Merge	合并重复的客户账户（账户层），处理发票/收款等AR交易
合并来源方	Merge-From Party/Source	被合并的旧记录
合并目标方	Merge-To Party/Target	合并后保留的记录
合并批次	Merge Batch	一次提交的一组合并请求

核心原则：

Party Merge 处理 交易方层 的重复（组织和人员）
Customer Merge 处理 客户账户层 的重复（AR相关）
两个合并是独立的并发请求，但可以联动执行
先合交易方，再合客户账户（推荐顺序）
合并后不可逆，必须先预览再执行

第一部分：交易方合并（Party Merge）

2.1 概述

Party Merge 是 Oracle TCA 提供的用于合并 TCA Registry 中重复交易方（Party）及其关联实体的功能。

为什么需要 Party Merge？

TCA Registry 是整个 E-Business Suite 共享的信息源
重复数据会降低交易方处理和报表的效率和准确性
例如：Vision Corp. 和 Vision Corporation 实际上是同一家公司，需要合并

Party Merge 的能力范围：

能力	说明
合并重复的交易方	如将 Vision Corp. 合并到 Vision Corporation
合并同一交易方下重复的站点	如某个Party下有两个相同的地址站点
合并交易方关系	Party之间的关联关系（如"联系人"、"子公司"）
合并联系人	组织交易方下的联系人
转移子实体	非精确重复的子实体会被转移而非合并

⚠️ 重要警告：

Party Merge 主要用于查重去重（De-duplication），也可用于并购整合（M&A），但必须充分测试。合并后，所有交易会被重指向到存活方，无法追溯被合并方的交易明细，也无法重印该方的发票。如果仍需对被合并方执行某些业务操作，则不应将其合并。

2.2 关键术语

术语	英文	说明
合并来源方	Merge-From Party	被合并的交易方，合并后状态变为 Merged 或 Deleted
合并目标方	Merge-To Party	保留存续的交易方
合并批次	Merge Batch	一组待合并的交易方或站点配对
合并状态 - 已合并	Merged	来源方标记为合并状态，记录仍在数据库中
合并状态 - 已删除	Deleted	来源方被物理删除，无法在任何搜索或交易窗口中检索到

2.3 合并流程

Party Merge 分为四个步骤：

Step 1: 创建合并批次（Create Merge Batch）
         ↓
Step 2: 处理合并批次（Process Merge Batch）
    → 预览模式（Preview）——不保存到数据库
    → 运行模式（Run Batch）——实际执行并保存
         ↓
Step 3: 审查合并日志（Review Party Merge Log）
         ↓
Step 4: 识别并修复错误（Identify Errors & Fix）

Step 1 — 创建合并批次：

操作路径：Merge Batch 窗口

关键规则：

只能合并同一交易方类型（Organizations跟Organizations，Persons跟Persons）
选中的交易方在批次处理完成前会被锁定，无法被其他批次选中
如果批次创建过程中出现错误，需在 Standard Request Submission 中查看 Create Merge Batch 程序的日志，修复后手动重新运行
批量原子性：整个批次必须全部成功处理，结果才会保存到数据库。如果一条记录出错，整个批次都不会合并。如需每条独立保存，每个配对单独创建一个批次
可以设置 HZ: Enable DQM Merge Suggestion 概要文件值为 'No' 来禁用 DQM 建议，提高性能

Step 2 — 处理合并批次：

提供三种处理选项：

方式	操作	说明
预览	Click "Preview Batch"	运行合并但不提交到数据库，可查看预期效果
立即提交	Click "Run Batch"	运行并保存合并结果
暂存提交	Save + 后续提交	保存批次后，稍后在 Standard Request Submission 中提交

预览模式的特点：

合并逻辑会执行，但结果不写入数据库
Merge Done 复选框不会勾选
Delete Merged Records 即使勾选也不会真的删除

运行模式的特点：

整个批次成功后才会保存到数据库
合并完成后 Merge Done 复选框会勾选
如果勾选了 Delete Merged Records，来源方会被设为 Deleted 状态

Step 3 — 审查合并日志：

日志内容：

报头	说明
Request ID	并发请求的ID
Log Message	合并顺序记录，包括开始时间、批次ID、批次名称、规则集、合并过程、已合并/转移的实体
Execution Status	执行状态（见下）

四种执行状态：

状态	说明
✅ 成功执行 / 批次回滚完成	预览模式成功运行，未保存
✅ 成功执行 / 批次提交完成	运行模式成功执行并保存到数据库
⚠️ 部分完成	部分记录未成功合并，但成功部分已保存。日志会详述错误
❌ 失败 / 批次回滚完成	合并过程未成功运行，无记录被保存

Step 4 — 识别与修复错误：

两种错误类型：

错误类型	原因	修复者
数据错误	记录中存在损坏数据，整个批次失败	业务用户可修正
过程错误	PL/SQL 过程编码/注册/测试不正确	开发人员或管理员

修复后，可在 Standard Request Submission 中重新提交 Party Merge 过程。

2.4 重复检查规则（各实体处理方式）

Party Merge 自动判断每个子实体是"合并（Merge）"还是"转移（Transfer）"：

规则： 如果基于表字段连接判断为精确重复 → Merge；否则 → Transfer。

实体类型	处理方式
联系点（Contact Points）	非精确重复 → 转移；精确重复 → 合并
联系偏好（Contact Preferences）	始终合并
客户账户（Customer Accounts）	转移到目标方。Party合并后，可再用Customer Merge合并账户
客户账户站点	取决于Party Site的处理方式：站点合并→指向目标；站点转移→跟随来源方
客户账户角色	指向来源方的改为指向目标方
客户联系点	指向目标方上对应的联系点

当Party为组织时：

子实体	判断规则
财务编号（Financial Numbers）	精确重复则合并，对应表 HZ_FINANCIAL_REPORTS
行业参考（Industrial Reference）	精确重复则合并，对应表 HZ_INDUSTRIAL_REFERENCE
组织指标（Organization Indicators）	精确重复则合并
证券发行（Securities Issued）	精确重复则合并

当Party为人员时：

子实体	判断规则
国籍（Citizenship）	精确重复则合并
教育（Education）	精确重复则合并
工作经历（Employment History）	精确重复则合并
个人兴趣（Person Interest）	精确重复则合并
语言（Person Language）	精确重复则合并
工作类别（Work Class）	精确重复则合并

对组织和人员均适用的：

子实体	判断规则
认证（Certifications）	精确重复则合并
信用评级（Credit Ratings）	始终转移（除非提供该信用信息的应用有自己的查重机制）
财务画像（Financial Profiles）	精确重复则合并
参考信息（References）	精确重复则合并

2.5 对 Source ID 和 D&B 数据的影响

Source ID 处理：

来源方的 Source ID 会被转移到目标方
如果同一来源系统不允许一个 TCA 记录映射多个 Source ID，则只有目标方的映射保持活跃
D&B 是唯一永远不允许一个 Party 映射多个 Source ID 的来源系统
示例：Oracle 1（Gorman:10001, D&B:22222）→ 合并到 Oracle 2 → Oracle 2 获得 Gorman:10001（新增）+ Gorman:10002（原有），但 D&B:33333 保持不变，D&B:22222 失活

D&B 数据处理：

场景	处理方式
D-U-N-S 编号不同	保留目标方的 D&B 数据，来源方 D&B 设为 Merged
D-U-N-S 编号相同	保留最新的 D&B 数据（可能是来源方的）
仅有来源方有 D&B 数据	来源方的 D&B 数据转移到目标方
来源方是目标方的分支	保留目标方的 D&B 数据
来源方是目标方的总部	来源方的 D&B 数据复制到目标方，目标方成为新的总部。来源方原来的所有分支归属到目标方

2.6 操作步骤（界面级）

创建交易方合并批次：

导航到 Merge Batch 窗口
输入唯一且相关的批次名称
选择合并原因（预定义或自定义）
勾选 Delete Merged Records（合并完成后删除来源方记录）；不勾选则来源方状态设为 Merged
在 Party Details 区域，输入需合并的 Party 配对（含 Party 类型和合并原因）
保存后再进入选项卡区域
可选：在 Party Sites / Party Relationships / Org Contacts 选项卡中细化合并操作

合并 Party Sites：

在 Merge Batch 窗口中进入 Party Sites 选项卡
输入来源站点地址和操作方式（Merge 或 Transfer）
如果选择 Merge，必须输入目标方站点地址

合并 Party Relationships：

进入 Party Relationships 选项卡
对每个关系，输入 Subject、Object 和关系类型
选择操作（Merge 或 Transfer）
如果选择 Merge，需在 To Relationships 区域输入目标方关系

注意： 此选项卡不显示人员作为联系人/员工/成员的关系（这些在 Org Contacts 选项卡中处理）

合并 Organization Contacts：

进入 Org Contacts 选项卡
输入联系人姓名和职位
选择 Merge 或 Transfer
如果选择 Merge，需输入目标方的组织联系人

查看 Profile 信息： 在 Person Profiles 或 Org Profiles 选项卡中查看双方合并前的画像信息（如税号、税登记号、生日、D-U-N-S 编号等）

合并同一 Party 下的重复站点：

在 Merge Batch 窗口中输入批次名称和原因
确保 Delete Merged Records 不勾选
勾选 Site Merge（目标方自动填充为来源方）
保存后在 Party Sites 选项卡中输入所有待合并的站点

2.7 日志与错误处理

日志查询： Standard Request Submission → Party Merge 过程 → 查看输出

常见数据错误： 损坏数据导致的批次级失败，用户可自行修正
常见过程错误： PL/SQL 代码问题，需要开发人员介入

重新提交失败批次：

在 Standard Request Submission 中查找失败的合并
修复错误
输入 Merge ID（合并自动追加在批次名称末尾的数字）重新运行

第二部分：客户合并（Customer Merge）

3.1 概述

Customer Merge 用于合并在 Oracle Receivables 中的重复客户账户（Customer Account）。

合并后会发生的动作：

被合并方（旧客户/站点）的所有交易活动转移到目标方
涉及的范围包括：发票、贷项通知单、承诺、信用、收款、调整、退单
同时检查 AutoInvoice 接口表中的记录
通过 Source System Management（SSM）保留与外部系统的链接

合并对象：

对象	说明
同一客户的不同站点	如客户关闭一个地点，将活动转移到另一个地点
不同客户的全部站点	如并购后合并两个客户的所有活动

预定义的站点用途（Site Uses）：

Bill-to（开单地址）
Ship-to（收货地址）
Statements（对账单地址）
Marketing（营销地址）
Legal（法律地址）
Dunning（催款地址）

只能合并相同用途的站点（Bill-to 只能合并到 Bill-to，Ship-to 只能合并到 Ship-to）

合并个人与组织：
Customer Merge 可以合并个人（Individuals）和组织（Organizations），两者可以互相合并。

示例：某个人以个人名义下了几笔订单，但后来发现这些采购是代表一家已有客户的公司完成的，可以用 Customer Merge 将个人合并到公司账户中。

决定 Inactivate 还是 Delete：

Inactive（不活跃状态）：保留审计线索。旧客户状态变为 Inactive，无法产生新交易，但随时可以查看或重新激活
Delete（删除）：从数据库中物理删除，不保留审计线索
注意：不能直接删除一个客户。 必须通过 Customer Merge 将要删除的客户（From Customer）合并到一个虚拟客户（To Customer），并勾选 Delete After Merge

Inactivate / Delete 的可行条件：

条件	可 Inactivate	可 Delete
站点仅在你的访问权限的 OU 内	✅	✅
其他 OU 中有不活跃站点	✅	❌
其他 OU 中有活跃站点	❌	❌

你只能在你有访问权限的 OU 中合并站点用途

第三方应用自动合并：

同时持有以下应用的，运行 Customer Merge 时自动处理这些应用中的相关交易：

应用	应用
Customer Service	Federal Financials
Grants Accounting	Inventory
Master Scheduling / MRP	Order Management
Payables	Pricing
Projects	Property Manager
Public Sector Financials	Purchasing
Quality	Shipping
Training Administration

3.2 税务验证（Tax Validation for Merge）

税务验证是合并的前提条件：

地址类型	合并条件
已在 Geography Hierarchy 中设置税务验证	城市、县、州等选中的地址元素必须完全一致
未设置税务验证	国家相同即可合并
混合类型（部分有验证，部分无）	不能合并

3.3 同一客户不同站点的合并

场景： 客户关闭一个站点，将该站点的所有活动转移到另一个现有站点。

前置条件：

可选：先完成 AutoInvoice 处理（减少接口表行数，提高效率）
可选：运行 Customer Listing 报表查看客户详情
创建映射图：明确哪些用途要合并到哪个站点
决定是 Inactivate 还是 Delete 旧站点信息

操作步骤：

导航到 Customers Merge 窗口
在 From 区域，选择客户类型（Organization/Individual）和客户名称/编号
选择 Operating Unit（或选 All 合并所有可访问 OU 中的账户站点）
选择合并原因（De-duplication 或 Merger）
在 To 区域，输入同一个客户的名称或编号
在 From 区域，选择要合并的每个站点
在 To 区域，输入新的地址
设置处理优先级（P1-High / P2-Medium / P3-Low）
点击 Merge 提交（弹出 Continue/Save 选项）
- Continue = 立即处理
- Save = 暂存，后续批量处理

重要： 合并同一客户的站点时，不可以设置 Delete After Merge 为 Yes。

3.4 不同客户之间的合并

场景： 公司收购了另一个公司，需要将两个客户合并。

特殊规则：

必须合并被合并方所有的站点用途（不能只合并部分）
必须将旧客户的所有站点用途分配到新客户的一个或多个站点用途
如果旧客户有某种用途而新客户没有同用途的地址，必须勾选 Create Same Site 复选框，将该地址和用途复制到目标方

操作步骤：

导航到 Customers Merge 窗口
在 From 区域，选择客户类型和要合并的客户
选择 Operating Unit（或 All）
选择合并原因
在 To 区域，选择目标客户类型和名称/编号
对 From 区域的每个站点，在 To 区域输入对应的地址
如需复制地址，勾选 Create Same Site（系统自动将 Location 字段值也转移过去）
选择 Delete 或 Inactivate 旧客户信息
设置处理优先级
点击 Merge 提交

Location 唯一性规则： 每个 OU 中，Location 对于同一客户账户+用途类型组合必须是唯一的。如果违反此验证，系统会自动追加"-C"尾部，或需手动输入。仅当概要文件 HZ: Location Updatable 设为 Yes 时才可手动更新 Location。

3.5 提交与执行报告

两种提交方式：

方式	说明
单独提交	在 Customers Merge 窗口中依次处理，每次一个合并
批量提交	在 Standard Request Submission 中一次提交多个合并

批量提交参数：

指定批量处理的合并数量
选择处理优先级（P1/P2/P3），系统会按优先级分组处理
合并集大小由 AR: Customer Merge Commit Size 概要文件控制

Customer Merge Execution Report（执行报告）：

字段	说明
Request ID	并发请求ID
Address	旧客户和新客户的地址
Location	旧客户和新客户的 Location
Name [Number]	客户名称和编号
Primary	是否为主要站点用途（Yes/No）
Site Use	站点用途（Bill-to、Ship-to等）
Status	Inactive 或 Delete

审查已合并的客户：
在 Customers Merge 窗口中查询已处理的客户，可查看并发请求 ID 和合并详情。

第三部分：Party Merge 与 Customer Merge 的关系

4.1 异同对比表

维度	Party Merge（交易方合并）	Customer Merge（客户合并）
层级	Party 层（交易方主数据）	Customer Account 层（客户账户+AR交易）
所属模块	Oracle TCA	Oracle Receivables
主要处理对象	Party、Party Site、Relationship、Contact	Customer Account、Account Site、Site Use
合并内容	Party 主数据 + 子实体	客户账户 + 交易（发票、收款等）
合并条件	同一 Party 类型	税务验证通过、相同用途站点
合并结果状态	Merged / Deleted	Inactive / Delete
是否可逆	❌ 不可逆	❌ 不可逆
是否涉及AR交易	仅转移客户账户，交易在Customer Merge中处理	直接处理所有AR交易重指向
Web Service	✅ Create Party Merge Request + Get Party Merge Details	✅ Get Account Merge Details
付费主体合并	可合并个人和组织，但只能同类型	个人和组织可以互相合并
批量处理	通过 Merge Batch	通过 Standard Request Submission

4.2 先后顺序场景示例

最佳实践：先 Party Merge，再 Customer Merge

因为 Party 是客户账户的父级，合并 Party 后客户账户会转移到目标方，此时再用 Customer Merge 合并重复的客户账户。

完整示例：

场景： Vision Corp. 和 Vision Inc. 是重复记录，双方都有 Party、Customer Account 和 Account Site。

Step 1 — Party Merge：

Vision Corp.（来源方）合并到 Vision Inc.（目标方）
站点 500 Vision Parkway 转移到 Vision Inc.
站点 600 Vision Parkway（视为重复）被合并
结果：Vision Corp. → Merged；Vision Inc. 获得两个客户账户（765432 和 234567）

Step 2 — Customer Merge：

客户账户 765432 合并到 234567
站点 2VISCORP 合并到 2VISINC
结果：客户账户 765432 → Inactive；234567 保留；所有交易重指向到目标

也可以反过来：先 Customer Merge 再 Party Merge
先合并客户账户（账户 765432 → 234567），再合并 Party。两种顺序都可行，但效果略有不同。

常见问题与避坑指南

❓ 合并后能不能撤回？

不能。 合并操作不可逆，务必先用 Preview 预览效果，确认无误后再 Run Batch。

❓ 为什么我的合并批次提交后一条都没生效？

因为 Party Merge 是批次级原子操作——批次中任意一条记录出错，整个批次都不会保存。检查日志找出错误记录修复后，用 Merge ID 重新提交。

❓ 什么情况下需要分别使用 Party Merge 和 Customer Merge？

发现同一公司有两条 Party 记录（如 Vision Corp. & Vision Inc.）：用 Party Merge
同一 Party 下有重复的客户账户（如两个 Account Number 对应同一客户）：用 Customer Merge
实际项目中往往先 Party Merge 再 Customer Merge 联动使用

❓ Delete 和 Inactivate 怎么选？

Inactivate：安全，保留审计线索，旧记录状态变为 Inactive，仍可查看和重新激活
Delete：激进，物理删除，无审计线索，不可恢复
建议：生产环境中优先用 Inactivate，仅在数据清理最终确认后考虑 Delete

❓ 合并后我的自定义表外键怎么办？

如果自定义表中有关联到 HZ_CUST_ACCOUNTS、HZ_CUST_ACCTS_SITES 或 HZ_CUST_SITE_USES_ALL 的外键，修改包 ARP_GENERIC_CMERGE 来确保外键有效。参考 $AR_TOP/install/sql/arplbtrx.sql 文件。

❓ 合并对 D&B 数据的影响是什么？

取决于 D-U-N-S 编号是否相同：

不同：保留目标方 D&B 数据
相同：保留最新数据
仅来源方有 D&B 数据：转移到目标方
来源方是总部：数据复制到目标方，目标方成为新总部

❓ 合并时有什么常见的性能优化措施？

设置 HZ: Enable DQM Merge Suggestion 为 'No'
合并前先完成 AutoInvoice 处理
使用批量处理而非单条提交
合理设置 AR: Customer Merge Commit Size 控制提交集大小

Q1：一个客户有多个地点，可以将多个地点分别合并到不同的新客户吗？

❌ 不可以。

根据 Oracle TCA User Guide 第9章规定：

"Customer Merge ensures that you inactivate or delete all site uses for the old customer; you cannot inactivate some site uses and delete others."

关键限制

Customer Merge 的操作界面是一对一的 — From 区域只有一个客户，To 区域也只有一个客户。所有 From 客户的站点用途必须映射到同一个 To 客户。
必须合并所有站点用途 — 不能只把部分站点合到 A 客户、另一部分合到 B 客户。文档原文：

"you must assign all of the old customer site uses to one or more of the new customer's site uses"

这里的"一个或多个"是指同一个新客户的多个站点用途（如同时映射到新客户的 Bill-to 和 Ship-to 地址），不是指多个新客户。
合并后旧客户所有站点都被 Inactivate/Delete — 不可能保留部分站点给另一个合并操作使用。

折中方案

方案	做法	风险
先拆分再合并	在 AR 中手动将原客户拆分为多个客户记录（创建新客户、转移部分交易），再分别合并到不同目标客户	手工拆分工作量大，需保证交易完整迁移
分批合并	先合部分站点到 A 客户，再合剩余站点到 B 客户	违反"all site uses must be processed"规则，系统不允许

建议做法

先评估这些地点之间的业务归属关系
如果地点确实要分属不同法人/业务线，应先在主数据层面重建客户结构（创建新客户、迁移交易和余额），再逐个合并
或者在 AR 中为每个业务实体创建独立的客户账户，然后单独走 Customer Merge

一句话总结：一个 Customer Merge 操作只能是一个 From → 一个 To，不能一拆多。

Q2：如果一个客户有多个账户，能将每个账户分别合并到不同的新客户吗？

✅ 可以。

这一点与地点（Site Use）完全不同。

原因：TCA 三层层级结构

Party（交易方）             HZ_PARTIES
  ├── Customer Account 1     HZ_CUST_ACCOUNTS
  │     └── Site Use 1a
  │     └── Site Use 1b
  ├── Customer Account 2     HZ_CUST_ACCOUNTS
  │     └── Site Use 2a
  └── Customer Account 3
        └── Site Use 3a

Customer Merge 操作的是 Customer Account 层，每个 Customer Account 是独立的并发请求。同一个 Party 下的多个 Customer Account，可以分别走独立的合并操作，合到不同的目标客户下。

场景举例

操作	From	To	结果
Customer Merge #1	客户P的账户A	客户X的账户X1	A 的站点→X1，A 被 inactivate
Customer Merge #2	客户P的账户B	客户Y的账户Y1	B 的站点→Y1，B 被 inactivate
剩余账户C	—	—	不动，继续正常使用

相当于一个 Party 的多个账户可以分家到不同的目标 Party 下。

注意事项

每个 FROM 账户余额必须为零 — 不能有未结清的 AR 交易、发票、收款等
税务主体限制 — 如果 FROM 账户有 Taxpayer ID / VAT 注册，合并后需满足目标客户所在地的税务规则
原 Party 的归属 — 如果 Party P 下的所有 Customer Account 都合并到不同 Party 了，Party P 本身不会自动删除（那是 Party Merge 的范畴），变成"空壳"Party，需额外清理
并发运行可行 — 多个 Customer Merge 请求可同时提交，只要处理不同 FROM 账户，不会锁冲突

与"一客户多地"的本质区别

场景	合并粒度	能否一拆多	原因
一客户多地点	Site Use	❌ 必须全部合到同一目标	Customer Merge 要求所有站点一次性映射完成
一客户多账户	Customer Account	✅ 可分别合到不同目标	每个账户是独立的 Customer Merge 请求，互不依赖

参考文档：

Oracle Trading Community Architecture User Guide, Release 12.1 (Part No. E13570-04)

Oracle Trading Community Architecture Administration Guide

Oracle Receivables User Guide (Duplicate Customer Report, Customer Listing Reports)

Oracle Customer Data Librarian User Guide (Merge Requests Overview)

posted on 2026-06-01 22:17 lizicheng 阅读(30) 评论(0) 收藏举报

刷新页面返回顶部