exec sp_readerrorlog

SELECT S.SPID, S.LOGINAME, S.LOGIN_TIME, S.LAST_BATCH, C.CLIENT_NET_ADDRESS 
FROM sys.sysprocesses S, sys.dm_exec_connections C 
WHERE S.spid = C.SESSION_ID 

Select top 20

 [사용 된 평균 CPU] = total_worker_time / qs.execution_count

, [사용 된 총 CPU] = total_worker_time

, [실행 횟수] = qs.execution_count

, [개별 쿼리] = SUBSTRING (qt.text, qs.statement_start_offset / 2, 

                    (CASE WHEN qs.statement_end_offset = -1 

                     THEN LEN (CONVERT (NVARCHAR (MAX), qt.text)) * 2 

                    ELSE qs.statement_end_offset END- 

                    qs.statement_start_offset) / 2)

, [상위 쿼리] = qt.text

, DatabaseName = DB_NAME (qt.dbid)

FROM sys.dm_exec_query_stats qs

CROSS APPLY sys.dm_exec_sql_text (qs.sql_handle) as qt

ORDER BY [사용 된 총 CPU] DESC, [사용 된 평균 CPU] DESC;

보고서, 의사 전달의 도구 이상도 이하도 아닌

기업 내의 많은 의사소통은 메일이나 보고서 등으로 이루어집니다. 사람과 일이 많기에 짧은 시간에 효율적인 의사결정을 내리기 위해서는 중요 내용만 있는 유형의 전달 도구를 통해 많은 사람에게 단기간에 전달되는 게 효율적이기 때문입니다. 그렇지만 이게 과해서 아무 말 보고서로 하드디스크를 낭비하고 아까운 종이를 버리고 인생을 낭비하는 일도 있습니다. 이것은 본질과 맞지 않는 것입니다. 이런 것을 차치하면 관리직의 숙명 중 하나는 효과적인 의사 소통에 있습니다. 특히 제안서나 보고서, 메일 같은 한 번 쓰면 빼도박도 못하는 종류의 것을 잘 사용하는 것 말이죠.

특히 기획자는 보고서가 많습니다. 세상의 수 많은 기획자들의 과업이 조금씩 다르지만 기본적으로는 보이지 않는 것을 설명해야 하는 일이 많기에 효율적인 의사 전달이 어렵습니다. 아직 나오지 않은 서비스나 상품을 설명하는 것부터 조직의 비전과 문화에 대한 설명, 역량의 발전과 시장 상황에 대한 내용은 말로도 어려운데 이걸 글로 쓰자니 쉬운 일이 아닙니다. 더군다나 한국 기업의 문제점 중 하나인 윗 사람이 시키지만 시키는 사람 조차 이게 뭘 하란 건지 모르는 일인 경우에는 더 그렇습니다. 제목은 알지만 내용은 계속 수정해 나가면서 어렴풋이 모두 알게 됩니다.

이런 많은 보고서를 잘 쓰는 것도 능력입니다. 몸이 거부할 수 있겠지만 현실이 그렇습니다. 자신의 생각을 잘 전달하는 것은 비단 기업 뿐 아니라 살아가는 모든 상황에서 큰 성취를 만들곤 합니다. 전략 기획자의 효과적인 보고서는 불필요한 행동을 없애고 기업 내부에서 정확한 방향으로 사업을 추진하는 역할을 합니다. 지지부진 하던 모두의 생각을 하나로 모으고 일을 실행하는 전환점이 되는 것입니다. 잘 쓴 보고서는 길지 않아서 읽는 사람이 잘 이해가 되고 핵심만 나와 있습니다. 그리고 그것을 부연하는 정확한 숫자와 사례가 나와서 누가 봐도 맞는 말이라는 인상을 줍니다. 과하지도 모자라지도 않는 것이죠.

하지만 이렇게 보고서를 쓰는 것은 쉬운 일은 아닙니다.  쓰고 싶은 것을 쓰지 못하게 만드는 외압도 문제지만 설령 뚜렷하게 주제를 알았다고 해도 표현력이 약해서 효과적으로 의사 전달을 못하는 경우도 있습니다. 어렵게 고민해서 창작을 하면 격려는 커녕 다시 쓰라는 핀잔만 날라오는 경우도 있습니다. 회사나 직장 상사가 잘못되었다면 어쩔 수 없지만 비교적 합리적인 사람이 그런 반응이 나온다면, 계속 나온다면 자신의 보고서 쓰는 방법을 바꾸어야 합니다.

먼저 소위 칭찬 들었던 보고서와 자신을 비교하지만 이런 경우 눈에 먼저 들어오는 것은 보고서 디자인과 화려한 그래프일 것입니다. 내용의 배열과 주장과 근거를 대는 것보다 당장 나의 보고서에서는 보여주지 못한 효과들에서 보고서 쓰기는 어렵다는 결론으로 포기할 수도 있습니다. 하지만 보고서의 기본적인 목적이 그런 데에 있지 않기 때문에 핵심적인 목적을 달성하는 데 필요한 것만 보면 됩니다. 읽는 사람을 이해시키는 방식 말이죠. 눈에 화려한 것보다 다 읽고 나서 이해가 되고 핵심적인 주장이 이건데 왜 이렇게 말하는지 머리에 남느냐에 대한 것이죠. 세부적으로 글자가 틀리고 줄이 안 맞고 이런 것은 부차적인 문제입니다. 그런데 시간을 낭비하면 정말 인생을 낭비하는 것입니다. 그러기에 핵심적인 부분만 보면 됩니다. 아래 내용들은 효과적인 보고서를 쓰는 방법에 대한 지극히 개인적인 생각이니 필요하시면 참고 하면 좋을 것 같습니다.

