web-erp-developers — Discussion on development of webERP

Re: [Web-erp-developers] TAX / VAT

[Danie B. <br...@na...>]

No not at this stage only one tax per item at this stage almost exactly like it
works now except in reverse with refferencial integrity. I.e StockMaster does
not specify the level but select a level from the list, In this case I have
changed Level to Tax Category. I would like to specify multiple taxes later but
that would constitute to much of a drastic change.

However when capturing GL type receipts and payments a tax authority must be
selected and the different Taxes will be selectable on a line by line basis.
I.E. You can use WebErp even if you just want to use it for plain accounting.

In regards to other add-ons happening. Manufacturing and Job Costing as well as
work orders, Addition of two more stock types, Personel Resource and Asset
Resource. It will later be linked to Personel and Assets. This will allow us to
create a work order based on a BOM and then allow us to substitute, add or
delete items in order to complete a job and get acurate costing. Resources will
never be shown on an invoice. The invoices will get an optional weight column
with weight total. We also have to complete the manuals.

Also I need to develop a way to specify positioning for addresses, items on
preprinted invoices. Any sugestions here would also be appreciated.

Also we thought of adding an StockGroupID into the stock master allowing a group
of stock items to be handled as the same stock item on an invoice. A sales
priority will probably also be required to specify wich true stock items should
be sold first. Your thoughts will be apreciated.

These changes will satify two customers/erp prospects at this point. One is a
manufacturer the other is a Shipping supplier. ( Two more using just the GUI
framework for now Beuty Parlors and Fitness Centers )

We know we are taking a big bite here, however we want to be ready with this
product and a GUI version by june next year. The Framework for the GUI is
nearly complete Reports are very profesional includes page edge recognition and
table wraping. We are going to a Trade Show promoting WebERP and GUI cost
probably arround R60000 +- $10000. as it is I/We are woking like crasy. Doing
anything and everything to get the money together. Have to register by Feb Next
Year.

I will be giving away a lot of my old products such as stock exchange software
and sms messaging software etc. as a drawing card.

Kind Regards and I hope this does not offend you.

Danie Brink

Quoting Daintrees <p.d...@pa...>:

