일반 원장을 Payables Management 또는 수취인 관리로 조정하는 경우의 차이점에 대한 정보

이 문서에서는 Microsoft Dynamics GP의 기록 노인 평가판 잔액 보고서에 기한이 있는 총 금액과 일반 원장의 계정 미결제 계정 잔액 또는 미수금 계정 잔액이 다른 이유를 설명합니다. 이 문서의 끝에는 일반적으로 질문과 대답이 있습니다.

적용 대상: Microsoft Dynamics GP
원본 KB 번호: 866570

GL로 조정 루틴은 Microsoft Dynamics GP 10.0(SP2)의 새로운 것입니다. 이 루틴은 Microsoft Office Excel 스프레드시트를 생성합니다. 이 스프레드시트를 사용하여 일반 원장에 게시된 Payables Management 또는 Receivables Management의 트랜잭션과 일치시킬 수 있습니다. 이 프로세스는 수정 트랜잭션을 생성하지 않습니다. 그러나 이 프로세스는 이 섹션에 나열된 트랜잭션 차이를 확인하는 데 도움이 될 수 있습니다. GL로 조정 창을 열려면 Microsoft Dynamics GP 메뉴의 도구를 가리키고 루틴을 가리킨 다음 재무를 가리킨 다음 GL로 조정을 선택합니다.

다음은 차이점을 일으킬 수 있는 문제를 실행 중인 목록입니다.

• 모든 GL 일괄 처리가 게시되는 것은 아닙니다. (GL로 조정 스프레드시트는 게시된 항목에 대해서만 보고합니다.)

• 기록 오래된 평가판 균형 보고서는 제한 사항으로 인쇄됩니다. 날짜 제한만 사용하여 기록 오래된 평가판 잔액 보고서를 다시 인쇄합니다.

• 모든 계정의 미지급 계정 또는 모든 계정 수취 계정이 일반 원장에서 볼 수 있는 것은 아닙니다. 일반 원장에서 모든 계정 지불 계정 또는 모든 계정 수취인 계정을 볼 수 있는지 확인합니다.

• Payables Management 또는 Receivables Management의 일괄 처리가 일반 원장에 게시되었습니다. 일반 원장의 일괄 처리는 게시되기 전에 변경되거나 편집되었습니다.

• 미지급 계정 또는 미수금 계정에 대한 조정은 일반 원장에 직접 입력되었을 수 있습니다. 이러한 트랜잭션은 일반 원장의 계정을 업데이트합니다. 그러나 이러한 트랜잭션은 이전 평가판 잔액 보고서를 업데이트하지 않습니다.

• 일반 원장의 자세한 평가판 잔액 보고서의 날짜 범위는 Payables Management 또는 수취인 관리의 기록 노인 평가판 잔액 보고서의 날짜 범위와 일치하지 않습니다. 기록 오래된 평가판 잔액 보고서를 인쇄할 때 사용 중인 보고서에 대한 트랜잭션 선택 영역에서 GL 게시 날짜 검사 상자를 선택합니다.

• 트랜잭션은 Payables Management 또는 수취 관리에서 게시되었습니다. 그러나 이러한 트랜잭션은 시작 잔액에 대한 경우 일반 원장에 게시되지 않았습니다. 구매 시리즈 또는 판매 시리즈의 게시 설정 창에서 일반 원장 검사 게시 상자가 선택되지 않은 경우 트랜잭션은 Payables Management 또는 수취인 관리에 게시됩니다. 그러나 이러한 트랜잭션은 일반 원장에 게시되지 않습니다.

• GL 검사 사용 가능한 할인 추적 상자는 Payables Management Setup 창 또는 수취인 관리 설정 창에서 선택되어 있습니다. 그런 다음 청구서의 순 금액이 일반 원장에 게시됩니다. 또한 나머지 금액은 사용 가능한 할인 계정에 게시됩니다. 순 금액만 일반 원장의 자세한 평가판 잔액 보고서에 표시됩니다. 그러나 청구서는 미지급금 관리 또는 수취 관리의 기록 노인 평가판 잔액에 총 송장을 표시합니다.

