Share via

當您將一般總賬與應付款管理或應收款管理協調時的差異相關信息

  • 發行項

本文討論為什麼一般總帳中的 帳戶可支付 帳戶餘額或帳戶應收賬款餘額，與 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 協調] 電子錶格只會報告張貼的專案。)

  • 歷程記錄過時試用餘額報表會列印有限制。 再次列印歷程記錄過時試用餘額報表，且只有日期限制。

  • 並非所有帳戶的可支付帳戶或所有應收賬款帳戶都會在一般總賬中檢視。 請確定您在 [一般總帳] 中檢視所有帳戶的可支付帳戶或所有應收賬款帳戶。

  • Payables Management 或 Receivables Management 中的批次已張貼到一般總帳。 一般總帳中的批次在張貼之前已變更或編輯。

  • 對可支付帳戶或應收賬款帳戶的調整可能已直接在一般總賬中輸入。 這些交易會更新一般總帳中的帳戶。 不過，這些交易不會更新歷程記錄過時試用餘額報告。

  • [一般總帳] 中 [詳細試用餘額] 報表的日期範圍，與 「應付賬款管理」或「應收款管理」中歷史過時試用餘額報表的日期範圍不符。 當您列印歷程記錄過時試用餘額報表時，請選取 [選取使用報表的交易] 區域中的 [GL 張貼日期 ] 複選 框。

  • 交易已張貼在「應付金管理」或「應收款管理」中。 不過，如果這些交易是用於開始餘額，則不會張貼到一般總帳。 如果在購買系列或銷售系列的 [張貼設定] 視窗中未選取 [ 張貼到一般 總帳] 複選框，則交易會張貼到 [支付專案管理] 或 [應收款管理]。 不過，這些交易不會張貼到一般總賬。

  • [ GL 中可用的追蹤折扣 ] 複選框選取於 [支付專案管理設定] 視窗或 [應收賬款管理設定] 視窗中。 然後，發票的凈金額會張貼到一般總帳。 此外，剩餘的金額會張貼到折扣可用的帳戶。 [一般總帳] 中的 [詳細試用餘額] 報告中只會顯示淨金額。 不過，發票會在Payables Management或Receivables Management的歷程記錄過時試用餘額上顯示發票總計。

  • 檔的停用期間與最初張貼的檔不同。 一般總帳中的詳細試用餘額報表可能不符合歷程記錄過時試用餘額報表。 例如，假設在 2007 年 1 月 1 日輸入發票。 此發票在 2007 年 2 月 1 日無效。 2007 年 2 月 1 日 - 2/28/2007 列印一般總賬詳細試用餘額報表。 無效的交易會出現在報表上。 如果使用相同的日期範圍列印歷程記錄過時試用期餘額，則無效的檔將不會列印在報表上，因為它已經失效。

  • 如果您想要將一般總帳中的帳戶可支付帳戶餘額或應收賬款帳戶餘額，餘額平衡到一段特定期間的「歷程記錄過時試用餘額」報表，則「歷程記錄過時試用餘額」報表的餘額必須與「一般總帳」中詳細試用餘額的凈變更進行一致。

  • 如果您想要將一般總帳中的帳戶可支付帳戶餘額或應收賬款帳戶餘額，餘額平衡至未在特定期間內的「歷程記錄過時試用餘額」報告，請判斷「支付帳戶管理」或「應收款管理」是否曾經取得平衡。 如果 Payables Management 或 Receivables Management 從未取得平衡，則開頭餘額可能不正確。 在此情況下，請先平衡最新的期間，然後以反向順序協調前幾個月。

  • 如果發生張貼中斷，批次可能未正確張貼到一般總賬、支付金管理或應收款管理。

  • 當您列印 [歷史過時試用餘額] 報表時，並未在 [排除] 區域中選取下列複選框。

  • 選取這些複選框，然後列印歷程記錄過時試用餘額報告。

    注意事項

    如果您想要依特定檔比對一般總賬詳細試用餘額報表和歷程記錄過時試用餘額報表，請清除 [ 完全付費檔] 複選框。

    • 未張貼的套用點數檔
    • 零餘額
    • 活動

  • 如果您在重新評估時使用多Currency Management，則選擇張貼到購買/銷售位移帳戶。

  • 在發票的 [支付金額交易專案] 視窗中輸入的信用卡金額。 這可能會導致支付金管理與一般總賬的協調不平衡，因為只有凈變更會張貼到一般總賬模組。  (也就是說，GL 交易似乎遺失，但 GL 端的金額會凈化為一個 GL 專案，而 PM 端可能會顯示三筆記錄。但它們在更新版本中仍應相符，並正確地移至 [相符的交易] 區段。)

  • 如果 Payables 或 Receivables 批次發生張貼中斷/問題，而且同時在 Work 和 Open 數據表中找到交易，刪除 Microsoft Dynamics GP 中的 RM 或 PM 批次將會造成問題。 在此情況下，使用者通常會看到這兩個數據表中的記錄，並決定 不需要工作批次，因此只要在 Microsoft Dynamics GP 中刪除它即可。 由於 Work 和 Open 資料表共用散發數據表，因此刪除 Microsoft Dynamics GP 中的批次也會移除隨附的散發記錄。 最終結果是交易標頭記錄存在，但 RM 或 PM 端沒有相符的散發套件，但 GL 已正確更新。 此問題將在下一版的 Microsoft Dynamics GP 中考慮。

  • 如果有折扣，分佈可能會顯示在 [可能相符] 區段中，且金額不同。 為了相符，應該先使用PM/RM帳戶提取折扣 GL 帳戶，再執行[與 GL 協調] 程式。 關閉電子表格，並使用列出的折扣 GL 帳戶重新執行。

  • 如果變更了 (CASH、PAY、PURCH) 類型，則 PM/RM 端可能會遺失散發套件。 在協調電子錶格上，帳戶只用於 GL 端。 此帳戶不會用於 PM/RM 端。 不論使用哪一個帳戶，PM/RM 端都會使用PAY或 REC 類型提取，因此您應該確定在協調視窗上列出所有 AP 或 AR 帳戶的原因。 如果您重新產生電子表格，只要切換 SQL 資料表中的散發類型，就不會自動顯示散發。  (這是舊版使用 CASH 類型付款並點擊 AP 帳戶的問題，但這些記錄會顯示在 GP 2016 中，因此不再出現問題。)

  • 相較於在 GL 中張貼的實際日期，請檢查套用數據表中的套用日期和 GL 張貼日期，以取得多Currency 交易。 例如，在 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 試用餘額報告之間。 如果符合這些專案，則您不需要在該月份執行 Reconcile to GL 工具。 GL 數據表是由轉帳和點數所組成，而 HATB 從中提取的數據表則是交易標頭和套用記錄數據表。 因此，客戶要求將 GL 中的散發與 RM 或 PM 中的通訊表進行協調，以協助找出該層級的差異。 因此，這就是建立協調至 GL 例程的原因。 它是一個疑難解答工具，用來比較模組之間的散發與散發，以協助識別遺漏的散發，這可能會導致您回到 HATB 中遺失的交易。 因此，使用 Reconcile to 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 上的餘額，則在一般支援案例中不支援此項。 我們識別的原因會列在此 KB 頂端，而且可能還有更多原因尚未識別。 但是，由於在協調至 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 的欄位：

