web-erp-developers — Discussion on development of webERP

[Web-erp-developers] Contribution Guidelines - 3rd Draft

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

I have removed all references to I (I hope) and clarified the Javascript
issue. I think that if there is a chance of it not working for one
browser/client machine/PDA then there has to be another way to fulfil
the function based just on PHP and plain vanilla html.

I slapped the modified Contribution Guidelines up on sourceforge at:

http://sourceforge.net/docman/display_doc.php?docid=24138&group_id=70949

as well as under the doc directory.


Phil

[Web-erp-developers] PDFCustomerList.php

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

Team,

I am stuck on a script PDFCustomerList.php it goes with
includes/PDFCustomerListPageHeader.inc to produce a report of customer
address, branch delivery addresses etc by Sales Territory and
Salespeson.

I have puzzled for too long on some obscure syntax error and wondered if
anyone else can figure it out - it going to be something simple and I'll
be embarassed but hey!

Thanks

Phil

[Web-erp-developers] Updates to CVS

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

I uploaded Steve's modifications to the main menu (index.php and
includes/header.inc) I think it looks better but an accountants
impression of what looks good may not be worth much. Steve likes it too!

Phil

Re: [Web-erp-developers] Contribution Guidelines - 2nd Draft

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

I think what is trying to be said is absolutely no Java and Javascript is
not encouraged except in some specific instances and those instances must
have an alternate non-javascript way such that an option in config.php or
elsewhere allows the user to select between the regular or Javascript way.

Phil, can you confirm.

Steve

----- Original Message ----- 
From: "Olwen Williams" <ol...@ha...>
To: <web...@li...>
Sent: Saturday, August 07, 2004 7:29 AM
Subject: Re: [Web-erp-developers] Contribution Guidelines - 2nd Draft


> In #3 should you be saying Java or Javascript?  They are not the same
> requirements are quite different.  My personal preference is to use
> small amounts of javascript, but not java.  I'm not aware of the
> presence/absence of javascript on PDA's  .
>
> Phil Daintree wrote:
> >
> > 3. Platform independence.
> >
> > I have steered deliberately away from Java due to the inconsistencies
> > between implimentations.
> > Java also increases the bandwidth requirements with downloading the
> > software - although I recognise there can also be a saving in "round
> > trips" to the server. However, Java is not available on some PDA
> > browsers and it takes memory and processing power at the client. Aim
> > number 1 requires us to keep the software requirements at the browser
> > end as minimal as  possible - just a pdf reader and any browser.
>
>
>
> -------------------------------------------------------
> 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] Contribution Guidelines - 2nd Draft

[Olwen W. <ol...@ha...>]

In #3 should you be saying Java or Javascript?  They are not the same 
requirements are quite different.  My personal preference is to use 
small amounts of javascript, but not java.  I'm not aware of the 
presence/absence of javascript on PDA's  .

Phil Daintree wrote:
> 
> 3. Platform independence.
> 
> I have steered deliberately away from Java due to the inconsistencies
> between implimentations.
> Java also increases the bandwidth requirements with downloading the
> software - although I recognise there can also be a saving in "round
> trips" to the server. However, Java is not available on some PDA
> browsers and it takes memory and processing power at the client. Aim
> number 1 requires us to keep the software requirements at the browser
> end as minimal as  possible - just a pdf reader and any browser.

Re: [Web-erp-developers] Contribution Guidelines - 2nd Draft

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

Steve,

Thanks for the feedback ...

I should take out references to I and lose this sentence ..

On Sat, 2004-08-07 at 21:42, skaill wrote:
> In goals,
> 
> 4. By use of plain English do you mean comments, message strings, ....?
> 

Re: [Web-erp-developers] Contribution Guidelines - 2nd Draft

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

In goals,

4. By use of plain English do you mean comments, message strings, ....?

In contributions,

5. I was wondering where the change.log was but found it in webERP > doc...

Steve 

----- Original Message ----- 
From: "Phil Daintree" <p.d...@pa...>
To: <web...@li...>
Sent: Friday, August 06, 2004 10:28 PM
Subject: [Web-erp-developers] Contribution Guidelines - 2nd Draft


