Thông tin về sự khác biệt khi bạn đối chiếu cái quản lý khoản phải trả hoặc quản lý khoản phải thu trong Microsoft Dynamics GP

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch thuật của Microsoft và có thể được Cộng đồng Microsoft chỉnh sửa lại thông qua công nghệ CTF thay vì một biên dịch viên chuyên nghiệp. Microsoft cung cấp các bài viết được cả biên dịch viên và phần mềm dịch thuật thực hiện và cộng đồng chỉnh sửa lại để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng nhiều ngôn ngữ Tuy nhiên, bài viết do máy dịch hoặc thậm chí cộng đồng chỉnh sửa sau không phải lúc nào cũng hoàn hảo. Các bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra.

Nhấp chuột vào đây để xem bản tiếng Anh của bài viết này: 866570
GIỚI THIỆU
Bài viết này thảo luận về lý do khoản tài khoản thanh toán hoặc các khoản phải thu tài khoản tài khoản trong cái khác với tổng số tiền đó là do trên các lịch sử từ cân đối thử báo cáo trong Microsoft Dynamics GP. Đó câu hỏi thường gặp ở cuối bài viết này.
Thông tin thêm
Reconcile với sổ cái là mới đối với Microsoft Dynamics GP 10.0 (SP2). Cái này tạo một bảng tính Microsoft Office Exel. Bạn có thể sử dụng bảng tính này để phù hợp với giao dịch quản lý khoản phải trả hoặc quản lý khoản phải thu được tải lên cái. Quá trình này tạo chỉnh giao dịch. Tuy nhiên, quá trình này có thể giúp bạn xác định các giao dịch khác nhau được liệt kê trong phần này. Để mở cửa sổ "Đối chiếu với GL", trỏ chuột vàocông cụ trên Microsoft Dynamics GP menu, trỏ đến công việc, trỏ tới tài chínhrồi sau đó bấm Reconcile vào sổ cái.


