|
|
| Line 42: |
Line 42: |
|
| |
|
| == Transacting == | | == Transacting == |
| ==== django-oscar ====
| | § deleted see history. |
| | |
| <blockquote class=plainlinks>
| |
| I chose this back end pkg because of its claim of being domain driven. That claim, as it turns out is based on dynamic class loading. So without quibbling and as its sole focus on txing is convenient it turns out to be an early anchor in my DDD praxis.
| |
| | |
| Provides front end for tx'ing objects. We introduce the notion of an ephemeral tx ledger, oriented to a single, possibly complex tx which is connected to the others (§ 2.4.1.1). Like 'ledger', transaction 'tx' is defined to be an abstract change to a ledger. The process of application of a real instance of such change to persistent ledgers is called settlement.
| |
| | |
| Consequently, any transaction requirements are realized as constraints on the [https://django-oscar.readthedocs.io/en/3.1/ref/apps/index.html 16 Oscar Apps] or new classes in its framework.
| |
| </blockquote>
| |
| | |
| == Accounting == | | == Accounting == |
| <blockquote>
| | § deleted see history. |
| === Design Principles ===
| |
| <blockquote>
| |
| | |
| ==== Abstraction and Unity ====
| |
| <blockquote>
| |
| #Ledgers are abstract entities realized differently in different packages but from the perspective of a single accounting ontology.
| |
| #Unless qualified, 'ledger' means double entry accounting ledger, a fundamental concept conserved across all ledger implementations, the basis of their unification.
| |
| </blockquote>
| |
| | |
| ==== Security and Transparency ====
| |
| <blockquote>
| |
| This is a requirement that requires a balancing of interests as transparency can conflict with security. Users. i.e. individuals and groups (including firms) may opt
| |
| for near complete opacity of their accounts which has been the general norm. The System, domain space, however is required to have open books and line items
| |
| against its books are why it's not complete opacity.
| |
| </blockquote>
| |
| </blockquote>
| |
| | |
| === Back End Packages ===
| |
| <blockquote><blockquote>
| |
| The pkgs that provide the functional detail in different use cases generally repeat and duplicate functions. By virtue of § 2.4.1.1.2 however, and system ops that implement it, they all operate against common ledgers. When function is duplicated, there is generally only one package that is contextually supported. For example, SQL/SMB has transaction interfaces but these are not used as django-oscar is selected for that and SQL/SMB is used as a back office system only.
| |
| </blockquote></blockquote>
| |
| <blockquote>
| |
| ==== hledger ====
| |
| | |
| The users personal ledger. It may be convenient for the group administrators personal ledger to be used as the group ledger and this is the assumed default. hledger-web is not duplicated, nonetheless because of its accounting function and system integration, it is deemed a part of 'redvant'.
| |
| | |
| ==== ledger ====
| |
| | |
| Basis of the System Journal, how the system views all ledgers. AKA ledger-cli, ledger c++, the original that was ported to hledger.
| |
| | |
| ==== SQL-Ledger / LedgerSMB ====
| |
| | |
| The enterprise Chart of Accounts (COA), typical of an ERP pkgs ledger. Individuals don't normally view this package and its interface is mod perl based.
| |
| Every O class user has its own COA.
| |
| The System COA is visible to all AKPERSONs.
| |
| | |
| </blockquote>
| |
| | |
| </blockquote>
| |
|
| |
|
| = Sonstiges = | | = Sonstiges = |