1. 반드시 고유명사를 쓴다

보고서의 결론은 고유명사가 있어야 합니다. 구체적인 대상을 지칭하지 않으면 인사이트가 없고 실행할 수 없는 보고서가 될 수 있습니다. 보고서가 문제를 진단해서 핵심 원인을 찾고 대안을 찾아서 실행 방법에 대해 탐구하는 것이 보통의 흐름이라면 각 과정에서 고유명사로 핵심적인 내용이 다루어져야 합니다. 예를 들어 핵심적인 문제가 무엇인지 다루는 내용에서는 '4분기 매출 악화의 원인은 가전 분야의 부진이었습니다'라는 말보다는 '4분기 매출 악화의 원인은 가전, 그 중에 청소기 000 모델의 부진이었습니다'라고 하는 것이 보다 정확한 문제 인식을 환기해 줍니다. 가전이 부진하다는 것보다 000 모델을 언급하는 것이 무엇을 바꾸어야 할지 구체적인 방향을 지시하기 때문입니다. 하지만 이런 것은 보통 민감한 사안이므로 내부에서는 안쓰는 것과 다름없는 대명사 위주의 보고서가 넘쳐납니다. 하지만 실무진 입장에서는 고유명사로 설명을 해야 이해가 쉽고 전사적으로 빠른 행동이 가능합니다. 대안의 경우에도 그렇습니다. 단순히 '1분기에는 비용을 절감하는 것과 함께...' 이런 식의 나열보다는 '1분기에는 영업외 비용인 000 비용을 00% 줄이고...' 이런 식의 구체적인 결론이 나야 실제 일을 진척한 기간의 성과가 온전히 드러나고 이후 정말 회사를 바꾸는 일에 이어질 수 있습니다. 고유명사를 말할 수 없다는 것은 실제로 핵심 내용을 알지 못하고 있든지 회사 문화가 굉장히 폐쇄적이고 정치적이든지 하는 원인이 많습니다.

2. 핵심이 되는 숫자와 사례를 함께 표기

주장의 정도와 근거의 핵심 변곡점은 숫자로 표현할 수 있다면 하는 것이 좋습니다. 방향은 고유명사 등으로 구체적으로 표현이 가능하지만 정도는 숫자로 표현하는 것이 서로 이해가 가능합니다. 목표 숫자라는 것은 막무가내식의 활동 혹은 전혀 하지 않는 활동 모두를 막아줍니다. 구체적인 근거가 동반된 상태에서 얼마까지 어떻게 하자는 표현은 전체적인 목표를 설정하는 일이기도 합니다. '생산라인의 리드타임을 현재 일 20분에서 크게 줄여야 한다'는 것보다는 '생산라인의 리드타임을 현재 일 20분에서 15분 수준으로 단축시켜야 한다'라는 표현이 더 좋습니다. 그리고 15분의 근거가 되는 우수 사례나 기술적인 변화를 함께 언급한다면 실제로 일이 될 확률이 높을 것입니다. 실제 이 정도를 보고할 수 있다는 것은 생각의 정리가 완결되었음을 의미하기 때문입니다. 특히 향후의 행동을 주장할 때는 숫자로 표현하는 것이 좋습니다. 숫자로 나타내지 않으면 단순한 구호에 그치는 일이 많습니다. '00 지점은 올해 매출 2배를 하겠습니다'라는 구호성 말보다 '00 지점은 000을 통해 2억, 000을 통해 4억을 추가하여 매출 6억을 추가하겠습니다'라는 게 더 구체적이고 나중에 확인할 수 있는 방법입니다. 물론 이런 숫자 자체를 정치적으로 오용하거나 확인할 수 없는 상태로 방치하면 그게 더 문제가 되겠지만요. 그러기에 목표 자체보다 이것이 가능한 근거들을 기술적으로 설명하는 데 더 많은 분량을 할애하는 것이 맞습니다.

3. 페이지 순서는 읽는 사람의 생각 순서로

보고서에서 중요한 것은 페이지의 순서입니다. 두괄식이 좋다는 것은 다 아실 것입니다. 결론을 앞에 쓰는 것은 어디서나 공통적입니다. 다만 결론 이후의 페이지 구성이 문제입니다. 이후 페이지의 구성은 처음 이 분야를 접하는 사람이 알아야 하는 배경부터 이것의 현상과 원인, 결론으로 이어지는 자연스러운 흐름을 취하는 것이 좋습니다. 반드시 알아야 할 전제를 뒤에 설명하면 전체적으로 혼란을 야기시키고 보고서는 곧 덮이게 됩니다. 페이지의 넘버링이나 타이틀에 신경을 많이 쓰지만 그보다는 페이지는 읽는 사람의 생각의 흐름에 맞추는 게 기본적인 접근이고 가장 시간을 많이 가져가야 할 부분입니다. 이런 관점으로 보다보면 필요없는 페이지가 많이 나옵니다. 흐름을 방해하거나 중간에 액자 형식으로 들어가 있어서 당장 없어도 대세에 영향이 없는 페이지가 발견됩니다. 그런 것은 빼면 됩니다. 보고서는 간명해야 만드는 사람이나 읽는 사람의 시간을 효율적으로 만들 수 있습니다. 정말 더 많은 분량의 배경 설명이 필요한 것이라면 그것은 보고서가 아닌 구두의 형태로 따로 하는 것이 맞습니다. 그걸 보고서로 요구하는 일은 없어져야 하겠습니다.

