문제

설계 패턴에 대한 좋은 리소스 (책, 권위 가이드 등) 또는 재무 회계 기능이 포함 된 소프트웨어에 대한 기타 모범 사례가 있습니까?

구체적으로 다음과 같은 문제를 처리하는 것에 대한 좋은 정보는 다음과 같습니다.

  • 돈 수량의 내부 표현
  • 계정, 저널 및 기타 기록의 내부 표현
  • 불일치 조정 (자동 또는 사용자 조치를 통해)
  • 회계 기간 처리 (매일, 주별, 월간)
  • 기업인에게 이해하는 UIS 및 인쇄 재무 보고서 설계

참고 : "권한 적"또는 널리 받아 들여지는 정보가 우리가 여기에서 찾고있는 것입니다. 그렇지 않으면, 이것은 사람들이 시도한 모든 것들의 큰 일화 목록으로 바뀌어 주제를 매우 주관적으로 만들 것입니다.

도움이 되었습니까?

해결책

마틴 파울러의 분석 패턴 그 주제 중 일부를 다룹니다.

다른 팁

얼마 전에 그러한 시스템 작업을 수행하도록 지정되었을 때 Martin Fowler 웹 사이트 에서이 링크를 찾았습니다.

마틴 파울러 - 회계 패턴

회계 항목, 거래 및 조정과 같은 회계 소프트웨어의 일부 패턴. 그가 묘사 한 건축은 이벤트를 기반으로합니다. 내가 작업하는 시스템이 이미 개발 단계의 중간에 있었고 디자인을 바꿀 수 없었기 때문에 완전히 읽지 마십시오.

도움이되기를 바랍니다.

I would have the following structural classes:

  1. Account - Represents a financial account. eg. Cash, Sale, Expense;
  2. Category - The category where the Account belongs to. eg. Asset, Expenses, Revenues;
  3. Mutation - Represents a financial entry of an account.
  4. Transaction - Contains a collection of mutations.
  5. Money - A composite class using Currency object and storing amount as long integer;

When I approached the design initially I kept thinking about Decorator and Builder Patterns. Tax calculation can use the Strategy Pattern. Observer Pattern can be used to veto Transaction.

통화를 다루기 위해서는 금액이 어떤 통화를 입력했는지뿐만 아니라 입력 한 시간, 그리고 그 당시 각 통화의 속도가 얼마인지 항상 기억해야한다는 것을 기억하십시오. 또한 회계사는 "부정확성"에 관해서는 용서하지 않습니다. 금액이 입력되면 입력 한 상태에서 저장해야하며 먼저 변환하지 않아야합니다. 나중에 입력 한 것처럼 입력 된 금액을 다시받을 수 없기 때문에 먼저 변환하지 않아야합니다.

이것들은 명백한 것들처럼 들릴지 모르지만 사람들은 현실 세계에서 그들에게 죄를 짓습니다.

추천 할 수 있습니다 엔터프라이즈 애플리케이션 아키텍처 패턴 그리고분석 패턴, 재사용 가능한 객체 모델 Martin Fowler는 모두 일반적인 문제에 소프트웨어 건축 패턴을 제공합니다.

나는 그것을 찾았다 데이터 모델 리소스 북 비즈니스 구조를 모델링하기위한 좋은 영감의 원천이됩니다. Apache ofbiz erp 이 책의 개념을 중심으로 지어졌습니다.

UI /보고의 경우 : Crystal Reports 및 Business Objects를 살펴보십시오. 둘 다 투자 회계 부서의 고용 장소에서 사용됩니다.

우리는 여기 내부 (JD Edwards)를 위해 다른 것들을 사용하지만 '예, 그렇게합니다'외에는 실제로 자세히 설명 할 수 없습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top