게시판을 검색해보니 같은 문제로 이미 질문하신 분이 있더군요.
머니플랜에서는 복식부기의 원리상 차변에서 출금처리된 항목은 대변에서 입금처리가 자동으로 되도록 되어 이체거래 연결시 한쪽만 체크해서 출*입금 부분을 설정하여 사용했었는데, 머니북에서는 이러한 차변 대변의 규정을 시행할 수가 없네요.
어떤 상황이냐면 통장 A에서 100만원을 출금하여 통장 B로 이체한 후에 두 통장간의 이체거래를 대체거래연결하면 두개의 통장이 모두 "입금"으로 항목명이 설정되거나 아니면 "출금"으로 설정이 되어 복식부기원리에맞지 않게 되고 있습니다. 수동으로 A통장은 출금으로 B통장은 입금으로 설정해보려고 해도 두 통장간의 거래가 이체등록(머니북에서는 대체상대계정 등록이겠지요)이 되어 있으면 이마저 불가능 하네요.
첨부화일에 저의 경우를 그림화일로 올렸으니 확인해주세요.
*추가로 자산 부채 현황은 문제가 없는데 소유자별, 종류별 보고서를 보려면 오류가 뜨네요.
*오류 내용은 아래와 같습니다만. 무슨 내용인지는 잘..
이 대화 상자 대신 JIT(Just-in-time) 디버깅을 호출하는
방법에 대한 자세한 내용은 이 메시지의 뒷부분을 참조하십시오.
************** 예외 텍스트 **************
System.NullReferenceException: 개체 참조가 개체의 인스턴스로 설정되지 않았습니다.
위치: MPReportView.ucReportSum.SetColumnHeaderStyle_Owner()
위치: MPReportView.ucReportSum.SetColumnHeaderStyle()
위치: MPReportView.ucReportSum.DisplaySummary()
위치: MPReportView.ucReportSum.datSelect_EditValueChanged(Object sender, EventArgs e)
위치: DevExpress.XtraEditors.Repository.RepositoryItem.RaiseEditValueChangedCore(EventArgs e)
위치: DevExpress.XtraEditors.Repository.RepositoryItemDateEdit.RaiseEditValueChangedCore(EventArgs e)
위치: DevExpress.XtraEditors.Repository.RepositoryItem.RaiseEditValueChanged(EventArgs e)
위치: DevExpress.XtraEditors.Repository.RepositoryItemDateEdit.RaiseEditValueChanged(EventArgs e)
위치: DevExpress.XtraEditors.BaseEdit.RaiseEditValueChanged()
위치: DevExpress.XtraEditors.BaseEdit.OnEditValueChanged()
위치: DevExpress.XtraEditors.TextEdit.OnEditValueChanged()
위치: DevExpress.XtraEditors.BaseEdit.OnEditValueChanging(ChangingEventArgs e)
위치: DevExpress.XtraEditors.BaseEdit.set_EditValue(Object value)
위치: MPReportView.ucReportSum.DrawingReport(enumREPORTTYPE iReportType)
위치: MoneyPlan.FrmReportSum.tmrStart_Tick(Object sender, EventArgs e)
위치: System.Windows.Forms.Timer.OnTick(EventArgs e)
위치: System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
위치: System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
------------------------------------------------------------------------------------------------
안녕하세요. 머니북(MoneyBook) 입니다.
말씀하신 내용 즉 상대계정의 대체항목에 대해서는 머니북에서는 기준을 가지고 있습니다. 이 부분은 사실은 머니플랜에서도 같은 기준이었는데 [입금/출금]의 표시 때문에 억지로 한쪽 게정이 [입금]이면 상대계정에는 [출금]으로 표시를 하도록 했었습니다. 사실은 이때문에 여러 어려움을 겪었지요.
대체거래는 2개의 거래가 각각 차변/대변으로 쌍으로 이루어집니다.
머니북은 이러한 차변/대변 거래를 잘 처리하고 있습니다.
항목의 표시를 말씀하셨는데 굳이 정확하게 표시를 하고자 한다면 다음과 같을 수 있을 겁니다.(차변/대변에 각각 항목을 표시한다면)
<b>(대출 계정을 중심으로 표시한다면)</b>
대출(빌린돈)
A대출 계정은 [대출(빌린돈)] / B일반예금 계정은 [입금]
대출상환
A계정은 [대출상환] / B일반예금계정은 [출금]
<b>(일반예금 계정을 중심으로 표시한다면)</b>
대출(빌린돈)
A대출 계정은 [입금] / B일반예금 계정은 [대출(빌린돈)]
대출상환
A계정은 [출금] / B일반예금계정은 [대출상환출금]
보시면 아시겠지만 대체거래의 상대계정의 항목은 늘 일정하게 [입금] 또는 [출금] 입니다. 적금불입을 적용해도 마찬가지도 [신용카드결제]를 적용해봐도 마찬가지지요.
여기서 2가지 문제가 발생을 합니다.
1. 어떤 계정을 기준으로 작성을 할 것이냐하는 문제가 생기지요. 대출계정을 기준으로 작성을 하면 대출계정에 [대출상환]이 표시되는데 그렇다면 일반예금통장에는 [입금] 또는 [출금]만 표시되어서 도대체 어떤 명목으로 입금/출금이 되었는지 알기가 어렵게 됩니다. 물론 메모에다 기록할 수 있겠지만... 과연 고객님들이 그렇게 할 것이며 용납이 될까요?
반대로 일반예금통장을 기준으로 한다면 대출계정에는 역시 [입금] 또는 [출금]만 기록되게 되겠지요.
이렇게 될 경우 [입금] 또는 [출금] 항목으로 집계되는 것은 아무런 의미도 없게되고 또한 엄청난 왜곡 현상이 생기게 됩니다.
2. 더큰 문제는 어떤 계정을 기준으로 할 것이냐를 고객님들이 결정을 하셔야 한다는 것입니다. 그런데 예전에는 대출계정을 기준으로 항목을 지정했고 지금은 일반예근통장을 기준으로 항목을 지정한다면 [대출상환] 표시는 대출통장에도 있고 일반예금통장에도 있게 됩니다. 아것을 강제 규정할 수는 물론 불가능 하지요.
살펴보면 [대출(빌린돈)] 항목이나 [대출상환] 항목은 중요한 반면에 상대계정에 반드시 발생하는 [입금] 또는 [출금]은 아무런 의미가 없음을 발견하실 수 있을 것입니다.
그래서 항목을 지정하면 그 항목을 양쪽게정 즉 상대계정에도 표시를 해주고 집계를 할 때는 한쪽만 가져다 집계를 하는 방법을 사용하는 겁니다.
때문에 [입금] 항목을 지정하면 상대게정에도 같은 [입금]이 표시되는 것이고 [출금]을 지정하면 상대게정에도 [출금]이 지정되는 것입니다.
이게 심정적으로는 즉 고객님들의 입장에서 보면 불합리하게 보이는 것이 사실이지요. 때문에 머니플랜에서 이 부분을 해결해드리기 위해 [입금]을 지정하면 상대게정에는 [출금]을 지정하는 방식으로 프로그램에서 강제처릴르 하게 되었는데 앞에서 말씀드렸듯이 집계는 어떻게 할 것인가가 문제가 되는 것이었지요. 때문에 집계도 예외처리를 하였다가 그것도 문제가 많아 결국은 [입금], [출금] 항목은 집계에서 제외를 한 것입니다.
머니북을 다시 설계를 하면서 이 부분에 대한 결론을 내린 것은 예외처리가 능사가 아니었다는 것이고 단순히 [입금], [출금]일 경우에는 하나의 항목 즉 [계정간이체]와 같은 하나의 항목을 표시해서 단순히 눈에 보이는 혼란을 피하기만 하자는 것입니다. 실제로 지금은 없어진 모두가 잘 아시는 [이모든] 프로그램에서는 대체거의 표시는 모두 [계정간이체]로 무조건 표시를 했었습니다. 그럴 경우에는 적금이 얼마나 불입되었는지 대출상환은 얼마나 되었는지를 알기가 어려워 좋은 방법은 아니었지만 상대적으로 고객들의 혼란은 없었을 겁니다.(사실 회계에 대해 잘 모르시는 고객님들이 대 부분이라 문제 제기도 없었거나 설사 문제 제기가 있더라도 구조상 어쩔 수 없었을 것입니다.)
얘기가 장황해졌는데
정리를 하자면 [입금]으로 입력하면 상대계정에 [출금]으로 또는 반대로 [출금]으로 지정하면 상대계정에 [입금]으로 강제로 지정하는 것은 맞지 않습니다. 아니 맞고 안 맞고를 따지기 전에 효과적이지 않습니다.
가계부를 쓰는 목적이 꼭 회계원칙을 지키자는 데 있지 않다고 생각 합니다. 알아보기 쉽고 통계가 잘 나오고 그로 인해 반성 또는 의욕을 갖게 된다면 그 이상 좋을게 없을 겁니다.
무조간 대체거래는 [계정간이체]로 표시하는 것은 집계(통계)에 유용하지 않습니다. 적금불입은 적금불입으로 집계되고 대출상환은 대출상환으로 집계되고 신용카드 결제는 신용카드 결제로 집계되는 것이 효과적입니다.
명목이 확실한(예로 든 적그불입, 대추랑환 같은) 항목은 양쪽 계정에 같이 표시되면 보기가 좋습니다. 어느 계정을 봐도 알 수가 있으니까요. 단순한 입금/출금일 경우에는 [계정간이체] 또는 [은행to현금], [현금to은행]과 같은 항목을 임의로 만들어 사용하면 효과적일 수 있습니다. 은행에 현금을 입금했을 때 표시를 한다면 역시 한쪽에는 [입금] 다른 한쪽에는 [출금]이 되어야한다고 할 때 입금이 얼마고 출금이 얼마인지를 집계하는 것은 앞에서 말씀드렸드싱 무수히 많은 입금/출금에 묻히지만 [현금to은행]과 같이 항목을 만들어 쓰면 현금을 은행에 얼마나 예금했고 반대로 은행에서 현금을 얼마나 인출했는지 집계를 해 볼 수가 있게 됩니다.
답변이 엄청 길었는데... 제대로 말씀을 드렸는지 모르겠습니다.
말이 길어지면 자꾸 변명처럼 보일 수 있습니다. 노파심으로 말씀을 드리자면 머니플랜에서도 늘 그랬지만 특히 머니북(MoneyBook)에서는 변명이나 프로그램을 옹호하는 측면에서 말씀을 드리지 않을 것입니다.
앞으로 10년, 20년 만들어갈 프로그램이기에 가급적 효율적이고 사용자에 맞게 만들어가야할 책임과 의무가 있음을 잘 알고 있습니다. 다만 어떤 의견이나 상황에 충분한 검토나 고민없이 왔다갔다 하면 절대로 안된다는 것을 잘 알고 있고 또한 머니북(MoneyBook) 기호기/개발/지원팀은 같은 생각을 가진 같은 팀이 적어도 10년이상 함께하고 있기에 그리고 고객님들과 함께하고 있기에 논의되는 대개의 문제들이나 상황들을 잘 알고 있다고 말씀드릴 수 있습니다.
앞으로 이러한 것들을 활짝 펼쳐나갈 것입니다. 예전 프로그램에서 뼈대가 갖고 있는 한계가 있었다면 새 프로그램인 머니북(MoneyBook)에서는 그러한 한계는 없기에 얼마든지 좋은 의견을 반영하고 개선해 나갈 수 있습니다.
뒷부분의 [자산/부채 소유자별 현황]의 오류는 발견을 할 수가 없는데 혹시 반복적인 문제라면 수고스럽ㅈ만 담당자에게 연락을 부탁드립니다. 데아터 변환 등에 의해 특별한 상황일 수 있기에 연락을 주시면 문제를 찾아내서 해결하는데 많은 도움이 될 것입니다.
고맙습니다.
머니플랜에서는 복식부기의 원리상 차변에서 출금처리된 항목은 대변에서 입금처리가 자동으로 되도록 되어 이체거래 연결시 한쪽만 체크해서 출*입금 부분을 설정하여 사용했었는데, 머니북에서는 이러한 차변 대변의 규정을 시행할 수가 없네요.
어떤 상황이냐면 통장 A에서 100만원을 출금하여 통장 B로 이체한 후에 두 통장간의 이체거래를 대체거래연결하면 두개의 통장이 모두 "입금"으로 항목명이 설정되거나 아니면 "출금"으로 설정이 되어 복식부기원리에맞지 않게 되고 있습니다. 수동으로 A통장은 출금으로 B통장은 입금으로 설정해보려고 해도 두 통장간의 거래가 이체등록(머니북에서는 대체상대계정 등록이겠지요)이 되어 있으면 이마저 불가능 하네요.
첨부화일에 저의 경우를 그림화일로 올렸으니 확인해주세요.
*추가로 자산 부채 현황은 문제가 없는데 소유자별, 종류별 보고서를 보려면 오류가 뜨네요.
*오류 내용은 아래와 같습니다만. 무슨 내용인지는 잘..
이 대화 상자 대신 JIT(Just-in-time) 디버깅을 호출하는
방법에 대한 자세한 내용은 이 메시지의 뒷부분을 참조하십시오.
************** 예외 텍스트 **************
System.NullReferenceException: 개체 참조가 개체의 인스턴스로 설정되지 않았습니다.
위치: MPReportView.ucReportSum.SetColumnHeaderStyle_Owner()
위치: MPReportView.ucReportSum.SetColumnHeaderStyle()
위치: MPReportView.ucReportSum.DisplaySummary()
위치: MPReportView.ucReportSum.datSelect_EditValueChanged(Object sender, EventArgs e)
위치: DevExpress.XtraEditors.Repository.RepositoryItem.RaiseEditValueChangedCore(EventArgs e)
위치: DevExpress.XtraEditors.Repository.RepositoryItemDateEdit.RaiseEditValueChangedCore(EventArgs e)
위치: DevExpress.XtraEditors.Repository.RepositoryItem.RaiseEditValueChanged(EventArgs e)
위치: DevExpress.XtraEditors.Repository.RepositoryItemDateEdit.RaiseEditValueChanged(EventArgs e)
위치: DevExpress.XtraEditors.BaseEdit.RaiseEditValueChanged()
위치: DevExpress.XtraEditors.BaseEdit.OnEditValueChanged()
위치: DevExpress.XtraEditors.TextEdit.OnEditValueChanged()
위치: DevExpress.XtraEditors.BaseEdit.OnEditValueChanging(ChangingEventArgs e)
위치: DevExpress.XtraEditors.BaseEdit.set_EditValue(Object value)
위치: MPReportView.ucReportSum.DrawingReport(enumREPORTTYPE iReportType)
위치: MoneyPlan.FrmReportSum.tmrStart_Tick(Object sender, EventArgs e)
위치: System.Windows.Forms.Timer.OnTick(EventArgs e)
위치: System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
위치: System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
------------------------------------------------------------------------------------------------
안녕하세요. 머니북(MoneyBook) 입니다.
말씀하신 내용 즉 상대계정의 대체항목에 대해서는 머니북에서는 기준을 가지고 있습니다. 이 부분은 사실은 머니플랜에서도 같은 기준이었는데 [입금/출금]의 표시 때문에 억지로 한쪽 게정이 [입금]이면 상대계정에는 [출금]으로 표시를 하도록 했었습니다. 사실은 이때문에 여러 어려움을 겪었지요.
대체거래는 2개의 거래가 각각 차변/대변으로 쌍으로 이루어집니다.
머니북은 이러한 차변/대변 거래를 잘 처리하고 있습니다.
항목의 표시를 말씀하셨는데 굳이 정확하게 표시를 하고자 한다면 다음과 같을 수 있을 겁니다.(차변/대변에 각각 항목을 표시한다면)
<b>(대출 계정을 중심으로 표시한다면)</b>
대출(빌린돈)
A대출 계정은 [대출(빌린돈)] / B일반예금 계정은 [입금]
대출상환
A계정은 [대출상환] / B일반예금계정은 [출금]
<b>(일반예금 계정을 중심으로 표시한다면)</b>
대출(빌린돈)
A대출 계정은 [입금] / B일반예금 계정은 [대출(빌린돈)]
대출상환
A계정은 [출금] / B일반예금계정은 [대출상환출금]
보시면 아시겠지만 대체거래의 상대계정의 항목은 늘 일정하게 [입금] 또는 [출금] 입니다. 적금불입을 적용해도 마찬가지도 [신용카드결제]를 적용해봐도 마찬가지지요.
여기서 2가지 문제가 발생을 합니다.
1. 어떤 계정을 기준으로 작성을 할 것이냐하는 문제가 생기지요. 대출계정을 기준으로 작성을 하면 대출계정에 [대출상환]이 표시되는데 그렇다면 일반예금통장에는 [입금] 또는 [출금]만 표시되어서 도대체 어떤 명목으로 입금/출금이 되었는지 알기가 어렵게 됩니다. 물론 메모에다 기록할 수 있겠지만... 과연 고객님들이 그렇게 할 것이며 용납이 될까요?
반대로 일반예금통장을 기준으로 한다면 대출계정에는 역시 [입금] 또는 [출금]만 기록되게 되겠지요.
이렇게 될 경우 [입금] 또는 [출금] 항목으로 집계되는 것은 아무런 의미도 없게되고 또한 엄청난 왜곡 현상이 생기게 됩니다.
2. 더큰 문제는 어떤 계정을 기준으로 할 것이냐를 고객님들이 결정을 하셔야 한다는 것입니다. 그런데 예전에는 대출계정을 기준으로 항목을 지정했고 지금은 일반예근통장을 기준으로 항목을 지정한다면 [대출상환] 표시는 대출통장에도 있고 일반예금통장에도 있게 됩니다. 아것을 강제 규정할 수는 물론 불가능 하지요.
살펴보면 [대출(빌린돈)] 항목이나 [대출상환] 항목은 중요한 반면에 상대계정에 반드시 발생하는 [입금] 또는 [출금]은 아무런 의미가 없음을 발견하실 수 있을 것입니다.
그래서 항목을 지정하면 그 항목을 양쪽게정 즉 상대계정에도 표시를 해주고 집계를 할 때는 한쪽만 가져다 집계를 하는 방법을 사용하는 겁니다.
때문에 [입금] 항목을 지정하면 상대게정에도 같은 [입금]이 표시되는 것이고 [출금]을 지정하면 상대게정에도 [출금]이 지정되는 것입니다.
이게 심정적으로는 즉 고객님들의 입장에서 보면 불합리하게 보이는 것이 사실이지요. 때문에 머니플랜에서 이 부분을 해결해드리기 위해 [입금]을 지정하면 상대게정에는 [출금]을 지정하는 방식으로 프로그램에서 강제처릴르 하게 되었는데 앞에서 말씀드렸듯이 집계는 어떻게 할 것인가가 문제가 되는 것이었지요. 때문에 집계도 예외처리를 하였다가 그것도 문제가 많아 결국은 [입금], [출금] 항목은 집계에서 제외를 한 것입니다.
머니북을 다시 설계를 하면서 이 부분에 대한 결론을 내린 것은 예외처리가 능사가 아니었다는 것이고 단순히 [입금], [출금]일 경우에는 하나의 항목 즉 [계정간이체]와 같은 하나의 항목을 표시해서 단순히 눈에 보이는 혼란을 피하기만 하자는 것입니다. 실제로 지금은 없어진 모두가 잘 아시는 [이모든] 프로그램에서는 대체거의 표시는 모두 [계정간이체]로 무조건 표시를 했었습니다. 그럴 경우에는 적금이 얼마나 불입되었는지 대출상환은 얼마나 되었는지를 알기가 어려워 좋은 방법은 아니었지만 상대적으로 고객들의 혼란은 없었을 겁니다.(사실 회계에 대해 잘 모르시는 고객님들이 대 부분이라 문제 제기도 없었거나 설사 문제 제기가 있더라도 구조상 어쩔 수 없었을 것입니다.)
얘기가 장황해졌는데
정리를 하자면 [입금]으로 입력하면 상대계정에 [출금]으로 또는 반대로 [출금]으로 지정하면 상대계정에 [입금]으로 강제로 지정하는 것은 맞지 않습니다. 아니 맞고 안 맞고를 따지기 전에 효과적이지 않습니다.
가계부를 쓰는 목적이 꼭 회계원칙을 지키자는 데 있지 않다고 생각 합니다. 알아보기 쉽고 통계가 잘 나오고 그로 인해 반성 또는 의욕을 갖게 된다면 그 이상 좋을게 없을 겁니다.
무조간 대체거래는 [계정간이체]로 표시하는 것은 집계(통계)에 유용하지 않습니다. 적금불입은 적금불입으로 집계되고 대출상환은 대출상환으로 집계되고 신용카드 결제는 신용카드 결제로 집계되는 것이 효과적입니다.
명목이 확실한(예로 든 적그불입, 대추랑환 같은) 항목은 양쪽 계정에 같이 표시되면 보기가 좋습니다. 어느 계정을 봐도 알 수가 있으니까요. 단순한 입금/출금일 경우에는 [계정간이체] 또는 [은행to현금], [현금to은행]과 같은 항목을 임의로 만들어 사용하면 효과적일 수 있습니다. 은행에 현금을 입금했을 때 표시를 한다면 역시 한쪽에는 [입금] 다른 한쪽에는 [출금]이 되어야한다고 할 때 입금이 얼마고 출금이 얼마인지를 집계하는 것은 앞에서 말씀드렸드싱 무수히 많은 입금/출금에 묻히지만 [현금to은행]과 같이 항목을 만들어 쓰면 현금을 은행에 얼마나 예금했고 반대로 은행에서 현금을 얼마나 인출했는지 집계를 해 볼 수가 있게 됩니다.
답변이 엄청 길었는데... 제대로 말씀을 드렸는지 모르겠습니다.
말이 길어지면 자꾸 변명처럼 보일 수 있습니다. 노파심으로 말씀을 드리자면 머니플랜에서도 늘 그랬지만 특히 머니북(MoneyBook)에서는 변명이나 프로그램을 옹호하는 측면에서 말씀을 드리지 않을 것입니다.
앞으로 10년, 20년 만들어갈 프로그램이기에 가급적 효율적이고 사용자에 맞게 만들어가야할 책임과 의무가 있음을 잘 알고 있습니다. 다만 어떤 의견이나 상황에 충분한 검토나 고민없이 왔다갔다 하면 절대로 안된다는 것을 잘 알고 있고 또한 머니북(MoneyBook) 기호기/개발/지원팀은 같은 생각을 가진 같은 팀이 적어도 10년이상 함께하고 있기에 그리고 고객님들과 함께하고 있기에 논의되는 대개의 문제들이나 상황들을 잘 알고 있다고 말씀드릴 수 있습니다.
앞으로 이러한 것들을 활짝 펼쳐나갈 것입니다. 예전 프로그램에서 뼈대가 갖고 있는 한계가 있었다면 새 프로그램인 머니북(MoneyBook)에서는 그러한 한계는 없기에 얼마든지 좋은 의견을 반영하고 개선해 나갈 수 있습니다.
뒷부분의 [자산/부채 소유자별 현황]의 오류는 발견을 할 수가 없는데 혹시 반복적인 문제라면 수고스럽ㅈ만 담당자에게 연락을 부탁드립니다. 데아터 변환 등에 의해 특별한 상황일 수 있기에 연락을 주시면 문제를 찾아내서 해결하는데 많은 도움이 될 것입니다.
고맙습니다.
