AP 전표 흐름 인보이스에서 지급까지
전편들 중에서 이미 AP를 다뤘습니다. 그런데 또 AP입니다. 관점이 다르기 때문입니다. 편 관점 질문 전편 (AP 송장 관련 내용) 회계 송장이 어떻게 GL 전표가 되는가 전편 (AP 지급 관련 내용) 프로세스 지급 시 어떤 이벤트가 생기는가 이번 데이터 모델 어느 테이블을 어떻게 조인하는가 현업 문의에 답하려면 결국 SQL을 짜야 하고, SQL을 짜려면 조인 조건과 카디널리티를
Oracle
커스텀 (Extension) 스키마 설계 및 개발 표준 과 원칙
전 편에서 명명 규칙을 다루면서 “커스텀은 XX로 시작한다”고 한 줄 언급했습니다. 이번에는 그 원칙이 왜 있고, 어디까지 확장되어야 하는지를 정리합니다. 솔직히 말하면, 이 주제는 개발하는 동안에는 별로 중요해 보이지 않습니다. 표준을 지키든 안 지키든 프로그램은 똑같이 돌아가니까요. 값이 드러나는 순간은 세 번입니다. 특히 세 번째가 결정적입니다. SAP 전환 프로젝트를 해 보면, 커스텀 목록을 정리하는 것만으로
Oracle EBS 테이블 명명 규칙 읽는 법
EBS 데이터베이스에는 테이블과 뷰가 2만 개 이상 있습니다. 이걸 다 외우는 사람은 없습니다. 외울 필요도 없습니다. 대충 접미어들이 이렇습니다. _ALL, _TL, _B, _V, _S 대신 이름 읽는 법을 알면, 처음 보는 테이블도 30초 안에 성격을 파악할 수 있습니다. 이 글은 그 읽는 법을 정리한 것입니다. 시리즈 중간의 짧은 실무 편이지만, 앞으로 어떤 EBS 작업을 하든
Oracle EBS에서 SAP으로 인터페이스 설계 방법
지금까지 네 편에 걸쳐 EBS의 조직 구조, 회계 전환, 지급, 마감을 봤습니다. 이번에는 그 구조들이 실제 전환 프로젝트에서 어떤 코드로 번역되는지 이야기합니다. 먼저 결론부터 말하면, 전환 프로젝트에서 가장 흔한 실패 패턴은 이것입니다. “EBS 테이블 구조를 분석했으니 이제 SAP 테이블에 매핑하면 되겠네요.” 이 접근은 거의 반드시 실패합니다. 이유를 먼저 보겠습니다. 1. 왜 테이블 대 테이블 매핑이
AP 지급 (AP Payment )과 선급금(Prepayment) , 실제 분개로 풀어보는 송장 결제 프로세스
전에 작성한 송장이 GL 전표가 되는 과정을 봤습니다. 그런데 AP의 절반은 아직 남아 있습니다. 지급(Payment) 입니다. 송장 회계가 “비용 / 미지급금”을 만든다면, 지급 회계는 그 미지급금을 없앱니다. 그리고 이 과정에서 송장 회계보다 훨씬 많은 이벤트가 생깁니다. 지급은 한 번에 끝나는 사건이 아니라 생애주기(lifecycle) 를 갖기 때문입니다. 여기에 선급금까지 얹히면 난이도가 한 단계 더 올라갑니다. “선급금
FND 테이블 완전 정복 FND_USER, FND_LOOKUP_VALUES, FND_FLEX_VALUES
FND는 Application Object Library(AOL) 의 약자입니다. AP도, GL도, HR도 전부 이 위에 얹혀 있습니다. 현업 문의 중 상당수가 사실은 FND 질문입니다. “이 코드값이 무슨 뜻이에요?” → 룩업 “이 컬럼이 화면에서 뭘로 보여요?” → 플렉스필드 “어제 돌린 배치 왜 실패했어요?” → 동시요청 “이 사람 왜 이 화면 못 들어가요?” → 책임/메뉴 이 네 갈래를 순서대로 봅니다.
PO · INV 흐름과 3-Way Matching
이번에는 PO와 INV의 흐름, 그리고 3-Way Match 과정을 살펴보겠습니다. 실무에서 AP 송장의 상당수는 PO 매칭 송장입니다. 그리고 AP 담당자가 가장 많이 받는 문의도 여기서 나옵니다. “송장이 PO에 매칭이 안 돼요.” “수량은 맞는데 Hold가 걸렸어요.” “미착 잔액이 몇 년째 안 없어져요.” 이 셋에 답하려면 PO와 입고 구조를 알아야 합니다. 1. Procure-to-Pay 전체 흐름 회계적으로는 입고 시점과
Subledger 에서 GL로 Create Accounting과 SLA
AP 송장이 GL로 , FA 자산이 GL로 가는 길을 두 경로가 똑같았습니다. 우연이 아닙니다. R12의 SLA(Subledger Accounting) 는 모든 서브레저가 공유하는 단 하나의 회계 엔진입니다. 이번 글은 그 엔진 자체를 봅니다. 1. 11i에서 무엇이 바뀌었나 11i는 모듈마다 자기 회계 로직을 갖고 있었습니다. R12는 이걸 하나로 통합했습니다. 실무적 이득이 큽니다. AP에서 배운 진단 방법이 FA에도, AR에도
AP 송장은 어떻게 GL 전표가 되는가 , R12 Subledger Accounting 연결방법확인
예전 글에서 EBS의 조직 구조가 데이터를 어떻게 잘라 놓는지 봤습니다. 이번에는 그 구조 위에서 거래 한 건이 회계 전표로 변신하는 과정을 따라갑니다. 현업에서 가장 자주 받는 질문 두 가지가 있습니다. “이 송장 GL에 언제 넘어갔어요?” “이 GL 전표 라인, 원래 어느 송장이에요?” 이 질문에 SQL 한 방으로 답할 수 있게 되는 것이 이 글의 목표입니다.