> 
> Tax can get hairy.
> 
> The changes you are proposing Danie does it mean that each line item can
> have more than one kind of tax associated with it as per Open-Accounting?
> 
> Will the tax category be another field in Stocks - perhaps replacing tax
> level.
> 
> I have not been through your earlier email so I am probably asking silly
> questions I'll go back and read up.
> 
> Phil
> 
> ----- Original Message ----- 
> From: "Danie Brink" <br...@na...>
> To: <web...@li...>
> Sent: Wednesday, August 04, 2004 11:40 AM
> Subject: Re: [Web-erp-developers] TAX / VAT
> 
> 
> > Ok I will explain how it will be set up using my example.
> >
> > We set up two tax categories FoodBooks and Other using lowest worst tax
> breakout
> > i.e. in germany you have 2 and in Say South Africa you have one. Notice
> that
> > you ignore the 0% as it is always available.
> >
> > Now you create two tax authorities Germany and South Africa.
> > Then we add Taxes for Authorities
> > Germany with LowVAT @ 7% GLAcc = XX1 and HighVAT @ 16 % GLAcc = XX2
> > South Africa with OneVat @ 14% GLAcc = XX3
> > **Note that these are the Names not the Inv Display Lable
> >
> > Now we assosiate categories with Authorities and Rates and
> >
> > Germany - FoodBooks = LowVat, Other = HighVat
> > South Africa - FoodBooks = OneVat, Other = One Vat
> >
> > It is slightly more complicated because there are two tax authorities in
> play
> > per record Receiving And Dispatching but it serves to demonstrate the
> point
> >
> > Selecting On the StockItem for "Core PHP Programing" TaxCategory =
> FoodBooks and
> > "100x 4 inch nails" TaxCategory = Other
> >
> > On invoice/Order the Sales Location becomes Dispatch and the Customer
> becomes
> > receiving thefore resolving with assosiation gives applicable taxes and
> GLAcc
> > Destinations for those taxes. The Taxes gives the display lables to apear
> on
> > the invoice.
> >
> > Note that the previous system also queried an assosiation table so about
> the
> > only difference is that we join three tables ( Stock, Assosiation, Taxes)
> as
> > the two required tax authorities are already selected and supplied through
> > location and customer. I do not think the over head of adding an extra
> table
> > into the query will be that significant as the taxes table is realy small
> and
> > Assosiation is very specific when StockTaxCategory=AssosiationTaxCategory.
> >
> > I hope this helps or is in line with what you explain.
> > You can query your GLAcc to find out exactly how many taxes were
> accumulated (
> > in, out or combined) as you please.
> >
> > **Note that setting a tax category to None=0 the tax is assumed to be 0
> and
> > there will be no GLAcc entries for 0% of anything.
> >
> > Now The Questions
> >
> > How much did I spent for goods from outside EuropeanUnion (native 0% VAT)
> ?
> >  * the answer lies in the purchased amount of items of this stock type as
> it is
> > known that it is external, therefore sales / purchaces of this item may be
> > posted to that GL account using the Stock Categories not the Tax
> Categories of
> > cause the amounts in the GL acount will exclude the vat amounts therefore
> it
> > could be included using the transaction ID.
> >
> > How much VAT did I pay at the customs for these goods? (not food or books
> 16%)
> >  * this problem may be solved by adding two more tax categories one set
> for
> > native and the other for non native using seperate GLAcc's you ignore the
> 0% as
> > the 16% for non native GLAcc will in fact be import duties. Once again the
> > stock item itself knows if it is natively aquired.
> >
> > How much did I spent for goods (bought at companies) from inside EU (0%
> VAT)
> >   * Determined by using Stock Categories not the Tax Categories quiry
> respective
> > GL Account.
> >
> > How much did I spend for goods from private German sellers (0% VAT)
> >   * Same solution as previous.
> >
> > How much did I spent for goods (bought at German companies) (16% VAT)
> >   * This one is slightly more tricky as you would like to exclude
> purchases of
> > 7% and 0% the solution here is to seperate items with different
> TaxCategories
> > into different StockCategories as well.
> >
> > It is probably better to introduce something like a taxcenter where a
> stock item
> > may be assigned a tax center either directly of through a tax category
> this
> > will leave the Stock Categories out of the equation.
> >
> > I hope all of this makes sence.
> >
> > Kind Regards
> > Danie Brink
> >
> > Quoting Dirk Eversmann <dir...@gr...>:
> >
> > > Thank you for your great response!
> > >
> > > @Dick Stins:
> > > "In the taxlevel you can enter the GL accountnumber per level.
> > > For your turnover, you can enter per item an accountnumer. So you can
> setup
> > > turnover 0%, turnover 7%, turnover ... GL accounts."
> > >
> > > Yes, but it does not really help :-(
> > >
> > > @Danie:
> > > "Could you send me a more thorough description as I am in the process of
> > > customizing the Taxes to work more modular so I might as well look at
> your
> > > requirement and try to incorporate it."
> > >
> > > I will try again to make it clear:
> > > I have to report in detail the VAT every month. VAT is the difference of
> > > Tax I have payed while purchasing goods and the Tax I collected while
> > > selling goods.
> > > Cases:
> > > I buy standard-goods (16%VAT) from a German distributor for EUR 116
> > > GL-Costs16%=EUR 100 / GL-VAT-paid-16%=EUR 16
> > >
> > > I sell standard-goods (16%VAT) to a German customer for EUR 174
> > > GL-Turnover16%=EUR 150 / GL-VAT-received-16%=EUR 24
> > >
> > > So I added EUR 50 value to the goods and have to pay EUR 16 VAT
> > >
> > > (food and books have 7%)
> > >
> > > No problem so far. The detailed report is the thing. My tax authority
> wants
> > > to know:
> > > How much did I spent for goods from outside EuropeanUnion (native 0%
> VAT)
> > > How much VAT did I pay at the customs for these goods? (since I do not
> sell
> > > food or books 16%)
> > >
> > > How much did I spent for goods (bought at companies) from inside EU (0%
> VAT)
> > >
> > > How much did I spend for goods from private German sellers (0% VAT)
> > > How much did I spent for goods (bought at German companies) (16% VAT)
> > >
> > > And a few more cases may apply.... Basicly same thing for selling
> > > goods......
> > >
> > > Problems with webERP arise in this situation:
> > > I pay with Mastercard (creditor) a bill of a US-company (0%VAT) and a
> bill
> > > of a German-company (16%VAT)
> > > I should have
> > > 1 liability
> > > 1 GL-cost-16%
> > > 1 GL-cost-0%
> > > 1 GL-paid-VAT-16%
> > > entry
> > >
> > > My workaround is setting up 2 Mastercard creditors: one with 16%VAT and
> one
> > > with 0% VAT. This leads of course into two liabilities....
> > >
> > > Hope, I made my problems clear.
> > >
> > > Have a nice day, Dirk
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> > > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> > > one more big change to announce. We are now OSTG- Open Source Technology
> > > Group. Come see the changes on the new OSTG site. www.ostg.com
> > > _______________________________________________
> > > Web-erp-developers mailing list
> > > Web...@li...
> > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> > one more big change to announce. We are now OSTG- Open Source Technology
> > Group. Come see the changes on the new OSTG site. www.ostg.com
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 

Re: [Web-erp-developers] Access (hot) Keys

[skaill <sk...@ro...>]

In the access key information it talks about using the alt or meta key.  I
don't know what a meta key is but maybe someone else does and it will
work...

----- Original Message ----- 
From: "Phil Daintree" <p.d...@pa...>
To: <web...@li...>
Sent: Wednesday, August 04, 2004 3:56 AM
Subject: Re: [Web-erp-developers] Access (hot) Keys


> It works ok on Firefox and goes right into the page but not with
> Konqueror - ALT+S brings up the settings menu of Konqueror and the other
> keys just dont have any impact at all.
>
> Phil
>
> On Tue, 2004-08-03 at 23:08, skaill wrote:
> > That's another reason I hope some others will try their browsers to
> > make sure with the hot keys that everything is good.  I only currently
> > can test in Windows browsers.
> >
> > Steve
> >         ----- Original Message ----- 
> >         From: Daintrees
> >         To: web...@li...
> >         Sent: Tuesday, August 03, 2004 4:09 PM
> >         Subject: Re: [Web-erp-developers] Access (hot) Keys
> >
> >         So long as other browsers dont choke on it these still have
> >         the old point and click option.
> >                 ----- Original Message ----- 
> >                 From: skaill
> >                 To: web...@li...
> >                 Sent: Wednesday, August 04, 2004 6:08 AM
> >                 Subject: [Web-erp-developers] Access (hot) Keys
> >
> >                 I built in some hotkeys for the top options including
> >                 Menu, Select Customer, Select Item and Select
> >                 Supplier.  They are accessed by alt-m, alt-c, alt-i
> >                 and alt-s.  However, they only work half of the
> >                 browsers which includes Mozilla so far.
> >
> >                 I'd be interested in hearing what other browsers
> >                 support these hotkeys at http://weberp.gocom.ca.
> >
> >                 Phil, what do you think about this hotkey
> >                 functionality?
> >
> >                 Steve
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [Web-erp-developers] IRC Chat Room

[Peter <use...@gm...>]

I'm cool with either one.

~Peter


----- Original Message -----
From: Rajnesh D. Singh <ra...@pa...>
Date: Wed, 4 Aug 2004 12:17:23 +1200
Subject: RE: [Web-erp-developers] IRC Chat Room
To: web...@li...

 

Good idea. 

  

We use freenode for #picisoc (Internet Society local chapter).

 
 
 
-----Original Message-----
From: web...@li...
[mailto:web...@li...] On Behalf Of
Chris Bice
Sent: Wednesday, 4 August 2004 3:31 AM
To: web...@li...
Subject: [Web-erp-developers] IRC Chat Room

 
 

Would anyone be opposed to using IRC, for realtime chat options.  I
know freenode.net hosts all of the #mysql, #php and many other great
open source project channels.  I will open a #weberp channel on
irc.freenode.net.  I will have my computer logged into it pretty much
all the time.

  

Chris

Re: [Web-erp-developers] Access (hot) Keys

[Phil D. <p.d...@pa...>]

It works ok on Firefox and goes right into the page but not with
Konqueror - ALT+S brings up the settings menu of Konqueror and the other
keys just dont have any impact at all.

Phil

On Tue, 2004-08-03 at 23:08, skaill wrote:
> That's another reason I hope some others will try their browsers to
> make sure with the hot keys that everything is good.  I only currently
> can test in Windows browsers.
>  
> Steve
>         ----- Original Message ----- 
>         From: Daintrees
>         To: web...@li...
>         Sent: Tuesday, August 03, 2004 4:09 PM
>         Subject: Re: [Web-erp-developers] Access (hot) Keys
>         
>         So long as other browsers dont choke on it these still have
>         the old point and click option.
>                 ----- Original Message ----- 
>                 From: skaill
>                 To: web...@li...
>                 Sent: Wednesday, August 04, 2004 6:08 AM
>                 Subject: [Web-erp-developers] Access (hot) Keys
>                 
>                 I built in some hotkeys for the top options including
>                 Menu, Select Customer, Select Item and Select
>                 Supplier.  They are accessed by alt-m, alt-c, alt-i
>                 and alt-s.  However, they only work half of the
>                 browsers which includes Mozilla so far.  
>                  
>                 I'd be interested in hearing what other browsers
>                 support these hotkeys at http://weberp.gocom.ca.
>                  
>                 Phil, what do you think about this hotkey
>                 functionality?
>                  
>                 Steve

Re: [Web-erp-developers] Developing new features.

[Phil D. <p.d...@pa...>]

Nice words are desperately needed at the minute ... thanks!

Phil

On Tue, 2004-08-03 at 14:05, Peter wrote:
> Our company (http://vincisystems.com) is considering using web-erp. It
> is by far the most complete open-source system that we have found.
> 
> As it is lacking several features that are critical for us, I will be
> developing and adding new features to web-erp (don't worry, I'm
> keeping track of my changes so that it can be incorporated into next
> release if you so desire)
> 
> My knowledge of PHP/MySQL is sufficient but I am still learning. I
> will probably be frequenting these lists for help.
> 
> I just wanted to stop by and say "Keep up the great work guys!"
> 
> ~Peter
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 

Re: [Web-erp-developers] TAX / VAT

[Daintrees <p.d...@pa...>]

Tax can get hairy.

The changes you are proposing Danie does it mean that each line item can
have more than one kind of tax associated with it as per Open-Accounting?

Will the tax category be another field in Stocks - perhaps replacing tax
level.

I have not been through your earlier email so I am probably asking silly
questions I'll go back and read up.

Phil

----- Original Message ----- 
From: "Danie Brink" <br...@na...>
To: <web...@li...>
Sent: Wednesday, August 04, 2004 11:40 AM
Subject: Re: [Web-erp-developers] TAX / VAT


> Ok I will explain how it will be set up using my example.
>
> We set up two tax categories FoodBooks and Other using lowest worst tax
breakout
> i.e. in germany you have 2 and in Say South Africa you have one. Notice
that
> you ignore the 0% as it is always available.
>
> Now you create two tax authorities Germany and South Africa.
> Then we add Taxes for Authorities
> Germany with LowVAT @ 7% GLAcc = XX1 and HighVAT @ 16 % GLAcc = XX2
> South Africa with OneVat @ 14% GLAcc = XX3
> **Note that these are the Names not the Inv Display Lable
>
> Now we assosiate categories with Authorities and Rates and
>
> Germany - FoodBooks = LowVat, Other = HighVat
> South Africa - FoodBooks = OneVat, Other = One Vat
>
> It is slightly more complicated because there are two tax authorities in
play
> per record Receiving And Dispatching but it serves to demonstrate the
point
>
> Selecting On the StockItem for "Core PHP Programing" TaxCategory =
FoodBooks and
> "100x 4 inch nails" TaxCategory = Other
>
> On invoice/Order the Sales Location becomes Dispatch and the Customer
becomes
> receiving thefore resolving with assosiation gives applicable taxes and
GLAcc
> Destinations for those taxes. The Taxes gives the display lables to apear
on
> the invoice.
>
> Note that the previous system also queried an assosiation table so about
the
> only difference is that we join three tables ( Stock, Assosiation, Taxes)
as
> the two required tax authorities are already selected and supplied through
> location and customer. I do not think the over head of adding an extra
table
> into the query will be that significant as the taxes table is realy small
and
> Assosiation is very specific when StockTaxCategory=AssosiationTaxCategory.
>
> I hope this helps or is in line with what you explain.
> You can query your GLAcc to find out exactly how many taxes were
accumulated (
> in, out or combined) as you please.
>
> **Note that setting a tax category to None=0 the tax is assumed to be 0
and
> there will be no GLAcc entries for 0% of anything.
>
> Now The Questions
>
> How much did I spent for goods from outside EuropeanUnion (native 0% VAT)
?
>  * the answer lies in the purchased amount of items of this stock type as
it is
> known that it is external, therefore sales / purchaces of this item may be
> posted to that GL account using the Stock Categories not the Tax
Categories of
> cause the amounts in the GL acount will exclude the vat amounts therefore
it
> could be included using the transaction ID.
>
> How much VAT did I pay at the customs for these goods? (not food or books
16%)
>  * this problem may be solved by adding two more tax categories one set
for
> native and the other for non native using seperate GLAcc's you ignore the
0% as
> the 16% for non native GLAcc will in fact be import duties. Once again the
> stock item itself knows if it is natively aquired.
>
> How much did I spent for goods (bought at companies) from inside EU (0%
VAT)
>   * Determined by using Stock Categories not the Tax Categories quiry
respective
> GL Account.
>
> How much did I spend for goods from private German sellers (0% VAT)
>   * Same solution as previous.
>
> How much did I spent for goods (bought at German companies) (16% VAT)
>   * This one is slightly more tricky as you would like to exclude
purchases of
> 7% and 0% the solution here is to seperate items with different
TaxCategories
> into different StockCategories as well.
>
> It is probably better to introduce something like a taxcenter where a
stock item
> may be assigned a tax center either directly of through a tax category
this
> will leave the Stock Categories out of the equation.
>
> I hope all of this makes sence.
>
> Kind Regards
> Danie Brink
>
> Quoting Dirk Eversmann <dir...@gr...>:
>
> > Thank you for your great response!
> >
> > @Dick Stins:
> > "In the taxlevel you can enter the GL accountnumber per level.
> > For your turnover, you can enter per item an accountnumer. So you can
setup
> > turnover 0%, turnover 7%, turnover ... GL accounts."
> >
> > Yes, but it does not really help :-(
> >
> > @Danie:
> > "Could you send me a more thorough description as I am in the process of
> > customizing the Taxes to work more modular so I might as well look at
your
> > requirement and try to incorporate it."
> >
> > I will try again to make it clear:
> > I have to report in detail the VAT every month. VAT is the difference of
> > Tax I have payed while purchasing goods and the Tax I collected while
> > selling goods.
> > Cases:
> > I buy standard-goods (16%VAT) from a German distributor for EUR 116
> > GL-Costs16%=EUR 100 / GL-VAT-paid-16%=EUR 16
> >
> > I sell standard-goods (16%VAT) to a German customer for EUR 174
> > GL-Turnover16%=EUR 150 / GL-VAT-received-16%=EUR 24
> >
> > So I added EUR 50 value to the goods and have to pay EUR 16 VAT
> >
> > (food and books have 7%)
> >
> > No problem so far. The detailed report is the thing. My tax authority
wants
> > to know:
> > How much did I spent for goods from outside EuropeanUnion (native 0%
VAT)
> > How much VAT did I pay at the customs for these goods? (since I do not
sell
> > food or books 16%)
> >
> > How much did I spent for goods (bought at companies) from inside EU (0%
VAT)
> >
> > How much did I spend for goods from private German sellers (0% VAT)
> > How much did I spent for goods (bought at German companies) (16% VAT)
> >
> > And a few more cases may apply.... Basicly same thing for selling
> > goods......
> >
> > Problems with webERP arise in this situation:
> > I pay with Mastercard (creditor) a bill of a US-company (0%VAT) and a
bill
> > of a German-company (16%VAT)
> > I should have
> > 1 liability
> > 1 GL-cost-16%
> > 1 GL-cost-0%
> > 1 GL-paid-VAT-16%
> > entry
> >
> > My workaround is setting up 2 Mastercard creditors: one with 16%VAT and
one
> > with 0% VAT. This leads of course into two liabilities....
> >
> > Hope, I made my problems clear.
> >
> > Have a nice day, Dirk
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> > one more big change to announce. We are now OSTG- Open Source Technology
> > Group. Come see the changes on the new OSTG site. www.ostg.com
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

RE: [Web-erp-developers] IRC Chat Room

[Rajnesh D. S. <ra...@pa...>]

Good idea.
 
We use freenode for #picisoc (Internet Society local chapter).
-----Original Message-----
From: web...@li...
[mailto:web...@li...] On Behalf Of
Chris Bice
Sent: Wednesday, 4 August 2004 3:31 AM
To: web...@li...
Subject: [Web-erp-developers] IRC Chat Room


Would anyone be opposed to using IRC, for realtime chat options.  I know
freenode.net hosts all of the #mysql, #php and many other great open
source project channels.  I will open a #weberp channel on
irc.freenode.net.  I will have my computer logged into it pretty much
all the time.
 
Chris 

Re: [Web-erp-developers] TAX / VAT

[Danie B. <br...@na...>]

Ok I will explain how it will be set up using my example.

We set up two tax categories FoodBooks and Other using lowest worst tax breakout
i.e. in germany you have 2 and in Say South Africa you have one. Notice that
you ignore the 0% as it is always available.

Now you create two tax authorities Germany and South Africa.
Then we add Taxes for Authorities
Germany with LowVAT @ 7% GLAcc = XX1 and HighVAT @ 16 % GLAcc = XX2
South Africa with OneVat @ 14% GLAcc = XX3
**Note that these are the Names not the Inv Display Lable  

Now we assosiate categories with Authorities and Rates and 

Germany - FoodBooks = LowVat, Other = HighVat
South Africa - FoodBooks = OneVat, Other = One Vat

It is slightly more complicated because there are two tax authorities in play
per record Receiving And Dispatching but it serves to demonstrate the point

Selecting On the StockItem for "Core PHP Programing" TaxCategory = FoodBooks and
"100x 4 inch nails" TaxCategory = Other

On invoice/Order the Sales Location becomes Dispatch and the Customer becomes
receiving thefore resolving with assosiation gives applicable taxes and GLAcc
Destinations for those taxes. The Taxes gives the display lables to apear on
the invoice.

Note that the previous system also queried an assosiation table so about the
only difference is that we join three tables ( Stock, Assosiation, Taxes) as
the two required tax authorities are already selected and supplied through
location and customer. I do not think the over head of adding an extra table
into the query will be that significant as the taxes table is realy small and
Assosiation is very specific when StockTaxCategory=AssosiationTaxCategory.

I hope this helps or is in line with what you explain.
You can query your GLAcc to find out exactly how many taxes were accumulated (
in, out or combined) as you please.

**Note that setting a tax category to None=0 the tax is assumed to be 0 and
there will be no GLAcc entries for 0% of anything.

Now The Questions

How much did I spent for goods from outside EuropeanUnion (native 0% VAT) ?
 * the answer lies in the purchased amount of items of this stock type as it is
known that it is external, therefore sales / purchaces of this item may be
posted to that GL account using the Stock Categories not the Tax Categories of
cause the amounts in the GL acount will exclude the vat amounts therefore it
could be included using the transaction ID.

How much VAT did I pay at the customs for these goods? (not food or books 16%)
 * this problem may be solved by adding two more tax categories one set for
native and the other for non native using seperate GLAcc's you ignore the 0% as
the 16% for non native GLAcc will in fact be import duties. Once again the
stock item itself knows if it is natively aquired.

How much did I spent for goods (bought at companies) from inside EU (0% VAT)
  * Determined by using Stock Categories not the Tax Categories quiry respective
GL Account.

How much did I spend for goods from private German sellers (0% VAT)
  * Same solution as previous.

How much did I spent for goods (bought at German companies) (16% VAT)
  * This one is slightly more tricky as you would like to exclude purchases of
7% and 0% the solution here is to seperate items with different TaxCategories
into different StockCategories as well.

It is probably better to introduce something like a taxcenter where a stock item
may be assigned a tax center either directly of through a tax category this
will leave the Stock Categories out of the equation.

I hope all of this makes sence.

Kind Regards
Danie Brink

Quoting Dirk Eversmann <dir...@gr...>:

> Thank you for your great response!
> 
> @Dick Stins:
> "In the taxlevel you can enter the GL accountnumber per level.
> For your turnover, you can enter per item an accountnumer. So you can setup
> turnover 0%, turnover 7%, turnover ... GL accounts."
> 
> Yes, but it does not really help :-(
> 
> @Danie:
> "Could you send me a more thorough description as I am in the process of
> customizing the Taxes to work more modular so I might as well look at your
> requirement and try to incorporate it."
> 
> I will try again to make it clear:
> I have to report in detail the VAT every month. VAT is the difference of 
> Tax I have payed while purchasing goods and the Tax I collected while 
> selling goods.
> Cases:
> I buy standard-goods (16%VAT) from a German distributor for EUR 116
> GL-Costs16%=EUR 100 / GL-VAT-paid-16%=EUR 16
> 
> I sell standard-goods (16%VAT) to a German customer for EUR 174
> GL-Turnover16%=EUR 150 / GL-VAT-received-16%=EUR 24
> 
> So I added EUR 50 value to the goods and have to pay EUR 16 VAT
> 
> (food and books have 7%)
> 
> No problem so far. The detailed report is the thing. My tax authority wants 
> to know:
> How much did I spent for goods from outside EuropeanUnion (native 0% VAT)
> How much VAT did I pay at the customs for these goods? (since I do not sell 
> food or books 16%)
> 
> How much did I spent for goods (bought at companies) from inside EU (0% VAT)
> 
> How much did I spend for goods from private German sellers (0% VAT)
> How much did I spent for goods (bought at German companies) (16% VAT)
> 
> And a few more cases may apply.... Basicly same thing for selling
> goods......
> 
> Problems with webERP arise in this situation:
> I pay with Mastercard (creditor) a bill of a US-company (0%VAT) and a bill 
> of a German-company (16%VAT)
> I should have
> 1 liability
> 1 GL-cost-16%
> 1 GL-cost-0%
> 1 GL-paid-VAT-16%
> entry
> 
> My workaround is setting up 2 Mastercard creditors: one with 16%VAT and one 
> with 0% VAT. This leads of course into two liabilities....
> 
> Hope, I made my problems clear.
> 
> Have a nice day, Dirk
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 

Re: [Web-erp-developers] Access (hot) Keys

[skaill <sk...@ro...>]

That's another reason I hope some others will try their browsers to make =
sure with the hot keys that everything is good.  I only currently can =
test in Windows browsers.

Steve
  ----- Original Message -----=20
  From: Daintrees=20
  To: web...@li...=20
  Sent: Tuesday, August 03, 2004 4:09 PM
  Subject: Re: [Web-erp-developers] Access (hot) Keys


  So long as other browsers dont choke on it these still have the old =
point and click option.
    ----- Original Message -----=20
    From: skaill=20
    To: web...@li...=20
    Sent: Wednesday, August 04, 2004 6:08 AM
    Subject: [Web-erp-developers] Access (hot) Keys


    I built in some hotkeys for the top options including Menu, Select =
Customer, Select Item and Select Supplier.  They are accessed by alt-m, =
alt-c, alt-i and alt-s.  However, they only work half of the browsers =
which includes Mozilla so far. =20

    I'd be interested in hearing what other browsers support these =
hotkeys at http://weberp.gocom.ca.

    Phil, what do you think about this hotkey functionality?

    Steve

[Web-erp-developers] Spanish/Portugese Translation

[Phil D. <ph...@du...>]

Rom,

Thanks for your note ...

There is work afoot to make it easier to translate the system such that when
changes are implemented the translation work will not need to be re-done.
However, this is some way away. An Italian chap is starting work on this but
we are discussing the best way to proceed. If you join the
web-erp-developers list you can contribute to the discussions.

Regards

Phil Daintree

Re: [Web-erp-developers] Access (hot) Keys

[Daintrees <p.d...@pa...>]

So long as other browsers dont choke on it these still have the old =
point and click option.
  ----- Original Message -----=20
  From: skaill=20
  To: web...@li...=20
  Sent: Wednesday, August 04, 2004 6:08 AM
  Subject: [Web-erp-developers] Access (hot) Keys


  I built in some hotkeys for the top options including Menu, Select =
Customer, Select Item and Select Supplier.  They are accessed by alt-m, =
alt-c, alt-i and alt-s.  However, they only work half of the browsers =
which includes Mozilla so far. =20

  I'd be interested in hearing what other browsers support these hotkeys =
at http://weberp.gocom.ca.

  Phil, what do you think about this hotkey functionality?

  Steve

[Web-erp-developers] Fw: Access (hot) Keys

[skaill <sk...@ro...>]

Actually IE works too but you have to press enter after hotkey.  Hotkey =
just focuses.

----- Original Message -----=20
From: skaill=20
To: web...@li...=20
Sent: Tuesday, August 03, 2004 2:08 PM
Subject: Access (hot) Keys


I built in some hotkeys for the top options including Menu, Select =
Customer, Select Item and Select Supplier.  They are accessed by alt-m, =
alt-c, alt-i and alt-s.  However, they only work half of the browsers =
which includes Mozilla so far. =20

I'd be interested in hearing what other browsers support these hotkeys =
at http://weberp.gocom.ca.

Phil, what do you think about this hotkey functionality?

Steve

[Web-erp-developers] Access (hot) Keys

[skaill <sk...@ro...>]

I built in some hotkeys for the top options including Menu, Select =
Customer, Select Item and Select Supplier.  They are accessed by alt-m, =
alt-c, alt-i and alt-s.  However, they only work half of the browsers =
which includes Mozilla so far. =20

I'd be interested in hearing what other browsers support these hotkeys =
at http://weberp.gocom.ca.

Phil, what do you think about this hotkey functionality?

Steve

Re: [Web-erp-developers] IRC Chat Room

[skaill <sk...@ro...>]

Don't know about everyone else but I don't keep my irc on anymore.  I =
think partly because of Messengers.  I know it has a place but not sure =
if there will be enough traffic such that people will go there thinking =
someone will be on.  Lots is good in forums too so it helps others.

Personally, think I'd rather share Messenger(s) ids.

That's just my take though.

Steve=20
  ----- Original Message -----=20
  From: Chris Bice=20
  To: web...@li...=20
  Sent: Tuesday, August 03, 2004 11:31 AM
  Subject: [Web-erp-developers] IRC Chat Room


  Would anyone be opposed to using IRC, for realtime chat options.  I =
know freenode.net hosts all of the #mysql, #php and many other great =
open source project channels.  I will open a #weberp channel on =
irc.freenode.net.  I will have my computer logged into it pretty much =
all the time.

  =20

  Chris=20

[Web-erp-developers] IRC Chat Room

[Chris B. <cb...@en...>]

Would anyone be opposed to using IRC, for realtime chat options.  I know
freenode.net hosts all of the #mysql, #php and many other great open
source project channels.  I will open a #weberp channel on
irc.freenode.net.  I will have my computer logged into it pretty much
all the time.
 
Chris 

[Web-erp-developers] Developing new features.

[Peter <use...@gm...>]

Our company (http://vincisystems.com) is considering using web-erp. It
is by far the most complete open-source system that we have found.

As it is lacking several features that are critical for us, I will be
developing and adding new features to web-erp (don't worry, I'm
keeping track of my changes so that it can be incorporated into next
release if you so desire)

My knowledge of PHP/MySQL is sufficient but I am still learning. I
will probably be frequenting these lists for help.

I just wanted to stop by and say "Keep up the great work guys!"

~Peter

[Web-erp-developers] TAX / VAT

[Dirk E. <dir...@gr...>]

Thank you for your great response!

@Dick Stins:
"In the taxlevel you can enter the GL accountnumber per level.
For your turnover, you can enter per item an accountnumer. So you can setup
turnover 0%, turnover 7%, turnover ... GL accounts."

Yes, but it does not really help :-(

@Danie:
"Could you send me a more thorough description as I am in the process of
customizing the Taxes to work more modular so I might as well look at your
requirement and try to incorporate it."

I will try again to make it clear:
I have to report in detail the VAT every month. VAT is the difference of 
Tax I have payed while purchasing goods and the Tax I collected while 
selling goods.
Cases:
I buy standard-goods (16%VAT) from a German distributor for EUR 116
GL-Costs16%=EUR 100 / GL-VAT-paid-16%=EUR 16

I sell standard-goods (16%VAT) to a German customer for EUR 174
GL-Turnover16%=EUR 150 / GL-VAT-received-16%=EUR 24

So I added EUR 50 value to the goods and have to pay EUR 16 VAT

(food and books have 7%)

No problem so far. The detailed report is the thing. My tax authority wants 
to know:
How much did I spent for goods from outside EuropeanUnion (native 0% VAT)
How much VAT did I pay at the customs for these goods? (since I do not sell 
food or books 16%)

How much did I spent for goods (bought at companies) from inside EU (0% VAT)

How much did I spend for goods from private German sellers (0% VAT)
How much did I spent for goods (bought at German companies) (16% VAT)

And a few more cases may apply.... Basicly same thing for selling goods......

Problems with webERP arise in this situation:
I pay with Mastercard (creditor) a bill of a US-company (0%VAT) and a bill 
of a German-company (16%VAT)
I should have
1 liability
1 GL-cost-16%
1 GL-cost-0%
1 GL-paid-VAT-16%
entry

My workaround is setting up 2 Mastercard creditors: one with 16%VAT and one 
with 0% VAT. This leads of course into two liabilities....

Hope, I made my problems clear.

Have a nice day, Dirk

[Web-erp-developers] Re: Italian Translation of web-erp

[Phil D. <p.d...@pa...>]

Luca,

Hope you dont mind - I subscribed you to the developers list - you have
to confirm if you wish to receive email discussion of web-erp
development.

I re-read you first email and I didn't understand correctly first time
out - I like your approach. I also like the idea of retaining the full
english text in the code somehow. It does seem that those in the know
like this gettext function I have not read up on it myself but bow to
those with the knowledge. I also have great respect for Sherif Omar and
Hani Nguaeb (hope he'll forgive my spelling of his surname!) who forked
web-erp into Open Accounting the last time multi-language raised itself
- I didn't have the stomach for it at the time!! Gettext was the way
they went. 

You know the issues I have :

1. Readability and ease of understanding the code
2. Readability and ease of understanding the code
3. Readability and ease of understanding the code
4, 5  and 6. Efficiency of the code (minising DB calls/Web server
parsing)

If these issues are satisfied then lets GO!

Phil

On Mon, 2004-08-02 at 13:11, ing. Luca Tur=?ISO-8859-1?Q?lon_Don=E0?=
wrote:
> Hi Phil.
> I've been reading thru your mail several times before answering, cause  wanted 
> to be sure to understand every single issue ou pointed out.
> 
> The main consideration that comes out is that your approach is very similar to 
> mine, i.e.:
> -You are proposing a function call, I am proposing to use an array with a 
> literal index.
> -You are proposing several files with the translation, i am proposing several 
> groups of rows in a table.
> 
> Firts let me explain one thing: my idea consists in loading an array from the 
> db, i.e.: in the beginning of every page I make a bulk load of all the labels 
> in the language that has to be shown. So we do not have a full read cycle 
> (connect-query-parse the query, disconnect) on the db for every single label 
> in the page. We read everything at the beginning, load it in the lang array 
> and then use the lang array. This should address the second concern that you 
> put in your email. There is another thing: if we add a column on the db table, 
> containing the script (or an unique code which identifies the script) that is 
> going to be rendered we can achieve two more thing: first we can load just the 
> labels used in that script, reducing the size of the array. Secondly we will 
> have a documentation of what is shown in every page.
> 
> Regarding the other concern, i.e. the smallness of 30 chars for a label 
> identifier, I believe that i could enlarge that column to a wider string: i do 
> not see any problem on this.
> 
> The last thing you say, that is the code should be easy understandable. Maybe 
> you're right in considering the code easier to read having a full english 
> label, but I think that a label identifier with some comment could do the 
> same. In this way you could avoid the problem you mentioned about changes in 
> the english labels.
> 
> Please now let me tell some other things about the "function" approach:
> a) there is no other way than creating a php script to translate the 
> application. With the db approach I could create a page to let any kind of 
> user (not only a PHP programmer) manage the translation
> b) it can become tough managing any new version of the system: with the db you 
> can query and see how many entries you have for each language, and you can 
> easily identify which labels has to be translated. With the included file 
> approach you have to work on the files, hoping that every file is written with 
> exactly the same approach. 
> c) Since you must delegate people to translate (unless you know at least 15 
> languages) you can loose control on the code: what if a russian sends you an 
> email saying that the system not working, just because the russian translator 
> forgot a ";" in his code? With the db approach the worst thing that could 
> happen is a wrong translation or something written in English, but not 
> something that halts the system.
> d) With the db you have a sort of documentation, which can help in creating 
> help files...
> e) it is at any time possible to automatically generate any language script, 
> i.e a language/italiano.php can be generated from the db and we can switch to 
> your "function" approach. 
> f) ther is another thing regarding the usage of the entire english label as a 
> parameter: imagine if you forget to put the function call. With the label 
> identifier you immediately see that there is something difficult to read on 
> the page. With the full english label you may even not notice the error.
> 
> 
> Finally: I do believe that the language variable should be kept, in the 
> future, in the session of the user, having each user working with his/her own 
> language. For now I am just using a default language, but in the future it can 
> be changed.
> 
> One very last thing: I have to work on it, 'cause these friends of mine needs 
> it, and I will work on the application making it multilanguage. I will go thru 
> the entire application, populating the db tables and changing the  scripts 
> where needed. After I will finish my job, I believe by the end of september, I 
> am going to send you the result of my job: thus you'll get a finished a work, 
> and you'd be not worried by having something not finished. The only thing is 
> to understand what has changed from noew (or better from the 2.9 release of 
> the system) till the end of september.
> 
> Luca
> 
> Scrive Phil Daintree <p.d...@pa...>:
> 
> > Hi Luca,
> > 
> > There has been quite a bit of a discussion about multi-language - there
> > are a lot of issues. Maybe I scare too easily, but it seems like a
> > massive undertaking :-O
> > 
> > Thanks so much for considering what is really quite a sizable project
> > here. The other fear factor in taking this sort of thing on is if we
> > start it I am the muggins that has a stuffed system if we can't finish
> > it. It sure would be great to make web-erp multi-language. 
> > 
> > I see the way you are heading with what you started .... my over-riding
> > and BIG worry in going to multi-language is that the code might become
> > more difficult to make sense of (of course it being in English must be
> > quite a snag for those who use another language anyway). Under the
> > scenario you are proposing we would, I guess have a varchar(30)
> > description for the label that would be substituted by the TEXT field.
> > There a couple of reasons why I'm not that keen on this approach:
> > 
> > 1. 30 characters isn't much to describe the text variable. The full
> > context that the label provides I think significantly improves the
> > ability to understand code.
> > 2. If this requires a query for every label then this could be quite an
> > overhead on the db and a potential delay for the user. (all users).
> > 
> > Of the approaches discussed in the developers list - there is an archive
> > of this http://sourceforge.net/mailarchive/forum.php?forum_id=34088
> > 
> > I prefer Steve Kaill's approach and the approach used in open-accounting
> > ie enclosing the the full label in a function call eg.
> > 
> > echo language("This is how I rekon we should do multi-language so the
> > code remains relatively easy to read");
> > 
> > the language function returns the language string required by the user. 
> > 
> > We hold a $_SESSION['language'] variable which is stored in the
> > www_users table and retreived at the time of login. 
> > 
> > This language variable would be the same name as the file to include
> > under a new languages directory. 
> > 
> > The function language would be in this include directory. 
> > 
> > The function language then takes the text of the english label as a
> > parameter - the $SESSION['language'] is defined as global inside this
> > function and returns the the language string appropriate - if there is
> > no match for the string parameter passed then the parameter ie the
> > english label is returned. 
> > 
> > The english language function in languages/english.php would just return
> > the parameter itself.
> > 
> > I have not gone down the track of considering if the label substitution
> > is done using an array or what .... I would probably take a look at
> > open-accounting logic. 
> > 
> > This approach does retain a critical requirement for webERP ie that of
> > easily understandable code.
> > 
> > All approaches have their down side - 
> > 
> > 1. This puts the overhead on the web-server/ php interpreter. However,
> > this is pretty fast.However,potentially significant memory is required -
> > for what I have tried desperately to be minimalist in terms of resources
> > required to run it.
> > 
> > 2. Anyone changing the english labels will stuff up the translation file
> > ie the include file of strings in english with the equivalent language
> > string!
> > 
> > Do you see any other snags with this approach Luca?
> > Could you consider a slightly different approach?
> > 
> > Phil
> > 
> > 
> > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=?ISO-8859-1?Q?lon_Don=E0?=
> > wrote:
> > > Hello Phil,
> > > I've started to work on it.
> > > Here is how I want to address the issue.
> > > First I am going to create a table containing all the labels
> > > 
> > > CREATE TABLE `languages` (
> > >   `id` bigint(20) NOT NULL auto_increment,
> > >   `LANGID` varchar(15) NOT NULL default '',
> > >   `TEXTID` varchar(30) NOT NULL default '',
> > >   `TEXT` varchar(255) NOT NULL default '',
> > >   UNIQUE KEY `id` (`id`)
> > > ) TYPE=InnoDB COMMENT='Table containing labels to be showed on the
> > pages'; 
> > > 
> > > (I don't think InnoDB is necessary for this table, since it is only
> > read by
> > > normal users, and loaded by installer: i kept that type only for
> > compatibility
> > > with your design).
> > > 
> > > TEXTID is a code that identifies a specific label in very page. With
> > some work
> > > we can undertsand if the same label is going to be used on diffrent
> > pages.
> > > TEXT is the text that is going to appear on the browser.
> > > 
> > > On the config.php file I've inserted another variable:
> > > $DefaultLanguage="ITALIANO"; //of course you can put ENGLISH
> > > 
> > > In session.inc i've inserted this line
> > >     include ("language.php");
> > > just after
> > >     include("includes/ConnectDB.inc");
> > > 
> > > As you can see in the attachment, language.php loads an array named
> > $lang with
> > > the contents of the table "languages".
> > > By default it loads the $DefaultLanguage, but if the variable is not
> > defined it
> > > loads the English table.
> > > 
> > > Then I simply substitute all the labels around the php and html code
> > with the
> > > corresponding entry in the $lang array.
> > > As an example you can see in the attached login.php file the following
> > lines: 9,
> > > 53, 57, 66.
> > > 
> > > Having the labels in a db table can lead to another enhancement: every
> > user can
> > > choose his/her own language. This could be useful for companies having
> > clients
> > > spreaded around various countries....
> > > 
> > > What do you think about? 
> > > Can we arrange my small improvement with the future developement you
> > are making
> > > in web-erp?
> > > 
> > > Luca
> > > 
> > > 
> > > Scrive Phil Daintree <p.d...@pa...>:
> > > 
> > > > There has been some discussion about multi-language recently on the
> > > > list.
> > > > 
> > > > I am prepared to maintain a rigorous log of changes to scripts.
> > Perhaps
> > > > I could produce a diff file for all changes on each release but you
> > > > would have to apply these changes to the italian version. I have had
> > a
> > > > similar request from a spanish speaking person.
> > > > 
> > > > An Italian version would be good.
> > > > 
> > > > web-erp is not ideally suited to multi-language as you point out
> > since
> > > > all labels, print and echo statements would need to be modified and
> > > > changes in the core scripts would need to be applied to each
> > language's
> > > > scripts manually.
> > > > 
> > > > Phil
> > > > 
> > > > 
> > > > On Thu, 2004-07-29 at 17:28, ing. Luca
> > Tur=?ISO-8859-1?Q?lon_Don=E0?=
> > > > wrote:
> > > > > Dear Phil,
> > > > > a couple of friends, who ar starting up a new fashion company here
> > in
> > > > italy, 
> > > > > are very interested in using the application you developed.
> > > > > 
> > > > > Since they're not very acquainted with the english language and
> > > > jargon, i need 
> > > > > to translate the application for them.
> > > > > 
> > > > > I have various ways to do this: one is to simply browse the code
> > and
> > > > change 
> > > > > all the labels into italian. Doing so, i am very concerned about
> > > > everytime you 
> > > > > give a new release: at that time I have to check every change in
> > every
> > > > single 
> > > > > file. 
> > > > > The other one is to modify the code in order to have a separate
> > place
> > > > in which 
> > > > > labels and all the language-dependent stuff are stored. This can
> > be a
> > > > DB table 
> > > > > or a file... i still don't know.
> > > > > Before starting this, i need to know a couple of things:
> > > > > First: are you going to do what I would like to do? In this case
> > when
> > > > do you 
> > > > > think you will release a multilingual version of web-erp? And: do
> > you
> > > > need any 
> > > > > help? I'd be happy to help in any way.
> > > > > Second: if you're not going to do the multilingual version, can I
> > work
> > > > on it? 
> > > > > Can we synch our two different tracks (the improvement of the
> > system
> > > > that 
> > > > > maybe you are doing and my translation-multilingual effort)? 
> > > > > 
> > > > > Please give me an answer on this, since i am strongly sponsoring
> > your 
> > > > > product...
> > > > > Best Regards,
> > > > > Luca 
> > > > > 
> > > > > PS: I am working on the translation of the manual. When finished,
> > I'll
> > > > send it 
> > > > > to you.
> > > > > 
> > > > 
> > 
> 

[Web-erp-developers] Re: Italian Translation of web-erp

[Phil D. <p.d...@pa...>]

Luca,

Hope you dont mind - I subscribed you to the developers list - you have
to confirm if you wish to receive email discussion of web-erp
development.

I re-read you first email and I didn't understand correctly first time
out - I like your approach. I also like the idea of retaining the full
english text in the code somehow. It does seem that those in the know
like this gettext function I have not read up on it myself but bow to
those with the knowledge. I also have great respect for Sherif Omar and
Hani Nguaeb (hope he'll forgive my spelling of his surname!) who forked
web-erp into Open Accounting the last time multi-language raised itself
- I didn't have the stomach for it at the time!! Gettext was the way
they went. 

You know the issues I have :

1. Readability and ease of understanding the code
2. Readability and ease of understanding the code
3. Readability and ease of understanding the code
4, 5  and 6. Efficiency of the code (minising DB calls/Web server
parsing)

If these issues are satisfied then lets GO!

Phil

On Mon, 2004-08-02 at 13:11, ing. Luca Tur=?ISO-8859-1?Q?lon_Don=E0?=
wrote:
> Hi Phil.
> I've been reading thru your mail several times before answering, cause  wanted 
> to be sure to understand every single issue ou pointed out.
> 
> The main consideration that comes out is that your approach is very similar to 
> mine, i.e.:
> -You are proposing a function call, I am proposing to use an array with a 
> literal index.
> -You are proposing several files with the translation, i am proposing several 
> groups of rows in a table.
> 
> Firts let me explain one thing: my idea consists in loading an array from the 
> db, i.e.: in the beginning of every page I make a bulk load of all the labels 
> in the language that has to be shown. So we do not have a full read cycle 
> (connect-query-parse the query, disconnect) on the db for every single label 
> in the page. We read everything at the beginning, load it in the lang array 
> and then use the lang array. This should address the second concern that you 
> put in your email. There is another thing: if we add a column on the db table, 
> containing the script (or an unique code which identifies the script) that is 
> going to be rendered we can achieve two more thing: first we can load just the 
> labels used in that script, reducing the size of the array. Secondly we will 
> have a documentation of what is shown in every page.
> 
> Regarding the other concern, i.e. the smallness of 30 chars for a label 
> identifier, I believe that i could enlarge that column to a wider string: i do 
> not see any problem on this.
> 
> The last thing you say, that is the code should be easy understandable. Maybe 
> you're right in considering the code easier to read having a full english 
> label, but I think that a label identifier with some comment could do the 
> same. In this way you could avoid the problem you mentioned about changes in 
> the english labels.
> 
> Please now let me tell some other things about the "function" approach:
> a) there is no other way than creating a php script to translate the 
> application. With the db approach I could create a page to let any kind of 
> user (not only a PHP programmer) manage the translation
> b) it can become tough managing any new version of the system: with the db you 
> can query and see how many entries you have for each language, and you can 
> easily identify which labels has to be translated. With the included file 
> approach you have to work on the files, hoping that every file is written with 
> exactly the same approach. 
> c) Since you must delegate people to translate (unless you know at least 15 
> languages) you can loose control on the code: what if a russian sends you an 
> email saying that the system not working, just because the russian translator 
> forgot a ";" in his code? With the db approach the worst thing that could 
> happen is a wrong translation or something written in English, but not 
> something that halts the system.
> d) With the db you have a sort of documentation, which can help in creating 
> help files...
> e) it is at any time possible to automatically generate any language script, 
> i.e a language/italiano.php can be generated from the db and we can switch to 
> your "function" approach. 
> f) ther is another thing regarding the usage of the entire english label as a 
> parameter: imagine if you forget to put the function call. With the label 
> identifier you immediately see that there is something difficult to read on 
> the page. With the full english label you may even not notice the error.
> 
> 
> Finally: I do believe that the language variable should be kept, in the 
> future, in the session of the user, having each user working with his/her own 
> language. For now I am just using a default language, but in the future it can 
> be changed.
> 
> One very last thing: I have to work on it, 'cause these friends of mine needs 
> it, and I will work on the application making it multilanguage. I will go thru 
> the entire application, populating the db tables and changing the  scripts 
> where needed. After I will finish my job, I believe by the end of september, I 
> am going to send you the result of my job: thus you'll get a finished a work, 
> and you'd be not worried by having something not finished. The only thing is 
> to understand what has changed from noew (or better from the 2.9 release of 
> the system) till the end of september.
> 
> Luca
> 
> Scrive Phil Daintree <p.d...@pa...>:
> 
> > Hi Luca,
> > 
> > There has been quite a bit of a discussion about multi-language - there
> > are a lot of issues. Maybe I scare too easily, but it seems like a
> > massive undertaking :-O
> > 
> > Thanks so much for considering what is really quite a sizable project
> > here. The other fear factor in taking this sort of thing on is if we
> > start it I am the muggins that has a stuffed system if we can't finish
> > it. It sure would be great to make web-erp multi-language. 
> > 
> > I see the way you are heading with what you started .... my over-riding
> > and BIG worry in going to multi-language is that the code might become
> > more difficult to make sense of (of course it being in English must be
> > quite a snag for those who use another language anyway). Under the
> > scenario you are proposing we would, I guess have a varchar(30)
> > description for the label that would be substituted by the TEXT field.
> > There a couple of reasons why I'm not that keen on this approach:
> > 
> > 1. 30 characters isn't much to describe the text variable. The full
> > context that the label provides I think significantly improves the
> > ability to understand code.
> > 2. If this requires a query for every label then this could be quite an
> > overhead on the db and a potential delay for the user. (all users).
> > 
> > Of the approaches discussed in the developers list - there is an archive
> > of this http://sourceforge.net/mailarchive/forum.php?forum_id=34088
> > 
> > I prefer Steve Kaill's approach and the approach used in open-accounting
> > ie enclosing the the full label in a function call eg.
> > 
> > echo language("This is how I rekon we should do multi-language so the
> > code remains relatively easy to read");
> > 
> > the language function returns the language string required by the user. 
> > 
> > We hold a $_SESSION['language'] variable which is stored in the
> > www_users table and retreived at the time of login. 
> > 
> > This language variable would be the same name as the file to include
> > under a new languages directory. 
> > 
> > The function language would be in this include directory. 
> > 
> > The function language then takes the text of the english label as a
> > parameter - the $SESSION['language'] is defined as global inside this
> > function and returns the the language string appropriate - if there is
> > no match for the string parameter passed then the parameter ie the
> > english label is returned. 
> > 
> > The english language function in languages/english.php would just return
> > the parameter itself.
> > 
> > I have not gone down the track of considering if the label substitution
> > is done using an array or what .... I would probably take a look at
> > open-accounting logic. 
> > 
> > This approach does retain a critical requirement for webERP ie that of
> > easily understandable code.
> > 
> > All approaches have their down side - 
> > 
> > 1. This puts the overhead on the web-server/ php interpreter. However,
> > this is pretty fast.However,potentially significant memory is required -
> > for what I have tried desperately to be minimalist in terms of resources
> > required to run it.
> > 
> > 2. Anyone changing the english labels will stuff up the translation file
> > ie the include file of strings in english with the equivalent language
> > string!
> > 
> > Do you see any other snags with this approach Luca?
> > Could you consider a slightly different approach?
> > 
> > Phil
> > 
> > 
> > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=?ISO-8859-1?Q?lon_Don=E0?=
> > wrote:
> > > Hello Phil,
> > > I've started to work on it.
> > > Here is how I want to address the issue.
> > > First I am going to create a table containing all the labels
> > > 
> > > CREATE TABLE `languages` (
> > >   `id` bigint(20) NOT NULL auto_increment,
> > >   `LANGID` varchar(15) NOT NULL default '',
> > >   `TEXTID` varchar(30) NOT NULL default '',
> > >   `TEXT` varchar(255) NOT NULL default '',
> > >   UNIQUE KEY `id` (`id`)
> > > ) TYPE=InnoDB COMMENT='Table containing labels to be showed on the
> > pages'; 
> > > 
> > > (I don't think InnoDB is necessary for this table, since it is only
> > read by
> > > normal users, and loaded by installer: i kept that type only for
> > compatibility
> > > with your design).
> > > 
> > > TEXTID is a code that identifies a specific label in very page. With
> > some work
> > > we can undertsand if the same label is going to be used on diffrent
> > pages.
> > > TEXT is the text that is going to appear on the browser.
> > > 
> > > On the config.php file I've inserted another variable:
> > > $DefaultLanguage="ITALIANO"; //of course you can put ENGLISH
> > > 
> > > In session.inc i've inserted this line
> > >     include ("language.php");
> > > just after
> > >     include("includes/ConnectDB.inc");
> > > 
> > > As you can see in the attachment, language.php loads an array named
> > $lang with
> > > the contents of the table "languages".
> > > By default it loads the $DefaultLanguage, but if the variable is not
> > defined it
> > > loads the English table.
> > > 
> > > Then I simply substitute all the labels around the php and html code
> > with the
> > > corresponding entry in the $lang array.
> > > As an example you can see in the attached login.php file the following
> > lines: 9,
> > > 53, 57, 66.
> > > 
> > > Having the labels in a db table can lead to another enhancement: every
> > user can
> > > choose his/her own language. This could be useful for companies having
> > clients
> > > spreaded around various countries....
> > > 
> > > What do you think about? 
> > > Can we arrange my small improvement with the future developement you
> > are making
> > > in web-erp?
> > > 
> > > Luca
> > > 
> > > 
> > > Scrive Phil Daintree <p.d...@pa...>:
> > > 
> > > > There has been some discussion about multi-language recently on the
> > > > list.
> > > > 
> > > > I am prepared to maintain a rigorous log of changes to scripts.
> > Perhaps
> > > > I could produce a diff file for all changes on each release but you
> > > > would have to apply these changes to the italian version. I have had
> > a
> > > > similar request from a spanish speaking person.
> > > > 
> > > > An Italian version would be good.
> > > > 
> > > > web-erp is not ideally suited to multi-language as you point out
> > since
> > > > all labels, print and echo statements would need to be modified and
> > > > changes in the core scripts would need to be applied to each
> > language's
> > > > scripts manually.
> > > > 
> > > > Phil
> > > > 
> > > > 
> > > > On Thu, 2004-07-29 at 17:28, ing. Luca
> > Tur=?ISO-8859-1?Q?lon_Don=E0?=
> > > > wrote:
> > > > > Dear Phil,
> > > > > a couple of friends, who ar starting up a new fashion company here
> > in
> > > > italy, 
> > > > > are very interested in using the application you developed.
> > > > > 
> > > > > Since they're not very acquainted with the english language and
> > > > jargon, i need 
> > > > > to translate the application for them.
> > > > > 
> > > > > I have various ways to do this: one is to simply browse the code
> > and
> > > > change 
> > > > > all the labels into italian. Doing so, i am very concerned about
> > > > everytime you 
> > > > > give a new release: at that time I have to check every change in
> > every
> > > > single 
> > > > > file. 
> > > > > The other one is to modify the code in order to have a separate
> > place
> > > > in which 
> > > > > labels and all the language-dependent stuff are stored. This can
> > be a
> > > > DB table 
> > > > > or a file... i still don't know.
> > > > > Before starting this, i need to know a couple of things:
> > > > > First: are you going to do what I would like to do? In this case
> > when
> > > > do you 
> > > > > think you will release a multilingual version of web-erp? And: do
> > you
> > > > need any 
> > > > > help? I'd be happy to help in any way.
> > > > > Second: if you're not going to do the multilingual version, can I
> > work
> > > > on it? 
> > > > > Can we synch our two different tracks (the improvement of the
> > system
> > > > that 
> > > > > maybe you are doing and my translation-multilingual effort)? 
> > > > > 
> > > > > Please give me an answer on this, since i am strongly sponsoring
> > your 
> > > > > product...
> > > > > Best Regards,
> > > > > Luca 
> > > > > 
> > > > > PS: I am working on the translation of the manual. When finished,
> > I'll
> > > > send it 
> > > > > to you.
> > > > > 
> > > > 
> > 
> 

Re: [Web-erp-developers] Fw: Italian Translation of web-erp

[Stins, D. <DR...@Zi...>]

I agree that it would a risk not to use existing knowledge implemented in
gnu gettext.
Or is gnu gettext overdone for web-erp?

see below.

Dick
----- Original Message -----
From: "skaill" <sk...@ro...>
To: <web...@li...>
Sent: Tuesday, August 03, 2004 12:01 AM
Subject: Re: [Web-erp-developers] Fw: Italian Translation of web-erp


> This is an area that we will need to work on as well.  If Luca wants
to"get
> together" at some point to work on this I am available.
>
> I would point out to Luca that keeping the original English strings in =
the
> code instead of using an identifier keeps the code WAY more readable.
> That's my opinion after having worked extensively with a product that d=
id
it
> with identifiers.  Code is scary to read when it has identifiers instea=
d
of
> literals.  Many will be thrown off by doing that.
>
> I have recently discovered a function in PHP called gettext which may b=
e
for
> exactly what we are trying to do.  I don't know enough about it but bef=
ore
> doing our own coding for Multilanguage it would be nice to see if the
built
> in gettext functionality will do it.
>
> Just guessing but I think loading the entire language file at the
beginning
> of each page may be much slower than doing a few reads within one page.=
  A
normally is one database read faster than several database reads. Since
every database read does need to do extra parsing which used to be
timeconsuming.
> few lines versus hundreds to thousands.  Plus the memory for each user
would
> be way more.  Here's an idea that actually ends up a modified version o=
f
I guess there will be about 700 translation strings with avarage length o=
f
10.
This is 7000 bytes. So when you plug in 256mb extra ram, you can support
256mb/7000bytes =3D 38347 users :)
> Luca's suggestion to keep the page number in the db.  Have an array of
> strings at the top of each page where those strings are the strings use=
d
> within the page.  Call a language function that retrieves and returns a=
ll
of
> these at the page beginning.  When language(...) is called within the
page,
> it first looks to see if the string was looked up already and uses that
> otherwise goes out to retrieve from the db, file or wherever.  This wil=
l
> minimize the amount needing to be looked up yet look it up (or most of =
it)
> all at once as Luca is suggesting.
>
> We can build in whatever is changed until September very easily.  It's
just
> important to know which version Luca started on.
>
> I agree that db storage is the best for the Multilanguage information o=
ver
> another way such as file.
>
> Steve
>
> ----- Original Message -----
> From: "Daintrees" <p.d...@pa...>
> To: <web...@li...>
> Cc: <luc...@pd...>
> Sent: Monday, August 02, 2004 4:21 PM
> Subject: [Web-erp-developers] Fw: Italian Translation of web-erp
>
>
> Luca,
>
> I am not sure if you have joined the developers list, but I have
forwareded
> this email to them because I would like to run your proposal past the
other
> interested and knowledgeable folk - hope you dont mind!
>
> We have a table of each script - that was added in 2.9 for the context
> sensitive help (currently not language specific) - each script is given=
 a