Dưới đây là danh sách chạy các vấn đề mà chúng tôi thấy rằng có thể gây ra sự khác biệt:

  • Báo cáo lịch sử từ cân đối thử in hạn chế. In báo cáo lịch sử tuổi cân đối thử lại với chỉ là một giới hạn ngày.
  • Không phải tất cả tài khoản thanh toán hoặc tài khoản tất cả các tài khoản phải thu nói chung xem sổ cái. Đảm bảo rằng bạn xem tất cả các tài khoản tài khoản thanh toán hoặc tất cả các tài khoản tài khoản khoản phải thu cái.
  • Lô quản lý khoản phải trả hoặc quản lý khoản phải thu được tải lên cái. Bó trong cái thay đổi hoặc chỉnh sửa trước khi nó được gửi.
  • Điều chỉnh tài khoản tài khoản thanh toán hoặc tài khoản phải thu tài khoản có thể nhập trực tiếp trong tổng sổ cái. Giao dịch các cập nhật tài khoản trong cái. Tuy nhiên, các giao dịch không Cập Nhật báo cáo cân đối thử tuổi lịch sử.
  • Phạm vi ngày trên cân đối thử chi tiết báo cáo trong tổng sổ cái phù hợp với phạm vi ngày lịch sử từ cân đối thử báo cáo quản lý khoản phải trả hoặc quản lý khoản phải thu. Khi bạn in báo cáo lịch sử từ cân đối thử, bấm để chọn hộp kiểm GL đăng ngày trong khu vực Chọn giao dịch trong báo cáo sử dụng .
  • Giao dịch đã được đăng trong quản lý khoản phải trả hoặc quản lý khoản phải thu. Tuy nhiên, các giao dịch đã không tải lên cái nếu họ cho số dư đầu. Nếu hộp kiểm Sau vào sổ cái chung không được chọn trong cửa sổ thiết lập quyền cho nhóm mua hoặc bán hàng loạt, các giao dịch sẽ được đăng để quản lý khoản phải trả hoặc quản lý khoản phải thu. Tuy nhiên, các giao dịch sẽ không được tải lên cái.
  • Hộp Theo dõi giảm giá bằng GL được chọn trong cửa sổ thiết lập quản lý khoản phải trả hoặc trong cửa sổ thiết lập quản lý khoản phải thu. Sau đó, số hóa đơn, mạng sẽ được gửi cái. Ngoài ra, số còn lại được tải lên tài khoản có giảm giá. Chỉ số mạng sẽ xuất hiện trong báo cáo chi tiết cân đối thử nói chung sổ cái. Tuy nhiên, hoá đơn Hiển thị tất cả tổng đơn trên lịch sử từ thử nghiệm cân bằng trong quản lý khoản phải trả hoặc quản lý khoản phải thu.
  • Tài liệu được voided trong một khoảng thời gian khác với họ đã được gửi. Cân đối thử chi tiết báo cáo trong tổng sổ cái có thể không phù hợp với báo cáo cân đối thử tuổi lịch sử. Ví dụ: giả sử hoá đơn vào 1/1/2007. Hoá đơn này được voided ngày 2/1/2007. Báo cáo cân đối thử chi tiết sổ cái chung được in 2/1/2007-28/2/2007. Giao dịch voided sẽ xuất hiện trong báo cáo. Nếu tuổi cân bằng lịch sử thử nghiệm máy in bằng cách sử dụng cùng một phạm vi ngày, voided tài liệu sẽ in báo cáo bởi vì nó đã được voided.
  • Nếu bạn muốn cân bằng tài khoản tài khoản thanh toán cân bằng hoặc các khoản phải thu tài khoản tài khoản dư nói chung sổ cái để các lịch sử từ cân đối thử báo cáo trong một thời gian nhất định, số dư từ báo cáo lịch sử cân đối thử tuổi phải được hòa vào mạng thay đổi trên cân đối thử chi tiết nói chung sổ cái trong cùng một thời gian.
  • Nếu bạn muốn cân bằng tài khoản thanh toán tài khoản hoặc tài khoản khoản phải thu khoản cân đối nói chung sổ cái để báo cáo lịch sử từ cân đối thử một ngày mà không có trong một thời gian, xác định xem quản lý khoản phải trả hoặc quản lý khoản phải thu có bao giờ được cân bằng. Nếu quản lý khoản phải trả hoặc quản lý khoản phải thu đã không bao giờ được cân bằng, số dư đầu có thể không chính xác. Trong trường hợp này, cân bằng nhất giai đoạn đầu tiên, và sau đó đối chiếu tháng trước theo thứ tự đảo ngược.
  • Nếu đăng gián đoạn xảy ra, lô có thể không có được đăng đúng cái, quản lý khoản phải trả hoặc quản lý khoản phải thu.
  • Không phải tất cả cái lô đã được đăng.
  • Khi bạn in báo cáo lịch sử từ cân đối thử, bạn đã không bấm để chọn hộp kiểm sau trong khu vực loại trừ:
    • Các ứng dụng tín dụng tài liệu
    • Không cân bằng
    • Hoạt động
    Bấm để chọn các hộp kiểm, và sau đó in báo cáo cân đối thử từ lịch sử.

    Lưu ý: Nếu bạn muốn khớp với báo cáo cân đối thử chi tiết sổ cái chung và báo cáo cân đối thử từ lịch sử của tài liệu cụ thể, bấm để bỏ chọn hộp kiểm tra Đầy đủ trả tài liệu .
  • Nếu bạn sử dụng quản lý đa tiền tệ khi bạn revalue, bạn chọn đăng lên tài khoản bù mua bán.
  • Trong Microsoft Dynamics GP 10.0, số thẻ tín dụng đã được nhập vào trong cửa sổ bút toán giao dịch khoản phải trả cho hóa đơn. Điều này có thể gây ra sự mất cân bằng reconcile quản lý khoản phải trả để cái vì chỉ thay đổi mạng sẽ đăng lên mô-đun cái.
  • Nếu có bài gián đoạn/vấn đề với lô khoản phải trả hoặc khoản phải thu và các giao dịch được tìm thấy trong cả công việc và mở bảng cùng một lúc, xoá hàng loạt RM hoặc PM GP sẽ gây ra sự cố. Trong trường hợp này, người dùng thường thấy ghi trong cả hai bảng và quyết định các không cần bó làm việc để chúng chỉ xoá trong GP. Vì công việc và mở bảng chia sẻ bảng phân phối, xoá hàng loạt trong GP cũng sẽ xoá hồ sơ phân phối với nó. Kết quả cuối cùng là ghi tiêu đề giao dịch tồn tại, nhưng không có không phân phối phù hợp bên RM hoặc chiều mà GL được cập nhật một cách chính xác. Vấn đề này sẽ được coi là phiên bản tiếp theo của Microsoft Dynamics GP.
  • Phân phối có thể hiển thị phần có thể phù hợp với số tiền khác nhau nếu có giảm giá. Để phù hợp, các tài khoản giảm giá GL nên đã được kéo bằng tài khoản PM/RM trước khi chạy Reconcile GL xử lý. Đóng bảng tính bật lên và chạy lại với tài khoản GL giảm giá được liệt kê cùng.
  • Phân phối có thể thiếu bên PM/RM nếu loại (tiền mặt, thanh toán, PURCH) được thay đổi. Bảng tính reconcile, tài khoản chỉ được sử dụng cho GL. Tài khoản không được sử dụng bên PM/RM. Phía PM/RM kéo bằng tiền hoặc mục nhập bất kể tài khoản nào được sử dụng, đó là lý do tại sao bạn phải đảm bảo danh sách tất cả các chạm hoặc AR tài khoản trên sổ reconcile. Và chỉ chuyển nhập phân phối trong bảng SQL không phân phối tự động xuất hiện nếu bạn tái tạo các bảng tính.
  • Kiểm tra áp dụng ngày và GL đăng ngày trong bảng áp dụng cho các giao dịch đa tiền tệ so với thực tế ngày này đã được đăng trong GL. Ví dụ, ngày 22 tháng 1, ghi tín dụng ngày 31 tháng 12 được áp dụng cho hóa đơn ngày 5 tháng 12 và ngày áp dụng và GL sau ngày còn lại là ngày 22. Tuy nhiên, khi đăng bó GL, người dùng đổi ngày 31 tháng 12. Trong trường hợp này, Reconcile sang GL bảng tính cho tháng mười hai liệt kê số thực hiện được/mất trên cả hai mặt và họ dường như đối chiếu. Tuy nhiên, báo cáo HATB nhận dạng số thực hiện được/mất chưa và sẽ giảm số tiền này khi so sánh với GL, vì nó không được áp dụng hoặc gửi đến ngày theo hồ sơ áp dụng.


