MHKIM:SUMMARY ACCOUNT의 HIERARCHY 및 재생성 - Applications (Korean)

제품: FIN_GL
작성날짜 : 2006-11-28
SUMMARY ACCOUNT의 HIERARCHY 및 재생성
================================
PURPOSE
-------
SUMMARY ACCOUNT의 HIERARCHY 및 재생성에 대한 내용
Explanation
-----------
문제 :
Summary Template에 등록된 Rollup group을 가지고 있는
Child Segment value임에도 예산통제가 이루어지지 않고 있는
문제가 발생했습니다.
아래의 Test step에서 보시는 것과 같이
CCID level에서의 예산통제말고,
Summary Account level에서도 예산통제가 가능합니다.
문제의 원인 :
gl_account_hierarchies table에 DETAIL_CODE_COMBINATION_ID 에
문제의 Account가 포함되지 않아 발생한 것으로,
Dynamic하게 Code조합이 신규로 만들어졌을 경우,
이미 생성된 Summary Template은 그 신규 Code조합을 인식하지
못해 발생한 것입니다.
* gl_summary_templates table과 gl_account_hierarchies table을
조합하여, 특정 Summary Template이 어떤 Code조합을 포함하고 있는지를
check할 수 있습니다.
조치사항 :
Program - Maintain Summary Template 프로그램으로
Summary Account생성이후에 발생된 신규 Code조합을
하위계정으로 인식 시켜줘야 합니다.
------------------------------------------------------------------
Setup Data
Account
AAA (Parent 계정) -> RU1(rollup group)
BBB
CCC
DDD
===> 세개의 Child계정이 등록됨.
Summary Account
D.D.RU1.T.T : 분기(Quarter), 절대(Absolute)로 등록
TEST계정
01.000.BBB.0000.000 => 2005년 3월,6월,9월,12월에 각각 100 원씩의 예산배정.
01.000.BBB.0000.110 => 예산금액 배정안함.
Budget Org
01.000.BBB.0000.000 에 대해서 분기(Quarter), 절대(Absolute)로 등록.
GL Journal 입력화면에서
01.000.BBB.0000.000 계정으로
JAN-05 Period로 200원을 DR 에 입력.
Fund check시 오류발생 (분기 합계금액 100원보다 큰 금액이기 때문)
01.000.BBB.0000.110 계정으로도 예산통제됨.
-------------------------------------------------------

Related

SUMMARY ACCOUNT생성후 추가된 계정값에 대한 확인

제품 : FIN_GL
작성날짜 : 2004-05-20
     
SUMMARY ACCOUNT생성후 추가된 계정값에 대한 확인
=================================
PURPOSE
-------
Summary Account가 일단 생성되면, 그 이후에 새로 추가된
계정 Code값이나, 변경된 Code Hierarchy는 인식하지 못합니다.
그렇기 때문에, Summary Account를 재생성해주거나,
관련 Concurrent프로그램 (program-maintain summary templates 혹은
Incremental Add_Delete Summary Template) 을 실행해주어야 합니다.
아래는 그 Test Step입니다.
Explanation
-----------
1. Book 및 Account Flexfleld신규 등록 (3개의 segment를 가지고 있음.)
2. Code입력 (그중 첫번째 segment에 대해서 아래와 같은 Hierarchy로 구성하였습니다.)
1000 (최상위에 Rollup group등록)
----> 1100
----> 1110
----> 1111,1112
----> 1120
----> 1121
3. 등록된 Rollup group을 포함하는 Summary Account등록
4. 추가 Parent및 Child Account등록
----> 1130
----> 1131
5. 두개의 segment 조합에 대해서 Test를 하였습니다.
=> 1121-AA-1000, 1131-BB-1000 (모두 Liability 계정)
이전 Test순서에서도 확인할 수 있듯이, 1121은 Summary Account생성전,
1131은 Summary Account생성후에 입력된 Data입니다.
6. Journal 입력 및 Posting
Code 조합 DR CR
1121-AA-1000 100
1121-AA-1000 100
1131-BB-1000 100
1131-BB-1000 100
=========================
200 200
7. Table에서 Data확인
1) GL_CODE_COMBINATIONS
각각의 Code조합 두개 (1121-AA-1000, 1131-BB-1000) 및 Summary Account(1000-T-T)에 대해서
CCID가 생성됨.
2) GL_BALANCES
각각의 조합에 대해서 Period_Net_DR값이 100 씩 생김.
1121-AA-1000 100
1131-BB-1000 100
Summary Account CCID에 대해서는 100 에 대한 Data만 발생함.
1000-T-T 100
8. Summary Account 삭제 및 재생성
GL_BALANCES table에 확인한 결과, 기존에 100이었던 Data는 삭제되고,
200에 대한 Data가 새로 생성됨.
1121-AA-1000 100
1131-BB-1000 100
1000-T-T 200
위의 Test결과로 미루어 볼때, Summary Account생성 후 등록된 Code값에 대해서는
인식을 하지 못하는 것으로 볼 수 있습니다.

MHKIM:AP PAYMENT ADJUSTMENT EVENT의 생성과정