> 
> I have drafted up another shot at contribution guidelines - once
> everyone is happy with it I will put it up as a document on sourceforge.
> 
> As always - comments appreciated.
> 
> Phil
> 
> GOALS of webERP
> 
> 1. To provide fast, web-based, integrated "best practise" business
> administration software.
> 
> 2. To be "low footprint" efficient and fast, with absolutely minimal
> network traffic.
> 
> This is to enable dial up/low band-width connections to work with
> reasonable response times. This will require some compromises with the
> use of graphics.
> 
> 3. Platform independence.
> 
> I have steered deliberately away from Java due to the inconsistencies
> between implimentations.
> Java also increases the bandwidth requirements with downloading the
> software - although I recognise there can also be a saving in "round
> trips" to the server. However, Java is not available on some PDA
> browsers and it takes memory and processing power at the client. Aim
> number 1 requires us to keep the software requirements at the browser
> end as minimal as  possible - just a pdf reader and any browser.
> 
> 4. Scripts easily readable and modifiable by a business.
> 
> You will notice extensive use of plain english throughout.
> PHP code written using control structures in a consistent way
> throughout. (See style guide)
> Well spaced and rigorously indented.
> Extensive commenting.
> Long descriptive variable names.
> There is also an interesting compromise between good programming
> practise in maximising code reuse through the use of includes, classes
> and common functions and in the number of separate scripts required to
> be understood before a developer has enough condidence to consider
> modifying the script. I believe that too many levels of abstraction can
> detract from ease of understanding the script. webERP uses a few common
> include files that must be understood:
> 
> includes/ConnectDB.inc   - database abstraction
> includes/session.inc - initiation of session and security checking
> includes/header.inc - page headings and quick menu links
> includes/footer.inc - page footer
> includes/PDFStarter_ros.inc - PDF report generation substitute for
> session.inc
> includes/DateFunctions.inc - Date functions
> 
> and config.php which is included by includes/session.inc. Most scripts
> use all the first 4. Transactional scripts also use an
> includes/DefineXXXXXXClass.php script. Apart from these files most
> scripts are otherwise self contained so that a knowledge of these
> includes and the script should be all thats needed to be confident in
> modifying the script.
> 
> CONTRIBUTIONS
> 
> Contributions to the webERP project are encouraged - these simple
> procedures for doing so are aimed at reducing the confusion and
> co-ordinating the efforts of all contributors:
> 
> 1.Join the developers mailing list.
> 
> http://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 
> Inform the list of your proposed developments and discuss the approach
> to be used. There are some knowlegable people on the list and they can
> contribute ideas if you let them. This is also good to avoid overlapping
> effort or combine efforts in working on different elements of the same
> project.
> 
> 2. Obtain the latest development scripts from CVS - see sourceforge
> instructions for anonymous cvs checkout the CVS files intially then
> updates daily - this only downloads any modified scripts, or update
> immediately before commencing any development.
> 
> http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1
> 
> 3. After any modifications to the scripts - email (only) the modified
> scripts (or ideally a diff file between the latest CVS scripts and your
> updated scripts) to dai...@so... within 12 hours of your
> last update from CVS. The project admin will have to digest the
> modifications and ensure the coding style is consistent, test the
> scripts and consider the implications of the modifications in acheiving
> the goals noted above. Plenty of narrative explaining the modifications
> should be posted in the developers list so all can consider the
> implications. They will be committed to CVS as soon as possible after
> receipt and testing. Only the project admin has write access to CVS.
> 
> 4. Where modifications span 10 or more scripts at the same time, request
> a stay on development from other developers using the list.
> 
> 5. All submissions of modifications or additions should be accompanied
> by a plain text change.log file describing the changes to each script.
> This explains to everyone the nature of the changes made. Each entry in
> the change log should state the developer name and date of the 
> change/addition. This file will be appended to the doc/change.log when
> the files are committed to CVS.
> 
> 6. Requests for modification of the database structure - with an extract
> of the SQL required to effect the changes should be made to
> dai...@so... These will be included in the version upgrage
> script as well as the latest database structure.
> 
> 
> 
> CODING STANDARDS
> 
> Function/Class/Variable Naming
> 
> Descriptive names should be used in preference to short variable names:
> 
> eg.
> 
> $a = 3.14159;
> 
> should be avoided in favour of:
> 
> $Pi = 3.14159;
> 
> The variable $i can be used as a counter.
> 
> As displayed above, there should be one space on either side of an
> equals sign used to assign the return value of a function to a variable.
> In the case of a block of related assignments, more space may be
> inserted to promote readability:
> 
> $Short         = foo($bar);
> $LongVariable = foo($baz);
> 
> Good descriptive variable names consisting of several words appended
> togther should have the first letter of each word capitalised.
> 
> eg.
> $longvariablename = 1;
> 
> should be written as:
> 
> $LongVariableName = 1;
> 
> 
> PHP Variables
> 
> The PHP variable arrays $_POST, $_GET, $_SERVER, $_SESSION provide
> context about where a variable comes from - many developers are tempted
> to abbreviate:
> 
> $StartingCustomer = $_POST['StartingCustomer'];
> 
> or worse:
> 
> $s = $_POST['StartingCustomer'];
> 
> This should be avoided in favour of using $_POST['StartAtCustomer']
> everywhere it is required so the reader can see where the variable comes
> from.
> 
> However, variables which could come from either a $_GET or a $_POST
> and/or a $_SESSION may be assigned as in the first example since there
> is no value in the context.
> 
> 
> Control Structures
> 
> All control structures (these include if, for, while, switch) must
> always use statement blocks.
> You  are  strongly  encouraged  to  always  use  curly  braces even in
> situations  where they are technically optional. Having them increases
> readability  and  decreases  the  likelihood  of  logic errors  being
> introduced when new lines are added.
> 
> eg.
> if ($VariableName == true)
> 
> echo "Variable was true";
> 
> whilst legal PHP syntax, this should be avoided in favour of the
> following syntax:
> 
> if ($VariableName == true) {
> 
> echo "Variable was true";
> }
> 
> Parenthesis should open on the same line (after a space) as the
> initiating control structure and close the statement block at the same
> level of indenting as the initiating line.
> 
> Else statements should be on the same line as the closing statment block
> from the preceeding elseif or if statement eg.
> 
> if ($VariableName == true) {
> 
> echo "Variable was true";
> 
> } else {
> 
> echo "Variable was false";
> 
> } /*end else $VariableName was false*/
> 
> This is the only time there should be anything other than a comment on
> the closing curly brace line. Comments on a closing curly brace line
> where the block has been quite a few lines of code are encouraged to
> show the control structure to which they related.
> 
> Whenever a statement block is used code within the block should be one
> tab indented.
> 
> Function defintions should follow the same conventions.
> 
> It  is  recommended  that  you  break  lines  at  approximately  75-85
> characters.
> 
> 
> Spacing
> 
> Where readability is improved lines of code should be separated by a
> line
> 
> 
> Comments
> 
> C style comment blocks in the format:
> 
> /* comments in here */
> 
> are preferred. But all comments gratefully received!
> 
> 
> Database Function Calls
> 
> There should never be any database specific calls in scripts other than
> includes/ConnectDB.inc
> All database calls should be performed by calling the abstraction
> functions in that script.
> 
> 
> SQL
> 
> Should be as ANSI compliant as possible.
> 
> SQL statements should be on several lines for easier reading eg.
> 
> $sql = "SELECT TransNo, TranDate, DebtorTrans.DebtorNo, BranchCode,
> Reference, InvText, Order_, Rate, OvAmount+OvGST+OvFreight+OvDiscount AS
> TotalAmt, CurrCode FROM DebtorTrans INNER JOIN DebtorsMaster ON
> DebtorTrans.DebtorNo=DebtorsMaster.DebtorNo WHERE ";
> 
> 
> is harder to read than:
> 
> $sql = "SELECT TransNo,
> TranDate,
> DebtorTrans.DebtorNo,
> BranchCode, Reference,
> InvText,
> Order_,
> Rate,
> OvAmount+OvGST+OvFreight+OvDiscount AS TotalAmt,
> CurrCode
> FROM
> DebtorTrans INNER JOIN DebtorsMaster
> ON DebtorTrans.DebtorNo=DebtorsMaster.DebtorNo
> WHERE ";
> 
> 
> Constants
> 
> Constants should always be all-uppercase, with underscores to separate
> words.
> 
> 
> PHP Code Tags
> 
> Always use <?php ?> to delimit PHP code, not the <? ?> shorthand. This
> is the most portable way to include PHP code on differing operating
> systems and setups.
> 
> 
> 
> -------------------------------------------------------
> 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