4. 원인이 있으면 대안이 있어야

초보자와 숙련자와의 결정적인 차이입니다. 대안을 제시하는 능력 말입니다. 문제와 원인만 잔뜩 나열하고 보고자의 지능과 배경지식을 자랑하는 보고서는 기업에서는 그리 필요하지 않습니다. 중요한 것은 대안을 가지고 발전시키고 바꾸어 나가는 것이니까요. 따라서 장황한 사례나 숫자의 나열로 많은 페이지를 써가며 문제를 파헤친 후 1~2장의 대안으로 막을 내리는 보고서는 우수한 보고서로 보기 어렵습니다. 보고 시점이 원인 진단에 그치는 경우가 아니라면요. 이것은 대안에 대한 생각 없이 이 보고서를 받는 사람에게 전적으로 맡기는 것입니다. 보고자의 두뇌는 여기 전혀 사용하지 않았다는 것이죠. 사실 보고자만큼 이 사안에 대해 고민한 시간이 많은 사람은 조직에 드물텐데 그렇게 되면 최선의 대안은 항상 나오기 어렵게 됩니다. 보고자는 반드시 1개 이상의 대안, 되도록이면 경우에 따라 몇 개의 대안을 준비하고 그것의 기대효과와 근거 필요한 역량에 대해 구체적인 서술 후 보고 받는 사람이 그것을 선택하게 만드는 것이 좋습니다. 보고 받는 사람이 뭔가 할 게 있는 보고회여야 하니까요. 다만 보고자의 생각이 들어가야 합니다. 이런 대안 중에 나는 보통의 경우 이게 더 낫다고 생각한다는 약한 의사 개진이 반드시 필요합니다. 없다면 보고자는 어렵게 일해 놓고 남들이 자신의 밥그릇을 가져가는 모습을 많이 보게 될 것입니다.

5. 대안은 구체적인 실행 방법으로

대안은 실행 대안입니다. 대안의 형태는 구체적 실행이 가능한 형태여야 합니다. 가령 대안의 아웃라인을 보여주는 것이죠. '이런 식의 아웃풋이 될 거다'를 이미지로 보여주거나 어디까지 할 거다라는 것을 미리 언급하거나 누가 얼마를 써가면서 언제까지 대략 가능하다는 스케쥴을 언급하거나 해야 한다는 것입니다. 대안이 구체적이지 않으면 애써 쓴 보고서 자체가 무의미한 것으로 취급되기 쉽습니다. 그리고 대안에 대한 지불 비용을 반드시 언급하는 것이 좋습니다. 효과만 잔뜩 쓴 것보다는 실제 이 정도의 비용이 발생한다든지 이게 필요하다든지 하는 비용의 언급이 있어야 일을 실체를 가지고 움직이고 보고 후 다른 소리가 기업 내부에서 나오지 않습니다. 이게 없다면 보고는 보고대로 했지만 일은 안되고 보고한 사람의 입장이 난처해지는 경우가 생깁니다. 보고회 역시 문제의 진단이 잘 되었는가에 많은 시간을 쓰는 게 맞지만 대안에 초점이 맞추어진 내용이라면 대안의 구체성과 성과의 정의, 성과가 되게 하는 방법에 많은 시간을 쏟는 게 맞습니다.

6. 페이지 아래 부분에 근거를 쓰고, 발전된 내용은 다음 페이지에

한 페이지는 두 개 이상의 메세지가 있으면 안 좋다는 것은 많이 아실 것입니다. 보통 페이지의 구성은 페이지의 타이틀, 그 아래 핵심적인 주장, 그리고 그것의 근거가 나오는 순서입니다. 위에서 다룬 내용은 대부분 주장에 대한 내용이었습니다. 하지만 근거 없는 주장은 소용이 없습니다. 대부분 프로젝트 기간에는 근거를 잡는데 많은 시간을 쓰게 되어 있습니다. 그 근거를 효과적인 것만 형상화해서 표현하는 것이 페이지 하나를 완성하는 핵심입니다. 근거는 보통 조직도, 순서도 같은 도면 형식부터 사례와의 비교, 현재와 미래의 변화, 핵심 원인이나 카테고리 분석 등 다양한 형식을 취할 수 있습니다. 핵심은 주장에 있는 숫자와 고유명사가 아래 근거를 통해 설명될 수 있느냐는 것입니다. 페이지를 구성하면서 논의가 발전될 수 있는데 그런 내용은 반드시 다음 페이지에 오도록 합니다. 한 페이지에 화살표로 시계열적인 다음 주제를 던지거나 더 세부적인 내용을 다루는 경우가 있는데 이런 것은 페이지 내 핵심 내용을 흐릿하게 만들면서 읽는 사람이 많은 공을 들여야 하게 만드는 원인이 됩니다.

7. 근거 데이터, 출처를 반드시 표기

근거 데이터, 출처를 표기하는 것은 기본입니다. 하지만 많이 빠트립니다. 특히 숫자나 사례는 어디서 나온 것인지 어딘가에 있어야 하며 그것의 시점, 누가 했는지, 어디서 확인할 수 있는지가 함께 표기 되어야 합니다. 처음 페이지를 보는 사람은 항상 그것을 의심하는 경우가 많기 때문에 이런 표기가 필요합니다. 표기하다보면 이 출처가 신뢰성이 있는지 없는지 스스로 알게 될 것입니다. 이왕이면 성공한 경험이 있고 유사한 사례, 권위를 인정받는 곳의 데이터를 가지고 하는 것이 더 낫다는 생각이 들 것입니다. 구호성에 그치는 보고서들은 근거 데이터가 없거나 빈약합니다. 작성하는 사람 스스로 제대로 된 합리적인 주장인지 검증할 수 있습니다.

