如何通过 Jack Henry jXchange 发送 ACH Addenda 备注？

明确结论

ACH 备注应通过 Addenda Record 发送。对于常见的 CCD、PPD、WEB 等 SEC Code，通常使用 Addenda Type Code 05，并将备注写入 Payment Related Information，例如：

<AddendaTypeCode>05</AddendaTypeCode>
<PaymentRelInfo>Payment invoice 12345</PaymentRelInfo>

需要注意的是，不同 jXchange/SilverLake 版本中的 ACHOrigAdd、PmtAdd XML 结构和字段名称可能不同。Addenda 节点是否直接位于 <EntryDetail> 下，字段名称是 AddendaTypeCode、AddendaTypeCd 还是其他形式，都必须以当前环境对应服务的 WSDL/XSD 为准，不能仅凭 NACHA 文件结构推断。

<AddendaInd>Y</AddendaInd> 一般是 ACH 文件 Entry Detail Record 中的派生标志。通过 jXchange 提交业务请求时，系统通常会根据是否存在 Addenda 数据自动生成该标志，调用方不需要单独设置。只有当前 jXchange schema 明确提供并要求该字段时，才需要传入。

字段如何对应 ACH 文件

最终生成的 NACHA 文件通常包含两类记录：

• Entry Detail Record：交易主体信息。
• Addenda Record：与该交易关联的附加付款信息。

Addenda Type Code 05 表示 Payment Related Information，备注内容写入该记录的 Payment Related Information 字段。对应的 NACHA 内容在概念上类似：

05Payment invoice 12345

Payment Related Information 最多为 80 个字符。为避免字符集、清算行或下游银行的兼容性问题，建议只使用 NACHA 允许的可打印字符，优先选择普通英文、数字、空格和常见标点。内容中不要保留示例使用的反引号或额外引号。

推荐发送：

Payment invoice 12345

而不是：

`"Payment invoice 12345"`

jXchange 请求中的放置位置

从业务含义看，Addenda 必须与具体的 ACH entry 关联，不能只放在 batch 或整个 payment request 层级。

如果当前版本的 schema 将 Addenda 定义为 <EntryDetail> 的子节点，可以参考下面的结构：

<EntryDetail>
    <!-- Receiver、amount、account 等交易字段 -->

    <Addenda>
        <AddendaTypeCode>05</AddendaTypeCode>
        <PaymentRelInfo>Payment invoice 12345</PaymentRelInfo>
    </Addenda>
</EntryDetail>

这只是结构示意，不能直接当作可提交的 jXchange XML。有些版本可能使用列表或包装节点，例如：

<EntryDetail>
    <!-- 交易字段 -->

    <AddendaArray>
        <AddendaInfo>
            <AddendaTypeCode>05</AddendaTypeCode>
            <PaymentRelInfo>Payment invoice 12345</PaymentRelInfo>
        </AddendaInfo>
    </AddendaArray>
</EntryDetail>

其他版本也可能使用 ACHAddendaInfo、AddendaRec、PmtAddenda 等名称。需要在当前服务定义中确认：

1. ACHOrigAdd 或 PmtAdd request 使用的 entry 节点名称。
2. entry 节点允许包含哪些 Addenda 子元素。
3. Addenda 节点能否重复。
4. PaymentRelInfo 的长度、字符集和必填规则。
5. Addenda type 字段是字符串、枚举，还是由系统自动确定。

如果 WSDL/XSD 中的 <EntryDetail> 没有 Addenda 子元素，就不能自行插入该节点。未知元素通常会引发 schema validation error，也可能被服务端忽略。遇到这种情况，需要确认是否应改用其他 jXchange operation、扩展对象或 SilverLake 专用接口。

是否需要设置 AddendaInd

没有 schema 依据时，不建议手动添加：

<AddendaInd>Y</AddendaInd>

在 NACHA Entry Detail Record 中，Addenda Record Indicator 的含义如下：

• 0：该 entry 没有 addenda。
• 1：该 entry 后存在一个或多个 addenda record。

