skip to content
 
developing second generation, OpenACS commerce packages
Begin main content

No registered users in community XoWiki
in last 20 minutes

SQL-Ledger porting notes

SL puts all AR data in AR table, AP data in AP table, GL data in GL table, with shared portions in acc_trans table.

To maximize usefulness and integration subsystems, consider adding a transaction type to the sql-ledger acc_trans or GL table and the GL relevant AR/AP transactions moved into the GL/acc_trans tables, while leaving the generic AR/AP tables/workflow separate. Reasons:

  1. reports that depend on the general ledger should work with the COA regardless of data origins and not be concerned about any external AR/AP workflow (since they can greatly vary).
  2. report code is simplified when all data of one general class are in 1 table.
  3. Controlling permissions when separating them by AR/AP/GL transactions (as SL does), where GL is given higher level authority, may require modifying a COA and adding extra account transfers to accomplish certain tasks, such as gift certificate purchases. Whereas moving permissions to be based on url allows much more flexibility.
Insight from a "General Ledger db design" discussion in pgsql-general mailing list  suggests we should leave the GL/AR/AP tables as currently implemented in sql-ledger (specifically, see the comments by Kenneth Downs on an inverted table hierarchy: http://archives.postgresql.org/pgsql-general/2007-02/msg01515.php)


Categories: other non-OpenACS software (ec-g2)

No comments available

Add comment