8. 단위나 주석은 읽는 사람을 위해

단위 표기나 주석을 아래에 넣는 것에 인색해서는 안됩니다. 다만 이런 표기가 본문을 가리거나 본문보다 더 눈에 잘 보이면 안됩니다. 단위 중에서는 우리가 일상적으로 많이 쓰는 것을 다 알거라고 생각하고 표기하지 않는 경우가 있는데 모든 숫자는 단위가 다 나와 있어야 합니다. 통화의 '원'이나 사람의 '명' 등은 많이 누락하는 단위입니다. 주석도 예외 사항이나 주의점을 반드시 설명해야 합니다. 나중에 백의 하나라도 다른 경우가 나오면 그것을 언급하지 않았었다는 이유만으로 나머지 부분들이 신뢰를 잃게 되는 경우가 많기 때문입니다. 대부분의 경우는 보고서를 읽는 사람이 이 내용에 대해 잘 모른다고 가정하고, 또 이 내용을 기본적으로 신뢰하지 않는다고 가정한 상태에서 읽는 사람에 대한 배려가 되는 장치를 만드는 게 좋은 보고서를 만드는 데 도움이 됩니다.

9. 핵심만 보이도록

페이지를 구성하고 나면 다시 한 번 봐야 합니다. 가장 먼저 무엇부터 눈에 들어오는지를 봐야 하기 때문입니다. 욕심으로 여기저기 디자인을 한 페이지는 정작 내용이 보이지 않습니다. 화려한 컬러로 덧칠한 레이아웃은 눈에 잘 보이지만 주장하고자 하는 것은 자세히 읽어야 알 수 있습니다. 그렇게 되면 짧은 시간 핵심적인 메세지를 전달하려는 본래의 취지를 잃어버린 것입니다. 차라리 이런 껍데기는 아예 없는 게 더 낫습니다. 전체적으로 사용하는 컬러는 2개 내지 3개 이내에서 정리되어야 합니다. 사실 1개로도 충분합니다. 컬러만 아니라 폰트나 글자의 크기로 얼마든지 주목받는 문장이나 단어를 만들 수 있습니다. 이런 수고는 오히려 화려한 디자인에 비해 만드는 시간이 더 들지는 않지만 고민은 더 필요한 부분입니다. 이왕이면 문장은 길지 않게 주어와 술어의 간격이 멀지 않고 주술 관계의 구조가 단순한 게 좋습니다. 그러면 문장은 자연스레 짧아지게 됩니다. 굳이 만연체로 쓸 필요가 없어집니다. 사례를 문장에 마구 집어 넣는다는 것은 그것을 관통하는 공통적인 성질에 대한 이해가 덜 되었음을 반증하는 것입니다. 사고가 정리가 되면 짧게 나오지 길게 늘어지지 않습니다.

소속된 집단마다 각 민족과 국가처럼 저마다 문화가 다릅니다. 그래서 보고서나 문체는 그 집단의 영향을 받는 것이 당연합니다. 위에서 다룬 내용들도 고지식하게 따로 존재하지는 않습니다. 현재 조직에서 만들어지고 읽혀지고 있는 토대 위에 이런 생각들을 잘 대입해 보면 보고서는 대학원 논문을 쓰는 것과 비슷한 구성, 혹은 뉴스 기사가 시작해서 자료가 나오고 인터뷰를 따고 맺음말을 맺는 구성과 매우 닮았다는 것을 알게 될 것입니다.중요한 것은 이런 토대 위에 말하고자 하는 내용, 그 자체인 것이죠. 이것은 이런 스킬만으로는 해결되지 않습니다. 오직 생각하는 것에 달려 있으니까요. 또 어떻게 해야 여기서 주장하는 아젠다를 실행하게끔 만드느냐를 생각해야 합니다. 일은 이제부터 시작이니까요.

[MSSQL] CPU 사용율과 메모리 사용율 관련

Database 서버가 언젠가부터 CPU 혹은 메모리 과부화가 발생하기 시작했다..

원인 발생 여부를 파악하기 위해 여러 검색을 통해 알아봤으나

분석 후 알아낸점은... 동시다발적으로 여러 트랜잭션 및 클라이언트의 쿼리 처리 등등으로 인한

복합적인 문제로 낙인...ㅠㅠ.... 결국 프로그램에서 처리해주지 않으면 안될것 같아, 개발이슈로 띄우고

개발하기로 했으나.. 알아보던 과정이 너무 여기저기 널린 얘기들과 정확히 이렇다 하는 내용이 없었다..

정리해두기로..

메모리 관련된 내용은 추후 업데이트 하기로하고 당착한 CPU 사용율에 좀더 신경을 써보자.

1. 떠돌아 다니는 쿼리문 + 해결방법

1) Sp_Who2 를 통한 문제 프로세스 검색 및 Kill

- Management 실행 => sp_Who2

- CPU 높은 놈을 찾자. Sp_Who2 내장 함수(?)의 경우 SQL 서비스단은 종료시키지 못한다.

(Status 가 Background 라던지.. Background 라던지...)

- 조건은 Status 가 RUNNABLE 상태, CPUTime 의 값이 유독 높은놈이 있다. 물론 해당 SPID를 가진 친구가 어떤 작업을 하는지

