> > Any references or tips on segregation of local changes appreciated.
> Ok. What type of changes are we talking about here? Are you talking about > adding columns to tables? > > If you're talking about adding tables, then it's probably best to have a > separate schema and add the tables you need to that; that way, when > LedgerSMB is upgraded, your added tables remain untouched. By priority, high to low: 1) Adding fields to tables and forms. 2) Possibly adding tables linked to tables. Legacy fields like 'url' have been repurposed by users. I prefer to just dump such stuff into the comment text. A dispute I expect to win. Either way, the mess is dealt with by hand. 3) Protecting against browser lockups. A default search on parts, yields over 27000 items. Postgres does this in a flash, goods.pl about 4 minutes, and the browser page goes unresponsive before scrolling through that data. 4) Changing the layout of some screen forms--parts, and the purchasing and sales chain of forms. 5) Minor logic changes in sales forms--extra fields that are derived from user input, some of which are saved. Extending the ability of 'terms' logic. N) Reworking or extension of the headings/accounts logic, so more than one kind of balance sheet and income statement can be run. I'd think LSMB could incorporate this. The primary issue would be that LSMB requires the usual-at-least-to-me sequence of GL accounts being Assets, Liabilities, Equity, Income/Revenue, to Expenses/Losses. Incidentally, setting up or doing much modification of a CoA through the web interface is brutal. Be well, Rob ------------------------------------------------------------------------------ _______________________________________________ Ledger-smb-users mailing list Ledger-smb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