• 문서는 원래 게시된 것과 다른 기간에 무효화되었습니다. 일반 원장의 자세한 평가판 잔액 보고서는 이전 평가판 잔액 보고서와 일치하지 않을 수 있습니다. 예를 들어 청구서가 2007년 1월 1일에 입력되었다고 가정합니다. 이 송장은 2007년 2월 1일에 무효화되었습니다. 일반 원장 세부 평가판 균형 보고서는 2007년 2월 1일 - 2007년 2월 28일 인쇄됩니다. 무효화된 트랜잭션이 보고서에 표시됩니다. 동일한 날짜 범위를 사용하여 기록 오래된 평가판 잔액을 인쇄하는 경우 무효화된 문서는 무효화되었기 때문에 보고서에 인쇄되지 않습니다.

• 일정 기간 동안 일반 원장의 미지급 계정 잔액 또는 미수금 계정의 계정 잔액을 특정 기간 동안 기록 노인 평가판 잔액 보고서에 분산하려면 기록 노인 평가판 잔액 보고서의 잔액을 동일한 기간 동안 일반 원장의 세부 평가판 잔액에 대한 순 변경 내용으로 조정해야 합니다.

• 일반 원장의 미지급 계정 잔액 또는 미수금 계좌 잔액을 특정 기간에 있지 않은 날의 기록 노인 평가판 잔액 보고서로 균형을 맞추려면 Payables Management 또는 Receivables Management의 잔액을 결정합니다. Payables Management 또는 Receivables Management가 균형 잡힌 적이 없는 경우 시작 잔액이 올바르지 않을 수 있습니다. 이 경우 가장 현재 기간의 균형을 먼저 조정한 다음 이전 달을 역순으로 조정합니다.

• 게시 중단이 발생한 경우 일괄 처리가 일반 원장, 지불 관리 또는 수취인 관리에 올바르게 게시되지 않았을 수 있습니다.

• 기록 노인 평가판 잔액 보고서를 인쇄할 때 제외 영역에서 다음 검사 상자를 선택하지 않았습니다.

• 이러한 검사 상자를 선택한 다음 기록 오래된 평가판 균형 보고서를 인쇄합니다.

  참고

  일반 원장 세부 평가판 균형 보고서 및 특정 문서별로 이전 평가판 잔액 보고서를 일치하려면 완전 지불 문서 검사 상자를 선택 취소합니다.

  • 게시되지 않은 적용된 신용 문서
  • 제로 밸런스
  • 활동

• 재평가할 때 다중 동시성 관리를 사용하는 경우 구매/판매 오프셋 계정에 게시하도록 선택했습니다.

• 청구서의 지급액 거래 항목 창에 입력된 크레딧 카드 금액입니다. 이렇게 하면 순 변경 내용만 일반 원장 모듈에 게시되므로 Payables Management가 일반 원장에 대한 조정에 불균형을 일으킬 수 있습니다. 즉, GL 트랜잭션이 누락된 것처럼 보이지만 GL 쪽의 금액은 하나의 GL 항목으로 그물로 묶인 반면 PM 측은 세 개의 레코드를 표시할 수 있습니다. 그러나 여전히 이후 버전에서 일치해야 하며 일치하는 트랜잭션 섹션으로 올바르게 이동해야 합니다.)

• Payables 또는 Receivables 일괄 처리에 중단/문제가 게시되고 트랜잭션이 동시에 작업 및 열기 테이블에서 발견되면 Microsoft Dynamics GP에서 RM 또는 PM 일괄 처리를 삭제하면 문제가 발생합니다. 이 instance 사용자는 일반적으로 두 테이블의 레코드를 보고 Microsoft Dynamics GP에서 삭제하기 위해 작업 일괄 처리가 필요하지 않다고 결정합니다. 작업 및 열기 테이블은 배포 테이블을 공유하므로 Microsoft Dynamics GP에서 일괄 처리를 삭제하면 배포 레코드도 제거됩니다. 최종 결과는 트랜잭션 헤더 레코드가 있지만 RM 또는 PM 쪽에 일치하는 배포가 없지만 GL이 올바르게 업데이트되었습니다. 이 문제는 다음 버전의 Microsoft Dynamics GP에서 고려됩니다.

• 할인이 있는 경우 잠재적으로 일치하는 섹션에 분포가 서로 다른 금액으로 표시될 수 있습니다. 일치하려면 GL에 조정 프로세스를 실행하기 전에 PM/RM 계정으로 할인 GL 계정을 가져와야 합니다. 스프레드시트를 닫고 할인 GL 계정도 나열된 상태에서 다시 실행합니다.