확인정도는 당연히 해야겠다. => DBCC INPUTBUFFER([SPID])

- 확인되었고 그놈을 죽여도 된다면.. 죽여버리자(?)! => KILL [SPID]

- 정리 : sp_Who2 => DBCC INPUTBUFFER([SPID]) => KILL [SPID]

2) 부하가 큰 쿼리문을 검색해서 프로그램 내 혹은 프로시저 등등에서 직접 수정하자!

- 간단보기와 상세보기로 나뉜다. (아래가 상세보기)

SELECT TOP 20

[Average CPU used] = total_worker_time / qs.execution_count

,[Total CPU used] = total_worker_time

,[Execution count] = qs.execution_count

,[Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2,

(CASE WHEN qs.statement_end_offset = -1

THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2

ELSE qs.statement_end_offset END -

qs.statement_start_offset)/2)

,[Parent Query] = qt.text

,DatabaseName = DB_NAME(qt.dbid)

FROM sys.dm_exec_query_stats qs

CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt

ORDER BY [Total CPU used] DESC, [Average CPU used] DESC;

SELECT TOP 20

[Average CPU used] = total_worker_time / qs.execution_count

,[Total CPU used] = total_worker_time

,[Last CPU used] = last_worker_time

,[MAX CPU used] = max_worker_time

,[Execution count] = qs.execution_count

,[Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2,

(CASE WHEN qs.statement_end_offset = -1

THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2

ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)

,[Parent Query] = qt.text

,DatabaseName = DB_NAME(qt.dbid)

,qs.creation_time

,qs.last_execution_time

FROM sys.dm_exec_query_stats qs

CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt

ORDER BY [Average CPU used] DESC;

3) 직접 모니터링해서 해당 프로세서를 죽이자!!!!! (!?)

- 성능모니터 실행 => 성능-모니터링 도구-성능 모니터 => 카운터 추가

- 사용 가능한 카운터에서 Thread 하위의 %Processor Time / ID Thread / Thread State / Thread Wait Reason 선택

- 선택한 개체의 인스턴스에서 sqlserv 명칭 죄다 선택..

- 모니터링...

현대차가 만든 '애플카' 이르면 2024년에 나온다 - 전자신문 (etnews.com)

과연 로그는 사과일까 H일까??

어머니 아파트 대표 명함을 위해 작성해보았다.

심플하고 간결하게

꼭 당선 됩시다!!!

어머니가 아파트 대표선거에 출마한다고 한다.

그래서 급하게 작성해보았다 홍보물~

퀄리티는 떨어져도 정성과 노력으로 만든 홍보물

어머니 이번에 아파트 대표 꼭 당선 됩시다!!1

화이팅

그 전에 SAP의 전표에 대해서 먼저 짚고 넘어가겠습니다. 

전표.. 영어로는 Document입니다. 

전표라고 해서 별다른 것은 없고 그냥 문서라고 생각하시면 됩니다. 

자재 입고라는 트랜잭션을 실행하고 나면 여러가지 문서가 생성됩니다. 

이 문서가 전표(Document)입니다. 

어떤 전표들이 발생할까요?

① 입고 트랜잭션을 실행했으니 입고 관련된 자재 문서(Material Document)가 생성됩니다. 

② 입고는 회계상의 거래입니다. 그래서 이와 관련한 회계 전표(Accounting Document)가 생성됩니다. 

③ 입고는 자재의 수불(재고의 증감)이 발생하는 것 입니다.

    그러므로 CO의 자재원장 전표(Material Ledger)가 발생합니다. 

④ 입고 시 구매단가와 이동평균가가 차이가 발생하면 차이를 인식해 주는 회계전표가 발생합니다. 

    (제 블로그의 35번 글을 참고하시기 바랍니다)

    이 차이금액은 회계전표만 발생하는 것이 아니라 관리회계 전표(Controlling Document)도 발생합니다. 

    왜냐하면, 차이 금액도 비용으로 인식하기 때문에 CO Object가 필요하며 그에 따라 관리회계 전표가 발생합니다. 

기본적으로 회계상 거래가 1건 발생하면 위의 4가지 형태로 전표가 발생한다고 생각하시면 됩니다. 

항상 같은 형태로 발생하는 것은 아닙니다. 

  - 위의 ④번의 경우 가격차이가 없다면 관리회계 전표는 발생하지 않습니다. 

  - 매출의 경우 관리회계전표가 아닌 수익성 분석 전표(Profitability Analysis)가 발생합니다. 

     이 부분은 매출을 설명할 때 자세하게 확인해 보겠습니다. 

  - 단순히 자재 저장위치(창고)를 이동하는 경우는 회계상의 거래가 아니기 때문에 자재문서만 발생합니다. 

아무튼 제가 여기서 말씀드리고 싶은 것은 물류 관련 트랜잭션이 발생하면 항상 문서가 발생하며

회계상의 거래인 경우 FI 전표 및 CO 전표가 함께 발생한다는 것입니다. 

그리고, 이 문서들은 하나의 거래에서 파생된 것이므로 위의 문서번호 중 1개만 알고 있더라고 

다른 문서(전표)를 모두 조회할 수 있습니다. 

이제 SAP의 전표(문서)는 여기까지 설명하고, 

실제로 입고 문서에서 회계전표, 관리회계전표, 자재원장 전표를 확인해 보겠습니다.

입고 트랜잭션을 실행하면 입고에 대한 자재문서가 자동으로 생성됩니다. 

