通过

在 Microsoft Dynamics GP（博客）中显示错误：“如果前一个会计年度存在未清理的负担金额，则无法转移 XXXX 的负担。”

本文提供了Microsoft Dynamics GP 中发生的错误的解决方案。

适用于： Microsoft Dynamics GP
原始 KB 数： 4567109

问题

可在此处找到博客文章。

“年终应计转让”窗口用于将开放式采购订单（PO）的应计余额从当前年度转移到下一年度。 转移过程会在当前年度自动清偿受阻碍的金额，并更新开放采购订单，其中包含将在明年交付的剩余金额。

负担年底转账窗口位于Purchasing > Routines > Year End Encumbrance Transfer.
运行此过程时，可能会收到以下错误：

如果前一个会计年度有未清偿的负债金额，则无法转移 XXXX 的负债。

原因

遇到错误的原因有很多。

  1. 有时，用户会将交易日期设为已转移年份内的日期。 在这种情况下，只需返回到交易发生的年份，并将这些旧交易值转移到未来。 其他时候，它并不那么简单。
  2. 有许多第三方、集成和自定义项与采购订单处理集成，有时数据可能不处于Microsoft Dynamics GP 预期的状态，从而导致错误。
  3. 此外，如果在发布时遇到任何中断，数据可能会损坏，从而导致错误。 在这种情况下，问题可能与ENC10111表有关，因为它可能没有交易的所有细节。 一般情况下，采购订单数据也可能损坏，导致采购订单无法转移。

解决方法

有一些选项可以尝试解决此错误。 我始终建议将 LIVE 数据的副本移动到测试公司进行测试。 此博客假设执行这些步骤的用户熟悉 Encumbrance 和采购订单（Purchase Order）数据，以及后端表格的结构或样式。 如果不熟悉，可能需要联系合作伙伴，或创建支持案例以获取帮助。 在支持案例中，我们可以协助解决一两个问题的采购订单并提供指导，但如果有多个采购订单出现问题，则可能需要为每个 PO 创建单独的案例，因为每个订单可能有不同的条件，需要单独分析数据。

选项 1： 运行过去所有年份的年终转移，以确保没有在需要转移的以前输入/插入的采购订单。

转到 “购买 > 例行公事 > 年终”转让。
从当前年份开始，然后继续逐年向后移动，以查找是否需要转移的采购订单。 如果有一个 PO 被“卡住”，并且在转移后仍然留在报告上，那么就需要通过运行名为“ALL PO 和收据”的脚本（此博客后面列出的链接）来深入调查，以确定该 PO 出现了什么问题。 很多时候，ENC10111不处于正确的状态，导致采购订单无法推进到下一年。 如果是这种情况，你可以运行选项 4 来使 PO 传输。

选项 2： 删除已完成的 POS 并删除历史记录。

如果你有特定的数据条件，其中传输报表上的采购订单不会移动，并且采购订单处于“已关闭”或“已取消”状态，请使用此选项。 可能是 PO 已损坏，只需从 GP 中删除即可。 如果您同意此选项，请执行以下步骤。

  1. 导航到“ 购买 > 实用工具 > ”，删除购买历史记录。 这将允许删除损坏的采购订单的采购订单、收据、帐户分发和日记历史记录。 我知道这可能显得有些过激，但在这个阶段，采购订单已经损坏并关闭或取消，除了逐个修复之外，无法采取其他措施。 因此，删除它可能是尝试的最佳选项。

    • 提示

      如果采购订单不在要删除的历史记录中，请使用“删除已完成的采购订单”例程将 PO 移动到历史记录文件。 导航到 “购买 > 例程 > ”，删除已完成的采购订单。

    • 完成的 PO 删除报告将在该过程完成后打印。 如果未删除采购订单（例如，如果正在使用或已损坏数据），则会在“已完成的 PO 删除报告”上打印一条消息，指示未删除采购订单。 在这种情况下，需要查看 ALL PO 和回执脚本结果，以确定错误，并通过后端修复或删除它。 如果它确实移动到历史记录，请继续执行下一步。
    • 现在可以使用“删除购买历史记录”窗口删除采购订单历史记录。

  2. 接下来，运行该工具来修复 ENC 数据。 （Microsoft Dynamics GP 菜单>维护>受压管理>例行维护）你需要使用根据采购订单的详细信息，然后根据详细信息使用摘要。

  3. 如果仍收到错误，请尝试再次传输年份，继续执行选项 3 的数据检查步骤。