• 유형(현금, 지불, PURCH)이 변경된 경우 PM/RM 쪽에서 배포가 누락될 수 있습니다. 스프레드시트 조정에서 계정은 GL 쪽에만 사용됩니다. PM/RM 쪽에서는 계정이 사용되지 않습니다. PM/RM 쪽은 사용되는 계정에 관계없이 PAY 또는 REC 형식을 사용하여 끌어오기 때문에 조정 창에 모든 AP 또는 AR 계정을 나열해야 합니다. 또한 단순히 SQL 테이블에서 배포 유형을 전환해도 스프레드시트를 다시 생성하는 경우 배포가 자동으로 표시되지 않습니다. (이것은 현금 유형을 사용하고 AP 계정을 타격하는 신용 카드 지불에 대한 이전 버전에서 문제였지만, 이러한 레코드는 GP 2016에 표시되므로 더 이상 문제가되지 않습니다.)

• 적용 테이블에서 적용 날짜 및 GL 게시 날짜를 확인하여 GL에 게시된 실제 날짜와 비교하여 다중 동시성 트랜잭션을 확인합니다. 예를 들어 1월 22일에 12월 31일자 신용 메모가 12월 5일의 청구서에 적용되었고 적용 날짜 및 GL 게시 날짜는 1월 22일로 남아 있었습니다. 그러나 GL 일괄 처리를 게시할 때 사용자는 날짜를 12월 31일로 변경했습니다. 이 경우 12월의 GL로 조정 스프레드시트에는 양측의 실현된 이익/손실 금액이 나열되어 있으며 조정된 것으로 보입니다. 그러나 HATB 보고서는 실현된 이익/손실 금액을 아직 인식하지 못하며 적용 기록에 따라 1월까지 적용되거나 게시되지 않았기 때문에 GL과 비교할 때 이 금액으로 인해 해제됩니다.  

자주 묻는 질문

Q1: GL에 대한 조정 스프레드시트가 GL에 대한 지급 가능/수취인에 대한 진정한 조정인가요?

A1: GL에 대한 조정 기능은 사용자가 RM/PM과 GL 간의 타의 추종을 불허하는 배포를 식별하는 데 도움이 되는 문제 해결 도구 입니다. 그것은 반드시 HATB에 묶기위한 것이 아니었으며 고객이 그것을하고 있다는 것을 알고 있지만 의도 된 목적은 아니었습니다. GL에 대한 조정 스프레드시트의 균형은 테이블의 분포에 대한 간단한 추가/빼기를 사용하는 가장 좋은 추정치입니다. HATB의 균형은 거의 모든 테이블을 고려하고 훨씬 더 복잡하고 정확한 균형이므로 두 테이블이 묶지 않는 경우가 많습니다.

실제 조정은 RM 또는 PM HATB(기록 노인 평가판 잔액)와 GL 평가판 균형 보고서 사이에 있어야 합니다. 이러한 항목이 일치하는 경우 해당 월에 GL로 조정 도구를 반드시 실행할 필요는 없습니다. GL 테이블은 직불 및 크레딧으로 구성되며 HATB가 가져오는 테이블은 트랜잭션 헤더이며 레코드 테이블을 적용합니다. 따라서 고객은 GL의 배포를 RM 또는 PM의 배포 테이블과 조정하여 해당 수준에서 차이를 찾을 수 있는 방법을 요청했습니다. 이것이 GL에 대한 조정 루틴이 만들어진 이유입니다. 누락된 배포를 식별할 수 있도록 모듈 간의 배포와 배포를 비교하는 문제 해결 도구로, HATB에서 누락된 트랜잭션으로 돌아갈 수 있습니다. 따라서 HATB를 GL 평가판 균형 조정에 도움이 되도록 GL에 조정 도구를 사용합니다. HATB 및 GL TB 잔액이 있는 경우 해당 달에 GL로 조정 도구를 실행할 필요가 없습니다.

Q2: GL로 조정 스프레드시트의 합계가 HATB의 합계와 일치해야 하나요?