입고 문서 번호를 확인해서 조회할 수도 있지만, 

저는 지난 시간에 확인한 구매오더에서 입고 문서를 확인하는 방법을 설명드리겠습니다. 

1. 구매오더 조회(T-Code : ME23N)

    아래 구매오더에서 하나의 품목을 선택한 후 아래 쪽 품목 데이터의 '구매오더 이력' Tab을 확인합니다. 

    여기 아래 리스트에 보시면 입고(물품대)라는 항목에 자재전표 번호가 있습니다. 

    이 부분을 클릭하면 해당 품목의 입고문서를 확인할 수 있습니다. 

    만약 입고가 되지 않았다면 아무런 리스트도 나타나지 않습니다. 

    아래 예시는 입고도 되었고, 송장 처리도 되었다는 것을 확인할 수 있습니다. 

[ 구매오더 조회 ] 

2. 자재 문서 조회 

    가. 입력인, 생성일 및 트랜잭션 코드를 확인할 수 있습니다. 

    나. 품번 및 자재내역, 수량, 저장위치 및 이동유형을 확인할 수 있습니다. 

    다. 상세 내역을 확인한 후에 'FI 문서'를 클릭합니다. 

[ 자재 문서 조회 ] 

3. 전표 리스트 

   FI 문서를 클릭하면 아래 화면과 같이 회계 전표 리스트가 보입니다. 

   현재 보이는 것은 회계전표(Accounting Document)와 자재원장(Material Ledger) 전표 2개 입니다. 

   입고할 때 구매단가와 이동평균가가 일치했기 때문에 관리회계전표(Controlling Document)는 발생하지 않았습니다. 

   가. 회계 전표는 FI 전표로 시산표에 반영되는 차변과 대변 항목 및 금액을 확인할 수 있습니다. 

   나. 자재 원장은 CO 관련 전표로 자재원장(CKM3)에 반영된 내역을 확인 수 있습니다.  

   먼저, 회계전표를 선택하여 자세히 확인해 보겠습니다. 

[ 전표 리스트 ]

4. 회계 전표 

     FI의 시산표에 반영되는 것으로 아래와 같이 분개된 것을 확인할 수 있다. 

      차) 구입부분품   ***     / 대) GR/IR   ***

     각 행을 클릭하면 차변과 대변 항목의 상세한 내역을 확인할 수 있으나, 

     여기서는 생략하겠습니다(간단한 것이니 직접 확인해 보시기 바랍니다).   

     구입부품의 경우 자산 계정으로 CO에서 원가요소를 생성하지 않았기 때문에 

     CO의 코스트센터, 내부오더, PSG 등에는 반영되지 않습니다. 

     왜냐하면 원가요소가 없기 때문입니다. ^^  

     여기에서 'Back'버튼을 클릭하면 전표 리스트로 다시 돌아 갑니다. 

[ 회계전표 ]

5. 전표 리스트

    이번에는 전표리스트에서 자재원장을 선택해 보겠습니다. 

[ 자재원장 ]

6. 자재원장 

     흔히들 보시던 CKM3의 화면은 아닙니다. 

     이런 전표 하나하나가 CKM3의 하나하나의 항목을 구성하고 있는 것 입니다. 

     회계전표에서 구입부분품은 자산계정으로 CO Object에는 반영이 되지 않는다고 했습니다. 

     그렇지만 재고의 증감으로 수불을 나타내는 것으로 이 부분은 CKM3(자재원장)에 반영됩니다. 

      아래 그림에서 마지막 열에 있는 'UP'이 재고 변경을 의미합니다. 

      해당 품번으로 300개의 재고가 추가되었고, 그때 금액은 52,800원입니다. 

      화면에서 '자재 가격 분석'을 클릭하시면 자재원장(Material Ledger, 'CKM3')를 확인할 수 있습니다. 

[ 자재원장 전표 ]

7. 자재원장 (CKM3) - 가격이력 

    처음부터 T-Code : CKM3를 입력하고 들어올 수 있고, 

    구매오더 →입고 문서 → FI 전표 → 자재원장 → 자재원장전표 → 자재가격분석으로 들어올 수도 있습니다. 

    해당 품번의 GR 입고로 300개, 52,800원이 추가되어

    총재고, 총액 및 신규 가격이 변경되었음을 확인할 수 있습니다. 

    이 내역을 확인하고, 중간 정도의 '뷰' 컬럼에서 '가격이력'을 '가격 결정 구조'로 변경해 보겠습니다. 

[ CKM3 - 가격 이력 ]

8. 자재원장 (CKM3) - 가격 결정 구조  

  가격 결정 구조의 범주는 크게 기초, 입고, 소비, 기말 재고로 구분되며

   각 범주마다 상세 범주가 있습니다. 

   입고의 경우 구매입고, 외주가공, 플랜트간 이전전기, 상품간 대체, 생산 입고 등이 있으며, 

   소비의 경우 판매, 생산투입, 코스트센터 출고, 외주가공, 플랜트간 이전전기, 상품간 대체  등이 있습니다. 

   재고가 입고되는 여러가지 경우, 소비되는 여러가지 경우의 수를 나타낸다고 이해하시면 됩니다. 

   이 부분은 나중에 상세히 설명하겠습니다. 

     구매 입고를 하는 부분이기 때문에 CKM의 입고에 구매오더라는

   범주로 수량, 금액 및 이동평균가를 확인할 수 있습니다. 

[ CKM3 - 가격 결정 구조 ]

이상으로 구매오더를 통해 부품을 입고했을 때 발생하는 자재문서, 회계전표 및 자재원장 전표를 확인해 보았습니다. 

