Re: [WebERP-developers] Proposed structure change for addresses

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [WebERP-developers] Proposed structure change for addresses

weberp
Hi Dave,

The branchpostal address stuff is used for addressing customer statements -
there is an option to address statements to branches or the head office.

The nature of webERP is such that there is no limit to the number of shipping
addresses - a customer charge account simply has as many branches as there
are physical locations  where a customer wants goods shipped to. If the
shipping address is simply a one off delivery then this can be entered at the
time of order - over-riding the default branch physcial address.

I am not sure I understand the motivation for the changes. Why would we want
to rename these fields? Is it not rather the descriptions in the UI that we
wish to commonise the data with other applications?


Phil

On Fri, 16 Sep 2005 09:14, Dave wrote:

> I am new to webERP and have decided to join in on the development effort to
> make webERP a force in the ERP market. I have spent the past several weeks
> testing the scripts and have identified a few areas that I plan to
> contribute; address structure, shipping options, interfaces to both a cart
> system and CRM application. I have code written and tested to interface
> with FedEx and UPS XML servers for rate estimation that I plan on
> integrating later but for now...
>
> I would like to change the structure for the address data within webERP.
> The current address structure contains address1 through address4 which
> leads to ambiguity on how to populate the database. A better structure
> would be:
>
> Name (or company name)
> Address1
> Address2
> City
> State or Province
> Postal Code
> Country
>
> This would allow entry of information in a better defined format and
> consistent with most other applications. This would also allow easier
> exchange of information between webERP and other applications (oscommerce,
> zencart, vtiger and sugarCRM to name a few).  I have identified the tables
> that need to be modified (8 total) and the scripts that are affected (there
> are many) and would like to solicit input from everyone on this proposal.
>
> I plan to change the table entry for 'address3' to 'city', 'address4' to
> 'stateprovince', and add 'postalcode' and 'country' fields. The exact field
> names vary between the tables but that's the idea. I will also upgrade all
> scripts affected and provide sql updates for new installs and upgrades.
>
> I plan on leaving the field lengths of the current address3 and address4
> the same length to prevent data loss when upgrading. Although there is a
> discrepancy here in that the database address4 is created with a length of
> 50 (during the install sql script) and the input form will only allow 40
> characters to be entered. (NOTE: I would think that 40 should be adequate
> since my proposed new field name is stateprovince and 40 should be big
> enough).
>
> Another question - What is the purpose of the brpostaddr1-4 in the
> custbranch table? I see that data can be entered in this field but it
> doesn't seem to be used for anything. I would like to eliminate it in favor
> of a future enhancement of one or more shipping address store in a separate
> table associated with either a branch or customer. My small business deals
> with many large companies that have several shipping addresses per
> customer. Putting the brpostaddr1-4 field in the custbrach table doesn't
> make sense and seems restrictive.
>
> Any feedback from the webERP development community would be greatly
> appreciated.
>
> Dave Premo

--
Phil Daintree
webERP Project Admin


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Web-erp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/web-erp-developers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [WebERP-developers] Proposed structure change for addresses

Colin-12

Hi Dave

Welcome.

As a recent adopter of weberp in a business I'm finding it to be a really
comprehensive framework and we are doing a lot with it to make it suit our needs.

I'm not sure how well qualified I am to speak for the general developer
community about your proposed changes to address fields, but I have a few
thoughts as follows:

> I would like to change the structure for the address data within webERP. The
> current address structure contains address1 through address4 which leads to
> ambiguity on how to populate the database. A better structure would be:
>
> Name (or company name)
> Address1
> Address2
> City
> State or Province
> Postal Code
> Country

> This would allow entry of information in a better defined format and
> consistent with most other applications.

I'm not sure why this structure would be 'better'?

In my experience most other apllications are (equally) as ad-hoc with their
address fields. And whose naming rules do you follow? Consider...

When is a City not a Town? (or vice-versa)

Neither State nor Province have any meaning in my country of birth or my
adopted one.