> unique id - this may also be helpful for security Steve - the idea of
> retrieving just the labels for the script being run is appealing as is
> having a user interface for translators that doesnt involve editing fil=
es.
> You have some good points. The best point of all - you are prepared to =
do
a
> lot of work for the project - most appreciated.
>
> Lets just see if there are any other opinions/pitfalls that the rest of
the
> team see - so we dont trip and fall on this.
>
> Phil
>
> ----- Original Message -----
> From: "ing. Luca Turlon Don=E0" <luc...@pd...>
> To: "Phil Daintree" <p.d...@pa...>
> Sent: Tuesday, August 03, 2004 12:11 AM
> Subject: Re: Italian Translation of web-erp
>
>
> > Hi Phil.
> > I've been reading thru your mail several times before answering, caus=
e
> wanted
> > to be sure to understand every single issue ou pointed out.
> >
> > The main consideration that comes out is that your approach is very
> similar to
> > mine, i.e.:
> > -You are proposing a function call, I am proposing to use an array wi=
th
a
> > literal index.
> > -You are proposing several files with the translation, i am proposing
> several
> > groups of rows in a table.
> >
> > Firts let me explain one thing: my idea consists in loading an array
from
> the
> > db, i.e.: in the beginning of every page I make a bulk load of all th=
e
> labels
> > in the language that has to be shown. So we do not have a full read
cycle
> > (connect-query-parse the query, disconnect) on the db for every singl=
e
> label
> > in the page. We read everything at the beginning, load it in the lang
> array
> > and then use the lang array. This should address the second concern t=
hat
> you
> > put in your email. There is another thing: if we add a column on the =
db
> table,
> > containing the script (or an unique code which identifies the script)
that
> is
> > going to be rendered we can achieve two more thing: first we can load
just
> the
> > labels used in that script, reducing the size of the array. Secondly =
we
> will
> > have a documentation of what is shown in every page.
> >
> > Regarding the other concern, i.e. the smallness of 30 chars for a lab=
el
> > identifier, I believe that i could enlarge that column to a wider
string:
> i do
> > not see any problem on this.
> >
> > The last thing you say, that is the code should be easy understandabl=
e.
> Maybe
> > you're right in considering the code easier to read having a full
english
> > label, but I think that a label identifier with some comment could do
the
> > same. In this way you could avoid the problem you mentioned about
changes
> in
> > the english labels.
> >
> > Please now let me tell some other things about the "function" approac=
h:
> > a) there is no other way than creating a php script to translate the
> > application. With the db approach I could create a page to let any ki=
nd
of
> > user (not only a PHP programmer) manage the translation
> > b) it can become tough managing any new version of the system: with t=
he
db
> you
> > can query and see how many entries you have for each language, and yo=
u
can
> > easily identify which labels has to be translated. With the included
file
> > approach you have to work on the files, hoping that every file is
written
> with
> > exactly the same approach.
> > c) Since you must delegate people to translate (unless you know at le=
ast
> 15
> > languages) you can loose control on the code: what if a russian sends
you
> an
> > email saying that the system not working, just because the russian
> translator
> > forgot a ";" in his code? With the db approach the worst thing that
could
> > happen is a wrong translation or something written in English, but no=
t
> > something that halts the system.
> > d) With the db you have a sort of documentation, which can help in
> creating
> > help files...
> > e) it is at any time possible to automatically generate any language
> script,
> > i.e a language/italiano.php can be generated from the db and we can
switch
> to
> > your "function" approach.
> > f) ther is another thing regarding the usage of the entire english la=
bel
> as a
> > parameter: imagine if you forget to put the function call. With the
label
> > identifier you immediately see that there is something difficult to r=
ead
> on
> > the page. With the full english label you may even not notice the err=
or.
> >
> >
> > Finally: I do believe that the language variable should be kept, in t=
he
> > future, in the session of the user, having each user working with
his/her
> own
> > language. For now I am just using a default language, but in the futu=
re
it
> can
> > be changed.
> >
> > One very last thing: I have to work on it, 'cause these friends of mi=
ne
> needs
> > it, and I will work on the application making it multilanguage. I wil=
l
go
> thru
> > the entire application, populating the db tables and changing the
scripts
> > where needed. After I will finish my job, I believe by the end of
> september, I
> > am going to send you the result of my job: thus you'll get a finished=
 a