A2: 아니요. GL로 조정 스프레드시트의 합계는 해당 테이블의 배포 레코드를 간단하게 추가/빼는 것일 뿐 다른 테이블은 고려하지 않습니다. HATB는 트랜잭션을 사용하여 균형을 계산하고 레코드 테이블을 적용하기 위해 완전히 다른 테이블을 보는 반면 훨씬 더 복잡한 계산입니다. 잔액을 가져오는 데 사용되는 계산 방법/테이블이 다르기 때문에 GL 스프레드시트에 대한 조정은 HATB 보고서의 노후화된 균형과 완전히 연결되지 않으며 조정을 어렵게 만듭니다. 조정의 잔액을 GL 스프레드시트와 HATB 보고서에 연결할 필요는 없습니다.

GL 스프레드시트에 대한 조정의 합계를 무시하고 일치하지 않는 섹션과 잠재적으로 일치하는 섹션을 사용하여 GL TB와 HATB의 차이를 설명할 수 있는지 확인하기 위해 연구할 차이점을 찾을 수 있습니다. GL 스프레드시트에 대한 조정은 진정한 조정이 아니며, 이것이 트랜잭션 수준에서도 차이가 있는지 확인하기 위해 연구에 대한 배포 차이를 식별하는 데 도움이 될 뿐입니다. 실제로 HATB가 GL TB와 일치하는 경우 식별할 차이점이 없으므로 해당 달의 GL 유틸리티에 대한 조정을 실행할 필요가 없습니다.

GL 스프레드시트에 대한 조정의 잔액을 HATB의 잔액과 연결하려는 경우 일반 지원 사례에서는 지원되지 않습니다. 식별한 이유는 이 KB의 맨 위에 나열되며 아직 확인되지 않은 더 많은 이유가 있을 수 있습니다. 그러나 이 조정은 GL 스프레드시트에 나열된 간단한 총 잔액과 HATB 보고서의 더 복잡한 계산 잔액 사이에 필요하지 않으며, 이 조정 유틸리티의 의도된 목적이 아니기 때문에 데이터를 심층 분석하여 서로 조정하는 데 도움이 되는 컨설팅 비용으로 간주됩니다.

Q3: GL 쪽에서 배포가 누락된 경우 어떻게 해야 하나요?

A3: RM 또는 PM 쪽에서 GL 쪽에 없는 배포를 찾으면 GL 쪽에서 타이밍 차이를 조사합니다. 모든 GL 일괄 처리가 게시되었는지 확인합니다. GL 쪽에서 실제로 누락된 경우 GL 배포를 만들려면 GL에 직접 조정 저널 항목을 입력해야 합니다.

Q4: RM 또는 PM 쪽에서 배포가 누락된 경우 어떻게 해야 하나요?

A4: GL 분포가 나열되었지만 RM 또는 PM 쪽에서 누락된 경우 먼저 타이밍 차이를 조사합니다. 또한 트랜잭션 자체가 HATB 보고서에 나열되고 이미 고려되고 있는지 확인하기 위한 연구입니다. 트랜잭션이 존재할 수 있지만 배포판이 누락된 것일 수 있습니다. 따라서 트랜잭션이 존재하는 경우 RM 또는 PM에서 배포를 어떻게 얻을 수 있을까요? 먼저 RM 또는 PM의 배포 테이블은 이 조정 스프레드시트 이외의 GP의 다른 용도 또는 보고서에 사용되지 않습니다. 그렇다면 RM 또는 PM에 다시 추가해야 할까요? 다른 곳에서는 사용되지 않는 테이블을 채울 만한 가치가 있는지 평가합니다.

그러나 PM 배포 테이블을 수정하도록 선택하면 적용된 레코드가 다시 열리도록 문서를 무효화해야 합니다. 그런 다음 트랜잭션 기록 제거 유틸리티를 사용하여 무효화된 문서를 제거합니다. 게시를 GL에 게시 하도록 설정하고 GL에 게시하지 마세요. void에서 만든 GL 일괄 처리를 삭제합니다. 그런 다음 문서를 Payables로 다시 키 지정하여 트랜잭션 및 배포를 다시 만듭니다. 이에 대한 GL 일괄 처리를 무효화해야 합니다. 그런 다음 새 문서를 열려 있는 문서에 다시 적용하면 다시 기록으로 이동해야 합니다.

RM 배포 테이블에서 문제를 해결하려면 청구서와 결제의 양쪽을 모두 제거하고 다시 키를 다시 입력하고 GL에서 일괄 처리를 삭제해야 합니다.

Q5: 잠재적으로 일치하는 섹션의 트랜잭션은 일치하는 것처럼 보입니다. 일치하는 섹션에 없는 이유는 무엇인가요?