Some places still dont use post codes at all.

And then the language issue throws it all out anyway.

There are several attempts at defining international standards for address
fields. I worked on a web app a few years ago where the lead dev insisted on
slavish adherence to some standard that I can neither remember nor find just
now but heres one that covers a lot of the issues:

http://www.oasis-open.org/committees/ciq/ciq.html#4

But until there is a clear standard, mapping addresses from one app to another
will require a bit of manual intervention.

Overall I suspect that address1 - 4 are meaningful enough, and tend to agree
with Phil in that it's what the end user sees that is more important what the
field is actually called. And with weberp the UI is pretty easily configured
to suit.

I have come across issues with field lengths being a bit 'mean' tho
(especially in these days of cheapo hd's) and not just with addresses. But
I'll get round to detailing this at some other time.

Kind Regards,


Colin

> This would also allow easier
> exchange of information between webERP and other applications (oscommerce,
> zencart, vtiger and sugarCRM to name a few).  I have identified the tables
> that need to be modified (8 total) and the scripts that are affected (there
> are many) and would like to solicit input from everyone on this proposal.
>
> I plan to change the table entry for 'address3' to 'city', 'address4' to
> 'stateprovince', and add 'postalcode' and 'country' fields. The exact field
> names vary between the tables but that's the idea. I will also upgrade all
> scripts affected and provide sql updates for new installs and upgrades.
>
> I plan on leaving the field lengths of the current address3 and address4 the
> same length to prevent data loss when upgrading. Although there is a
> discrepancy here in that the database address4 is created with a length of
> 50 (during the install sql script) and the input form will only allow 40
> characters to be entered. (NOTE: I would think that 40 should be adequate
> since my proposed new field name is stateprovince and 40 should be big
> enough).
>
> Another question - What is the purpose of the brpostaddr1-4 in the
> custbranch table? I see that data can be entered in this field but it
> doesn't seem to be used for anything. I would like to eliminate it in favor
> of a future enhancement of one or more shipping address store in a separate
> table associated with either a branch or customer. My small business deals
> with many large companies that have several shipping addresses per customer.
> Putting the brpostaddr1-4 field in the custbrach table doesn't make sense
> and seems restrictive.
>
> Any feedback from the webERP development community would be greatly
> appreciated.
>
> Dave Premo
------- End of Original Message -------



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Web-erp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/web-erp-developers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [WebERP-developers] Proposed structure change for addresses

Dave-34
In reply to this post by weberp
Phil,
I have two common scenarios. I sell medical batteries to service companies
(resale) and direct. The service companies can have branches where the bill
goes to a common address (HQ) or could go to the branch. Within these
branches, they typically want me to drop ship the product directly to the
medical centers and hospitals. So I have a need both for multiple branches
and ship to addresses. I understand that the delivery address can be
overwritten during the sales order entry but these customers will typically
drop ship to the same locations. Storing the shipping addresses separately
would be a huge benefit for me as most of my customers expect me to have the
addresses saved from their last order. Another common scenario is a service
company that drop ships to a few locations frequently. These are usually
hospitals and are not branches of the service company. It would be very
confusing to link them together because they are separate businesses.
Additionally, It's not uncommon for the hospital to order from me directly
as well. for this reason, I believe a separate shipping database table would
be beneficial and more versatile.

If you have any ideas on how I can work both the branch and drop shipping
address in the current structure, I will drop this issue and move on.

How about if I modify my structure change as follows:
Leave address3 and address4 as is.
Add address5 and address6. I can handle the naming through the UI. This will
allow me to enter the postal code and country without the need to parse the
address field for shipping rate estimation.

Dave

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Phil
Daintree
Sent: Friday, September 16, 2005 12:36 AM
To: [hidden email]
Subject: Re: [WebERP-developers] Proposed structure change for addresses


Hi Dave,

The branchpostal address stuff is used for addressing customer statements -
there is an option to address statements to branches or the head office.

The nature of webERP is such that there is no limit to the number of
shipping
addresses - a customer charge account simply has as many branches as there
are physical locations  where a customer wants goods shipped to. If the
shipping address is simply a one off delivery then this can be entered at
the
time of order - over-riding the default branch physcial address.

I am not sure I understand the motivation for the changes. Why would we want
to rename these fields? Is it not rather the descriptions in the UI that we
wish to commonise the data with other applications?


Phil

On Fri, 16 Sep 2005 09:14, Dave wrote:
> I am new to webERP and have decided to join in on the development effort
to

> make webERP a force in the ERP market. I have spent the past several weeks
> testing the scripts and have identified a few areas that I plan to
> contribute; address structure, shipping options, interfaces to both a cart
> system and CRM application. I have code written and tested to interface
> with FedEx and UPS XML servers for rate estimation that I plan on
> integrating later but for now...
>
> I would like to change the structure for the address data within webERP.
> The current address structure contains address1 through address4 which
> leads to ambiguity on how to populate the database. A better structure
> would be:
>
> Name (or company name)
> Address1
> Address2
> City
> State or Province
> Postal Code
> Country
>
> This would allow entry of information in a better defined format and
> consistent with most other applications. This would also allow easier
> exchange of information between webERP and other applications (oscommerce,
> zencart, vtiger and sugarCRM to name a few).  I have identified the tables
> that need to be modified (8 total) and the scripts that are affected
(there
> are many) and would like to solicit input from everyone on this proposal.
>
> I plan to change the table entry for 'address3' to 'city', 'address4' to
> 'stateprovince', and add 'postalcode' and 'country' fields. The exact
field

> names vary between the tables but that's the idea. I will also upgrade all
> scripts affected and provide sql updates for new installs and upgrades.
>
> I plan on leaving the field lengths of the current address3 and address4
> the same length to prevent data loss when upgrading. Although there is a
> discrepancy here in that the database address4 is created with a length of
> 50 (during the install sql script) and the input form will only allow 40
> characters to be entered. (NOTE: I would think that 40 should be adequate
> since my proposed new field name is stateprovince and 40 should be big
> enough).
>
> Another question - What is the purpose of the brpostaddr1-4 in the
> custbranch table? I see that data can be entered in this field but it
> doesn't seem to be used for anything. I would like to eliminate it in
favor
> of a future enhancement of one or more shipping address store in a
separate
> table associated with either a branch or customer. My small business deals
> with many large companies that have several shipping addresses per
> customer. Putting the brpostaddr1-4 field in the custbrach table doesn't
> make sense and seems restrictive.
>
> Any feedback from the webERP development community would be greatly
> appreciated.
>
> Dave Premo

--
Phil Daintree
webERP Project Admin


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Web-erp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/web-erp-developers




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Web-erp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/web-erp-developers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [WebERP-developers] Proposed structure change for addresses

Dave-34
In reply to this post by Colin-12
Thanks for the feedback. I reviewed the document you linked below and as a
result I changed the proposal in response to Phil's email. Repeated here
too:
Leave address3 and address4 alone.
Add address5 and address6 to allow me to enter data into the database for
shipping rate estimation with the need to parse the city, state and postal
code. I'll handle everything else with the UI.

Dave

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of
Colin
Sent: Friday, September 16, 2005 6:35 AM
To: [hidden email]
Subject: Re: [WebERP-developers] Proposed structure change for addresses



Hi Dave

Welcome.

As a recent adopter of weberp in a business I'm finding it to be a really
comprehensive framework and we are doing a lot with it to make it suit our
needs.

I'm not sure how well qualified I am to speak for the general developer
community about your proposed changes to address fields, but I have a few
thoughts as follows:

> I would like to change the structure for the address data within webERP.
The
> current address structure contains address1 through address4 which leads
to
> ambiguity on how to populate the database. A better structure would be:
>
> Name (or company name)
> Address1
> Address2
> City
> State or Province
> Postal Code
> Country

> This would allow entry of information in a better defined format and
> consistent with most other applications.

I'm not sure why this structure would be 'better'?

In my experience most other apllications are (equally) as ad-hoc with their
address fields. And whose naming rules do you follow? Consider...

When is a City not a Town? (or vice-versa)

Neither State nor Province have any meaning in my country of birth or my
adopted one.

Some places still dont use post codes at all.

And then the language issue throws it all out anyway.

There are several attempts at defining international standards for address
fields. I worked on a web app a few years ago where the lead dev insisted on
slavish adherence to some standard that I can neither remember nor find just
now but heres one that covers a lot of the issues:

http://www.oasis-open.org/committees/ciq/ciq.html#4

But until there is a clear standard, mapping addresses from one app to
another
will require a bit of manual intervention.

Overall I suspect that address1 - 4 are meaningful enough, and tend to agree
with Phil in that it's what the end user sees that is more important what
the
field is actually called. And with weberp the UI is pretty easily configured
to suit.

I have come across issues with field lengths being a bit 'mean' tho
(especially in these days of cheapo hd's) and not just with addresses. But
I'll get round to detailing this at some other time.

Kind Regards,


Colin

> This would also allow easier
> exchange of information between webERP and other applications (oscommerce,
> zencart, vtiger and sugarCRM to name a few).  I have identified the tables
> that need to be modified (8 total) and the scripts that are affected
(there
> are many) and would like to solicit input from everyone on this proposal.
>
> I plan to change the table entry for 'address3' to 'city', 'address4' to
> 'stateprovince', and add 'postalcode' and 'country' fields. The exact
field
> names vary between the tables but that's the idea. I will also upgrade all
> scripts affected and provide sql updates for new installs and upgrades.
>
> I plan on leaving the field lengths of the current address3 and address4
the

> same length to prevent data loss when upgrading. Although there is a
> discrepancy here in that the database address4 is created with a length of
> 50 (during the install sql script) and the input form will only allow 40
> characters to be entered. (NOTE: I would think that 40 should be adequate
> since my proposed new field name is stateprovince and 40 should be big
> enough).
>
> Another question - What is the purpose of the brpostaddr1-4 in the
> custbranch table? I see that data can be entered in this field but it
> doesn't seem to be used for anything. I would like to eliminate it in
favor
> of a future enhancement of one or more shipping address store in a
separate
> table associated with either a branch or customer. My small business deals
> with many large companies that have several shipping addresses per
customer.
> Putting the brpostaddr1-4 field in the custbrach table doesn't make sense
> and seems restrictive.
>
> Any feedback from the webERP development community would be greatly
> appreciated.
>
> Dave Premo
------- End of Original Message -------



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Web-erp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/web-erp-developers




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Web-erp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/web-erp-developers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [WebERP-developers] Proposed structure change for addresses

Scott Rosa
Although I have not been following this discussion real close, here are my two pennies worth of thoughts.  For me, not being hardcore programmer, not having discrete fields for the address components renders them pretty much useless if I want to try to integrate with my shipping application (UPS Worldship).   Dave's proposal of address1-6, city/town/village (whatever you want to call it),  a state or province, and some kind of postal code is much more useful and reliable to me.  Having free form fields to hold the the city,state,zip means that I have to rely on my users to enter that information in the same location, with the same punctuation, every time in order for me to have any shot at parsing the data into usable form for other applications, namely my shipping app.   If more discrete fields are required for different countries to deliver a package, then why cannot we just add them?  Am I being too naive to ask, how many can there possibly be to deliver a package? 

Regards,
Scott

Dave wrote:
Thanks for the feedback. I reviewed the document you linked below and as a
result I changed the proposal in response to Phil's email. Repeated here
too:
Leave address3 and address4 alone.
Add address5 and address6 to allow me to enter data into the database for
shipping rate estimation with the need to parse the city, state and postal
code. I'll handle everything else with the UI.

Dave

-----Original Message-----
From: [hidden email]
[[hidden email]]On Behalf Of
Colin
Sent: Friday, September 16, 2005 6:35 AM
To: [hidden email]
Subject: Re: [WebERP-developers] Proposed structure change for addresses



Hi Dave

Welcome.

As a recent adopter of weberp in a business I'm finding it to be a really
comprehensive framework and we are doing a lot with it to make it suit our
needs.

I'm not sure how well qualified I am to speak for the general developer
community about your proposed changes to address fields, but I have a few
thoughts as follows:

  
I would like to change the structure for the address data within webERP.
    
The
  
current address structure contains address1 through address4 which leads
    
to
  
ambiguity on how to populate the database. A better structure would be:

Name (or company name)
Address1
Address2
City
State or Province
Postal Code
Country
    

  
This would allow entry of information in a better defined format and
consistent with most other applications.
    

I'm not sure why this structure would be 'better'?

In my experience most other apllications are (equally) as ad-hoc with their
address fields. And whose naming rules do you follow? Consider...

When is a City not a Town? (or vice-versa)

Neither State nor Province have any meaning in my country of birth or my
adopted one.

Some places still dont use post codes at all.

And then the language issue throws it all out anyway.

There are several attempts at defining international standards for address
fields. I worked on a web app a few years ago where the lead dev insisted on
slavish adherence to some standard that I can neither remember nor find just
now but heres one that covers a lot of the issues:

http://www.oasis-open.org/committees/ciq/ciq.html#4

But until there is a clear standard, mapping addresses from one app to
another
will require a bit of manual intervention.

Overall I suspect that address1 - 4 are meaningful enough, and tend to agree
with Phil in that it's what the end user sees that is more important what
the
field is actually called. And with weberp the UI is pretty easily configured
to suit.

I have come across issues with field lengths being a bit 'mean' tho
(especially in these days of cheapo hd's) and not just with addresses. But
I'll get round to detailing this at some other time.

Kind Regards,


Colin

  
This would also allow easier
exchange of information between webERP and other applications (oscommerce,
zencart, vtiger and sugarCRM to name a few).  I have identified the tables
that need to be modified (8 total) and the scripts that are affected
    
(there
  
are many) and would like to solicit input from everyone on this proposal.

I plan to change the table entry for 'address3' to 'city', 'address4' to
'stateprovince', and add 'postalcode' and 'country' fields. The exact
    
field
  
names vary between the tables but that's the idea. I will also upgrade all
scripts affected and provide sql updates for new installs and upgrades.

I plan on leaving the field lengths of the current address3 and address4
    
the
  
same length to prevent data loss when upgrading. Although there is a
discrepancy here in that the database address4 is created with a length of
50 (during the install sql script) and the input form will only allow 40
characters to be entered. (NOTE: I would think that 40 should be adequate
since my proposed new field name is stateprovince and 40 should be big
enough).

Another question - What is the purpose of the brpostaddr1-4 in the
custbranch table? I see that data can be entered in this field but it
doesn't seem to be used for anything. I would like to eliminate it in
    
favor
  
of a future enhancement of one or more shipping address store in a
    
separate
  
table associated with either a branch or customer. My small business deals
with many large companies that have several shipping addresses per
    
customer.
  
Putting the brpostaddr1-4 field in the custbrach table doesn't make sense
and seems restrictive.

Any feedback from the webERP development community would be greatly
appreciated.

Dave Premo
    
------- End of Original Message -------



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Web-erp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/web-erp-developers




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Web-erp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/web-erp-developers


  
------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Web-erp-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/web-erp-developers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [WebERP-developers] Proposed structure change for addresses

weberp
In reply to this post by Dave-34
>
> If you have any ideas on how I can work both the branch and drop shipping
> address in the current structure, I will drop this issue and move on.
>

I don't see much difference between branch and shipping address I would simply
make up branches for every shipping address that you wish to store or may
potentially be used again. The branch field is avaialable in sales analysis
too so you can see what volumes, amounts you are shipping where. At first
glace I'm not sure that I see any great advantage about having a separate
shipping address table?


> How about if I modify my structure change as follows:
> Leave address3 and address4 as is.
> Add address5 and address6. I can handle the naming through the UI. This
> will allow me to enter the postal code and country without the need to
> parse the address field for shipping rate estimation.
>
> Dave
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Phil
> Daintree
> Sent: Friday, September 16, 2005 12:36 AM
> To: [hidden email]
> Subject: Re: [WebERP-developers] Proposed structure change for addresses
>
>
> Hi Dave,
>
> The branchpostal address stuff is used for addressing customer statements -
> there is an option to address statements to branches or the head office.
>
> The nature of webERP is such that there is no limit to the number of
> shipping
> addresses - a customer charge account simply has as many branches as there
> are physical locations  where a customer wants goods shipped to. If the
> shipping address is simply a one off delivery then this can be entered at
> the
> time of order - over-riding the default branch physcial address.
>
> I am not sure I understand the motivation for the changes. Why would we
> want to rename these fields? Is it not rather the descriptions in the UI
> that we wish to commonise the data with other applications?
>
>
> Phil
>
> On Fri, 16 Sep 2005 09:14, Dave wrote:
> > I am new to webERP and have decided to join in on the development effort
>
> to
>
> > make webERP a force in the ERP market. I have spent the past several
> > weeks testing the scripts and have identified a few areas that I plan to
> > contribute; address structure, shipping options, interfaces to both a
> > cart system and CRM application. I have code written and tested to
> > interface with FedEx and UPS XML servers for rate estimation that I plan
> > on integrating later but for now...
> >
> > I would like to change the structure for the address data within webERP.
> > The current address structure contains address1 through address4 which
> > leads to ambiguity on how to populate the database. A better structure
> > would be:
> >
> > Name (or company name)
> > Address1
> > Address2
> > City
> > State or Province
> > Postal Code
> > Country
> >
> > This would allow entry of information in a better defined format and
> > consistent with most other applications. This would also allow easier
> > exchange of information between webERP and other applications
> > (oscommerce, zencart, vtiger and sugarCRM to name a few).  I have
> > identified the tables that need to be modified (8 total) and the scripts
> > that are affected
>
> (there
>
> > are many) and would like to solicit input from everyone on this proposal.
> >
> > I plan to change the table entry for 'address3' to 'city', 'address4' to
> > 'stateprovince', and add 'postalcode' and 'country' fields. The exact
>
> field
>
> > names vary between the tables but that's the idea. I will also upgrade
> > all scripts affected and provide sql updates for new installs and
> > upgrades.
> >
> > I plan on leaving the field lengths of the current address3 and address4
> > the same length to prevent data loss when upgrading. Although there is a
> > discrepancy here in that the database address4 is created with a length
> > of 50 (during the install sql script) and the input form will only allow
> > 40 characters to be entered. (NOTE: I would think that 40 should be
> > adequate since my proposed new field name is stateprovince and 40 should
> > be big enough).
> >
> > Another question - What is the purpose of the brpostaddr1-4 in the
> > custbranch table? I see that data can be entered in this field but it
> > doesn't seem to be used for anything. I would like to eliminate it in
>
> favor
>
> > of a future enhancement of one or more shipping address store in a
>
> separate
>
> > table associated with either a branch or customer. My small business
> > deals with many large companies that have several shipping addresses per
> > customer. Putting the brpostaddr1-4 field in the custbrach table doesn't
> > make sense and seems restrictive.
> >
> > Any feedback from the webERP development community would be greatly
> > appreciated.
> >
> > Dave Premo
>
> --
> Phil Daintree
> webERP Project Admin
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Web-erp-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Web-erp-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

--
Phil Daintree
webERP Project Admin


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Web-erp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/web-erp-developers
Loading...