Payables Management -- GL
憑券號碼 -- 原始控制編號
TRX 來源 -- 原始 TRX 來源
張貼日期 -- 交易日期
帳戶金額 -- 轉帳金額或點數金額

問 6：如果我在 GL 或 RM/PM 中按下遺漏的散發套件，然後重新執行 [與 GL 協調] 電子表格，不相符或可能相符的專案是否會移至 [相符] 區段？

A6：否。 如果交易是個別索引鍵，則 會有不同的憑券號碼和 Trx 原始程式碼。 [張貼日期] 和 [金額] 最好相符，這可將它們放在電子表格的 [可能相符] 區段中。

問 7：為什麼每月或每季電子表格的結束餘額不符合下一個月或每季電子表格的 \[開始餘額\]？

A7：如果一個期間的終止餘額不符合下一個期間的開始餘額，通常是因為子總賬數據表中沒有相關聯標頭記錄的孤立散發記錄所致。 結束餘額是由Excel在電子錶格中右側計算。 它只會取得電子表格頂端該期間的開始餘額，並新增/減去電子錶格上顯示的通訊記錄，以達到結束餘額。 另一方面，在下一個期間，開始餘額的計算方式是使用SQL數據表中散發記錄的簡單轉帳/信用額度計算，而預存程式會聯結標頭數據表，因此不會包含遺漏標頭記錄的任何散發套件。 最終結果可能是某些散發已計算成先前電子表格的結束餘額，並在下一個期間從開始餘額中省略。

問 8：RM/PM 端的散發套件確實存在，但並未提取到電子錶格中。

A8：檢閱下列疑難解答秘訣：

  • 檢查 Reconcile to 電子錶格上使用的日期範圍。
  • 確認散發套件確實存在於 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] 視窗中餘額的相關信息。