[Web-erp-developers] Contribution Guidelines - 2nd Draft

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

I have drafted up another shot at contribution guidelines - once
everyone is happy with it I will put it up as a document on sourceforge.

As always - comments appreciated.

Phil

GOALS of webERP

1. To provide fast, web-based, integrated "best practise" business
administration software.

2. To be "low footprint" efficient and fast, with absolutely minimal
network traffic.

This is to enable dial up/low band-width connections to work with
reasonable response times. This will require some compromises with the
use of graphics.

3. Platform independence.

I have steered deliberately away from Java due to the inconsistencies
between implimentations.
Java also increases the bandwidth requirements with downloading the
software - although I recognise there can also be a saving in "round
trips" to the server. However, Java is not available on some PDA
browsers and it takes memory and processing power at the client. Aim
number 1 requires us to keep the software requirements at the browser
end as minimal as  possible - just a pdf reader and any browser.

4. Scripts easily readable and modifiable by a business.

You will notice extensive use of plain english throughout.
PHP code written using control structures in a consistent way
throughout. (See style guide)
Well spaced and rigorously indented.
Extensive commenting.
Long descriptive variable names.
There is also an interesting compromise between good programming
practise in maximising code reuse through the use of includes, classes
and common functions and in the number of separate scripts required to
be understood before a developer has enough condidence to consider
modifying the script. I believe that too many levels of abstraction can
detract from ease of understanding the script. webERP uses a few common
include files that must be understood:

includes/ConnectDB.inc   	- database abstraction
includes/session.inc	 	- initiation of session and security checking
includes/header.inc 	 	- page headings and quick menu links
includes/footer.inc	 	- page footer
includes/PDFStarter_ros.inc	- PDF report generation substitute for
session.inc
includes/DateFunctions.inc	- Date functions

and config.php which is included by includes/session.inc. Most scripts
use all the first 4. Transactional scripts also use an
includes/DefineXXXXXXClass.php script. Apart from these files most
scripts are otherwise self contained so that a knowledge of these
includes and the script should be all thats needed to be confident in
modifying the script.

CONTRIBUTIONS

Contributions to the webERP project are encouraged - these simple
procedures for doing so are aimed at reducing the confusion and
co-ordinating the efforts of all contributors:

1.Join the developers mailing list.

http://lists.sourceforge.net/lists/listinfo/web-erp-developers

Inform the list of your proposed developments and discuss the approach
to be used. There are some knowlegable people on the list and they can
contribute ideas if you let them. This is also good to avoid overlapping
effort or combine efforts in working on different elements of the same
project.

2. Obtain the latest development scripts from CVS - see sourceforge
instructions for anonymous cvs checkout the CVS files intially then
updates daily - this only downloads any modified scripts, or update
immediately before commencing any development.

http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1

3. After any modifications to the scripts - email (only) the modified
scripts (or ideally a diff file between the latest CVS scripts and your
updated scripts) to dai...@so... within 12 hours of your
last update from CVS. The project admin will have to digest the
modifications and ensure the coding style is consistent, test the
scripts and consider the implications of the modifications in acheiving
the goals noted above. Plenty of narrative explaining the modifications
should be posted in the developers list so all can consider the
implications. They will be committed to CVS as soon as possible after
receipt and testing. Only the project admin has write access to CVS.

4. Where modifications span 10 or more scripts at the same time, request
a stay on development from other developers using the list.

5. All submissions of modifications or additions should be accompanied
by a plain text change.log file describing the changes to each script.
This explains to everyone the nature of the changes made. Each entry in
the change log should state the developer name and date of the 
change/addition. This file will be appended to the doc/change.log when
the files are committed to CVS.

6. Requests for modification of the database structure - with an extract
of the SQL required to effect the changes should be made to
dai...@so... These will be included in the version upgrage
script as well as the latest database structure.



CODING STANDARDS

Function/Class/Variable Naming

Descriptive names should be used in preference to short variable names:

eg.

$a = 3.14159;

should be avoided in favour of:

$Pi = 3.14159;

The variable $i can be used as a counter.

As displayed above, there should be one space on either side of an
equals sign used to assign the return value of a function to a variable.
In the case of a block of related assignments, more space may be
inserted to promote readability:

$Short         = foo($bar);
$LongVariable = foo($baz);

Good descriptive variable names consisting of several words appended
togther should have the first letter of each word capitalised.

eg.
$longvariablename = 1;

should be written as:

$LongVariableName = 1;


PHP Variables

The PHP variable arrays $_POST, $_GET, $_SERVER, $_SESSION provide
context about where a variable comes from - many developers are tempted
to abbreviate:

$StartingCustomer = $_POST['StartingCustomer'];

or worse:

$s = $_POST['StartingCustomer'];

This should be avoided in favour of using $_POST['StartAtCustomer']
everywhere it is required so the reader can see where the variable comes
from.

However, variables which could come from either a $_GET or a $_POST
and/or a $_SESSION may be assigned as in the first example since there
is no value in the context.


Control Structures

All control structures (these include if, for, while, switch) must
always use statement blocks.
You  are  strongly  encouraged  to  always  use  curly  braces even in
situations  where they are technically optional. Having them increases
readability  and  decreases  the  likelihood  of  logic errors  being
introduced when new lines are added.

eg.
if ($VariableName == true)

	echo "Variable was true";

whilst legal PHP syntax, this should be avoided in favour of the
following syntax:

if ($VariableName == true) {

	echo "Variable was true";
}

Parenthesis should open on the same line (after a space) as the
initiating control structure and close the statement block at the same
level of indenting as the initiating line.

Else statements should be on the same line as the closing statment block
from the preceeding elseif or if statement eg.

