지금까지 네 편에 걸쳐 EBS의 조직 구조, 회계 전환, 지급, 마감을 봤습니다. 이번에는 그 구조들이 실제 전환 프로젝트에서 어떤 코드로 번역되는지 이야기합니다. 먼저 결론부터 말하면, 전환 프로젝트에서 가장 흔한 실패 패턴은 이것입니다. “EBS 테이블 구조를 분석했으니 이제 SAP 테이블에 매핑하면 되겠네요.” 이 접근은 거의 반드시 실패합니다. 이유를 먼저 보겠습니다. 1. 왜 테이블 대 테이블 매핑이
전에 작성한 송장이 GL 전표가 되는 과정을 봤습니다. 그런데 AP의 절반은 아직 남아 있습니다. 지급(Payment) 입니다. 송장 회계가 “비용 / 미지급금”을 만든다면, 지급 회계는 그 미지급금을 없앱니다. 그리고 이 과정에서 송장 회계보다 훨씬 많은 이벤트가 생깁니다. 지급은 한 번에 끝나는 사건이 아니라 생애주기(lifecycle) 를 갖기 때문입니다. 여기에 선급금까지 얹히면 난이도가 한 단계 더 올라갑니다. “선급금
FND는 Application Object Library(AOL) 의 약자입니다. AP도, GL도, HR도 전부 이 위에 얹혀 있습니다. 현업 문의 중 상당수가 사실은 FND 질문입니다. “이 코드값이 무슨 뜻이에요?” → 룩업 “이 컬럼이 화면에서 뭘로 보여요?” → 플렉스필드 “어제 돌린 배치 왜 실패했어요?” → 동시요청 “이 사람 왜 이 화면 못 들어가요?” → 책임/메뉴 이 네 갈래를 순서대로 봅니다.
이번에는 PO와 INV의 흐름, 그리고 3-Way Match 과정을 살펴보겠습니다. 실무에서 AP 송장의 상당수는 PO 매칭 송장입니다. 그리고 AP 담당자가 가장 많이 받는 문의도 여기서 나옵니다. “송장이 PO에 매칭이 안 돼요.” “수량은 맞는데 Hold가 걸렸어요.” “미착 잔액이 몇 년째 안 없어져요.” 이 셋에 답하려면 PO와 입고 구조를 알아야 합니다. 1. Procure-to-Pay 전체 흐름 회계적으로는 입고 시점과
AP 송장이 GL로 , FA 자산이 GL로 가는 길을 두 경로가 똑같았습니다. 우연이 아닙니다. R12의 SLA(Subledger Accounting) 는 모든 서브레저가 공유하는 단 하나의 회계 엔진입니다. 이번 글은 그 엔진 자체를 봅니다. 1. 11i에서 무엇이 바뀌었나 11i는 모듈마다 자기 회계 로직을 갖고 있었습니다. R12는 이걸 하나로 통합했습니다. 실무적 이득이 큽니다. AP에서 배운 진단 방법이 FA에도, AR에도
예전 글에서 EBS의 조직 구조가 데이터를 어떻게 잘라 놓는지 봤습니다. 이번에는 그 구조 위에서 거래 한 건이 회계 전표로 변신하는 과정을 따라갑니다. 현업에서 가장 자주 받는 질문 두 가지가 있습니다. “이 송장 GL에 언제 넘어갔어요?” “이 GL 전표 라인, 원래 어느 송장이에요?” 이 질문에 SQL 한 방으로 답할 수 있게 되는 것이 이 글의 목표입니다.
월말결산시 , 회계팀에서 오는 전화는 거의 항상 같은 문장으로 시작합니다. “AP 기간이 안 닫히는데요.” 그리고 이어지는 대화도 대체로 비슷합니다. “뭐라고 나와요?” — “그냥 안 닫힌다고만 나와요.” EBS는 기간 마감을 막을 때 친절하게 이유를 설명해 주지 않습니다. 대신 미결 항목(Unaccounted Transactions)이 남아 있다는 사실만 알려줍니다. 무엇이 남았는지는 직접 찾아야 합니다. 이 글은 그 “직접 찾는 순서”를
EBS를 처음 만지는 사람이 가장 먼저 부딪히는 벽은 화면도, PL/SQL도 아닙니다. “분명 데이터가 있는데 조회하면 0건” 이 상황입니다. 같은 데이터인데 왜 이럴까요. 답은 전부 Multi-Org(멀티 오그) 구조에 있습니다. 이 글에서는 EBS 조직 계층을 위에서 아래로 훑고, 그것이 테이블과 세션에 어떻게 반영되는지까지 정리합니다. 1. 조직 계층 전체 그림 EBS의 조직은 대략 이렇게 쌓여 있습니다. 각 계층이
외부 시스템에서 SAP로 회계 전표를 밀어 넣는 작업. 요건만 보면 단순하다. “AP 인보이스 데이터를 받아서 전표를 생성한다.” 그런데 실제로 붙여보면 상황이 다르다. 차변과 대변이 0.01원 차이로 안 맞고, 세금 라인을 넣으면 갑자기 dynpro 오류가 뜨고, 로컬에서 되던 게 QAS에서는 Field Status 오류를 내뱉는다. 표준 문서에는 파라미터 목록만 나열되어 있을 뿐, 왜 이 순서로 넣어야 하는지,
