Hi Francoise Re: Currency. Yes, we also have a field to indicate currency for each transaction. But we only use EUR and GBP and we do not have any currency translation/revaluing processes.
Re: Multi-Company. For transportability and auditing etc I could see the point of having separate DBs. However, I cannot see much point in having separate tables. Each record can be flagged with a Company id field. The only complication is perhaps maintaining separate sequence numbers. Re: Invoicing. Does your model include invoicing, debtors, creditors etc and, if so, do you have separate tables for invoicing? In my case, I am trying to do everything with one Aclines table. This means we have to do some fancy footwork with flagging each document and transaction, but there's a big pay-off for doing searching and reporting. Re: General. Accounting is a bit of a minefield. I am purposely keeping our accounting extremely simple but if you spent a year working on a blueprint, it is probably going to be much more complex. Enterprise level accounting systems seem to be very complex -- lots of tables and security. Before commissioning the software, maybe you should publish the blueprint and let people make some comments. If your ideas are interesting to others, you might get some people to chip in with the costs etc. Something simple which also works on GoogleApps could be quite revolutionary! Regards, - David On Dec 17, 9:40 pm, "Francois (Jersey)" <francois.ches...@googlemail.com> wrote: > Hi David, > > Interestingly enough my model is very similar to yours :;) > > Our naming convention are a little bit different: > > What you called Docs, we have called transactions > What you called Aclines, we called transac_lines > > In order to have a multi-currency accounting, you have to add the > following tables > > currencies (with name, shortname and country) > currency_rates (date, rate, currency_rates_source), with all rates > stored against the Euro. Using the Euro as a based currency is a trick > to work internally and not visible to the user > currency_rates_source: which is a way to have more than one source of > data for foreign exchange > > In addition in Acline has 2 extra colums to reflect the fact that a > transaction can be in a currency (transaction currency) which can be > different from the currency of accounting for the company (functional > currency or reporting currency). > > so you have for acline > > [date] [account number linked to account table] [decimal value in > transaction currency] [currency linked to the currency table] [decimal > value in functional currency, converted decimal value using the fxrate > from the table] > [transaction id linked to transactions] > > so our test is that the sum of decimal value in functional currency is > equal to zero to be able to validate. > > That is a brief introduction, but we can do more but that would be a > good start. From that basic model you can do anything in accounting, > you just need to add info to accline or what I call transaction_lines. > > One question for Massimo. Let's say I want to have a different table > for each client, is it possible to create dynamic table? I don't know > whether it is clear. > > Say for example, depending on the client, can we load a different sets > of tables? Please let me know if you want clarification. > > Thanks, > > Francois > > On Dec 17, 6:21 pm, villas <villa...@gmail.com> wrote: > > > HiFrancois > > > I am currently writing some software for our copmany accounts. The > > only problem is that it will be fairly specific to our requirements, > > not to mention very simple. > > > To give you an idea. > > > We have 3 tables. Docs, Accounts, Aclines. > > We start by entering a new document in the Docs table. > > We then enter related debits and credits for the Doc in the Aclines > > table. > > Each row in the Aclines table has a related Account number. > > Once the entries balance, they are 'approved' and then cannot be > > altered (except by superuser). > > > Listings can then be made by Doc and by Account. All physical > > paperwork is filed/scanned by Doc id and be easily retrieved when > > necessary. > > > I think this idea would be far too simple for anyone else's accounts. > > However, if you give me some idea of your project perhaps some > > elements would overlap, especially for data entry. > > > I see a role for Massimo's spreadsheet for reporting or modelling > > budgets etc. > > > Regards, > > -David > > > On Dec 17, 7:31 am, "Francois(Jersey)" > > > <francois.ches...@googlemail.com> wrote: > > > Is anyone wanting to join forces to create a MIT/GPL accounting > > > software? > > > > I spent a year writing specification for a multi currencies accounting > > > software and would love to share with other people. We have a nice > > > interface for entering > > > transactions:http://olivvv.aptanacloud.com/compta/index.html > > > >Francois > > > > On Dec 8, 1:22 am, villas <villa...@gmail.com> wrote: > > > > > Yes, it was just a thought. > > > > Now we have a decimal field I'm trying out someaccountingideas. > > > > Thanks.- Hide quoted text - > > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