if ($VariableName == true) {

	echo "Variable was true";

} else {

	echo "Variable was false";

} /*end else $VariableName was false*/

This is the only time there should be anything other than a comment on
the closing curly brace line. Comments on a closing curly brace line
where the block has been quite a few lines of code are encouraged to
show the control structure to which they related.

Whenever a statement block is used code within the block should be one
tab indented.

Function defintions should follow the same conventions.

It  is  recommended  that  you  break  lines  at  approximately  75-85
characters.


Spacing

Where readability is improved lines of code should be separated by a
line


Comments

C style comment blocks in the format:

/* comments in here */

are preferred. But all comments gratefully received!


Database Function Calls

There should never be any database specific calls in scripts other than
includes/ConnectDB.inc
All database calls should be performed by calling the abstraction
functions in that script.


SQL

Should be as ANSI compliant as possible.

SQL statements should be on several lines for easier reading eg.

$sql = "SELECT TransNo, TranDate, DebtorTrans.DebtorNo, BranchCode,
Reference, InvText, Order_, Rate, OvAmount+OvGST+OvFreight+OvDiscount AS
TotalAmt, CurrCode FROM DebtorTrans INNER JOIN DebtorsMaster ON
DebtorTrans.DebtorNo=DebtorsMaster.DebtorNo WHERE ";


is harder to read than:

$sql = "SELECT TransNo,
		TranDate,
		DebtorTrans.DebtorNo,
		BranchCode, Reference,
		InvText,
		Order_,
		Rate,
		OvAmount+OvGST+OvFreight+OvDiscount AS TotalAmt,
		CurrCode
	FROM
		DebtorTrans INNER JOIN DebtorsMaster
		ON DebtorTrans.DebtorNo=DebtorsMaster.DebtorNo
	WHERE ";


Constants

Constants should always be all-uppercase, with underscores to separate
words.


PHP Code Tags

Always use <?php ?> to delimit PHP code, not the <? ?> shorthand. This
is the most portable way to include PHP code on differing operating
systems and setups.

Fw: [Web-erp-developers] Serialization and BOM

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

A clarification.  I didn't mean to be saying that web-erp follows all of
PEAR.  I was only referring to the coding standards section within PEAR.

Steve

----- Original Message ----- 
From: "skaill" <sk...@ro...>
To: <web...@li...>
Sent: Thursday, August 05, 2004 2:15 PM
Subject: Re: [Web-erp-developers] Serialization and BOM


> I think Phil mentioned PEAR which can be found here
> http://pear.php.net/manual/en/standards.php
> It is a short and easy read.  Basically it's what they teach in school or
> you've seen in lots of good programs.  Chances are you're doing already.
>
> Steve
>
> ----- Original Message ----- 
> From: "Danie Brink" <br...@na...>
> To: <web...@li...>
> Sent: Wednesday, August 04, 2004 7:07 PM
> Subject: Re: [Web-erp-developers] Serialization and BOM
>
>
> > Hi Peter
> >
> > I don't know if any of the other guys are awake right now, so I will try
> to
> > answer some of your questions.
> >
> > Serialization has been build into the stock to some extend Phil and
Jessie
> > worked on this, so they will probably fill you in on serialization.
> >
> > BOMS already have multilevel support in that a manufactured item with
its
> own
> > BOM may be used within another BOM. There is however no single interface
> to
> > edit a tree like structure.
> >
> > Reporting of the BOM Tree are also lacking although with a bit of work
it
> is
> > possible to build such a report.
> >
> > Like all of us go ahead, look through the code and if you feel up to it
go
> ahead
> > and try. If you would like to run it past the the list do so. Phil is
> fearly
> > strict on the source code structure ( not overly so, but he has a point)
> on the
> > way he would like the code. Have a look at the current code you will see
> he
> > likes to keep every file as self contained as possible.
> > He or someone else will probably mention it again soon. :)
> >
> > Someone mentioned a while back where we could find the standard Phil
would
> like
> > us to use, If someone could tell us again. Also mabe Phil could put it
on
> the
> > Source Forge Site as well under some FAQ. Just a thought. *wink-wink*
> >
> > There is also some work under way on work orders and costing by me and
my
> guys,
> > And we are also doing some work on the taxes and manuals. We will
> contribute it
> > back and Phil will decide what he want's to include. It's his baby and
he
> did a
> > good job so far.
> >
> > Kind Regards
> > Danie Brink
> >
> > Quoting Peter <use...@gm...>:
> >
> > > I've shown Web-ERP to my manager and he was very impressed. It far
> > > surpasses any open source ERP software we have used.
> > >
> > > Among a couple of small features, some requirements he had:
> > >
> > > * The support of serialized stock
> > > * BOM reporting
> > > * Milti - level BOM
> > >
> > > Has development started on these features? If so, can I help? If
> > > development has not started, a co-worker and I can start developing
> > > these.
> > >
> > > I have programmed some in PHP and MySQL and I have done a lot of
> > > programming in other languages including C++ so I understand the OOP
> > > mentality.
> > >
> > > ~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
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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] Re: TAX / VAT

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

Ok had a look, this problem will be solved. You will be able to set up 
the tax matrix as in first example. However I see th eproblem with the 
branches/locations in regards to the GL Accounts, I will have a look and 
see if I can allow for this without enforcing it.

The changes will however have a significant impact so I will break it up 
into two phases 1 st phase will only allow for different taxes but not 
different accounts per location. What is left out will become part of 
Phase II

I am still not to clear on the COST of Sales side but I will cover that 
after Phase II, I still need to do one more tax php page and then fix up 
the refferntial stuff as well as all the pages referencing th eprevious 
taxes. And I need to be carefull. Once I get the same results I can 
focus on the Cost Of Sales problem.

Hope this helps.

Kind Regads
Danie Brink

Kind Regards.


Dirk Eversmann wrote:

> Hello,
>
> to understand my difficulties, please visit http://tax.grade.de/vat.txt
>
> 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] Re: TAX / VAT

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

Hi Thanks will have a look.


Dirk Eversmann wrote:

> Hello,
>
> to understand my difficulties, please visit http://tax.grade.de/vat.txt
>
> 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
>
>

[Web-erp-developers] Numbers in Europe

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