제품: FIN_AP
작성날짜 : 2006-10-18
AP PAYMENT ADJUSTMENT EVENT의 생성과정
=================================
PURPOSE
-------
AP PAYMENT ADJUSTMENT EVENT의 생성과정
Explanation
-----------
Payment 처리시에 default type인 Quick(약식)이외에
"Manual"(수동) type으로 처리하게되면
Data저장 이후에도 "Enter/Adjust Invoices"버튼이 활성화됩니다.
만약, 잘못 지급처리된 invoice가 있을 경우,
"Enter/Adjust Invoices"버튼을 누르고, 기존 invoice에 대해서 check option으로 선택한 후,
"Reverse Payment" 로 해당 invoice의 지급을 취소하고,
동일 금액의 다른 invoice로 재입력하면, 재처리에 대한 event는
"Payment Adjustment"로 생성됩니다.
* 예제*
1. Invoice 입력
amount : 100$, 200$, 300$
2. 승인 및 Accounting작업
3. Payment처리
Payment type은 "Manual"(수동)으로 선택.
4.
TEST로 입력된 100$ 와 200$ 에 대한 지급처리
지급 총 금액은 300$
5. 입력된 Payment를 재조회 후, "Enter/Adjust Invoices"를 선택
6. 100$와 200$ 에 대해서 check한 후, Reverse Payment버튼을 누름.
7. 새로운 line에 300$ 의 invoice를 입력/저장
8. Accounting작업을 하게되면
처음 입력된 invoice정보들에 대해서 Payment event로 accounting이 생성되고
재 조회후 작업한 변동사항에 대해서는 "Payment Adjustment" event로 accounting이 생성됩니다.

INVOICE에 PREPAYMENT를 APPLY한 후의 DATA FLOW

제품 : FIN_AP
작성날짜 : 2004-05-19
     
INVOICE에 PREPAYMENT를 APPLY한 후의 DATA FLOW
========================================
PURPOSE
-------
Invoice에 Prepayment를 Apply한 후의 Data변화에 대해서
간략하게 설명합니다.
Explanation
-----------
승인 및 Accounting처리가 끝난 Invoice에 대해서 Prepayment를 Apply하게되면,
승인상태는 "Need reapproval"이고, Accounted상태는 "Partial"로 바뀌게 됩니다.
그 후에 Approve작업 및 Accounting작업을 하면,
다시 "Approved"와 "Yes"로 바뀌게 되고, 그 후에 Prepayment unapply하게되면,
다시 상태는 "Need Reapproval"과 "Partial"로 바뀝니다.
Table level에서는 Accounting전까지는 송장 Main table, 즉,
AP_INVOICES_ALL, AP_INVOICE_DISTRIBUTIONS_ALL, AP_PAYMENT_SCHEDULES_ALL 등의
특정 column값들만 변하게 되고, Accounting생성작업이 실행되면,
Event와 AP_AE_HEADERS_ALL, AP_AE_LINES_ALL table등에 각각의 Event data가
발생하게 됩니다.
즉, Invoice, Prepayment Apply, Prepayment unapply 등과 같은 Event data가 발생합니다.

GL ACCOUNT 화면에서 기존에 등록한 CCID 가 나타나지 않는다.

제품 : FIN_GL
작성날짜 : 2004-10-14
     
GL ACCOUNT 화면에서 기존에 등록한 CCID 가 나타나지 않는다.
========================================
PURPOSE
-------
Problem Description
-------------------
GL Account 화면에서 기존에 등록한 CCID가 나타나지 않고 새로이 등록하고자 하면 이미 등록이 되어 있단 Error 가 발생한다.
ccid 조회시 발생하는 error는 다음과 같다.
APP-FND-00906: You can only query existing flexfield code combinations. You
entered query criteria in your flexfield that does not identify an existing
code combination.
Workaround
----------
Update GL_CODE_COMBINATIONS
set SUMMARY_FLAG = 'N'
where CODE_COMBINATION_ID = <문제의 ccid> and
CHART_OF_ACCOUNTS_ID = ;
Solution Description
--------------------
GL Account 화면에서는 원래 Summary Acocunt 는 조회 할 수 가 없는데 위와 같은 문제가 발생하는 경우는 ccid segment 중 하나가 이전에 summary 로 check 되어 있다가 향후에 child value 로 변경이 되었기 때문이다.
따라서 gl_code_combinatios 에서 summary_flag 를 'N'로 만들어 주면 조회가 가능하다.
그러나 summary account에 대해서는 위의 작업을 수행 하면 안되니 특별히 주의 하도록 한다.
Reference Documents
-------------------
Note 258808.1

MRP_RELIEF_INTERFACE TABLE의 목적과 PURGE방법

제품 : MFG_MRP
작성날짜 : 2004-11-25
     
MRP_RELIEF_INTERFACE TABLE의 목적과 PURGE방법
=======================================
PURPOSE
-------
MRP_RELIEF_INTERFACE TABLE에 Data가 증가하여 Performance문제가
발생함. 이 Table의 사용 목적과 PURGE방법
Explanation
-----------
1. 'mrp_relief_interface' 이 테이블이 정확하게 어디에 사용하는
테이블입니까?
이 Table은 여러 모듈의 Trigger에 의해 Record가 생성됩니다.
사용되는 용도는 다음과 같습니다.
(1) Sales order에 Shipment가 발생하였을 때 , Shipped quantity가
insert된다.
이 data는 MDS Relief를 위해 사용된다.
(2) purchase requisition, purchase order, po recieving, or wip
discrete job이 발생하였을 때 mrp_relief_interface에 record가
insert된다.
이 data는 MPS Relief를 위해 사용된다.
2. MRP_RELIEF_INTERFACE TABLE의 Record는 언제 어떻게 삭제됩니까?
이 Interface table은 바로 삭제되는 것이 아니라, Planning Manager에
의해 하루에 한번씩 삭제됩니다.
Planning manager가 "Once-A-Day Task Workers"를 call하고 이
processor가 daily cleanup 작업을 수행합니다.
Delete하는 기준은 profile option: MRP:Interface Table History Days
를 기준으로 삭제하게 됩니다.
Example
-------
Reference Documents
-------------------

Categories

Resources