하나의 물류 거래가 발생하면 각 모듈과 관련된 여러가지 전표(문서)가 생성됩니다. 

구매오더를 생성한 후 입고를 하게되면 

FI에서는 차변에 구입부품, 대변에 GR/IR로 분개가 발생하면서 시산표에 반영되고, 

CO에서는 자재원장의 입고에 재고 수량과 금액이 반영됩니다. 

위 예시에서는 보이지 않았지만, 

입고 시 구매단가와 이동평균가가 서로 달라 차이가 발생하면

그 차이 부분을 인식하고, 바로 재고에 반영하는 회계전표(FI)가 추가로 하나 더 발생하며

CO 관련된 것으로 '관리회계전표'도 발생합니다. 

관리회계전표는 이 차이 금액을 특정 코스트센터로 반영하는 것을 보여 줍니다. 

(특정 코스트센터는 CO의 IMG Setting 중 '자동계정지정'에서 가능합니다)

이 부분도 예시를 찾아서 화면으로 한번 보여드리도록 하겠습니다. 

CO 결산 과정에 앞서 SAP 물류 흐름과 그에 따라 발생하는 전표를 확인하고, 

CO Report에 어떻게 반영되는지를 먼저 알아 보겠습니다. 

물류 흐름은 말로 설명하면 아주 간단합니다. 

제조업이니까....

생산에 필요한 자재를 구매(매입)해서(MM) 제품을 생산하여(PP) 고객에게 납품합니다(SD)

이 중에서 오늘은 먼저 자재 업무의 일부분을 확인해 보겠습니다. 

자재에서 가장 중요한 업무가 무엇일까요?

저는 생산에 필요한 자재를 구매하는 것이라고 생각합니다.^^ 

(저와 생각이 다른 분이 있으실지도 모르겠네요)

실제로 SAP에서 자재 업무가 많고 다양하지만, 

이번에는 핵심업무 자재 구매에 대해서 알아 보겠습니다. 

SAP에서 자재 구매업무 절차를 수행하는 방법도 다양합니다. 

하지만 제가 아는 방법 1가지만 설명드리겠습니다. 

이 방법도 각자 회사 상황에 맞게 사용한 것이라 약간의 차이는 있을 겁니다. 

SAP 자재 구매 업무는 아래 4단계로 실행합니다. 

   구매 요청(PR) → 구매오더(PO) 생성 → 입고 → 송장(Invoice) 처리 또는 

   구매 요청(PR) → 구매오더(PO) 생성 → 송장(Invoice) 처리 → 입고

  (입고와 송장처리는 순서가 바뀔 수도 있습니다. 아래에서 추가 설명하겠습니다.)

이 중에서 구매요청(PR)은 있어도 되고, 없어도 됩니다. 

제가 다니는 회사에도 처음에는 있었으나, 굳이 필요가 없는 일이라 프로세스에서 제거했습니다. 

그래서 자재 구매업무는 구매오더 생성, 입고, 송장처리 3단계로 이루어져 있습니다. 

우선 각각 단계를 글로 한번 배워 봅시다. ^^

① 구매오더(PO, Purchasing Order)

    말 그대로 구매할 자재를 주문하는 것입니다. 

    A 자재를 B업체에서 100개를 구매하겠다.

    이때 단가 정보도 같이 입력되기 때문에 구매금액도 알수가 있습니다. 

       그리고, 회사 내부에 자재 구매하는 조직이 여러개로 나누어져 있다면 (자재1팀, 자재2팀 등)

    어느 팀에서 구매하는지('구매조직')에 대한 정보도 입력되어 있습니다. 

    하지만 구매오더.. 즉 주문은 회계상의 거래가 아니기 때문에 회계전표는 발생하지 않습니다. 

② 입고(GR, Good Receipt)

     주문한 자재를 업체에서 우리 공장으로 납품하여 우리가 가용할 수 있는 재고로 되는 것입니다. 

     말이 어렵네요....

     쉽게 실물 자재가 우리 공장에 들어온거죠^^

     이 때 실물 자재(자산)의 움직임이 있기 때문에 회계상 거래 입니다. 

③ 송장(Invoice Verification)

     업체에 매입 대금을 인식하는 행위입니다. 

     물건을 샀으니 그에 상응하는 돈을 지불해야겠죠..^^

     실제 지불은 아니고 지불할 금액을 회계상으로 인식하는 것입니다(외상매입금 ). 

여기서 질문입니다. ^^

입고와 송장을 왜 구분했을까요? 

물건 사면서 바로 대금지불하면 되는데, 왜 굳이 2개를 구분했을까요?

여기에서 아주 중요한 개념이 하나 나옵니다. 

GR/IR...   

Good Receipt, Invoice Receipt....

우리가 동네 수퍼마켓에서 과자를 하나 사면 돈을 바로 지급하고 과자를 삽니다. 

이것은 입고와 송장처리가 동시에 발생하는 겁니다. 

하지만, 일반회사는 어떨까요? 

자재 주문을 하면 업체에서 자재를 가져다 줍니다. 

그리고, 월말에 한달동안 납품한 자재에 대한 세금계산서를 보냅니다. 

매 건별로 돈을 지불하는 것이 아니라 한달에 한번씩만 돈을 지불합니다. 

그러니 자재 입고와 금액 지불하는 것을 구분해 놓은 것입니다. 

더 쉬운 예는 수입입니다. 

수입의 경우 송장.... 종이로 된 서류입니다.