Someone had a comment about changing commas to periods for Europe (and =
elsewhere).  We were talking about a solution that involved  thousands =
and decimal variables in config.  I've run across the commands in php =
called setlocale and localeconv that would appear to be able to do this =
and much more.  That person may want to lookup setlocale in the php =
manual for more info.  Looks like it sets decimal places and all sorts =
of others too.

Steve

Re: [Web-erp-developers] Re: Web-erp Multilanguage developement

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

Two comments about the textualid/token use instead of looking up by actual
string.

Firstly, most strings will not be very long.  Of course many will be more
than 40 characters but unlikely to be more than a couple of sentences.  If
they were going to be long then the developer would likely put into the
database as opposed to hard coding.

Secondly, it is my belief, unless someone can say different, that this
greater string length will be no faster or slower in database lookup.  The
database will have them indexed either way and would not go beyond the
character that makes it distinct.  e.g.

"Hello world"

"Hello dinner"

At the w and d these two strings are different and will be indexed in that
way to be found at the w and d difference.  The parameter pass to the
function (be it Luca's or gettext) will not take more or less time either as
long as it is passed by reference (VAR) as opposed to a value that gets a
copy.

Steve

----- Original Message ----- 
From: "Daintrees" <p.d...@pa...>
To: <luc...@pd...>
Cc: <web...@li...>
Sent: Friday, August 06, 2004 6:05 AM
Subject: [Web-erp-developers] Re: Web-erp Multilanguage developement


Luca,

I didn't see the index.php script you sent must have missed that email -
will hunt through my archive.

I see the beauty of your approach - I like it's efficiency and the
possibility for user translation - the reduced likely hood of syntax
problems in the translation file etc. Its just that it will destroy the easy
readability of the scripts and whilst multi-language would be brilliant I
really don't want to compromise the system and the fundamental aims of the
project - as I am sure you appreciate. The other lesser problem I see is
that I am not so keen on creating a script with textualids and then inputing
textualids and english translations into the database.

The snag with 40 characters is that some of the echo statements where an
error message is returned or some instruction printed on the screen are way
more than 40 characters. Say the script

SelectSalesOrder.php with the instruction....

"To search for sales orders for a specific part use the part selection
facilities below"

I've not counted, but this string must be getting close to 100 characters
with that one and there are many longer messages. So 40 characters is just
not going to cut it.

I don't know much about multi-language applications, but the guys that do
all use gettext .... I figure that this must be the best approach.

I'll try and find the index.php you sent to have a look. Thanks for
considering the good of the project in your work - it really would be a
significant contribution if you could make it work.

Phil


-------Original Message-------

From: ing. Luca Turlon Donà
Date: 08/06/04 18:52:39
To: Daintrees
Subject: Re: Web-erp Multilanguage developement

Phil,
I am sympathetic with your feeling, i.e. I am strongly bearing in mind the
fact that readability is a MUST (in capital letters!)
That's why I am creating the textual ids simply eliminating blanks and words
like "and" from what is currently displayed. As an example "Work Centre
Maintenance" has a textual id wich is WorkCentreMaintenance. If you feel
unconfortable with this I can try another approach: Keeping the English
label
as textual id: the only thing is to replace blanks with "_".
With this approach, until now 40 chars has been sufficient to have a self
explaining textualid, but I am ready to enlarge that field again.

So the problem is not the size of the textual id but the readability: I sent
the modified index.php. Have you read it? Do you feel that the textual ids
are
understandable?
Please I need Your feedback.
Luca

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

> Luca,
>
> I feel this approach will destroy readability with only a 40 character
> lookup field. Good luck with it anyway.
>
> Regards
> Phil
>
> -------Original Message-------
>
> From: ing. Luca Turlon Donà
> Date: 08/06/04 03:45:55
> To: Phil Daintree
> Cc: web-erp-developers@.SYNTAX-ERROR
> Subject: Web-erp Multilanguage developement
>
> Phil and all developers
>
> I've started the multilanguage job.
> I designed 3 tables.
> - "labelids" contains a numerical id for each label, a textual id (which
> is
> more understandable and will be used in the scripts). Each label refers
> to a
> single script and the textual id has to be unique.
> - "languages" contains the languages into wich the application could be
> translated
> - "labelsText" contains the text that is going to be displayed
> Attached you can find a png with the db schema.
>
> I used the SimpleWebFront plugin of FabForce DBDesigner to automatically
> generate the application to insert the values.
>
> I finished modifying the 'index.php' file. Now I have all the menus in
> Italian.
>
> There is a nice thing in the approach I am following: the application is
> not
> affected by the work I am doing: i.e. I can stop making code changes and
> go
> to
> lunch: the application still works (unless you make syntax error of
> course!!!).
> I enclose the modified index.php file. You can search for "echo $lang"
> to
> find
> all the points where code changed.
>
> see all
> Luca
>
>
>
>




-------------------------------------------------------
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

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

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

Hello,

to understand my difficulties, please visit http://tax.grade.de/vat.txt

Have a nice day, Dirk

[Web-erp-developers] Re: Web-erp Multilanguage developement

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

Luca,

I didn't see the index.php script you sent must have missed that emai=
l -
will hunt through my archive.

I see the beauty of your approach - I like it's efficiency and the
possibility for user translation - the reduced likely hood of syntax
problems in the translation file etc. Its just that it will destroy t=
he easy
readability of the scripts and whilst multi-language would be brillia=
nt I
really don't want to compromise the system and the fundamental aims o=
f the
project - as I am sure you appreciate. The other lesser problem I see=
 is
that I am not so keen on creating a script with textualids and then i=
nputing
textualids and english translations into the database.=20

The snag with 40 characters is that some of the echo statements where=
 an
error message is returned or some instruction printed on the screen a=
re way
more than 40 characters. Say the script=20

SelectSalesOrder.php with the instruction....

"To search for sales orders for a specific part use the part selectio=
n
facilities below"
=20
I've not counted, but this string must be getting close to 100 charac=
ters
with that one and there are many longer messages. So 40 characters is=
 just
not going to cut it.=20

I don't know much about multi-language applications, but the guys tha=
t do
all use gettext .... I figure that this must be the best approach.

I'll try and find the index.php you sent to have a look. Thanks for
considering the good of the project in your work - it really would be=
 a
significant contribution if you could make it work.

Phil


-------Original Message-------
=20
=46rom: ing. Luca Turlon Don=E0
Date: 08/06/04 18:52:39
To: Daintrees
Subject: Re: Web-erp Multilanguage developement
=20
Phil,
I am sympathetic with your feeling, i.e. I am strongly bearing in min=
d the
fact that readability is a MUST (in capital letters!)
That's why I am creating the textual ids simply eliminating blanks an=
d words
like "and" from what is currently displayed. As an example "Work Cent=
re
Maintenance" has a textual id wich is WorkCentreMaintenance. If you f=
eel
unconfortable with this I can try another approach: Keeping the Engli=
sh
label
as textual id: the only thing is to replace blanks with "_".
With this approach, until now 40 chars has been sufficient to have a =
self
explaining textualid, but I am ready to enlarge that field again.
=20
So the problem is not the size of the textual id but the readability:=
 I sent
the modified index.php. Have you read it? Do you feel that the textua=
l ids
are
understandable?
Please I need Your feedback.
Luca
=20
Scrive Daintrees <p.d...@pa...>:
=20
> Luca,
>
> I feel this approach will destroy readability with only a 40 charac=
ter
> lookup field. Good luck with it anyway.
>
> Regards
> Phil
>
> -------Original Message-------
>
> From: ing. Luca Turlon Don=E0
> Date: 08/06/04 03:45:55
> To: Phil Daintree
> Cc: web-erp-developers@.SYNTAX-ERROR
> Subject: Web-erp Multilanguage developement
>
> Phil and all developers
>
> I've started the multilanguage job.
> I designed 3 tables.
> - "labelids" contains a numerical id for each label, a textual id (=
which
> is
> more understandable and will be used in the scripts). Each label re=
fers
> to a
> single script and the textual id has to be unique.
> - "languages" contains the languages into wich the application coul=
d be
> translated
> - "labelsText" contains the text that is going to be displayed
> Attached you can find a png with the db schema.
>
> I used the SimpleWebFront plugin of FabForce DBDesigner to automati=
cally
> generate the application to insert the values.
>
> I finished modifying the 'index.php' file. Now I have all the menus=
 in
> Italian.
>
> There is a nice thing in the approach I am following: the applicati=
on is
> not
> affected by the work I am doing: i.e. I can stop making code change=
s and
> go
> to
> lunch: the application still works (unless you make syntax error of
> course!!!).
> I enclose the modified index.php file. You can search for "echo $la=
ng"
> to
> find
> all the points where code changed.
>
> see all
> Luca
>
>
>
>
=20

Re: [Web-erp-developers] Serialization and BOM

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

Thanks Skaill. I'll read up on that.

Chris, I am very interested in your RMA system. If I can be of any
assistance please let me know.
 Thanks!

~Peter

On Thu, 5 Aug 2004 14:15:48 -0400, skaill <sk...@ro...> wrote:
> I think Phil mentioned PEAR which can be found here
> http://pear.php.net/manual/en/standards.php
> It is a short and easy read.  Basically it's what they teach in school or
> you've seen in lots of good programs.  Chances are you're doing already.
> 
> Steve
> 
> 
> 
> ----- Original Message -----
> From: "Danie Brink" <br...@na...>
> To: <web...@li...>
> Sent: Wednesday, August 04, 2004 7:07 PM
> Subject: Re: [Web-erp-developers] Serialization and BOM
> 
> > Hi Peter
> >
> > I don't know if any of the other guys are awake right now, so I will try
> to
> > answer some of your questions.
> >
> > Serialization has been build into the stock to some extend Phil and Jessie
> > worked on this, so they will probably fill you in on serialization.
> >
> > BOMS already have multilevel support in that a manufactured item with its
> own
> > BOM may be used within another BOM. There is however no single interface
> to
> > edit a tree like structure.
> >
> > Reporting of the BOM Tree are also lacking although with a bit of work it
> is
> > possible to build such a report.
> >
> > Like all of us go ahead, look through the code and if you feel up to it go
> ahead
> > and try. If you would like to run it past the the list do so. Phil is
> fearly
> > strict on the source code structure ( not overly so, but he has a point)
> on the
> > way he would like the code. Have a look at the current code you will see
> he
> > likes to keep every file as self contained as possible.
> > He or someone else will probably mention it again soon. :)
> >
> > Someone mentioned a while back where we could find the standard Phil would
> like
> > us to use, If someone could tell us again. Also mabe Phil could put it on
> the
> > Source Forge Site as well under some FAQ. Just a thought. *wink-wink*
> >
> > There is also some work under way on work orders and costing by me and my
> guys,
> > And we are also doing some work on the taxes and manuals. We will
> contribute it
> > back and Phil will decide what he want's to include. It's his baby and he
> did a
> > good job so far.
> >
> > Kind Regards
> > Danie Brink
> >
> > Quoting Peter <use...@gm...>:
> >
> > > I've shown Web-ERP to my manager and he was very impressed. It far
> > > surpasses any open source ERP software we have used.
> > >
> > > Among a couple of small features, some requirements he had:
> > >
> > > * The support of serialized stock
> > > * BOM reporting
> > > * Milti - level BOM
> > >
> > > Has development started on these features? If so, can I help? If
> > > development has not started, a co-worker and I can start developing
> > > these.
> > >
> > > I have programmed some in PHP and MySQL and I have done a lot of
> > > programming in other languages including C++ so I understand the OOP
> > > mentality.
> > >
> > > ~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
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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] Serialization and BOM

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