A5: 각 배포 레코드에 대해 일치하는 여러 필드가 있습니다. 일치 섹션으로 이동하려면 모든 필드가 일치해야 합니다. 일부 필드가 일치하지 않는 경우 잠재적으로 일치하는 섹션에 배치됩니다. 예를 들어 PM에서 GL까지 일치하는 필드는 다음과 같습니다.

Payables Management -- GL
바우처 번호 -- 원래 컨트롤 번호
TRX 원본 -- 원래 TRX 원본
게시 날짜 -- 트랜잭션 날짜
계정 금액 -- 직불 금액 또는 크레딧 금액

Q6: GL 또는 RM/PM에서 누락된 배포를 키로 지정하고 GL 스프레드시트로 조정을 다시 실행하면 일치하지 않거나 잠재적으로 일치하는 항목이 일치 섹션으로 이동합니까?

A6: 아니요. 트랜잭션이 별도로 키를 지정하는 경우 에는 다른 바우처 번호와 Trx 소스 코드가 있습니다. 게시 날짜 및 금액이 일치할 수 있으므로 스프레드시트의 잠재적으로 일치하는 섹션에 배치할 수 있습니다.

Q7: 월별 또는 분기별 스프레드시트의 End Balance가 다음 월별 또는 분기별 스프레드시트의 시작 잔액과 일치하지 않는 이유는 무엇인가요?

A7: 한 마침표의 종료 잔액이 다음 기간의 시작 잔액과 일치하지 않는 경우 하위 원장 테이블에 연결된 헤더 레코드가 없는 분리된 배포 레코드로 인해 발생하는 경우가 많습니다. 끝 잔액은 스프레드시트의 Excel에서 바로 계산됩니다. 스프레드시트 맨 위에 있는 해당 기간의 시작 잔액을 사용하고 스프레드시트에 표시되는 배포 레코드를 추가/빼서 종료 잔액에 도달합니다. 반면, 다음 기간에는 SQL 테이블의 배포 레코드에 대한 간단한 이체/크레딧 계산을 수행하여 시작 잔액을 계산하고 저장 프로시저는 헤더 테이블에 조인하므로 헤더 레코드가 누락된 배포는 포함하지 않습니다. 최종 결과는 일부 분포가 이전 스프레드시트의 끝 잔액으로 계산되고 다음 기간의 시작 잔액에서 생략되었을 수 있습니다.

Q8: RM/PM 쪽의 배포판이 존재하지만 스프레드시트로 끌어들이지는 않습니다.

A8: 다음 문제 해결 팁을 검토합니다.

• 스프레드시트에 조정에 사용되는 날짜 범위를 검사합니다.
• 분포가 PM에 대한 PM10100 또는 PM30600 테이블에 있는지 확인합니다. (또는 RM의 경우: RM10101 또는 RM30301 검색) 이러한 배포의 날짜를 검사하여 스프레드시트에 대해 입력한 범위 내에 있는지 확인합니다. RM 또는 PM 배포 테이블에서 이러한 데이터를 찾는 것이 중요하며, instance 위해 재인쇄된 게시 저널에만 의존하지 않는 것이 중요합니다.
• RM 또는 PM 테이블에서 배포를 찾으면 프런트 엔드의 문서에서 이러한 배포를 확인합니다. PAY 또는 REC 또는 AVAIL의 배포 유형이 있나요? 이전 버전의 RM 또는 PM 쪽에서 조정 스프레드시트로 끌어올 유일한 형식입니다. (업데이트: 크레딧 카드 지불은 테이블에 있는 현금 형식의 AP 계정에 대한 배포를 생성할 수 있지만 GL 스프레드시트에 대한 조정은 이 분포를 왼쪽에 표시하지 않았습니다. 따라서 데이터 문제가 아니라 스프레드시트에 대한 표시 문제일 뿐입니다. 그러나 현재 캐시 유형이 스프레드시트에 올바르게 표시되므로 이 문제는 Microsoft Dynamics GP 2016에서 문제가 되지 않으므로 문제가 되지 않습니다.)

Q9: GL로 조정 창이 다른 통화로 표시되도록 할 수 있나요?

A9: 기능 통화만 표시하도록 설계된 GL로 조정 창입니다. 자세한 내용은 Microsoft Dynamics GP에서 GL로 조정 창의 잔액에 대한 정보를 참조하세요.