> work,
> > and you'd be not worried by having something not finished. The only
thing
> is
> > to understand what has changed from noew (or better from the 2.9 rele=
ase
> of
> > the system) till the end of september.
> >
> > Luca
> >
> > Scrive Phil Daintree <p.d...@pa...>:
> >
> > > Hi Luca,
> > >
> > > There has been quite a bit of a discussion about multi-language -
there
> > > are a lot of issues. Maybe I scare too easily, but it seems like a
> > > massive undertaking :-O
> > >
> > > Thanks so much for considering what is really quite a sizable proje=
ct
> > > here. The other fear factor in taking this sort of thing on is if w=
e
> > > start it I am the muggins that has a stuffed system if we can't fin=
ish
> > > it. It sure would be great to make web-erp multi-language.
> > >
> > > I see the way you are heading with what you started .... my
over-riding
> > > and BIG worry in going to multi-language is that the code might bec=
ome
> > > more difficult to make sense of (of course it being in English must=
 be
> > > quite a snag for those who use another language anyway). Under the
> > > scenario you are proposing we would, I guess have a varchar(30)
> > > description for the label that would be substituted by the TEXT fie=
ld.
> > > There a couple of reasons why I'm not that keen on this approach:
> > >
> > > 1. 30 characters isn't much to describe the text variable. The full
> > > context that the label provides I think significantly improves the
> > > ability to understand code.
> > > 2. If this requires a query for every label then this could be quit=
e
an
> > > overhead on the db and a potential delay for the user. (all users).
> > >
> > > Of the approaches discussed in the developers list - there is an
archive
> > > of this http://sourceforge.net/mailarchive/forum.php?forum_id=3D340=
88
> > >
> > > I prefer Steve Kaill's approach and the approach used in
open-accounting
> > > ie enclosing the the full label in a function call eg.
> > >
> > > echo language("This is how I rekon we should do multi-language so t=
he
> > > code remains relatively easy to read");
> > >
> > > the language function returns the language string required by the
user.
> > >
> > > We hold a $_SESSION['language'] variable which is stored in the
> > > www_users table and retreived at the time of login.
> > >
> > > This language variable would be the same name as the file to includ=
e
> > > under a new languages directory.
> > >
> > > The function language would be in this include directory.
> > >
> > > The function language then takes the text of the english label as a
> > > parameter - the $SESSION['language'] is defined as global inside th=
is
> > > function and returns the the language string appropriate - if there=
 is
> > > no match for the string parameter passed then the parameter ie the
> > > english label is returned.
> > >
> > > The english language function in languages/english.php would just
return
> > > the parameter itself.
> > >
> > > I have not gone down the track of considering if the label
substitution
> > > is done using an array or what .... I would probably take a look at
> > > open-accounting logic.
> > >
> > > This approach does retain a critical requirement for webERP ie that=
 of
> > > easily understandable code.
> > >
> > > All approaches have their down side -
> > >
> > > 1. This puts the overhead on the web-server/ php interpreter. Howev=
er,
> > > this is pretty fast.However,potentially significant memory is
required -
> > > for what I have tried desperately to be minimalist in terms of
resources
> > > required to run it.
> > >
> > > 2. Anyone changing the english labels will stuff up the translation
file
> > > ie the include file of strings in english with the equivalent langu=
age
> > > string!
> > >
> > > Do you see any other snags with this approach Luca?
> > > Could you consider a slightly different approach?
> > >
> > > Phil
> > >
> > >
> > > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=3D?ISO-8859-1?Q?lon_Don=3D=
E0?=3D
> > > wrote:
> > > > Hello Phil,
> > > > I've started to work on it.
> > > > Here is how I want to address the issue.
> > > > First I am going to create a table containing all the labels
> > > >
> > > > CREATE TABLE `languages` (
> > > >   `id` bigint(20) NOT NULL auto_increment,
> > > >   `LANGID` varchar(15) NOT NULL default '',
> > > >   `TEXTID` varchar(30) NOT NULL default '',
> > > >   `TEXT` varchar(255) NOT NULL default '',
> > > >   UNIQUE KEY `id` (`id`)
> > > > ) TYPE=3DInnoDB COMMENT=3D'Table containing labels to be showed o=
n the
> > > pages';
> > > >
> > > > (I don't think InnoDB is necessary for this table, since it is on=
ly
> > > read by
> > > > normal users, and loaded by installer: i kept that type only for
> > > compatibility
> > > > with your design).
> > > >
> > > > TEXTID is a code that identifies a specific label in very page. W=
ith
> > > some work
> > > > we can undertsand if the same label is going to be used on diffre=
nt
> > > pages.
> > > > TEXT is the text that is going to appear on the browser.
> > > >
> > > > On the config.php file I've inserted another variable:
> > > > $DefaultLanguage=3D"ITALIANO"; //of course you can put ENGLISH
> > > >
> > > > In session.inc i've inserted this line
> > > >     include ("language.php");
> > > > just after
> > > >     include("includes/ConnectDB.inc");
> > > >
> > > > As you can see in the attachment, language.php loads an array nam=
ed
> > > $lang with
> > > > the contents of the table "languages".
> > > > By default it loads the $DefaultLanguage, but if the variable is =
not
> > > defined it
> > > > loads the English table.
> > > >
> > > > Then I simply substitute all the labels around the php and html c=
ode
> > > with the
> > > > corresponding entry in the $lang array.
> > > > As an example you can see in the attached login.php file the
following
> > > lines: 9,
> > > > 53, 57, 66.
> > > >
> > > > Having the labels in a db table can lead to another enhancement:
every
> > > user can
> > > > choose his/her own language. This could be useful for companies
having
> > > clients
> > > > spreaded around various countries....
> > > >
> > > > What do you think about?
> > > > Can we arrange my small improvement with the future developement =
you
> > > are making
> > > > in web-erp?
> > > >
> > > > Luca
> > > >
> > > >
> > > > Scrive Phil Daintree <p.d...@pa...>:
> > > >
> > > > > There has been some discussion about multi-language recently on
the
> > > > > list.
> > > > >
> > > > > I am prepared to maintain a rigorous log of changes to scripts.
> > > Perhaps
> > > > > I could produce a diff file for all changes on each release but
you
> > > > > would have to apply these changes to the italian version. I hav=
e
had
> > > a
> > > > > similar request from a spanish speaking person.
> > > > >
> > > > > An Italian version would be good.
> > > > >
> > > > > web-erp is not ideally suited to multi-language as you point ou=
t
> > > since
> > > > > all labels, print and echo statements would need to be modified
and
> > > > > changes in the core scripts would need to be applied to each
> > > language's
> > > > > scripts manually.
> > > > >
> > > > > Phil
> > > > >
> > > > >
> > > > > On Thu, 2004-07-29 at 17:28, ing. Luca
> > > Tur=3D?ISO-8859-1?Q?lon_Don=3DE0?=3D
> > > > > wrote:
> > > > > > Dear Phil,
> > > > > > a couple of friends, who ar starting up a new fashion company
here
> > > in
> > > > > italy,
> > > > > > are very interested in using the application you developed.
> > > > > >
> > > > > > Since they're not very acquainted with the english language a=
nd
> > > > > jargon, i need
> > > > > > to translate the application for them.
> > > > > >
> > > > > > I have various ways to do this: one is to simply browse the c=
ode
> > > and
> > > > > change
> > > > > > all the labels into italian. Doing so, i am very concerned ab=
out
> > > > > everytime you
> > > > > > give a new release: at that time I have to check every change=
 in
> > > every
> > > > > single
> > > > > > file.
> > > > > > The other one is to modify the code in order to have a separa=
te
> > > place
> > > > > in which
> > > > > > labels and all the language-dependent stuff are stored. This =
can
> > > be a
> > > > > DB table
> > > > > > or a file... i still don't know.
> > > > > > Before starting this, i need to know a couple of things:
> > > > > > First: are you going to do what I would like to do? In this c=
ase
> > > when
> > > > > do you
> > > > > > think you will release a multilingual version of web-erp? And=
:
do
> > > you
> > > > > need any
> > > > > > help? I'd be happy to help in any way.
> > > > > > Second: if you're not going to do the multilingual version, c=
an
I
> > > work
> > > > > on it?
> > > > > > Can we synch our two different tracks (the improvement of the
> > > system
> > > > > that
> > > > > > maybe you are doing and my translation-multilingual effort)?
> > > > > >
> > > > > > Please give me an answer on this, since i am strongly sponsor=
ing
> > > your
> > > > > > product...
> > > > > > Best Regards,
> > > > > > Luca
> > > > > >
> > > > > > PS: I am working on the translation of the manual. When
finished,
> > > I'll
> > > > > send it
> > > > > > to you.
> > > > > >
> > > > >
> > >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technolog=
y
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technolog=
y
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Fw: [Web-erp-developers] Fw: Italian Translation of web-erp

[skaill <sk...@ro...>]

It looks like the best way to do Multilanguage is using gettext.  I'm not
saying it can't be done another way but a huge ongoing project exists that
supports it and several Open Source programs use it.  Using this method
would mean we have support and a supply of tools/code examples to get the
job done. Getting language files for various languages contributed from
others would be easier.  Also, for all developers in the future they will
likely know gettext over anything else and combining Multilanguage softwares
would be easier.  It really turns out very easy and is basically identical
to the ways of doing it that we have been discussing.

One issue with gettext is you may have to install the gettext facility into
php.  I'm not sure if it comes with it, however the php manual does discuss
it.

I found an example Open Source program that uses the gettext facility that
could serve as an example.

The only challenge now is how to create the language files it uses.  I
believe there are good tools available for doing it that help create, manage
and track.  Just haven't looked into that part yet.

Steve

----- Original Message ----- 
From: "skaill" <sk...@ro...>
To: <web...@li...>
Sent: Monday, August 02, 2004 6:11 PM
Subject: Re: [Web-erp-developers] Fw: Italian Translation of web-erp


> Here is more information about the GNU gettext...
>
> http://www.gnu.org/software/gettext/gettext.html
>
> Just starting to read it myself but looks promising.
>
> Steve
>
> ----- Original Message ----- 
> From: "Daintrees" <p.d...@pa...>
> To: <web...@li...>
> Cc: <luc...@pd...>
> Sent: Monday, August 02, 2004 4:21 PM
> Subject: [Web-erp-developers] Fw: Italian Translation of web-erp
>
>
> Luca,
>
> I am not sure if you have joined the developers list, but I have
forwareded
> this email to them because I would like to run your proposal past the
other
> interested and knowledgeable folk - hope you dont mind!
>
> We have a table of each script - that was added in 2.9 for the context
> sensitive help (currently not language specific) - each script is given a
> unique id - this may also be helpful for security Steve - the idea of
> retrieving just the labels for the script being run is appealing as is
> having a user interface for translators that doesnt involve editing files.
> You have some good points. The best point of all - you are prepared to do
a
> lot of work for the project - most appreciated.
>
> Lets just see if there are any other opinions/pitfalls that the rest of
the
> team see - so we dont trip and fall on this.
>
> Phil
>
> ----- Original Message ----- 
> From: "ing. Luca Turlon Donà" <luc...@pd...>
> To: "Phil Daintree" <p.d...@pa...>
> Sent: Tuesday, August 03, 2004 12:11 AM
> Subject: Re: Italian Translation of web-erp
>
>
> > Hi Phil.
> > I've been reading thru your mail several times before answering, cause
> wanted
> > to be sure to understand every single issue ou pointed out.
> >
> > The main consideration that comes out is that your approach is very
> similar to
> > mine, i.e.:
> > -You are proposing a function call, I am proposing to use an array with
a
> > literal index.
> > -You are proposing several files with the translation, i am proposing
> several
> > groups of rows in a table.
> >
> > Firts let me explain one thing: my idea consists in loading an array
from
> the
> > db, i.e.: in the beginning of every page I make a bulk load of all the
> labels
> > in the language that has to be shown. So we do not have a full read
cycle
> > (connect-query-parse the query, disconnect) on the db for every single
> label
> > in the page. We read everything at the beginning, load it in the lang
> array
> > and then use the lang array. This should address the second concern that
> you
> > put in your email. There is another thing: if we add a column on the db
> table,
> > containing the script (or an unique code which identifies the script)
that
> is
> > going to be rendered we can achieve two more thing: first we can load
just
> the
> > labels used in that script, reducing the size of the array. Secondly we
> will
> > have a documentation of what is shown in every page.
> >
> > Regarding the other concern, i.e. the smallness of 30 chars for a label
> > identifier, I believe that i could enlarge that column to a wider
string:
> i do
> > not see any problem on this.
> >
> > The last thing you say, that is the code should be easy understandable.
> Maybe
> > you're right in considering the code easier to read having a full
english
> > label, but I think that a label identifier with some comment could do
the
> > same. In this way you could avoid the problem you mentioned about
changes
> in
> > the english labels.
> >
> > Please now let me tell some other things about the "function" approach:
> > a) there is no other way than creating a php script to translate the
> > application. With the db approach I could create a page to let any kind
of
> > user (not only a PHP programmer) manage the translation
> > b) it can become tough managing any new version of the system: with the
db
> you
> > can query and see how many entries you have for each language, and you
can
> > easily identify which labels has to be translated. With the included
file
> > approach you have to work on the files, hoping that every file is
written
> with
> > exactly the same approach.
> > c) Since you must delegate people to translate (unless you know at least
> 15
> > languages) you can loose control on the code: what if a russian sends
you
> an
> > email saying that the system not working, just because the russian
> translator
> > forgot a ";" in his code? With the db approach the worst thing that
could
> > happen is a wrong translation or something written in English, but not
> > something that halts the system.
> > d) With the db you have a sort of documentation, which can help in
> creating
> > help files...
> > e) it is at any time possible to automatically generate any language
> script,
> > i.e a language/italiano.php can be generated from the db and we can
switch
> to
> > your "function" approach.
> > f) ther is another thing regarding the usage of the entire english label
> as a
> > parameter: imagine if you forget to put the function call. With the
label
> > identifier you immediately see that there is something difficult to read
> on
> > the page. With the full english label you may even not notice the error.
> >
> >
> > Finally: I do believe that the language variable should be kept, in the
> > future, in the session of the user, having each user working with
his/her
> own
> > language. For now I am just using a default language, but in the future
it
> can
> > be changed.
> >
> > One very last thing: I have to work on it, 'cause these friends of mine
> needs
> > it, and I will work on the application making it multilanguage. I will
go
> thru
> > the entire application, populating the db tables and changing the
scripts
> > where needed. After I will finish my job, I believe by the end of
> september, I
> > am going to send you the result of my job: thus you'll get a finished a
> work,
> > and you'd be not worried by having something not finished. The only
thing
> is
> > to understand what has changed from noew (or better from the 2.9 release
> of
> > the system) till the end of september.
> >
> > Luca
> >
> > Scrive Phil Daintree <p.d...@pa...>:
> >
> > > Hi Luca,
> > >
> > > There has been quite a bit of a discussion about multi-language -
there
> > > are a lot of issues. Maybe I scare too easily, but it seems like a
> > > massive undertaking :-O
> > >
> > > Thanks so much for considering what is really quite a sizable project
> > > here. The other fear factor in taking this sort of thing on is if we
> > > start it I am the muggins that has a stuffed system if we can't finish
> > > it. It sure would be great to make web-erp multi-language.
> > >
> > > I see the way you are heading with what you started .... my
over-riding
> > > and BIG worry in going to multi-language is that the code might become
> > > more difficult to make sense of (of course it being in English must be
> > > quite a snag for those who use another language anyway). Under the
> > > scenario you are proposing we would, I guess have a varchar(30)
> > > description for the label that would be substituted by the TEXT field.
> > > There a couple of reasons why I'm not that keen on this approach:
> > >
> > > 1. 30 characters isn't much to describe the text variable. The full
> > > context that the label provides I think significantly improves the
> > > ability to understand code.
> > > 2. If this requires a query for every label then this could be quite
an
> > > overhead on the db and a potential delay for the user. (all users).
> > >
> > > Of the approaches discussed in the developers list - there is an
archive
> > > of this http://sourceforge.net/mailarchive/forum.php?forum_id=34088
> > >
> > > I prefer Steve Kaill's approach and the approach used in
open-accounting
> > > ie enclosing the the full label in a function call eg.
> > >
> > > echo language("This is how I rekon we should do multi-language so the
> > > code remains relatively easy to read");
> > >
> > > the language function returns the language string required by the
user.
> > >
> > > We hold a $_SESSION['language'] variable which is stored in the
> > > www_users table and retreived at the time of login.
> > >
> > > This language variable would be the same name as the file to include
> > > under a new languages directory.
> > >
> > > The function language would be in this include directory.
> > >
> > > The function language then takes the text of the english label as a
> > > parameter - the $SESSION['language'] is defined as global inside this
> > > function and returns the the language string appropriate - if there is
> > > no match for the string parameter passed then the parameter ie the
> > > english label is returned.
> > >
> > > The english language function in languages/english.php would just
return
> > > the parameter itself.
> > >
> > > I have not gone down the track of considering if the label
substitution
> > > is done using an array or what .... I would probably take a look at
> > > open-accounting logic.
> > >
> > > This approach does retain a critical requirement for webERP ie that of
> > > easily understandable code.
> > >
> > > All approaches have their down side -
> > >
> > > 1. This puts the overhead on the web-server/ php interpreter. However,
> > > this is pretty fast.However,potentially significant memory is
required -
> > > for what I have tried desperately to be minimalist in terms of
resources
> > > required to run it.
> > >
> > > 2. Anyone changing the english labels will stuff up the translation
file
> > > ie the include file of strings in english with the equivalent language
> > > string!
> > >
> > > Do you see any other snags with this approach Luca?
> > > Could you consider a slightly different approach?
> > >
> > > Phil
> > >
> > >
> > > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=?ISO-8859-1?Q?lon_Don=E0?=
> > > wrote:
> > > > Hello Phil,
> > > > I've started to work on it.
> > > > Here is how I want to address the issue.
> > > > First I am going to create a table containing all the labels
> > > >
> > > > CREATE TABLE `languages` (
> > > >   `id` bigint(20) NOT NULL auto_increment,
> > > >   `LANGID` varchar(15) NOT NULL default '',
> > > >   `TEXTID` varchar(30) NOT NULL default '',
> > > >   `TEXT` varchar(255) NOT NULL default '',
> > > >   UNIQUE KEY `id` (`id`)
> > > > ) TYPE=InnoDB COMMENT='Table containing labels to be showed on the
> > > pages';
> > > >
> > > > (I don't think InnoDB is necessary for this table, since it is only
> > > read by
> > > > normal users, and loaded by installer: i kept that type only for
> > > compatibility
> > > > with your design).
> > > >
> > > > TEXTID is a code that identifies a specific label in very page. With
> > > some work
> > > > we can undertsand if the same label is going to be used on diffrent
> > > pages.
> > > > TEXT is the text that is going to appear on the browser.
> > > >
> > > > On the config.php file I've inserted another variable:
> > > > $DefaultLanguage="ITALIANO"; //of course you can put ENGLISH
> > > >
> > > > In session.inc i've inserted this line
> > > >     include ("language.php");
> > > > just after
> > > >     include("includes/ConnectDB.inc");
> > > >
> > > > As you can see in the attachment, language.php loads an array named
> > > $lang with
> > > > the contents of the table "languages".
> > > > By default it loads the $DefaultLanguage, but if the variable is not
> > > defined it
> > > > loads the English table.
> > > >
> > > > Then I simply substitute all the labels around the php and html code
> > > with the
> > > > corresponding entry in the $lang array.
> > > > As an example you can see in the attached login.php file the
following
> > > lines: 9,
> > > > 53, 57, 66.
> > > >
> > > > Having the labels in a db table can lead to another enhancement:
every
> > > user can
> > > > choose his/her own language. This could be useful for companies
having
> > > clients
> > > > spreaded around various countries....
> > > >
> > > > What do you think about?
> > > > Can we arrange my small improvement with the future developement you
> > > are making
> > > > in web-erp?
> > > >
> > > > Luca
> > > >
> > > >
> > > > Scrive Phil Daintree <p.d...@pa...>:
> > > >
> > > > > There has been some discussion about multi-language recently on
the
> > > > > list.
> > > > >
> > > > > I am prepared to maintain a rigorous log of changes to scripts.
> > > Perhaps
> > > > > I could produce a diff file for all changes on each release but
you
> > > > > would have to apply these changes to the italian version. I have
had
> > > a
> > > > > similar request from a spanish speaking person.
> > > > >
> > > > > An Italian version would be good.
> > > > >
> > > > > web-erp is not ideally suited to multi-language as you point out
> > > since
> > > > > all labels, print and echo statements would need to be modified
and
> > > > > changes in the core scripts would need to be applied to each
> > > language's
> > > > > scripts manually.
> > > > >
> > > > > Phil
> > > > >
> > > > >
> > > > > On Thu, 2004-07-29 at 17:28, ing. Luca
> > > Tur=?ISO-8859-1?Q?lon_Don=E0?=
> > > > > wrote:
> > > > > > Dear Phil,
> > > > > > a couple of friends, who ar starting up a new fashion company
here
> > > in
> > > > > italy,
> > > > > > are very interested in using the application you developed.
> > > > > >
> > > > > > Since they're not very acquainted with the english language and
> > > > > jargon, i need
> > > > > > to translate the application for them.
> > > > > >
> > > > > > I have various ways to do this: one is to simply browse the code
> > > and
> > > > > change
> > > > > > all the labels into italian. Doing so, i am very concerned about
> > > > > everytime you
> > > > > > give a new release: at that time I have to check every change in
> > > every
> > > > > single
> > > > > > file.
> > > > > > The other one is to modify the code in order to have a separate
> > > place
> > > > > in which
> > > > > > labels and all the language-dependent stuff are stored. This can
> > > be a
> > > > > DB table
> > > > > > or a file... i still don't know.
> > > > > > Before starting this, i need to know a couple of things:
> > > > > > First: are you going to do what I would like to do? In this case
> > > when
> > > > > do you
> > > > > > think you will release a multilingual version of web-erp? And:
do
> > > you
> > > > > need any
> > > > > > help? I'd be happy to help in any way.
> > > > > > Second: if you're not going to do the multilingual version, can
I
> > > work
> > > > > on it?
> > > > > > Can we synch our two different tracks (the improvement of the
> > > system
> > > > > that
> > > > > > maybe you are doing and my translation-multilingual effort)?
> > > > > >
> > > > > > Please give me an answer on this, since i am strongly sponsoring
> > > your
> > > > > > product...
> > > > > > Best Regards,
> > > > > > Luca
> > > > > >
> > > > > > PS: I am working on the translation of the manual. When
finished,
> > > I'll
> > > > > send it
> > > > > > to you.
> > > > > >
> > > > >
> > >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [Web-erp-developers] Interface

[Phil D. <ph...@du...>]

Great works in ie and Firefox @600x800

Phil
  ----- Original Message -----=20
  From: skaill=20
  To: web...@li...=20
  Sent: Tuesday, August 03, 2004 4:29 PM
  Subject: Re: [Web-erp-developers] Interface


  Thought some more.  I changed the font/bold.  Does it look good now?

  Steve
    ----- Original Message -----=20
    From: Daintrees=20
    To: web...@li...=20
    Sent: Monday, August 02, 2004 8:54 PM
    Subject: Re: [Web-erp-developers] Interface


    Its still wrapping - its not a huge deal.

    Phil
      ----- Original Message -----=20
      From: skaill=20
      To: web...@li...=20
      Sent: Tuesday, August 03, 2004 9:09 AM
      Subject: Re: [Web-erp-developers] Interface


      Ok, I think the 800x600 should not have Inquiries and Reports =
wrapping underneath the image now which should look better.  At the same =
time I made all the headings look better in positioning.

      Please take another look here http://weberp.gocom.ca to confirm =
when you get a chance.

      Steve
        ----- Original Message -----=20
        From: Daintrees=20
        To: web...@li...=20
        Sent: Monday, August 02, 2004 4:09 PM
        Subject: Re: [Web-erp-developers] Interface


        Looks better on a 1024x768 than on a 600x800 screen. The =
inquiries and reports heading has to wrap onto two lines.

        The spaced links are less intimidating block of text too.

        Great!


        Notice that the heading/title of the page is missing?

        Phil
          ----- Original Message -----=20
          From: skaill=20
          To: web...@li...=20
          Sent: Tuesday, August 03, 2004 4:40 AM
          Subject: Re: [Web-erp-developers] Interface


          Refined some more at http://weberp.gocom.ca including spacing =
out the action links.

          Steve
            ----- Original Message -----=20
            From: Daintrees=20
            To: web...@li...=20
            Sent: Sunday, August 01, 2004 9:08 PM
            Subject: Re: [Web-erp-developers] Interface


            By menu items I mean the links to action a specific option.
              ----- Original Message -----=20
              From: skaill=20
              To: web...@li...=20
              Sent: Monday, August 02, 2004 11:34 AM
              Subject: Re: [Web-erp-developers] Interface


              Have you looked in the past day or two, Phil?  Some of =
your comments may be before I did a bunch of work.  Hopefully you have =
some time to look again.  No question marks anymore and they were only =
temporary before I was going to create a help graphic.  Anyway, I think =
the way you did with the one Help at the top is good as long as we =
document clearly, possibly in the first online help screen, that the =
help will change contextually.  Possibly by the menu items you mean the =
menu_group_items or do you mean the main_menu?

              The menus would be javascript.  However, I believe when I =
did testing in several browsers on this site I created =
www.goldenwitch.com they worked on all.  Some people with various =
browsers could try going to that site to see if the drop-down menus work =
perfectly.  It is minimal and very standard javascript.  I agree with =
avoiding javascript, java and any other language as much as possible but =
you can't make drop-down menus unless you have code at the client side.  =
I think ALL languages besides PHP, HTML and CSS should be optional in =
the config or elsewhere.

              I still have to get up with the cvs thing.  I have it =
installed but haven't tried it out.  When I do something it's all at =
once so one day soon I'll be doing cvs and will send you.

              I saw the user and database in the newest demo.  Something =
else I noticed though was that the Help gave an error.  Can't remember =
exactly where or why right now though.

              Steve

                ----- Original Message -----=20
                From: Daintrees=20
                To: web...@li...=20
                Sent: Sunday, August 01, 2004 4:15 PM
                Subject: Re: [Web-erp-developers] Interface


                I guess this would be java?
                If it could be made to work in all forms of java then it =
would be a useful addition - I have tried to avoid it so far and have no =
knowlege personally. It is nice not to depend on java for anything. I =
agree it would be good.

                I would like to clean the css if you send me the files.=20

                I like the vertical oreintation of the menus - I think =
it needs some spacing between the menu items - they all merge together.
                As previously mentioned I am not so keen on the =
preponderance of question marks. I think this is probably superseeded =
following our discussion on the help.

                I already added the user and database to the titles - in =
2.9


                Phil



                  ----- Original Message -----=20
                  From: skaill=20
                  To: web...@li...=20
                  Sent: Monday, August 02, 2004 2:35 AM
                  Subject: [Web-erp-developers] Interface


                  I've been working with the interface quite a bit now.  =
For those who would like to see what I've done go to =
http://weberp.gocom.ca.  Please make many, many comments good or bad.

                  While I've been doing this I fixed some incorrect code =
and cleaned it up, especially the css.  There were several places that =
had commands which weren't actually being used and in fact would lead =
someone to think that what they were seeing should be different.  This =
is typical and I'm no exception but I took the time to do some cleanup.  =
I think it is easier to read and understand now.

                  Phil, if you like parts of this refined interface or =
all of it we can get it into the base product.  Let me know.

                  I'm seriously thinking about adding code that will do =
drop-down menus and allow a user option to specify whether they see the =
interface displayed now or they see drop-down menus.  With the drop-down =
menus it would allow everything to be accessible all the time with =
little screen space taken up.  It also looks pro.  Plus the fast access =
options become basically irrelevant with drop-down menus.

                  Steve

Re: [Web-erp-developers] Interface

[skaill <sk...@ro...>]

Thought some more.  I changed the font/bold.  Does it look good now?

Steve
  ----- Original Message -----=20
  From: Daintrees=20
  To: web...@li...=20
  Sent: Monday, August 02, 2004 8:54 PM
  Subject: Re: [Web-erp-developers] Interface


  Its still wrapping - its not a huge deal.

  Phil
    ----- Original Message -----=20
    From: skaill=20
    To: web...@li...=20
    Sent: Tuesday, August 03, 2004 9:09 AM
    Subject: Re: [Web-erp-developers] Interface


    Ok, I think the 800x600 should not have Inquiries and Reports =
wrapping underneath the image now which should look better.  At the same =
time I made all the headings look better in positioning.

    Please take another look here http://weberp.gocom.ca to confirm when =
you get a chance.

    Steve
      ----- Original Message -----=20
      From: Daintrees=20
      To: web...@li...=20
      Sent: Monday, August 02, 2004 4:09 PM
      Subject: Re: [Web-erp-developers] Interface


      Looks better on a 1024x768 than on a 600x800 screen. The inquiries =
and reports heading has to wrap onto two lines.

      The spaced links are less intimidating block of text too.

      Great!


      Notice that the heading/title of the page is missing?

      Phil
        ----- Original Message -----=20
        From: skaill=20
        To: web...@li...=20
        Sent: Tuesday, August 03, 2004 4:40 AM
        Subject: Re: [Web-erp-developers] Interface


        Refined some more at http://weberp.gocom.ca including spacing =
out the action links.

        Steve
          ----- Original Message -----=20
          From: Daintrees=20
          To: web...@li...=20
          Sent: Sunday, August 01, 2004 9:08 PM
          Subject: Re: [Web-erp-developers] Interface


          By menu items I mean the links to action a specific option.
            ----- Original Message -----=20
            From: skaill=20
            To: web...@li...=20
            Sent: Monday, August 02, 2004 11:34 AM
            Subject: Re: [Web-erp-developers] Interface


            Have you looked in the past day or two, Phil?  Some of your =
comments may be before I did a bunch of work.  Hopefully you have some =
time to look again.  No question marks anymore and they were only =
temporary before I was going to create a help graphic.  Anyway, I think =
the way you did with the one Help at the top is good as long as we =
document clearly, possibly in the first online help screen, that the =
help will change contextually.  Possibly by the menu items you mean the =
menu_group_items or do you mean the main_menu?

            The menus would be javascript.  However, I believe when I =
did testing in several browsers on this site I created =
www.goldenwitch.com they worked on all.  Some people with various =
browsers could try going to that site to see if the drop-down menus work =
perfectly.  It is minimal and very standard javascript.  I agree with =
avoiding javascript, java and any other language as much as possible but =
you can't make drop-down menus unless you have code at the client side.  =
I think ALL languages besides PHP, HTML and CSS should be optional in =
the config or elsewhere.

            I still have to get up with the cvs thing.  I have it =
installed but haven't tried it out.  When I do something it's all at =
once so one day soon I'll be doing cvs and will send you.

            I saw the user and database in the newest demo.  Something =
else I noticed though was that the Help gave an error.  Can't remember =
exactly where or why right now though.

            Steve

              ----- Original Message -----=20
              From: Daintrees=20
              To: web...@li...=20
              Sent: Sunday, August 01, 2004 4:15 PM
              Subject: Re: [Web-erp-developers] Interface


              I guess this would be java?
              If it could be made to work in all forms of java then it =
would be a useful addition - I have tried to avoid it so far and have no =
knowlege personally. It is nice not to depend on java for anything. I =
agree it would be good.

              I would like to clean the css if you send me the files.=20

              I like the vertical oreintation of the menus - I think it =
needs some spacing between the menu items - they all merge together.
              As previously mentioned I am not so keen on the =
preponderance of question marks. I think this is probably superseeded =
following our discussion on the help.

              I already added the user and database to the titles - in =
2.9


              Phil



                ----- Original Message -----=20
                From: skaill=20
                To: web...@li...=20
                Sent: Monday, August 02, 2004 2:35 AM
                Subject: [Web-erp-developers] Interface


                I've been working with the interface quite a bit now.  =
For those who would like to see what I've done go to =
http://weberp.gocom.ca.  Please make many, many comments good or bad.

                While I've been doing this I fixed some incorrect code =
and cleaned it up, especially the css.  There were several places that =
had commands which weren't actually being used and in fact would lead =
someone to think that what they were seeing should be different.  This =
is typical and I'm no exception but I took the time to do some cleanup.  =
I think it is easier to read and understand now.

                Phil, if you like parts of this refined interface or all =
of it we can get it into the base product.  Let me know.

                I'm seriously thinking about adding code that will do =
drop-down menus and allow a user option to specify whether they see the =
interface displayed now or they see drop-down menus.  With the drop-down =
menus it would allow everything to be accessible all the time with =
little screen space taken up.  It also looks pro.  Plus the fast access =
options become basically irrelevant with drop-down menus.

                Steve

Re: [Web-erp-developers] Interface

[skaill <sk...@ro...>]

I can only make it not wrap by making the font smaller.  However, before =
it was wrapping underneath the image which looked worse than now.

Steve
  ----- Original Message -----=20
  From: Daintrees=20
  To: web...@li...=20
  Sent: Monday, August 02, 2004 8:54 PM
  Subject: Re: [Web-erp-developers] Interface


  Its still wrapping - its not a huge deal.

  Phil
    ----- Original Message -----=20
    From: skaill=20
    To: web...@li...=20
    Sent: Tuesday, August 03, 2004 9:09 AM
    Subject: Re: [Web-erp-developers] Interface


    Ok, I think the 800x600 should not have Inquiries and Reports =
wrapping underneath the image now which should look better.  At the same =
time I made all the headings look better in positioning.

    Please take another look here http://weberp.gocom.ca to confirm when =
you get a chance.

    Steve
      ----- Original Message -----=20
      From: Daintrees=20
      To: web...@li...=20
      Sent: Monday, August 02, 2004 4:09 PM
      Subject: Re: [Web-erp-developers] Interface


      Looks better on a 1024x768 than on a 600x800 screen. The inquiries =
and reports heading has to wrap onto two lines.

      The spaced links are less intimidating block of text too.

      Great!


      Notice that the heading/title of the page is missing?

      Phil
        ----- Original Message -----=20
        From: skaill=20
        To: web...@li...=20
        Sent: Tuesday, August 03, 2004 4:40 AM
        Subject: Re: [Web-erp-developers] Interface


        Refined some more at http://weberp.gocom.ca including spacing =
out the action links.

        Steve
          ----- Original Message -----=20
          From: Daintrees=20
          To: web...@li...=20
          Sent: Sunday, August 01, 2004 9:08 PM
          Subject: Re: [Web-erp-developers] Interface


          By menu items I mean the links to action a specific option.
            ----- Original Message -----=20
            From: skaill=20
            To: web...@li...=20
            Sent: Monday, August 02, 2004 11:34 AM
            Subject: Re: [Web-erp-developers] Interface


            Have you looked in the past day or two, Phil?  Some of your =
comments may be before I did a bunch of work.  Hopefully you have some =
time to look again.  No question marks anymore and they were only =
temporary before I was going to create a help graphic.  Anyway, I think =
the way you did with the one Help at the top is good as long as we =
document clearly, possibly in the first online help screen, that the =
help will change contextually.  Possibly by the menu items you mean the =
menu_group_items or do you mean the main_menu?

            The menus would be javascript.  However, I believe when I =
did testing in several browsers on this site I created =
www.goldenwitch.com they worked on all.  Some people with various =
browsers could try going to that site to see if the drop-down menus work =
perfectly.  It is minimal and very standard javascript.  I agree with =
avoiding javascript, java and any other language as much as possible but =
you can't make drop-down menus unless you have code at the client side.  =
I think ALL languages besides PHP, HTML and CSS should be optional in =
the config or elsewhere.

            I still have to get up with the cvs thing.  I have it =
installed but haven't tried it out.  When I do something it's all at =
once so one day soon I'll be doing cvs and will send you.

            I saw the user and database in the newest demo.  Something =
else I noticed though was that the Help gave an error.  Can't remember =
exactly where or why right now though.

            Steve

              ----- Original Message -----=20
              From: Daintrees=20
              To: web...@li...=20
              Sent: Sunday, August 01, 2004 4:15 PM
              Subject: Re: [Web-erp-developers] Interface


              I guess this would be java?
              If it could be made to work in all forms of java then it =
would be a useful addition - I have tried to avoid it so far and have no =
knowlege personally. It is nice not to depend on java for anything. I =
agree it would be good.

              I would like to clean the css if you send me the files.=20

              I like the vertical oreintation of the menus - I think it =
needs some spacing between the menu items - they all merge together.
              As previously mentioned I am not so keen on the =
preponderance of question marks. I think this is probably superseeded =
following our discussion on the help.

              I already added the user and database to the titles - in =
2.9


              Phil



                ----- Original Message -----=20
                From: skaill=20
                To: web...@li...=20
                Sent: Monday, August 02, 2004 2:35 AM
                Subject: [Web-erp-developers] Interface


                I've been working with the interface quite a bit now.  =
For those who would like to see what I've done go to =
http://weberp.gocom.ca.  Please make many, many comments good or bad.

                While I've been doing this I fixed some incorrect code =
and cleaned it up, especially the css.  There were several places that =
had commands which weren't actually being used and in fact would lead =
someone to think that what they were seeing should be different.  This =
is typical and I'm no exception but I took the time to do some cleanup.  =
I think it is easier to read and understand now.

                Phil, if you like parts of this refined interface or all =
of it we can get it into the base product.  Let me know.

                I'm seriously thinking about adding code that will do =
drop-down menus and allow a user option to specify whether they see the =
interface displayed now or they see drop-down menus.  With the drop-down =
menus it would allow everything to be accessible all the time with =
little screen space taken up.  It also looks pro.  Plus the fast access =
options become basically irrelevant with drop-down menus.

                Steve

Re: [Web-erp-developers] Fw: Italian Translation of web-erp

[Daintrees <p.d...@pa...>]

I forwarded your comments to Luca - I dont think hes on the list.
Gettext is the way open-accounting did it.

Phil

----- Original Message -----=20
=46rom: "skaill" <sk...@ro...>
To: <web...@li...>
Sent: Tuesday, August 03, 2004 10:01 AM
Subject: Re: [Web-erp-developers] Fw: Italian Translation of web-erp


> This is an area that we will need to work on as well.  If Luca want=
s to
"get
> together" at some point to work on this I am available.
>
> I would point out to Luca that keeping the original English strings=
 in the
> code instead of using an identifier keeps the code WAY more readabl=
e.
> That's my opinion after having worked extensively with a product th=
at did
it
> with identifiers.  Code is scary to read when it has identifiers in=
stead
of
> literals.  Many will be thrown off by doing that.
>
> I have recently discovered a function in PHP called gettext which m=
ay be
for
> exactly what we are trying to do.  I don't know enough about it but=
 before
> doing our own coding for Multilanguage it would be nice to see if t=
he
built
> in gettext functionality will do it.
>
> Just guessing but I think loading the entire language file at the
beginning
> of each page may be much slower than doing a few reads within one p=
age.  A
> few lines versus hundreds to thousands.  Plus the memory for each u=
ser
would
> be way more.  Here's an idea that actually ends up a modified versi=
on of
> Luca's suggestion to keep the page number in the db.  Have an array=
 of
> strings at the top of each page where those strings are the strings=
 used
> within the page.  Call a language function that retrieves and retur=
ns all
of
> these at the page beginning.  When language(...) is called within t=
he
page,
> it first looks to see if the string was looked up already and uses =
that
> otherwise goes out to retrieve from the db, file or wherever.  This=
 will
> minimize the amount needing to be looked up yet look it up (or most=
 of it)
> all at once as Luca is suggesting.
>
> We can build in whatever is changed until September very easily.  I=
t's
just
> important to know which version Luca started on.
>
> I agree that db storage is the best for the Multilanguage informati=
on over
> another way such as file.
>
> Steve
>
> ----- Original Message -----=20
> From: "Daintrees" <p.d...@pa...>
> To: <web...@li...>
> Cc: <luc...@pd...>
> Sent: Monday, August 02, 2004 4:21 PM
> Subject: [Web-erp-developers] Fw: Italian Translation of web-erp
>
>
> Luca,
>
> I am not sure if you have joined the developers list, but I have
forwareded
> this email to them because I would like to run your proposal past t=
he
other
> interested and knowledgeable folk - hope you dont mind!
>
> We have a table of each script - that was added in 2.9 for the cont=
ext
> sensitive help (currently not language specific) - each script is g=
iven a
> unique id - this may also be helpful for security Steve - the idea =
of
> retrieving just the labels for the script being run is appealing as=
 is
> having a user interface for translators that doesnt involve editing=
 files.
> You have some good points. The best point of all - you are prepared=
 to do
a
> lot of work for the project - most appreciated.
>
> Lets just see if there are any other opinions/pitfalls that the res=
t of
the
> team see - so we dont trip and fall on this.
>
> Phil
>
> ----- Original Message -----=20
> From: "ing. Luca Turlon Don=E0" <luc...@pd...>
> To: "Phil Daintree" <p.d...@pa...>
> Sent: Tuesday, August 03, 2004 12:11 AM
> Subject: Re: Italian Translation of web-erp
>
>
> > Hi Phil.
> > I've been reading thru your mail several times before answering, =
cause
> wanted
> > to be sure to understand every single issue ou pointed out.
> >
> > The main consideration that comes out is that your approach is ve=
ry
> similar to
> > mine, i.e.:
> > -You are proposing a function call, I am proposing to use an arra=
y with
a
> > literal index.
> > -You are proposing several files with the translation, i am propo=
sing
> several
> > groups of rows in a table.
> >
> > Firts let me explain one thing: my idea consists in loading an ar=
ray
=66rom
> the
> > db, i.e.: in the beginning of every page I make a bulk load of al=
l the
> labels
> > in the language that has to be shown. So we do not have a full re=
ad
cycle
> > (connect-query-parse the query, disconnect) on the db for every s=
ingle
> label
> > in the page. We read everything at the beginning, load it in the =
lang
> array
> > and then use the lang array. This should address the second conce=
rn that
> you
> > put in your email. There is another thing: if we add a column on =
the db
> table,
> > containing the script (or an unique code which identifies the scr=
ipt)
that
> is
> > going to be rendered we can achieve two more thing: first we can =
load
just
> the
> > labels used in that script, reducing the size of the array. Secon=
dly we
> will
> > have a documentation of what is shown in every page.
> >
> > Regarding the other concern, i.e. the smallness of 30 chars for a=
 label
> > identifier, I believe that i could enlarge that column to a wider
string:
> i do
> > not see any problem on this.
> >
> > The last thing you say, that is the code should be easy understan=
dable.
> Maybe
> > you're right in considering the code easier to read having a full
english
> > label, but I think that a label identifier with some comment coul=
d do
the
> > same. In this way you could avoid the problem you mentioned about
changes
> in
> > the english labels.
> >
> > Please now let me tell some other things about the "function" app=
roach:
> > a) there is no other way than creating a php script to translate =
the
> > application. With the db approach I could create a page to let an=
y kind
of
> > user (not only a PHP programmer) manage the translation
> > b) it can become tough managing any new version of the system: wi=
th the
db
> you
> > can query and see how many entries you have for each language, an=
d you
can
> > easily identify which labels has to be translated. With the inclu=
ded
file
> > approach you have to work on the files, hoping that every file is
written
> with
> > exactly the same approach.
> > c) Since you must delegate people to translate (unless you know a=
t least
> 15
> > languages) you can loose control on the code: what if a russian s=
ends
you
> an
> > email saying that the system not working, just because the russia=
n
> translator
> > forgot a ";" in his code? With the db approach the worst thing th=
at
could
> > happen is a wrong translation or something written in English, bu=
t not
> > something that halts the system.
> > d) With the db you have a sort of documentation, which can help i=
n
> creating
> > help files...
> > e) it is at any time possible to automatically generate any langu=
age
> script,
> > i.e a language/italiano.php can be generated from the db and we c=
an
switch
> to
> > your "function" approach.
> > f) ther is another thing regarding the usage of the entire englis=
h label
> as a
> > parameter: imagine if you forget to put the function call. With t=
he
label
> > identifier you immediately see that there is something difficult =
to read
> on
> > the page. With the full english label you may even not notice the=
 error.