jXchange/SilverLake 通常能根据请求中是否包含 Addenda block 计算这个值。因此，更合理的做法是提交 Addenda 数据：

<Addenda>
    <AddendaTypeCode>05</AddendaTypeCode>
    <PaymentRelInfo>Payment invoice 12345</PaymentRelInfo>
</Addenda>

再由核心系统生成正确的 indicator。

如果当前 request schema 确实定义了 AddendaInd，需要查看该字段的文档说明：

• 如果它是只读字段、响应字段或系统生成字段，不要传入。
• 如果它是请求必填字段，则在提供 Addenda 时将其设为 Y 或 schema 指定的值。
• 不要让 indicator 显示存在 addenda，实际请求中却没有 Addenda block。

NACHA 文件通常使用 0/1，jXchange 业务对象则可能使用 Y/N，两者的取值规则不能直接混用。

SEC Code 限制

Addenda 是否可用及其数量上限，取决于 SEC Code 和适用的 NACHA 规则。

常见情况如下：

• CCD：通常允许一个 Type 05 addenda。
• PPD：通常允许一个 Type 05 addenda。
• WEB：通常允许一个 Type 05 addenda。
• CTX：用于企业付款，支持多个 addenda，常用于结构化汇款信息。
• 其他 SEC Code：可能允许一个 addenda，也可能限制具体用途，或不适合承载任意业务备注。

因此，不能只验证 AddendaTypeCode=05，还要确认：

• 所选 SEC Code 是否允许 addenda。
• 允许添加多少个 addenda。
• Payment Related Information 是否符合该 SEC Code 的用途。
• ODFI 或 ACH processor 是否设置了比 NACHA 规则更严格的限制。

如果只需发送一条简短的 invoice reference，在 CCD、PPD 或 WEB 下通常使用一个 Type 05 addenda，但最终仍需由开户行或 ACH processor 确认受理规则。除非 SEC Code 和处理平台明确允许，否则不要为了发送多条备注而重复添加多个 Type 05 record。

SilverLake 侧可能需要的配置

NACHA 规则允许 addenda，并不意味着当前 SilverLake 环境已经开放了这项能力。通常需要检查：

• ACH origination 产品或接口权限是否启用。
• 对应 company/originator 是否获准使用所选 SEC Code。
• ACH template 或 transaction code 是否允许 addenda。
• 当前 jXchange 服务版本是否提供 Addenda 映射。
• SilverLake 到 ACH processor 的输出映射是否保留 Payment Related Information。
• 银行是否对 addenda 的内容、字符或数量设置额外校验。
• 测试环境与生产环境是否使用相同的 ACH 配置。

具体配置名称会随 SilverLake 版本、银行部署方式和 ACH processor 而变化，不能假定所有环境都有统一的开关。

建议的验证流程

先从当前环境导出或查看 ACHOrigAdd/PmtAdd 对应的 WSDL/XSD，并在 request entry 类型中搜索：

Addenda
PaymentRelInfo
AddendaType
AddendaInd

然后构造一笔测试交易，使用以下内容：

<PaymentRelInfo>Payment invoice 12345</PaymentRelInfo>

请求提交成功后，除了检查 jXchange 的成功响应，还应查看 SilverLake 生成的 ACH 文件或 ACH 出站预览，确认：

• Entry Detail Record 的 Addenda Record Indicator 正确。
• entry 后紧跟 Type 05 Addenda Record。
• Payment Related Information 没有被截断或删除。
• Addenda sequence number 和 entry detail sequence number 由系统正确生成。
• batch/control totals 和 addenda count 正确。

如果 schema 接受了请求，但最终 ACH 文件中没有 addenda，问题通常出在 SilverLake 映射、originator 配置或 processor 配置，而不是 PaymentRelInfo 文本本身。此时应向 Jack Henry 或银行的 SilverLake/ACH 管理团队提供具体的 jXchange 服务版本、operation 名称、request schema，以及脱敏后的请求和生成文件，以便核对。

备注：内容仅供参考。