I think Phil mentioned PEAR which can be found here
http://pear.php.net/manual/en/standards.php
It is a short and easy read.  Basically it's what they teach in school or
you've seen in lots of good programs.  Chances are you're doing already.

Steve

----- Original Message ----- 
From: "Danie Brink" <br...@na...>
To: <web...@li...>
Sent: Wednesday, August 04, 2004 7:07 PM
Subject: Re: [Web-erp-developers] Serialization and BOM


> Hi Peter
>
> I don't know if any of the other guys are awake right now, so I will try
to
> answer some of your questions.
>
> Serialization has been build into the stock to some extend Phil and Jessie
> worked on this, so they will probably fill you in on serialization.
>
> BOMS already have multilevel support in that a manufactured item with its
own
> BOM may be used within another BOM. There is however no single interface
to
> edit a tree like structure.
>
> Reporting of the BOM Tree are also lacking although with a bit of work it
is
> possible to build such a report.
>
> Like all of us go ahead, look through the code and if you feel up to it go
ahead
> and try. If you would like to run it past the the list do so. Phil is
fearly
> strict on the source code structure ( not overly so, but he has a point)
on the
> way he would like the code. Have a look at the current code you will see
he
> likes to keep every file as self contained as possible.
> He or someone else will probably mention it again soon. :)
>
> Someone mentioned a while back where we could find the standard Phil would
like
> us to use, If someone could tell us again. Also mabe Phil could put it on
the
> Source Forge Site as well under some FAQ. Just a thought. *wink-wink*
>
> There is also some work under way on work orders and costing by me and my
guys,
> And we are also doing some work on the taxes and manuals. We will
contribute it
> back and Phil will decide what he want's to include. It's his baby and he
did a
> good job so far.
>
> Kind Regards
> Danie Brink
>
> Quoting Peter <use...@gm...>:
>
> > I've shown Web-ERP to my manager and he was very impressed. It far
> > surpasses any open source ERP software we have used.
> >
> > Among a couple of small features, some requirements he had:
> >
> > * The support of serialized stock
> > * BOM reporting
> > * Milti - level BOM
> >
> > Has development started on these features? If so, can I help? If
> > development has not started, a co-worker and I can start developing
> > these.
> >
> > I have programmed some in PHP and MySQL and I have done a lot of
> > programming in other languages including C++ so I understand the OOP
> > mentality.
> >
> > ~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
> >
>
>
>
>
> -------------------------------------------------------
> 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] Serialization and BOM

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