> >
> >
> > Finally: I do believe that the language variable should be kept, =
in the
> > future, in the session of the user, having each user working with
his/her
> own
> > language. For now I am just using a default language, but in the =
future
it
> can
> > be changed.
> >
> > One very last thing: I have to work on it, 'cause these friends o=
f mine
> needs
> > it, and I will work on the application making it multilanguage. I=
 will
go
> thru
> > the entire application, populating the db tables and changing the
scripts
> > where needed. After I will finish my job, I believe by the end of
> september, I
> > am going to send you the result of my job: thus you'll get a fini=
shed a
> work,
> > and you'd be not worried by having something not finished. The on=
ly
thing
> is
> > to understand what has changed from noew (or better from the 2.9 =
release
> of
> > the system) till the end of september.
> >
> > Luca
> >
> > Scrive Phil Daintree <p.d...@pa...>:
> >
> > > Hi Luca,
> > >
> > > There has been quite a bit of a discussion about multi-language=
 -
there
> > > are a lot of issues. Maybe I scare too easily, but it seems lik=
e a
> > > massive undertaking :-O
> > >
> > > Thanks so much for considering what is really quite a sizable p=
roject
> > > here. The other fear factor in taking this sort of thing on is =
if we
> > > start it I am the muggins that has a stuffed system if we can't=
 finish