Câu hỏi thường gặp:


Câu hỏi 1: Là Reconcile GL bảng tính hòa đúng cho khoản phải thu/khoản phải trả vào sổ cái?

A1: Reconcile để GLfeature là một công cụ gỡ rối' để giúp người dùng xác định chưa từng phân phối giữa RM/PM và GL. Đó không nhất thiết phải buộc trong HATB và mà không đích, mặc dù chúng tôi biết khách hàng đang phục. Số dư trên Reconcile sang bảng tính GL là tốt nhất ước tính bằng cách sử dụng trình bổ sung/trừ đơn giản trên phân phối trong bảng. Số dư trên HATB đi gần như tất cả bảng vào xem xét và phức tạp hơn và chính xác cân bằng và như vậy hai thường không buộc ra.

'Đúng' đối chiếu nên giữa RM hoặc PM lịch sử từ cân đối thử (HATB) và cân đối thử GL báo cáo. Nếu các kết hợp, sau đó bạn sẽ không nhất thiết phải chạy Reconcile công cụ GL tháng. Bảng GL được ghi nợ và tín dụng, và và bảng HATB kéo từ tiêu đề giao dịch và áp dụng bảng dữ liệu. Vì vậy khách hàng yêu cầu cách đối chiếu phân phối trong GL bảng phân phối trong RM chiều nhằm tìm thấy sự khác biệt ở cấp đó. Đây là lý do tại sao Reconcile với sổ cái được tạo ra. Nó được dự định là một công cụ khắc phục sự cố để so sánh phân phối để phân phối giữa các mô-đun để giúp xác định thiếu phân phối, có thể dẫn bạn về transactionfrom thiếu HATB. Để sử dụng Reconcile GL công cụ như là một trợ giúp chỉ để giúp bạn đối chiếu HATB để cân đối thử GL. Nếu HATB và GL TB cân bằng, sau đó không thực sự phải chạy Reconcile công cụ GL tháng.


Câu hỏi 2: Nên tổng số trên Reconcile sang GL bảng tính phù hợp với tổng số trên HATB?