Peter,

I have built a RMA, and warranty system that I am now trying to
incorporate into webERP. I'm not too sure how much longer it will be
before I get it converted, but that may be an option for you if you
didn't want to re-write it.

Chris

-----Original Message-----
From: web...@li...
[mailto:web...@li...] On Behalf Of
Peter
Sent: Thursday, August 05, 2004 6:48 AM
To: web...@li...
Subject: Re: [Web-erp-developers] Serialization and BOM

Thanks!

I will start working on fleshing out some of the BOM functionality.

By the way, is there a way we can enter in RMA's? If not, I'll start
working on that too.

Much of our information is on mas200 so I am starting to write import
scripts that will accept the mas200 database dumps.

~Peter

On Thu, 05 Aug 2004 12:36:26 +1200, Daintrees
<p.d...@pa...> wrote:
> > Like all of us go ahead, look through the code and if you feel up to
it go
> ahead
> > and try. If you would like to run it past the the list do so. Phil
is
> fearly
> > strict on the source code structure ( not overly so, but he has a
point)
> on the
> > way he would like the code. Have a look at the current code you will
see
> he
> > likes to keep every file as self contained as possible.
> > He or someone else will probably mention it again soon. :)
> 
> Thats well put Danie - I prefer to keep everything together rather
than look
> through 12 files to figure out a script.
> Hope I am not too grizzly and putting folks off though!! I really need
some
> help.
> 
> >
> > Someone mentioned a while back where we could find the standard Phil
would
> like
> > us to use, If someone could tell us again. Also mabe Phil could put
it on
> the
> > Source Forge Site as well under some FAQ. Just a thought.
*wink-wink*
> >
> 
> Its a solid point again Danie - I will draft something up from old
emails
> and stick it in the docs as a standing reference for contributors.
> 
> Phil
> 
> 
> 
> 
> -------------------------------------------------------
> 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] Serialization and BOM

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

Thanks!

I will start working on fleshing out some of the BOM functionality.

By the way, is there a way we can enter in RMA's? If not, I'll start
working on that too.

Much of our information is on mas200 so I am starting to write import
scripts that will accept the mas200 database dumps.

~Peter

On Thu, 05 Aug 2004 12:36:26 +1200, Daintrees
<p.d...@pa...> wrote:
> > Like all of us go ahead, look through the code and if you feel up to it go
> ahead
> > and try. If you would like to run it past the the list do so. Phil is
> fearly
> > strict on the source code structure ( not overly so, but he has a point)
> on the
> > way he would like the code. Have a look at the current code you will see
> he
> > likes to keep every file as self contained as possible.
> > He or someone else will probably mention it again soon. :)
> 
> Thats well put Danie - I prefer to keep everything together rather than look
> through 12 files to figure out a script.
> Hope I am not too grizzly and putting folks off though!! I really need some
> help.
> 
> >
> > Someone mentioned a while back where we could find the standard Phil would
> like
> > us to use, If someone could tell us again. Also mabe Phil could put it on
> the
> > Source Forge Site as well under some FAQ. Just a thought. *wink-wink*
> >
> 
> Its a solid point again Danie - I will draft something up from old emails
> and stick it in the docs as a standing reference for contributors.
> 
> Phil
> 
> 
> 
> 
> -------------------------------------------------------
> 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] Serialization and BOM

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

> Like all of us go ahead, look through the code and if you feel up to it go
ahead
> and try. If you would like to run it past the the list do so. Phil is
fearly
> strict on the source code structure ( not overly so, but he has a point)
on the
> way he would like the code. Have a look at the current code you will see
he
> likes to keep every file as self contained as possible.
> He or someone else will probably mention it again soon. :)

Thats well put Danie - I prefer to keep everything together rather than look
through 12 files to figure out a script.
Hope I am not too grizzly and putting folks off though!! I really need some
help.

>
> Someone mentioned a while back where we could find the standard Phil would
like
> us to use, If someone could tell us again. Also mabe Phil could put it on
the
> Source Forge Site as well under some FAQ. Just a thought. *wink-wink*
>

Its a solid point again Danie - I will draft something up from old emails
and stick it in the docs as a standing reference for contributors.

Phil

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

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

Wow - he's back!!
All sounds exciting.

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


