有关将总账与应付账款管理或应收账款管理进行协调时的差异的信息

本文讨论为什么总帐中的 应付帐款 帐户余额或 应收账款 帐户余额与 Microsoft Dynamics GP 中历史过期试用余额报表上的应付总额不同。 本文末尾有一些常见问题。

适用于: Microsoft Dynamics GP
原始 KB 编号: 866570

协调到 GL 例程是 Microsoft Dynamics GP 10.0 (SP2) 的新增功能。 此例程生成 Microsoft Office Excel 电子表格。 可以使用此电子表格来匹配已过帐到总账的应付账款管理或应收账款管理中的交易。 此过程不会生成更正事务。 但是,此过程可以帮助你确定本节中列出的事务差异。 若要打开“协调到 GL”窗口,请指向 Microsoft Dynamics GP 菜单上的“工具”,指向“例程”,指向“财务”,然后选择“协调到 GL”。

下面是我们所看到的可能导致差异的问题的运行列表:

  • 并非所有 GL 批处理都会发布。  (仅对已发布条目的“与 GL 电子表格协调”报表。)

  • 历史过期试用余额报表打印有限制。 再次打印历史过期试用余额报表,但只有日期限制。

  • 并非所有应付账款或所有应收账款都显示在总帐中。 请确保在总帐中查看所有应付帐款或所有应收账款帐户。

  • 应付账款管理或应收账款管理中的批已过帐到总帐。 总帐中的批在过帐之前已更改或编辑。

  • 对应付帐款或应收账款帐户的调整可能已直接输入总帐。 这些事务更新总帐中的帐户。 但是,这些交易不会更新历史过期试用余额报表。

  • 总帐中详细试用余额报表的日期范围与应付账款管理或应收账款管理中历史过期试用余额报表的日期范围不匹配。 打印“历史过期试用余额”报表时,请在“选择报表使用事务”区域中选中“GL 过帐日期检查”框。

  • 交易在应付账款管理或应收账款管理中过帐。 但是,如果这些交易用于初始余额,则不会过帐到总账。 如果未在购买系列或销售系列的“过帐设置”窗口中选择“过帐到总帐检查”框,则交易将过帐到应付账款管理或应收账款管理。 但是,这些交易不会过帐到总账。

  • 在“应付帐款管理设置”窗口或“应收账款管理设置”窗口中选择了“跟踪 GL 检查中可用的折扣”框。 然后,发票的净金额将过帐到总帐。 此外,剩余金额将过帐到可用折扣帐户。 只有净金额才会显示在总帐的“详细试用余额”报表上。 但是,发票在应付账款管理或应收账款管理中显示历史过期试用余额的总发票总额。

  • 文件在最初发布的时间段内作废。 总帐中的详细试用余额报表可能与历史过期试用余额报表不匹配。 例如,假设在 2007 年 1 月 1 日输入了发票。 此发票于 2007 年 2 月 1 日失效。 2007 年 2 月 1 日 - 2007 年 2 月 28 日打印了总账详细试算报表。 已取消的事务将显示在报表上。 如果使用相同的日期范围打印历史过期试用余额,则失效的文档将不会在报表上打印,因为它已被作废。

  • 如果要将总账中的应付账款帐户余额或应收账款帐户余额与某一时期的历史过期试用余额报表相平衡,则必须将历史过期试用余额报表中的余额与同一时期总帐中详细试用余额的净变化进行调节。

  • 如果要将总帐中的应付账款帐户余额或应收账款帐户余额与非特定时段的一天的历史过期试用余额报表相平衡,请确定应付账款管理或应收账款管理是否已平衡。 如果应付账款管理或应收账款管理从未平衡,则起始余额可能不正确。 在这种情况下,首先平衡当前时段,然后按相反顺序调和前几个月。

  • 如果发生过帐中断,则批可能未正确过帐到总帐、应付账款管理或应收账款管理。

  • 打印“历史过期试用余额”报表时,未在“排除”区域中选择以下检查框。

  • 选中这些检查框,然后打印“历史过期试用余额”报表。

    注意

    如果要按特定文档匹配总帐详细试用余额报表和历史过期试用余额报表,请清除“完全付费文档检查”框。

    • 未过账的已应用信用文档
    • 零余额
    • 活动
  • 如果在重估时使用多货币管理,则选择过帐到购买/销售抵消帐户。

  • 信用卡发票的“应付账款交易项”窗口中输入的金额。 这可能会导致应付账款管理与总账的对帐不平衡,因为只有净更改才会过帐到总帐模块。  (也就是说,似乎 GL 事务缺失,但 GL 端的金额被净化为一个 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 挂钩,这不是预期目的,尽管我们知道客户正在这样做。 协调到 GL 电子表格上的余额是对表中的分布使用简单加法/减法的最佳估计值。 而HATB上的余额几乎考虑了每一个表,而且要复杂得多,而且要准确得多,所以两者往往不相上下。

真正的协调应在 RM 或 PM 历史过期试用余额 (HATB) 与 GL 试用余额报告之间。 如果这些匹配,则不一定需要为该月运行协调到 GL 工具。 GL 表由借方和额度组成,HATB 从中提取的表是事务标头并应用记录表。 因此,客户需要一种方法来将 GL 中的分布与 RM 或 PM 中的分布表相协调,以帮助找到该级别的差异。 因此,这就是创建协调到 GL 例程的原因。 它旨在成为一种故障排除工具,用于将分发与模块之间的分布进行比较,以帮助识别缺少的分发,这可能会导致你从 HATB 返回缺少的事务。 因此,使用协调到 GL 工具只是为了 帮助你将 HATB 与 GL 试用余额进行协调。 如果 HATB 和 GL TB 余额,则不需要为该月运行“协调到 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:如果 GL 端缺少分发版,该怎么办?

A3:如果在 RM 或 PM 端发现不在 GL 端的分布,请调查 GL 端的计时差异。 检查以确保所有 GL 批都已过帐。 如果 GL 端确实缺少它们,则需要将调整日记条目直接键入 GL,以便该条目创建 GL 分布。

问题 4:如果 RM 或 PM 端缺少分发版,该怎么办?

A4:如果列出 GL 分布,但在 RM 或 PM 端缺少,请先调查计时差异。 此外,研究是否在 HATB 报表上列出了交易本身,并且是否已说明这一点。 事务可能存在,但只是缺少分布。 那么,如果 事务确实存在,问题就变成了如何获取 RM 或 PM 中的分布? 首先,请记住,RM 或 PM 中的分布表不用于 GP 中除此协调电子表格以外的任何其他目的或报表。 那么,真的有必要将它们重新添加到 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 表中的分布记录进行简单的借方/信用计算来计算起始余额,并且存储过程会联接标头表,因此不会包括缺少标头记录的任何分布。 最终结果可能是,某些分布被计算到上一个电子表格的结束余额中,而从下一个周期的开始余额中省略。

问题 8:RM/PM 端的分布确实存在,但未拉入电子表格。

A8:查看以下故障排除提示:

  • 检查在“协调到电子表格”上使用的日期范围。
  • 验证 PM 的PM10100或PM30600表中是否存在分布。 (或 RM:搜索RM10101或RM30301) 检查这些分布中的日期,确保它们位于为电子表格输入的范围内。 请务必在 RM 或 PM 分布表中查找这些日志,而不是仅依赖重印的过帐日记帐( 例如)。
  • 如果在 RM 或 PM 表中找到了分布区,请在前端的文档上查看这些分布。 它们是否具有 PAY 或 REC 或 AVAIL 的分发类型? 这些类型是将拉取到旧版本中 RM 或 PM 端的协调电子表格的唯一类型。  (更新:信用卡付款可能会向 AP 帐户生成一个分配,该帐户上的现金类型位于表中,但与 GL 电子表格的对帐未在左侧显示此分布。因此,只是电子表格的显示问题,而不是数据问题。但是,这似乎不是 Microsoft Dynamics GP 2016 中的问题,因为 CASH 类型现在已正确显示在电子表格上,因此一路上已修复。)

问题 9:是否可以以其他货币显示“协调到 GL”窗口?

A9:“协调到 GL”窗口,旨在仅显示 功能 货币。 有关详细信息,请参阅 有关 Microsoft Dynamics GP 中“协调到 GL”窗口中的余额的信息