Share via

Microsoft Dynamics GP 中电子资金转移 (EFT) 格式的自定义数据字段

  • 项目

本文提供有关 Microsoft Dynamics GP 中电子资金转移 (EFT) 格式的自定义数据字段的信息。

适用于： Microsoft Dynamics GP
原始 KB 编号： 2956922

症状

许多银行都提供检查打印服务、CEPS 计划和其他需要统一付款文件的服务。 Microsoft Dynamics GP 中的 EFT 功能旨在符合标准已发布 NACHA 格式的必填字段。 因此，如果尝试为银行提供的某些其他服务创建自定义平面文件，则需要设置自定义格式，并且可能需要灵巧性自定义来实现某些字段。 Microsoft Dynamics GP 目前不支持自定义格式，下面列出了我们的案例策略。 请记住，仅仅因为可以在格式的特定行中选择字段，并不一定意味着它被设计为在该行中工作。

在以下链接中查看 EFT 配置器文件的案例策略。 当前策略是每个支持事件一个字段或错误消息。 但是，如果该字段的功能在尝试使用它的行中不起作用，则需要灵巧性自定义。

Microsoft 支持专业人员用于确定何时支持案例成为咨询参与的指南

原因

如果你尝试获取 Microsoft Dynamics GP 中尚未提供的自定义 EFT 格式，则可能需要一个灵巧自定义来实现自定义格式，以便为银行提供的其他服务创建一个平面文件。

解决方案

下面是一些需要注意的自定义字段：

唯一文件标识符/EFT 文档 ID：

“唯一文件编号”功能是每个生成的 EFT 文件的唯一编号。 如果在多个行类型上选中，则每行中都会打印相同的数字，并在每次生成新的 EFT 文件时递增。 此数字已通过映射字段在 Microsoft Dynamics GP 中可用，如下所示：

EFT 下一个文件编号：
映射到：数据字段
表：Checkbook 电子资金转移主机
字段：EFT 下一个文件编号

注意

生成的银行预钞文件将在此字段中打印零。

批处理标头/批处理控制行中的批处理 ID：

Microsoft Dynamics GP 旨在将所有付款放入 EFT 文件中的单个批处理中，这是可以接受的。 (大多数银行并不关心 Microsoft Dynamics GP.) 中包括了多少个单独的批 ID，因此，拉入文件的所有批都将在 EFT 文件中显示为一个大批。 因此，每个文件只能看到一个 Batch 标头和一个批处理控制行。 这是设计使然，银行可以接受。

序列号：

此字段设计为仅在 Addenda Line 类型中工作。 如果此字段在任何其他行类型中不起作用，则需要请求自定义。

发票编号：

发票编号和金额旨在以格式的附录行进行映射，应按如下所示进行映射以提取正确的信息：

发票编号：
映射到：数据字段
表：PM 应用于历史记录文件
字段：应用于文档编号

发票金额：
映射到：数据字段
表：PM 应用于历史记录文件
字段：应用金额 (如果不起作用，请尝试接下来 从应用金额应用 ，并验证其金额是否正确。)

*对于发票，您仅限于 PM 应用到历史记录表 (PM30300) 中的字段，因此无法获取发票说明或 PO 字段等字段。 EFT 文件设置为获取付款记录信息，而不是发票信息，但应用记录上提供的信息以外的信息。

标题行中的任何“count”或“sum”字段：

一般情况下，任何“count”或“sum”字段都只能在页脚行中工作，或者在行已列出之后。 因此，大多数“count”或“sum”字段仅在 Batch Control 和文件控制页脚行中工作，在“标头”或“详细信息”行中不起作用。 需要测试才能验证。

详细信息行上的附录记录数：

Addenda Count 仅适用于 Addenda 行类型，不适用于详细信息、批处理控制或文件控制行。 附录行只能在连续列出之后（而不是之前）进行计数。

例如，“Addenda Count”在文件控制标题行或详细信息付款行中不起作用，因为尚未列出附录记录数。 系统无法在列出它们之前对其进行计数或总计。 (因此，如果没有灵巧自定义，将无法满足 CTX 格式的此要求。)

作为一种解决方法，批处理控制和文件控制行中提供了“详细信息 + 附录”选项，大多数银行已接受这些选项。 因此，请向银行验证他们是否接受此字段。 另一种方法是使用“每个发票一检查一检查”而不是“每个供应商一检查”生成 EFT 文件。 由于每个详细信息行都有一个包含此选项的附录行，因此可以在详细信息行中将此代码硬编码为“1”。

行计数：

“行计数”数据字段设计为在“文件控制”行中工作，并将对文件的所有行进行计数。 此字段在任何其他行类型中都不起作用。

例如，如果 EFT 文件中总共有 10 行，批处理控制行中的行计数将列出 9，因为它只能列出前面的行。 文件控制行中的行计数将列出正确的计数 10，因为此字段用于此行。 但是，“行计数”字段不适用于附加的页脚行 (尾部标签 1 和尾部标签 2) ，因为这些附加的页脚行不是标准 NACHA 格式的一部分。

其他日期格式：

(在日期中包含短划线或斜杠以实现 MM-DD-YYYYY 或 MM/DD/YYYY)

对于 EFT 文件格式的日期字段，配置器的下拉列表中仅提供 MMDDYYYYYYY 或 DDMMYYYYY 等日期格式。 但是，可以通过将日期字段拆分为“五个字段” (，只要日期位于) 行中的位置，银行就不会知道差异。 例如，使第一个字段的长度为 2，并将其“左对齐”，然后选择“MMDDYY”，以便它抓取 MM。 然后使用短划线或斜杠将第二个字段的长度设置为 1 作为常量。 然后，使第三个字段的长度为 2，“左对齐”它并选择“DDMMYY”，以便它抓取 DD。 第四个字段的长度为 1，作为带有斜杠或短划线的 CONSTANT。 使最后一个字段的长度为 4，“左对齐”，并这次选择 YYYYMMDD 格式。 (或长度为 2，如果需要，请选择“YYMMDD”。)

更多信息

设置 EFT 文件格式属于咨询服务，但不再接受。 最好自行测试并使用 Dynamics GP 中的默认格式作为指导，因为列出了你需要的大多数标准字段，并且 GP 编码以实现我们提供的格式。 可以创建一个支持案例，以获取每个案例一个字段的帮助。

有关 EFT 设置和其他常见问题解答的详细信息，请参阅 在 Microsoft Dynamics GP 的应付款管理或应收账款管理的电子资金转移中生成 EFT 文件或 EFT 预注文件时要遵循的准则。