> > > it. It sure would be great to make web-erp multi-language.
> > >
> > > I see the way you are heading with what you started .... my
over-riding
> > > and BIG worry in going to multi-language is that the code might=
 become
> > > more difficult to make sense of (of course it being in English =
must be
> > > quite a snag for those who use another language anyway). Under =
the
> > > scenario you are proposing we would, I guess have a varchar(30)
> > > description for the label that would be substituted by the TEXT=
 field.
> > > There a couple of reasons why I'm not that keen on this approac=
h:
> > >
> > > 1. 30 characters isn't much to describe the text variable. The =
full
> > > context that the label provides I think significantly improves =
the
> > > ability to understand code.
> > > 2. If this requires a query for every label then this could be =
quite
an
> > > overhead on the db and a potential delay for the user. (all use=
rs).
> > >
> > > Of the approaches discussed in the developers list - there is a=
n
archive
> > > of this http://sourceforge.net/mailarchive/forum.php?forum_id=
=3D34088
> > >
> > > I prefer Steve Kaill's approach and the approach used in
open-accounting
> > > ie enclosing the the full label in a function call eg.
> > >
> > > echo language("This is how I rekon we should do multi-language =
so the
> > > code remains relatively easy to read");
> > >
> > > the language function returns the language string required by t=
he
user.
> > >
> > > We hold a $_SESSION['language'] variable which is stored in the
> > > www_users table and retreived at the time of login.
> > >
> > > This language variable would be the same name as the file to in=
clude
> > > under a new languages directory.
> > >
> > > The function language would be in this include directory.
> > >
> > > The function language then takes the text of the english label =
as a
> > > parameter - the $SESSION['language'] is defined as global insid=
e this
> > > function and returns the the language string appropriate - if t=
here is
> > > no match for the string parameter passed then the parameter ie =
the
> > > english label is returned.
> > >
> > > The english language function in languages/english.php would ju=
st
return
> > > the parameter itself.
> > >
> > > I have not gone down the track of considering if the label
substitution
> > > is done using an array or what .... I would probably take a loo=
k at
> > > open-accounting logic.
> > >
> > > This approach does retain a critical requirement for webERP ie =
that of
> > > easily understandable code.
> > >
> > > All approaches have their down side -
> > >
> > > 1. This puts the overhead on the web-server/ php interpreter. H=
owever,
> > > this is pretty fast.However,potentially significant memory is
required -
> > > for what I have tried desperately to be minimalist in terms of
resources
> > > required to run it.
> > >
> > > 2. Anyone changing the english labels will stuff up the transla=
tion
file
> > > ie the include file of strings in english with the equivalent l=
anguage
> > > string!
> > >
> > > Do you see any other snags with this approach Luca?
> > > Could you consider a slightly different approach?
> > >
> > > Phil
> > >
> > >
> > > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=3D?ISO-8859-1?Q?lon_=
Don=3DE0?=3D
> > > wrote:
> > > > Hello Phil,
> > > > I've started to work on it.
> > > > Here is how I want to address the issue.
> > > > First I am going to create a table containing all the labels
> > > >
> > > > CREATE TABLE `languages` (
> > > >   `id` bigint(20) NOT NULL auto_increment,
> > > >   `LANGID` varchar(15) NOT NULL default '',
> > > >   `TEXTID` varchar(30) NOT NULL default '',
> > > >   `TEXT` varchar(255) NOT NULL default '',
> > > >   UNIQUE KEY `id` (`id`)
> > > > ) TYPE=3DInnoDB COMMENT=3D'Table containing labels to be show=
ed on the
> > > pages';
> > > >
> > > > (I don't think InnoDB is necessary for this table, since it i=
s only
> > > read by
> > > > normal users, and loaded by installer: i kept that type only =
for
> > > compatibility
> > > > with your design).
> > > >
> > > > TEXTID is a code that identifies a specific label in very pag=
e. With
> > > some work
> > > > we can undertsand if the same label is going to be used on di=
ffrent
> > > pages.
> > > > TEXT is the text that is going to appear on the browser.
> > > >
> > > > On the config.php file I've inserted another variable:
> > > > $DefaultLanguage=3D"ITALIANO"; //of course you can put ENGLIS=
H
> > > >
> > > > In session.inc i've inserted this line
> > > >     include ("language.php");
> > > > just after
> > > >     include("includes/ConnectDB.inc");
> > > >
> > > > As you can see in the attachment, language.php loads an array=
 named
> > > $lang with
> > > > the contents of the table "languages".
> > > > By default it loads the $DefaultLanguage, but if the variable=
 is not
> > > defined it
> > > > loads the English table.
> > > >
> > > > Then I simply substitute all the labels around the php and ht=
ml code
> > > with the
> > > > corresponding entry in the $lang array.
> > > > As an example you can see in the attached login.php file the
following
> > > lines: 9,
> > > > 53, 57, 66.
> > > >
> > > > Having the labels in a db table can lead to another enhanceme=
nt:
every
> > > user can
> > > > choose his/her own language. This could be useful for compani=
es
having
> > > clients
> > > > spreaded around various countries....
> > > >
> > > > What do you think about?
> > > > Can we arrange my small improvement with the future developem=
ent you
> > > are making
> > > > in web-erp?
> > > >
> > > > Luca
> > > >
> > > >
> > > > Scrive Phil Daintree <p.d...@pa...>:
> > > >
> > > > > There has been some discussion about multi-language recentl=
y on
the
> > > > > list.
> > > > >
> > > > > I am prepared to maintain a rigorous log of changes to scri=
pts.
> > > Perhaps
> > > > > I could produce a diff file for all changes on each release=
 but
you
> > > > > would have to apply these changes to the italian version. I=
 have
had
> > > a
> > > > > similar request from a spanish speaking person.
> > > > >
> > > > > An Italian version would be good.
> > > > >
> > > > > web-erp is not ideally suited to multi-language as you poin=
t out
> > > since
> > > > > all labels, print and echo statements would need to be modi=
fied
and
> > > > > changes in the core scripts would need to be applied to eac=
h
> > > language's
> > > > > scripts manually.
> > > > >
> > > > > Phil
> > > > >
> > > > >
> > > > > On Thu, 2004-07-29 at 17:28, ing. Luca
> > > Tur=3D?ISO-8859-1?Q?lon_Don=3DE0?=3D
> > > > > wrote:
> > > > > > Dear Phil,
> > > > > > a couple of friends, who ar starting up a new fashion com=
pany
here
> > > in
> > > > > italy,
> > > > > > are very interested in using the application you develope=
d.
> > > > > >
> > > > > > Since they're not very acquainted with the english langua=
ge and
> > > > > jargon, i need
> > > > > > to translate the application for them.
> > > > > >
> > > > > > I have various ways to do this: one is to simply browse t=
he code
> > > and
> > > > > change
> > > > > > all the labels into italian. Doing so, i am very concerne=
d about
> > > > > everytime you
> > > > > > give a new release: at that time I have to check every ch=
ange in
> > > every
> > > > > single
> > > > > > file.
> > > > > > The other one is to modify the code in order to have a se=
parate
> > > place
> > > > > in which
> > > > > > labels and all the language-dependent stuff are stored. T=
his can
> > > be a
> > > > > DB table
> > > > > > or a file... i still don't know.
> > > > > > Before starting this, i need to know a couple of things:
> > > > > > First: are you going to do what I would like to do? In th=
is case
> > > when
> > > > > do you
> > > > > > think you will release a multilingual version of web-erp?=
 And:
do
> > > you
> > > > > need any
> > > > > > help? I'd be happy to help in any way.
> > > > > > Second: if you're not going to do the multilingual versio=
n, can
I
> > > work
> > > > > on it?
> > > > > > Can we synch our two different tracks (the improvement of=
 the
> > > system
> > > > > that
> > > > > > maybe you are doing and my translation-multilingual effor=
t)?
> > > > > >
> > > > > > Please give me an answer on this, since i am strongly spo=
nsoring
> > > your
> > > > > > product...
> > > > > > Best Regards,
> > > > > > Luca
> > > > > >
> > > > > > PS: I am working on the translation of the manual. When
finished,
> > > I'll
> > > > > send it
> > > > > > to you.
> > > > > >
> > > > >
> > >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the change=
s on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? N=
ow,
> one more big change to announce. We are now OSTG- Open Source Techn=
ology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the change=
s on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? N=
ow,
> one more big change to announce. We are now OSTG- Open Source Techn=
ology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>