A2: Không. Tổng số ngày Reconcile sang bảng tính GL là chỉ một đơn giản thêm/trừ phân phối ghi trong bảng đó và không có bất kỳ bảng khác xem xét. Trong khi HATB nhìn hoàn toàn khác bảng tính một cân bằng cách sử dụng giao dịch và áp dụng ghi bảng và là một tính toán phức tạp hơn. Vì tính toán khác nhau phương pháp/bảng được sử dụng để lấy các cân đối, Reconcile sang bảng tính GL không phải hoàn toàn hòa vào dư lão hóa trên các báo cáo HATB và khiến đối chiếu chúng trở nên khó khăn. Nó không cần thiết để buộc các cân đối trên reconcile sang bảng tính GL HATB báo cáo.

Chúng tôi khuyên bạn nên bỏ qua tổng trên reconcile sang bảng tính GL, và chỉ sử dụng phần Unmatched và phù hợp có thể giúp bạn tìm thấy sự khác biệt để nghiên cứu để xem nếu đó cũng có thể giải thích sự khác biệt giữa GL TB và HATB. Reconcile sang bảng tính GL không hòa đúng và chỉ được dùng để là sự hỗ trợ để giúp bạn xác định sự khác biệt phân phối nghiên cứu để xem nếu điều này cũng có sự khác biệt ở cấp độ giao dịch. Thực tế, nếu HATB khớp với GL TB, thực sự sẽ không có cần thiết để chạy reconcile GL Tiện ích cho tháng, vì không có sự khác biệt để xác định.

Nếu vẫn muốn buộc cân bằng trên reconcile sang GL bảng tính cân bằng trên HATB, điều này không được hỗ trợ trong trường hợp hỗ trợ thông thường. Lý do chúng tôi đã xác định được liệt kê ở trên cơ sở kiến thức này và có thể có nhiều lý do chưa xác định. Tuy nhiên, vì reconcile này không cần thiết từ tất cả dư đơn giản được liệt kê trên reconcile GL bảng tính và cân bằng tính phức tạp hơn trên báo cáo HATB không đích Tiện ích reconcile này, nó sẽ được coi là chi phí tư vấn thâm nhập vào dữ liệu của bạn để giúp bạn đối chiếu này với nhau.



Câu hỏi 3: Tôi phải làm gì nếu phân phối thiếu bên GL?

A3: nếu bạn tìm thấy phân phối RM hoặc PM bên phải phía GL, điều tra phía GL cho thời gian khác nhau. Kiểm tra để đảm bảo rằng tất cả GL lô được đăng. Nếu có sự thiếu bên GL, bạn sẽ cần để mục Nhật ký adjusting trực tiếp vào GL các mục để tạo phân phối GL.



Câu hỏi 4: Tôi phải làm gì nếu phân phối thiếu bên RM hoặc PM?

A4: Nếu phân phối GL được liệt kê, nhưng thiếu bên RM hoặc PM, đầu tiên nghiên cứu cho thời gian khác nhau. Cũng nghiên cứu để xem các giao dịch tự được liệt kê trong báo cáo HATB và đã được chiếm. Có thể giao dịch tồn tại, nhưng các bản phân phối chỉ thiếu. Vì vậy, vấn đề có 'làm thế nào tôi nhận phân phối trong RM PM, nếu giao dịch không?' Trước tiên, hãy nhớ bảng phân phối trong RM PM không được sử dụng cho bất kỳ mục đích nào khác hay một báo cáo trong GP, khác hơn này đối chiếu bảng tính. Như vậy là cần thiết để có được thêm vào RM hoặc PM? Đánh giá nếu nó là giá trị thời gian của bạn để xác định một bảng không sử dụng bất kỳ nơi nào khác.

Tuy nhiên, nếu bạn muốn sửa chữa bảng phân phối PM, bạn phải huỷ tài liệu, để áp dụng hồ sơ di chuyển trở lại để mở. Sử dụng các loại bỏ giao dịch lịch sử hữu ích để loại bỏ các tài liệu voided. Đảm bảo đặt bài ' đăng lên ' GL và không 'gửi đến vào sổ cái'. Xoá bó GL tạo khoảng trống. Sau đó, rekey tài liệu trở lại vào khoản phải trả, do đó, giao dịch và phân phối được tạo lại. Hãy chắc chắn void GL lô này. Sau đó áp dụng lại tài liệu mới để mở tài liệu và họ sẽ di chuyển lịch sử một lần nữa.