> Hi Phil
>
> I see you are awake and the list has ignored my answer to this question. I
hope
> it apears again.
>
> The short answer is no we do not implement multiple taxes on a single
entry. All
> we are doing is reversing the way it has been implemented by giving the
level a
> name and implementing ref integrity. It also means the levels will be
named. We
> will also be spliting the rates from the levels/Tax categories and we are
> binding them as a tax type conected to a tax authority. A linktable
replaces
> the old Taxlevel table and the arbitry level in stack master is replaced
with a
> reference to the TaxCategory Table. It allows for rate maintenance
independant
> of the actual levels by tax authority.
>
> I am currently half way through this and will finish it as soon as
possible. We
> are also doning a lot of work on the Work Orders and Costing ( The Full
> manufacturing you just mentioned. ) Although the costing will be a
prototype on
> our side, writen in a different lanuage. There are also some automatic
unit
> conversion in the works and a GUI version of WebERP. Its going to be hell
to
> keep up with you guys, But everything will be contributed inculding the
report
> framework at a later stage. It is more flexible in regards to multilevel
> reporting, However it is part of the GUI framework and uses an expression
> parser. So I will probably make it an independent server you can
comunicate
> with via local host. There are a lot more we want to do before we are
ready for
> the Trade Show next year June.
>
> Kind Regards and let me know what you think.
>
> 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
> >
>
>
>
>
> -------------------------------------------------------
> 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

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

Hi Phil

I see you are awake and the list has ignored my answer to this question. I hope
it apears again.

The short answer is no we do not implement multiple taxes on a single entry. All
we are doing is reversing the way it has been implemented by giving the level a
name and implementing ref integrity. It also means the levels will be named. We
will also be spliting the rates from the levels/Tax categories and we are
binding them as a tax type conected to a tax authority. A linktable  replaces
the old Taxlevel table and the arbitry level in stack master is replaced with a
reference to the TaxCategory Table. It allows for rate maintenance independant
of the actual levels by tax authority.

I am currently half way through this and will finish it as soon as possible. We
are also doning a lot of work on the Work Orders and Costing ( The Full
manufacturing you just mentioned. ) Although the costing will be a prototype on
our side, writen in a different lanuage. There are also some automatic unit
conversion in the works and a GUI version of WebERP. Its going to be hell to
keep up with you guys, But everything will be contributed inculding the report
framework at a later stage. It is more flexible in regards to multilevel
reporting, However it is part of the GUI framework and uses an expression
parser. So I will probably make it an independent server you can comunicate
with via local host. There are a lot more we want to do before we are ready for
the Trade Show next year June.

Kind Regards and let me know what you think.

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] Serialization and BOM

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

Hi Peter

I don't know if any of the other guys are awake right now, so I will try to
answer some of your questions.

Serialization has been build into the stock to some extend Phil and Jessie
worked on this, so they will probably fill you in on serialization. 

BOMS already have multilevel support in that a manufactured item with its own
BOM may be used within another BOM. There is however no single interface to
edit a tree like structure. 

Reporting of the BOM Tree are also lacking although with a bit of work it is
possible to build such a report. 

Like all of us go ahead, look through the code and if you feel up to it go ahead
and try. If you would like to run it past the the list do so. Phil is fearly
strict on the source code structure ( not overly so, but he has a point) on the
way he would like the code. Have a look at the current code you will see he
likes to keep every file as self contained as possible.
He or someone else will probably mention it again soon. :)

Someone mentioned a while back where we could find the standard Phil would like
us to use, If someone could tell us again. Also mabe Phil could put it on the
Source Forge Site as well under some FAQ. Just a thought. *wink-wink*

There is also some work under way on work orders and costing by me and my guys,
And we are also doing some work on the taxes and manuals. We will contribute it
back and Phil will decide what he want's to include. It's his baby and he did a
good job so far.

Kind Regards
Danie Brink

Quoting Peter <use...@gm...>:

> I've shown Web-ERP to my manager and he was very impressed. It far
> surpasses any open source ERP software we have used.
> 
> Among a couple of small features, some requirements he had:
> 
> * The support of serialized stock
> * BOM reporting
> * Milti - level BOM
> 
> Has development started on these features? If so, can I help? If
> development has not started, a co-worker and I can start developing
> these.
> 
> I have programmed some in PHP and MySQL and I have done a lot of
> programming in other languages including C++ so I understand the OOP
> mentality.
> 
> ~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] Serialization and BOM

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

Hi Peter,

Serialised/batch controlled stock - has just been implemented in 2.9
BOM listings are currently only to the 1st level down - this has been there
since 1.0 as has multi-level BOMs - there is no limit to the number of
levels.

The downer is that BOMs are considered manufacturing functionality where in
fact web-erp is otherwise weak in manufacturing functionality. This is an
area to be focused on although I do get dragged into other areas as other
developers get an energy burst in a particular area.

web-erp is predominantly procedural with some OO concepts applied where
applicable.

Phil

> From: "Peter" <use...@gm...>
> To: "web-erp-dev" <web...@li...>
> Sent: Thursday, August 05, 2004 9:13 AM
> Subject: [Web-erp-developers] Serialization and BOM
>
>
> > I've shown Web-ERP to my manager and he was very impressed. It far
> > surpasses any open source ERP software we have used.
> >
> > Among a couple of small features, some requirements he had:
> >
> > * The support of serialized stock
> > * BOM reporting
> > * Milti - level BOM
> >
> > Has development started on these features? If so, can I help? If
> > development has not started, a co-worker and I can start developing
> > these.
> >
> > I have programmed some in PHP and MySQL and I have done a lot of
> > programming in other languages including C++ so I understand the OOP
> > mentality.
> >
> > ~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
> >
>

[Web-erp-developers] Serialization and BOM

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

I've shown Web-ERP to my manager and he was very impressed. It far
surpasses any open source ERP software we have used.

Among a couple of small features, some requirements he had:

* The support of serialized stock
* BOM reporting
* Milti - level BOM

Has development started on these features? If so, can I help? If
development has not started, a co-worker and I can start developing
these.

I have programmed some in PHP and MySQL and I have done a lot of
programming in other languages including C++ so I understand the OOP
mentality.

~Peter