本文讨论为什么应付账款帐户余额或应收账款帐户余额与Microsoft Dynamics GP中的历史账龄试算表报告的总到期金额不同。 本文末尾有常见问题。
适用于： Microsoft Dynamics GP
原始 KB 数： 866570
GL 协调例程是Microsoft Dynamics GP 10.0 （SP2） 的新增功能。 此例程生成Microsoft 办公室 Excel 电子表格。 可以使用此电子表格来匹配已发布到总账本的应付管理或应收账款管理中的交易。 此过程不会生成更正事务。 但是，此过程可以帮助你确定本节中列出的事务差异。 若要打开“协调到 GL”窗口，请在“Microsoft Dynamics GP”菜单上指向“工具”，指向“例程”，指向“财务”，然后选择“协调到 GL”。
下面是我们看到的可能导致差异的事项的持续更新列表：
并非所有 GL 批处理都已发布。 （协调 GL 电子表格仅报告已发布的条目。
历史应收账款余额报告打印受限制。 再次打印历史过期试用余额报告，仅包含日期限制。
并非所有应付帐户或所有应收账款帐户都在总账中查看。 请确保在总账中查看所有应付帐户或所有应收账款帐户。
应付账款管理或应收账款管理中的批次被发布到总账本。 一般账本中的批处理在发布之前进行了更改或编辑。
对应付帐户或应收账款帐户的调整可能已直接在总账中输入。 这些交易更新总分类账中的账户。 但是，这些交易不会更新历史过期试用余额报告。
总账本中详细试用余额报表的日期范围与“应付款管理”或“应收账款管理”中“历史过期试用余额”报表的日期范围不匹配。 打印历史过期试用余额报表时，请在“使用报表的选择交易”区域中选中“GL 发布日期”复选框。
交易在应付账款管理或应收账款管理中发布。 但是，如果这些交易是用于期初余额，则不会记入总账本。 如果未在“购买系列”或“销售”系列的“发布设置”窗口中选中“发布到总账本”复选框，则交易将发布到“应付账款管理”或“应收账款管理”。 但是，这些交易不会记录到总账本。
"在“应付管理设置”窗口或“应收账款管理设置”窗口中，已选中“在 GL 中跟踪可用折扣”复选框。" 然后，发票的净金额将发布到总账本。 此外，剩余金额将记录到可用折扣账户。 在总账本中，只有净金额才会显示在“详细试用余额”报表中。 在应付管理或应收账款管理中，发票会在历史过期试用余额中显示总发票总额。
文档在与其最初发布不同的时间段内被作废。 总账本中的详细试用余额报表可能与历史过期试用余额报告不匹配。 例如，假设在 2007 年 1 月 1 日输入了发票。 此发票于 2007 年 2 月 1 日失效。 打印出的总账明细试用余额报告适用于 2007 年 2 月 1 日至 2007 年 2 月 28 日。 作废的交易将显示在报表上。 如果使用同一日期范围打印历史过期试用余额，则无效的文档将不会打印在报表上，因为它已失效。
如果要平衡总账中的应付账款账户余额或应收账款账户余额与某一时期的历史账龄试用余额报告，则必须将该报告中的余额调整为同一时期总账中详细试用余额的净变动。
如果要将总账模块中的应付帐户余额或应收账款余额与不在特定期间内某一天的历史账龄试算表报告对账，请确定应付账款管理或应收账款管理是否曾经做过平衡。 如果应付管理或应收账款管理从未平衡过，则开始余额可能不正确。 在这种情况下，首先平衡最新时期，然后按相反的顺序核对前几个月。
如果发生发布中断，批次可能无法正确发布到总账、应付账管理或应收账管理。
打印“历史账龄试算表”报表时，未选中“排除”部分中的以下复选框。
选中这些复选框，然后打印历史账龄试算表报告。
注意
如果要按特定文档匹配“总账本详细试算平衡报表”和“历史账龄试算平衡报表”，请清除“已全额支付的文档”复选框。
- 未发布应用的信用文档
- 零余额
- 活动
如果在重估时使用多币种管理，则选择发布到“采购/销售抵销账户”。
在发票的“应付交易输入”窗口中输入的信用卡金额。 这可能会导致应付管理与总账对账不平衡，因为只有净变化才会过账到总账模块。 （也就是说，GL 事务似乎缺失，但总账端的金额合并为一个总账条目，而 PM 端可能会显示三条记录。但它们仍应在更高版本中匹配，并正确地移动到“匹配的事务”部分。）
如果应付或应收账款批次发生发布中断或问题，且交易同时存在于‘工作’表和‘开放’表中，那么在 Microsoft Dynamics GP 中删除 RM 或 PM 批次会引发问题。 在此实例中，用户通常会查看这两个表中的记录，并决定不需要这项工作批处理，因此他们只需在 Microsoft Dynamics GP 中将其删除。 由于 Work 表和 Open 表共享一个分发表，因此删除 Microsoft Dynamics GP 中的批记录也会同时删除分发表中的分发记录。 最终结果是事务标头记录存在，但 RM 或 PM 端没有匹配的分布，但 GL 已正确更新。 此问题将在下一版本的 Microsoft Dynamics GP 中考虑。
如果存在折扣，分配可能会以不同金额显示在“潜在匹配”部分。 为了匹配，在运行“与 GL 协调”进程之前，应已使用 PM/RM 帐户拉取折扣 GL 帐户。 关闭电子表格，并使用列出的折扣 GL 帐户重新运行电子表格。
如果类型（CASH、PAY、PURCH）被更改，PM/RM 端可能会缺少分配。 在协调电子表格中，该帐户仅用于 GL 端。 该帐户不在 PM/RM 端使用。 无论使用何种帐户，PM/RM 端都会使用 PAY 或 REC 类型提取，因此您应该确保在对账窗口中列出所有 AP 或 AR 帐户。 重新生成电子表格时，仅切换 SQL 表中的分发类型不会自动显示分发。 （这是以前版本中信用卡付款使用 CASH 类型并影响到 AP 帐户的问题，但这些记录在 GP 2016 中显示，因此不再是一个问题。）
在应用表中检查多币种交易的应用日期和 GL 发布日期，并与其在 GL 中发布的实际日期进行比较。 例如，在 1 月 22 日，12 月 31 日的信用备忘录应用于 12 月 5 日的发票，应用日期和 GL 邮票保留为 1 月 22 日。 但是，发布 GL 批处理时，用户将日期更改为 12 月 31 日。 在这种情况下，12月的对账到 GL 的电子表格列出了双方实现的收益/损失金额，并且它们似乎已经对齐。 但是，HATB 报告尚未识别已实现的收益/损失金额，并且与 GL 相比，这一金额会存在差异，因为根据应用记录，直到 1 月才进行了应用或记账。
常见问题
问 1：GL 对账电子表格是否是应付/应收账款与 GL 的真正对账？
A1：协调 GL 功能是一种 故障排除工具 ，可帮助用户识别 RM/PM 和 GL 之间不匹配的分布。 这不一定意味着要与 HATB 结成关系，这不是预期目的，尽管我们知道客户正在这样做。 与总帐核对的电子表格上的余额是根据表中的分配进行简单加减计算得出的大致估计。 而 HATB 上的余额几乎考虑了每个表格，因此它们更为复杂和准确，所以两者往往不会对齐。
真正的和解应该是 RM 或 PM 历史过期试用余额 （HATB） 和 GL 试用余额报告之间。 如果这些匹配项一致，那么当月不必运行“对账到总账”工具。 GL 表由借记和贷记组成，HATB 提取的表是事务标头表和应用记录表。 因此，客户要求通过某种方法将 GL 中的分布与 RM 或 PM 中的分发表进行协调，以帮助找到该级别的差异。 因此，这就是为什么创建与总分类账协调例程的原因。 它旨在成为一种故障排除工具，用于比较不同模块间的分布，以帮助识别缺失的分布，这可能会导致您回溯到 HATB 中缺失的事务。 因此，请仅使用“Reconcile to GL”工具作为辅助工具，以帮助将 HATB 与 GL 试用余额进行协调。 如果 HATB 和 GL TB 的金额平衡，那么实际上没有必要在该月运行“Reconcile to GL”工具。
问 2：协调 GL 电子表格上的总计是否与 HATB 上的总计匹配？
A2：否。 协调 GL 电子表格中的总计只是该表中分布记录的简单加减，不会考虑任何其他表。 而 HATB 则查看完全不同的表，使用事务表来计算余额，并应用记录表，这是一种更加复杂的计算。 由于用于获取余额的不同计算方法/表，预计与 GL 电子表格的协调不会完全与 HATB 报表上的老化余额挂钩，并且会使它们难以协调。 无需将 GL 电子表格余额与 HATB 报表进行核对或关联。
建议忽略与 GL 电子表格协调的总计，只需使用不匹配的和可能的匹配部分来帮助你找到差异来研究这是否还可能解释 GL TB 和 HATB 之间的差异。 与 GL 电子表格的协调不是真正的对帐，只是为了帮助你确定分布差异，以研究这是否也是交易级别的差异。 事实上，如果 HATB 与 GL TB 匹配，那个月实际上完全不需要运行对 GL 的对账工具，因为没有需要识别的差异。
如果仍希望将与 GL 电子表格的余额与 HATB 上的余额挂钩，则常规支持案例中不支持此功能。 我们确定的原因列在此知识库的顶部，可能还有更多尚未确定的原因。 但是，由于不需要对 GL 电子表格上的简单总余额与 HATB 报表中更复杂的计算余额进行对账，而这也不是此对账工具的预期用途，因此，深入分析您的数据以协助您进行这些对账将被视为一项咨询费用。
问题 3：如果总账中缺少分配项，该怎么办？
A3：如果在 RM 或 PM 端找到不在 GL 端的分布，请调查 GL 端是否存在计时差异。 检查确保所有 GL 批次都已发布。 如果 GL 端确实缺少它们，则需要将调整日记条目直接输入到 GL 中，以便创建 GL 分发版。
问 4：如果 RM 或 PM 端缺少分发版，该怎么办？
A4：如果列出了 GL 分布，但在 RM 或 PM 端缺失，首先调查是否存在时间差异。 此外，还研究该交易本身是否在 HATB 报告中列出，并且已考虑在内。 交易可能存在，但只是分配缺失。 因此，问题就变成了 如果事务存在，我该如何在 RM 或 PM 中获取分布呢？ 首先，请记住，除对账电子表格外，RM 或 PM 中的分布表不用于任何其他用途或报告。 那么，真的有必要将它们添加回 RM 或 PM 中？ 评估是否值得你填入一个在其他地方都未使用的表。
但是，如果你选择修复 PM 分布表，则必须取消文档，以便应用的记录移回打开。 然后使用“删除事务历史记录”实用工具删除无效的文档。 请确保将帖子 设置为 GL， 不要 发布到 GL。 删除 void 创建的 GL 批处理。 然后将文档重新输入到“应付”模块中，以便重新创建事务和分配。 请务必为此取消 GL 批处理。 然后将新文档再次应用于打开的文档，打开的文档应再次移至历史记录。
要在 RM 分配表中修复此问题，您必须删除发票和付款的条目，并重新输入它们，然后在 GL 中删除批处理。
问 5：“潜在匹配”部分中的交易看起来似乎匹配。 为什么它们不在“匹配”部分中？
A5：每个分配记录都有若干个匹配的字段。 所有字段必须匹配才能将其移动到“匹配”部分。 如果某些字段匹配，但不是所有字段都匹配，则它将把其置于“潜在匹配”部分。 例如，以下是 PM 与 GL 的匹配字段：
应付管理 -- GL
代金券编号 -- 发起控制编号
TRX 源 -- 原始 TRX 源
发布日期 -- 交易日期
账户金额 - 借方金额或贷方金额
问 6：如果我在 GL 或 RM/PM 中键入缺少的分布，然后重新运行与 GL 的对账电子表格，不匹配或可能匹配的项目是否会移动到“已匹配”部分？
A6：否。 如果事务单独进行密钥处理，将具有不同的代金券号和 Trx 源代码。 充其量“发布日期”和“金额”可能匹配，这可能会将它们放入电子表格的“潜在匹配”部分。
问 7：为什么每月或季度电子表格上的结束余额与下一个月或季度电子表格中的“开始余额”不匹配？
A7：如果一个周期的结束余额与下一个周期的开始余额不匹配，通常是因为在子账本表中存在未与头记录关联的孤立分配记录。 结束余额由 Excel 在电子表格中计算。 它只需要在电子表格顶部的该时间段的开始余额，并添加/减去电子表格中显示的分布记录，以到达结束余额。 另一方面，在下一个时间段内，开始余额是通过对 SQL 表中的分布记录进行简单的借记/信用计算来计算的，存储过程会联接标头表，因此它不包括缺少标头记录的任何分布。 最终结果可能是，某些分配被计入上一个电子表格的期末余额，并从下一个周期的期初余额中省略。
Q8：RM/PM 端的分布确实存在，但未被导入电子表格。
A8：查看以下故障排除提示：
- 检查协调电子表格中使用的日期范围。
- 验证分发是否存在于 PM 的PM10100或PM30600表中。 （或 RM：搜索RM10101或RM30301）检查这些分布中的日期，确保它们位于你为电子表格输入的范围内。 请务必在 RM 或 PM 分发表中查找这些内容，而不是仅依赖于重新打印的帖子日记，例如。
- 如果在 RM 或 PM 表中找到分布情况，就在前端界面的文档上查看这些分布情况。 他们是否有“PAY”或“REC”或“AVAIL”的分布类型？ 这些类型是唯一将导入到旧版本中与 RM 或 PM 相关的协调工作表的类型。 （更新：信用卡付款可能会向应付账款账户生成一个分配，该分配的类型为现金，确实存在于表中，但在与总分类账电子表格核对时，左侧没有显示此分配。因此，这只是电子表格的显示问题，而不是数据问题。但是，这似乎不是 Microsoft Dynamics GP 2016 中的问题，因为 CASH 类型现在在电子表格上正确显示，因此问题已得到解决。）
问 9：是否可以将“对账到总账”窗口显示为其他货币？
A9：“协调与 GL”窗口旨在仅显示 功能 货币。 有关详细信息，请参阅 Microsoft Dynamics GP 中“与 GL 协调”窗口中的余额的相关信息。