Để khắc phục nó vào bảng phân phối RM, bạn sẽ phải loại bỏ cả hai bên đơn và thanh toán rekey chúng trở lại và xoá hàng loạt trong GL.



Câu hỏi 5: Giao dịch trong phần có khả năng kết hợp giống như họ phù hợp. Tại sao không chúng trong phần Matched?

A5:Có nhiều trường hợp cho mỗi hồ sơ phân phối. Tất cả các trường phải phù hợp với di chuyển sang phần Matched. Nếu một số nhưng không phải tất cả các trường phù hợp, sau đó nó sẽ đặt nó trong phần có thể xuất hiện. Ví dụ: đây là trường hợp cho chiều vào sổ cái:

Quản lý khoản phải trả - GL
Phiếu số - Có nguồn gốc điều khiển số
Nguồn SG - Nguồn gốc SG nguồn
Đăng ngày - ngày giao dịch
Trên tài khoản tiền - Ghi số tiền hoặc số tiền tín dụng


Q6: Nếu tôi khoá phân phối thiếu GL hoặc RM/PM bật lên và chạy Reconcile sang bảng tính GL sẽ di chuyển các khả năng phù hợp hoặc chưa từng phần Matched?

A6: Không. Nếu giao dịch được keyed riêng các sẽ có số phiếu khác nhau và mã nguồn SG. Tốt nhất đăng ngày và số lượng có thể phù hợp, mà có thể đặt chúng trong phần có khả năng kết hợp của bảng tính.



Q7:Sao dư kết thúc vào một bảng tính hàng tháng hoặc hàng quý không khớp với số dư đầu trên bảng tính hàng tháng hoặc hàng quý tiếp theo?

A7: Ifthe kết thúc cân bằng một thời gian không khớp với số dư đầu kỳ tiếp theo, nó thường do hồ sơ phân phối đơn lẻ phải có tiêu đề ghi trong bảng phụ sổ cái. Cân bằng kết thúc được tính bằng Excel ngay trong bảng tính. Nó chỉ có số dư đầu cho giai đoạn đầu của bảng tính và thêm/trừ ghi phân phối xuất hiện trên bảng tính đến dư kết thúc. Mặt khác, trong giai đoạn tiếp theo, số dư đầu được tính bằng cách tính đơn giản ghi nợ/tín dụng phân phối các bản ghi trong bảng SQL và quy trình được lưu trữ kết nối bảng tiêu đề, do đó, nó sẽ không bao gồm bất kỳ phân phối thiếu sơ tiêu đề. Kết quả cuối cùng có thể là phân phối một số được tính vào số dư kết thúc vào bảng tính trước, và bỏ qua từ số dư đầu giai đoạn tiếp theo.



Câu hỏi 8: Phân phối bên RM/PM tồn tại, nhưng không kéo vào bảng tính.

A8: Xem lại các mẹo gỡ rối:
  • Kiểm tra ngày rangeused trên Reconcile sang bảng tính.
  • Kiểm chứng rằng các bản phân phối trong bảng PM10100 hoặc PM30600 PM. (hoặc RM: tìm RM10101 hoặc RM30301) kiểm tra ngày trên các bản phát hành để đảm bảo rằng họ nằm trong phạm vi bạn nhập bảng tính. Điều quan trọng để xác định trong bảng phân phối RM hoặc PM và phải dựa vào in lại bài báo ví dụ.
  • Nếu bạn thấy các bản phân phối trong bảng RM hoặc PM, sau đó xem phân phối các tài liệu trong các kết thúc. Họ có một loại phân phối trả hoặc mục? Đây là những loại duy nhất sẽ được kéo bảng tính reconcile bên RM hoặc PM.


Cảnh báo: Bài viết này được dịch tự động

Thuộc tính

ID Bài viết: 866570 - Xem lại Lần cuối: 09/07/2016 21:02:00 - Bản sửa đổi: 0.8

Microsoft Dynamics GP 2015, Microsoft Dynamics GP 2013, Microsoft Dynamics GP 2010, Microsoft Dynamics GP 10.0, Microsoft Dynamics GP 9.0

  • kbexpertiseinter kbhowto kbinfo kbexpertisebeginner kbmbsmigrate kbmt KB866570 KbMtvi
Phản hồi