요즘에는 E-mail이나 Fax로 금방 보낼 수 있죠

어떤 자재를 얼마만큼 보냅니다라는 정보를 업체에서 우리회사에 보냅니다. 

그러면 우리는 지불할 금액을 먼저 인식합니다(외상매입금).

자재는 배를 타고 와야하기 때문에 2달이 걸립니다. 

이렇듯 자재 입고 시점과 지불할 금액을 인식(외상매입금)하는 시점이 다릅니다. 

그래서 입고와 송장을 구분해 놓은 것이라고 생각합니다. 

그리고, 이런 이유로 입고와 송장처리는 순서가 바뀔 수도 있는 것입니다.

그래서 아래와 같은 분개가 발생합니다. 

입고 시 :   부품 xxx   /  GR/IR  xxx

송장 시 :   GR/IR xxx    / 외상매입금  xxx

일반적으로 부품인식 금액과 외상매입금 인식 금액은 동일하기 때문에, 

입고시 GR/IR 대변금액과 송장 시 GR/IR 차변 금액은 일치합니다. 

그래서 이 부분을 월말에 FI에서 상계하여 잔액이 0이 되게 만들어주는 

GR/IR 반제 작업을 수행합니다. 

어려운 이야기로 갑자기 빠져버렸네요. --; 

아무튼 이런 개념이 있다는 걸 아시고, CO 담당자는 크게 신경쓰지 않으셔도 됩니다. ^^

자.. 이제 본격적으로 구매업무로 들어가 보겠습니다.^^

구매오더, 입고, 송장 처리하는 트랜잭션을 따로 설명하지 않겠습니다. 

이는 MM 모듈 업무로 제가 설명하는 것은 부적절다고 생각합니다. 

다만, CO 담당자도 어느 정도 알고는 있어야 하기 때문에

구매오더에서 입고와 송장 처리 문서를 확인하고, 

회계 전표를 확인하는 방법을 간단하게 알아보겠습니다.

1. 구매오더(PO) 조회 : T-Code ME23N

아래 구매오더는 이미 입고와 송장처리가 완료된 것입니다. 

제가 미리 알고 이 오더를 보여드리는 것은 아니고, 

아래 화면에서 바로 확인할 수가 있습니다. 

하나씩 확인해 보겠습니다. 

  ① 구매오더 번호입니다.  PO 번호로 나중에 송장처리를 수행합니다.

  ② 공급업체 번호입니다. 어떤 업체에서 구매하는지를 알 수 있습니다. 

  ③ ~ ⑤ : 구입할 자재의 품번과 내역, 수량 및 단위당 단가를 확인할 수 있습니다. 

  ⑥ 구매오더이력 :

        이 Tab에서 해당 구매오더는 입고와 송장처리가 완료되었다는 것을 확인할 수 있습니다. 

        처음에 구매오더를 생성하면 이 Tab의 아래에 아무런 내역이 없습니다. 

        그런데, 지금 보시면 ⑦번 입고(물품대)와 ⑧번 물품대 송장검증이라는 항목이 있습니다. 

      ⑦번 입고(물품대)가 입고가 되었을 때 업데이트되는 내용이며, 

      ⑧번 물품대 송장검증은 송장 처리가 완료되었을 때 업데이트 되는 내용입니다. 

여기에서 입고 문서를 확인하려면 ⑦번 입고(물품대)에 위에 있는 자재전표를 클릭하면 되고, 

송장 문서를 확인하려면  ⑧번 물품대 송장검증위에 있는 자재전표를 클릭하면 됩니다. 

아래 구매오더에는 구매하는 자재가 1개입니다.

하지만 동일한 업체에서 여러 가지 자재를 구매할 수도 있겠죠

그러면 품목이 여러개 나타나며,  ⑨번의 품번을 변경하면서 구매오더 이력을 확인해야 합니다. 

왜 그럴까요? 2개 품목을 주문했지만 업체 사정으로 1개는 오늘 납품하고,

다른 1개는 일주일 후에 납품할 수도 있습니다. 

품목마다 업체에서 제품을 생산 주기가 다를 수 있기 때문에 납품 일자가 다를 수 있습니다. 

또한 아래 PO는 300개를 주문해서 300개가 한꺼번에 입고되었지만, 

100개, 100개, 100개씩 3번에 나눠서 분할 입고가 되기도 합니다. 

대부분의 경우의 수가 다 포함되어 있다고 생각하시면 됩니다. 

[ 구매오더 조회 ]

위의 PO는 표준 PO입니다.

그렇다는 다른 유형의 PO도 있다는 것을 눈치채셨겠죠?

품번이 없을 경우 PO을 생성하는 방법

입고와 동시에 소비 처리하는 방법 등 여러가지 PO가 있을 수 있습니다. 

그리고 IMG Setting으로 추가 PO 방식을 생성할 수도 있습니다.

(이 부분은 MM 모듈에서 하는 거라 저는 모릅니다^^)

어떤 유형이라 하더라도 기본적인 틀은 표준 PO와 비슷합니다. 

각자 회사에서 사용하는 PO를 하나씩 확인해 보시면 이해하는데 도움이 되실겁니다. 

앞에서 다른 이야기를 하다보니 정작 필요한 얘기는 하지 못하고 말았네요. 

오늘은 구매오더 조회하는 방법을 간단히 소개드리고, 

다음 포스팅에서 입고 관련 문서를 확인하는 방법을 설명드리도록 하겠습니다. 

오늘은 여기까지 하겠습니다. 

항상 건강하고 행복하세요..*