On Sat, Jun 23, 2001 at 11:58:52AM +0100, Mark Tiramani wrote:
> > but I cannot find the customertax vendortax and partstax tables
> > How is this done? With some sql statements?
>
> The customertax etc. are new database tables that are required to support the multiple tax accounts available in 1.4.
> You must add the items to the new tables by hand. If you currently only need one level of tax for all your
> services/products and clients then I believe you only need to populate the customertax table by hand.
>
> First, back-up your sql-ledger postgres database.
Hmm, how do I do that? I have no good knowledge of psql organization.
WHat I did was to "cp" /var/lib/pgsql/data/base/db1 to var/lib/pgsql/data/base/db2
Is that enough?
> Assuming you have already run the script 'update.sql' in the sql directory of the 1.4.x distribution against your sql-
> ledger database, here is an example for simple GST/VAT:
>
> look at the 'tax' table of your sql-ledger database and get the value from the 'chart_id' column for your main GST tax.
How do I look? Ins
psql db2
then what?
> look at the 'customer' table and get the first relevant value from the 'id' column.
> enter this customer 'id' value into the 'customer_id' column of the new 'customertax' table.
> enter the 'chart_id' from the 'tax' table into the 'chart_id' column of the same row of the new 'customertax' table.
>
> repeat the above for every customer to which this tax rate applies.
>
> In sql-ledger go to the 'Edit Customer' screen for each customer to which you supply a taxable service/part and
> check the checkbox labled 'Taxable _ GST'.
>
> In sql-ledger go to each service/part you supply and check the checkbox at the bottom of the 'Edit Service' screen
> that is labled something like '2310-GST'.
I get the error
ERROR: Relation 'tax' does not exist SELECT chart_id FROM tax WHERE chart_id = 10004
very early in the process, when editing the tax account.
> > And why is this necessary? I think one should be very careful
> > with doing changes to the database of an existing account
> > database - it could potentuallty hurt your accounts.
>
> If you do the updates as described you should have no problems. However, it is of course advisable to back-up your
> sql-ledger database before doing the update.
Thanks for the help!
But I see some general problems in this kind of upgrade.
You need to have good knowledge of sql, and psql, and then
do quite some work in the hand. I don't understand why this could
not be a perl script, where you enter the tax account numbers in
a form, and then it does all of this for you. And then it could
also run the update.pl script on demand.
On the other hand, I am amzed that it can be done.
That is, it is possible to change the underlying data structure
of the db in a well,defined way. The Tax stuff is some add ons.
Some of the critics here say that the architecture of SL is too simple,
and that you cannot then build on SL. But with what is now demonstrated,
another strategy, using SL now, and then make an upgrade when/if a better
data model becomes available.
An upgrade like this just has to be better supported, eg by having
some programs directly available from the web user interface.
If not, then SL is an accounting system for programmers only.
Dieter, what do you think? Could the next database update be
fully supported by a web interface? Or are there problems in this?
Could be done as a special page from the admin page.
(are there checks in the database for which version it is?
The version could stored in a table.)
Keld
|