选项 3： 数据检查脚本

下面有一个脚本，可用于尝试识别导致传输出错的罪魁祸首 PO（s）。 许多 PO 可能出现在返回的列表中，但请专注于其中返回的第一个。 并非所有列出的 POS 都一定不好。 它在标识到第一个损坏的采购订单后就停止，并随后列出其余的订单。 如果我们修复了第一个损坏的采购订单，则希望 PO 的其余部分会从列表中删除，转移不会出现问题。 如果没有，则需要重复此过程，直到列表被清除。

选项 3 的操作总体为：

  1. 运行以下脚本，
  2. 在列表中的第一个 PO 上运行 ALL PO 和回执脚本。
  3. 修复列表中的第一个 PO 数据，
  4. 再次尝试传输。

你必须首先找到一年没有受影响的采购订单。 若要执行此操作，需要确定两个事项。

  • 确定你是会计年度还是日历年。 这很重要！ 导航到 管理 >> 设置 >> 公司 >> 会计周期;记下年份的开始日期和结束日期。
  • 运行年终结转时遇到了哪个年份的错误？ 例如，如果要将 2017 转移到 2018，请注意。

知道 #1 和 #2 后，现在可以运行以下脚本来查找问题 PO（s）。 若要运行脚本，需要针对与会计/日历年份匹配的日期范围以及 1 个额外日期运行该脚本。

使用以下脚本。 关键是输入正确的日期。

如果是日历，则 2017 年 1 月 1 日到 2018 年 1 月 1 日。 假设你已设置 5 月 1 日开始的会计年度，因此下面是我的示例。

如果我的第一个周期从 2017 年 5 月 1 日开始，到 2018 年 4 月 30 日结束的一年，我的脚本将如下所示：

declare @FROM varchar(10) set @FROM ='05/01/2017'
declare @TO varchar(10) set @TO ='05/01/2018'
declare @FROMDATE DATETIME set @FROMDATE = CONVERT(DATETIME, @FROM, 101)
declare @TODATE DATETIME set @TODATE = CONVERT(DATETIME, @TO, 101)
select *
from ( select ENC10110.PONUMBER, ENC10110.POLNENUM,
ENC10110.ENCBSTAT, ENC10110.INVINDX,
ENC10110.REQDATE,
(SUM(ENC10111.ENCMBAMT) - ISNULL(
(
select SUM(LIQUDAMT)
from ENC10500
where (GLPOSTDT>=@FROMDATE and GLPOSTDT<@TODATE) AND
ENC10110.PONUMBER = ENC10500.PONUMBER AND
ENC10110.POLNENUM = ENC10500.POLNENUM),0)
) AS REMAMT
from ENC10111
inner join ENC10110
ON ENC10111.PONUMBER = ENC10110.PONUMBER AND
ENC10111.POLNENUM = ENC10110.POLNENUM
where (ENC10111.TRXDATE>=@FROMDATE and ENC10111.TRXDATE<@TODATE) AND
ENC10110.ENCBSTAT<>3
  GROUP by  ENC10110.PONUMBER, ENC10110.POLNENUM,
      ENC10110.ENCBSTAT, ENC10110.INVINDX,
      ENC10110.REQDATE
) AS ENC
where REMAMT<>0

关键是了解应运行的日期。 如果不使用正确的日期限制，你可能会得到你认为错误的结果，但实际上它们是正确的，并且只是因为运行日期限制的方式而显示。 我总是建议你从你试图转会的年份开始， 然后逐年返回， 直到你收到没有结果。 如果使用最后一个示例设置，请从以下开始：

declare @FROM varchar(10) set @FROM ='05/01/2017'
declare @TO varchar(10) set @TO ='05/01/2018'

然后：

declare @FROM varchar(10) set @FROM ='05/01/2016'
declare @TO varchar(10) set @TO ='05/01/2017'

然后：

declare @FROM varchar(10) set @FROM ='05/01/2015'
declare @TO varchar(10) set @TO ='05/01/2016'

依此，直到结果为零为止。 如果 2015 年到 2016 年没有收到任何结果，那么我会运行 2016 到 2017 年以前的脚本，这就是我将开始故障排除的地方。 练习的目的是找出问题开始的位置。 通常情况下，你将从列表中第一个采购订单的所有 PO 和收据脚本中获取结果，并查看数据以确定问题所在。 确定问题并修复数据后，应能够重新运行 Encumbrance 例程维护，然后传输年份。

所有 Encumbrance 用户都位于等于或大于 11.00.1799 的 GP 版本上，这一点至关重要。

注意

支持可以帮助解决一两个问题 PO（s）并查看数据，以提供有关如何修复它们的建议，但如果有许多 POS，则需要与合作伙伴合作来修复数据或创建单独的案例来帮助分析数据问题。 每个 PO 都有多个表格需要分析，因此在一个支持案例中处理一两个采购订单是可以接受的，但之后的情况更偏向于咨询，需要合作伙伴的协助才能完成工作。

有关收集所有 PO 和收据脚本的说明。

在此处找到的 脚本

使用下面的说明在文本中运行它。

此声明的目标是查看与特定采购订单相关的所有数据。 它只是 SELECT 语句。 它不会更新/删除数据。

declare @PONUMBER char(20)
select @PONUMBER = 'POXXXX'
  1. 在脚本中输入您的采购订单编号以替换 POXXXX。
  2. 按 （Ctrl + T）或选择 菜单栏上的“结果到文本 ”按钮，然后再执行以将结果发送到文本。
  3. 根据结果对公司数据库执行操作。
  4. 右键单击 结果，并另存为 .rpt。

选项 4： 删除特定采购订单（或所有ENC10111）ENC10111中的数据，这些订单已损坏，并在枚举上运行协调，然后重试传输。

  1. 运行该工具以修复数据，并查看该工具是否修复了任何采购订单。 然后查看转账是否完成。 （Microsoft Dynamics GP 菜单>维护>履约管理>例程维护） 你需要使用基于采购订单的详细信息，然后使用根据详细信息的摘要。 如果没有，请转到步骤 2。

  2. 通过运行以下 IN TEST 删除ENC10111表。 我想强调，在此步骤中您可能会删除一些无问题的数据，但如果由于某些原因需要进行研究，PO 表的完整性仍会得到保留。 传输无法完成的原因是，ENC 表之间存在差异，因此这是排除这一点的最简单方法。GP 会将此表替换为 每个 PO 的净 金额。

    -----------------
 DELETE ENC10111
-----------------

    注意

    如果只有一个 PO 无法传输或清除传输报告，则可以指定要删除的特定 PO。

    DELETE ENC10111 WHERE PONUMBER = 'XXX'

  3. 删除表中的数据后，运行该实用工具以重新填充ENC10111表。 （Microsoft Dynamics GP 菜单>维护>留置管理>例行维护）。 首先，你需要使用基于采购订单的详细信息，然后根据详细信息汇总，最后再次尝试年终转移。

  4. 如果传输仍有问题，请使用 OPTION 3 中的检查数据脚本，并查看该 PO 是否已列出。 然后继续执行该选项中的步骤来修复数据。

最终目标是在选项 3 中逐年运行脚本，并且没有返回任何数据，这意味着可以处理年终传输过程而不出错。

选项 5： 禁用和重新启用枚举

如果发现大量的数据损坏，最好是考虑禁用负债或支出预留，将所有已关闭/取消的采购订单移动到历史记录，然后重新启用负债或支出预留。

注意

若要将已关闭/取消的 PO 移动到历史记录，请使用“删除已完成的采购订单”例程将 PO 移动到历史记录文件。 导航到 采购流程 > 删除已完成的采购订单。

只要设置为在 POP 设置中维护历史记录，就不会丢失任何采购订单处理数据。 你仅失去了一些来自历史年份的旧负担细节，这些细节属于历史中的 Pos。 对于当前年份，你仍会留下当前未完成的存货，你已为其开具采购订单。