web-erp-developers — Discussion on development of webERP

[WebERP-developers] Fwd: [Web-erp-svn] SF.net SVN: web-erp:[6884] trunk

[Rafael C. <raf...@gm...>]

en-GB native speakers: Please review text in ManualTax.html (Tax Category
Maintenance). Thanks. Rafael


---------- Forwarded message ----------
From: <rc...@us...>
Date: 2014-09-13 17:06 GMT-06:00
Subject: [Web-erp-svn] SF.net SVN: web-erp:[6884] trunk
To: web...@li...


Revision: 6884
          http://sourceforge.net/p/web-erp/reponame/6884
Author:   rchacon
Date:     2014-09-13 23:06:42 +0000 (Sat, 13 Sep 2014)
Log Message:
-----------
Add info to help manual.

Modified Paths:
--------------
    trunk/doc/Manual/ManualTax.html
    trunk/includes/DatabaseTranslations.php

Modified: trunk/doc/Manual/ManualTax.html
===================================================================
--- trunk/doc/Manual/ManualTax.html     2014-09-13 04:12:51 UTC (rev 6883)
+++ trunk/doc/Manual/ManualTax.html     2014-09-13 23:06:42 UTC (rev 6884)
@@ -55,3 +55,30 @@
 <p>The TaxAuthority of the warehouse the goods are delivered from, the
TaxLevel of the item and the Tax Authority of the branch of the customer
being delivered to are determined. Using all three of these factors the
rate is returned from the TaxAuthLevels table.</p>

 <p>General ledger posting relating to the taxes calculated are made in
accordance with the codes set up in the Tax Authority table. <!-- Help End:
TaxAuthorities --></p>
+
+<!-- Begin: Tax Categories -->
+<div class="floatright">
+    <a class="minitext" href="#top">⬆ Top</a>
+</div>
+
+<h2><a id="TaxCategories">Tax Category Maintenance</a></h2>
+
+<p>In this script, you can enter, edit or delete a  tax category name.</p>
+
+<p>You can enter any tax category name. But there are three special tax
category names:</p>
+
+<ul>
+
+<li><b>Exempt</b>. "<i>Exempt</i>" written in British English (en-GB).
This tax category name is translated to other languages, if translated term
is available. You can edit and you can delete this category.</li>
+
+<li><b>Freight</b>. "<i>Freight</i>" written in British English (en-GB).
This tax category name is translated to other languages, if translated term
is available. You can NOT edit nor you can NOT delete this category,
because it is used in several scripts.</li>
+
+<li><b>Handling</b>. "<i>Handling</i>" written in British English (en-GB).
This tax category name is translated to other languages, if translated term
is available. You can edit and you can delete this category.</li>
+
+</ul>
+
+
+
+<!-- End: Tax Categories -->
+
+

Modified: trunk/includes/DatabaseTranslations.php
===================================================================
--- trunk/includes/DatabaseTranslations.php     2014-09-13 04:12:51 UTC
(rev 6883)
+++ trunk/includes/DatabaseTranslations.php     2014-09-13 23:06:42 UTC
(rev 6884)
@@ -4,9 +4,9 @@
 The script includes/DatabaseTranslations.php is a locale language file for
the
 contents of the fields in the database. The purpose of this file is to
translate
 the database fields that appears in screens and reports. This script is
only
-used at the time that the system default language file is language file is
-rebuilt. Can be extended for scripts and other tables where the data from
the
-table is static and used to display.
+used at the time that the system default language file is rebuilt. Can be
+extended for scripts and other tables where the data from the table is
static
+and used to display.
 *******************************************************************************/

 // scripts.description:


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Web-erp-svn mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/web-erp-svn

[WebERP-developers] CustomerInquiry.php W3C html code.

[Rafael C. <raf...@gm...>]

Hi,

A good practice, and a way to avoid problems with web browsers, is that
tables MUST HAVE the same quantity of table-datacells ("<td>" tags). If is
needed, you can use the "colspan" attribute (
quantity of columns a cell should span).

In CustomerInquiry.php I fixed this problem. But, now I see the lsat
version with the fix undo and again we have the same problems in some web
browsers.

Is there any reason for that?

Regards, Rafael.

Re: [WebERP-developers] Use of work centers and locations

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

yep great idea

Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

On 11/09/14 19:03, Pak Ricard wrote:
> Hi Phil:
>
> Now it's crystal clear. Then, does it make sense to add a flag to 
> locations table, to mark locations to be used / hiden for WO purposes?
>
> As I see it, not all locations are meant to be production locations, 
> so it seems logicalk to show only those locations available for WO 
> purposes.
>
> Does it sound OK? If so, I'm happy to code it.
>
> Regards,
> Ricard
>
> 2014-09-11 14:51 GMT+08:00 Phil Daintree <ph...@lo... 
> <mailto:ph...@lo...>>:
>
>     Hi Ricard,
>
>     Well work centres are meant to refer to the cells within locations
>     where the work is done ... in a jewellery manufacturing business
>     there might be a stone polishing work centre, a soldering work
>     centre, turning, annealing and such like. Each work centre might
>     have different overhead rate applicable with differing machine
>     content etc and this was the intention with work centres. The BOMs
>     are defined by work centre so the materials can be specified by
>     work centre. They are quite different to locations (AKA inventory
>     locations/factories or warehouses). There can be a different BOM
>     at a different location/factory that in turn may well refer to
>     different work centres.
>
>     Phil
>
>     Phil Daintree
>     Logic Works Ltd - +64 (0)275 567890
>     http://www.logicworks.co.nz
>
>     On 11/09/14 16:01, Pak Ricard wrote:
>>     Hi all:
>>
>>     If I understood it properly, we do have a table called
>>     workcentres which is supposed to contain the locations where WO
>>     can be produced.
>>     If so, why do we use locations table to select the Factory
>>     Location when entering a WO?
>>
>>     locations table can include locations used as ready to sell
>>     warehouses, shops, recycle bins,  component warehouses, etc
>>     besides "factory locations".
>>
>>     In WorkOrderEntry (and similar scripts), should we restrict the
>>     drop down locations list to locations being set up as work centers?
>>
>>     Regards,
>>     Ricard
>>
>>
>>     ------------------------------------------------------------------------------
>>     Want excitement?
>>     Manually upgrade your production database.
>>     When you want reliability, choose Perforce
>>     Perforce version control. Predictably reliable.
>>     http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>>
>>
>>     _______________________________________________
>>     Web-erp-developers mailing list
>>     Web...@li...  <mailto:Web...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>     ------------------------------------------------------------------------------
>     Want excitement?
>     Manually upgrade your production database.
>     When you want reliability, choose Perforce
>     Perforce version control. Predictably reliable.
>     http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Web-erp-developers mailing list
>     Web...@li...
>     <mailto:Web...@li...>
>     https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] Use of work centers and locations

[Pak R. <pak...@gm...>]

Hi Phil:

Now it's crystal clear. Then, does it make sense to add a flag to locations
table, to mark locations to be used / hiden for WO purposes?

As I see it, not all locations are meant to be production locations, so it
seems logicalk to show only those locations available for WO purposes.

Does it sound OK? If so, I'm happy to code it.

Regards,
Ricard

2014-09-11 14:51 GMT+08:00 Phil Daintree <ph...@lo...>:

>  Hi Ricard,
>
> Well work centres are meant to refer to the cells within locations where
> the work is done ... in a jewellery manufacturing business there might be a
> stone polishing work centre, a soldering work centre, turning, annealing
> and such like. Each work centre might have different overhead rate
> applicable with differing machine content etc and this was the intention
> with work centres. The BOMs are defined by work centre so the materials can
> be specified by work centre. They are quite different to locations (AKA
> inventory locations/factories or warehouses). There can be a different BOM
> at a different location/factory that in turn may well refer to different
> work centres.
>
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz
>
> On 11/09/14 16:01, Pak Ricard wrote:
>
> Hi all:
>
>  If I understood it properly, we do have a table called workcentres which
> is supposed to contain the locations where WO can be produced.
> If so, why do we use locations table to select the Factory Location when
> entering a WO?
>
>  locations table can include locations used as ready to sell warehouses,
> shops, recycle bins,  component warehouses, etc besides "factory
> locations".
>
>  In WorkOrderEntry (and similar scripts), should we restrict the drop
> down locations list to locations being set up as work centers?
>
> Regards,
> Ricard
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>

Re: [WebERP-developers] Use of work centers and locations

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

Hi Ricard,

Well work centres are meant to refer to the cells within locations where 
the work is done ... in a jewellery manufacturing business there might 
be a stone polishing work centre, a soldering work centre, turning, 
annealing and such like. Each work centre might have different overhead 
rate applicable with differing machine content etc and this was the 
intention with work centres. The BOMs are defined by work centre so the 
materials can be specified by work centre. They are quite different to 
locations (AKA inventory locations/factories or warehouses). There can 
be a different BOM at a different location/factory that in turn may well 
refer to different work centres.

Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

On 11/09/14 16:01, Pak Ricard wrote:
> Hi all:
>
> If I understood it properly, we do have a table called workcentres 
> which is supposed to contain the locations where WO can be produced.
> If so, why do we use locations table to select the Factory Location 
> when entering a WO?
>
> locations table can include locations used as ready to sell 
> warehouses, shops, recycle bins,  component warehouses, etc besides 
> "factory locations".
>
> In WorkOrderEntry (and similar scripts), should we restrict the drop 
> down locations list to locations being set up as work centers?
>
> Regards,
> Ricard
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] TableRows()

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

 > I bet 90% of developers find easier to understand a script of 300 
lines instead of one of 600

Well the thing is we are really not talking about reducing the amount of 
code to understand - we are talking about dotting it around in a 
multitude of new files. You still need to understand the 600 lines - but 
now you have to open 30 files to identify where it is .... actually MUCH 
more difficult IMHO - maybe we must agree to differ.

We would have a bunch of functions that you have no idea in which file 
to even find them - grep is the best bet before you can even find the 
code. Alternatively we have a load of includes which at least we know 
where the code is.

Yes we have the advantage that we can reuse these functions and includes 
and we can write the code once - but in many cases the code is actually 
slightly different so we end up with a multitude of ifs to accommodate 
the different uses for the similar code.

Where there are serious reuse possibilities then please do discuss your 
proposal with me first.

See http://www.weberp.org/Development.html

*1.*Join the developers me ailing 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 knowledgeable people on the list and they can 
contribute ideas if you let them. Alternatively, there is a section on 
the webERP forum for posting development specifications for what you 
propose to do.

Of course, if I have any concerns about a proposal then I will chime in.

Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

On 11/09/14 15:03, Pak Ricard wrote:
> Hi all:
>
> Agree that we need to focus in new stuff, but also think that we 
> mostly create new stuff based on current scripts, so the better 
> (readable and short) they are, the better and faster  we can create 
> new stuff and the test will be easily done.
> As Phil pointed out, I learned PHP with webERP (I am computer 
> engineer, so I had some background), but I bet 90% of developers find 
> easier to understand a script of 300 lines instead of one of 600
>
> Well, we should move ahead, but the initial reason of this thread is 
> still there:
> Should Rafael's work on TableRows be accepted or not?
> When we find something like the CalculateDemand (i just had to create 
> another script using demand), should we create the function and "clean 
> up" some scripts so they use the abstraction? or will the job be 
> rejected?
>
> I think we the developers should know, and avoid the frustrating part 
> of spending some time in a commit to see it reverted and not useful.
>
>
>
> Regards,
> Ricard
>
> 2014-09-11 10:39 GMT+08:00 ExsonQu <hex...@gm... 
> <mailto:hex...@gm...>>:
>
>     *Dear all,*
>
>                I agree with Phil that we should pay more attention to
>     those old
>     codes' (or called redundant?). The abstraction to avoid have at
>     least some
>     merit that:
>                1. If there is a bug in the code, it's very clear.
>                2. I believe in most of time, it's fast.
>                3. If we change these tested stable codes, it becomes
>     green code.
>     It introduce new risk to our users.
>                4. And most of the time, it sacrifice the readability.
>     Because we
>     have to understand a new definition which seems intuitive to the
>     author but
>     others have to study it.
>
>               I think most of the time, I don't like the code style of
>     webERP
>     because I cannot code fast. Its a hand-make style and not
>     economic. But the
>     style make those codes reliable and robust and fast. And it's very
>     easy to
>     modify what you need to do is just to search those strings you need.
>
>               So lets focus on adding new features instead of those
>     existed
>     codes or the coding convention, IMHO.
>
>               Best regards!
>
>               Exson
>
>
>
>
>
>
>
>
>
>
>     --
>     View this message in context:
>     http://weberp-accounting.1478800.n4.nabble.com/TableRows-tp4657615p4657634.html
>     Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
>     ------------------------------------------------------------------------------
>     Want excitement?
>     Manually upgrade your production database.
>     When you want reliability, choose Perforce
>     Perforce version control. Predictably reliable.
>     http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Web-erp-developers mailing list
>     Web...@li...
>     <mailto:Web...@li...>
>     https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[WebERP-developers] Use of work centers and locations

[Pak R. <pak...@gm...>]

Hi all:

If I understood it properly, we do have a table called workcentres which is
supposed to contain the locations where WO can be produced.
If so, why do we use locations table to select the Factory Location when
entering a WO?

locations table can include locations used as ready to sell warehouses,
shops, recycle bins,  component warehouses, etc besides "factory
locations".

In WorkOrderEntry (and similar scripts), should we restrict the drop down
locations list to locations being set up as work centers?

Regards,
Ricard

Re: [WebERP-developers] TableRows()

[Jonathan (T. <th...@ic...>]

My view, would be to take the same approach as the Table class that I've
built (sorry for taking so long to finalize development, life has it's
complications)! Each table from weberp should have a class associated, with
functions to modify the table. That way we remove all direct queries from
the main files, and put it in classes. By doing this for everything, and
giving one file per class, (especially if we use an autoloader so that the
class name is the same as the file name) we make it very obvious where the
code is coming from, while at the same time abstracting the code,
amplifying re-use. I can commit an example of that this weekend to the
working branch if people are interested.

On 11 September 2014 10:03, Pak Ricard <pak...@gm...> wrote:

> Hi all:
>
> Agree that we need to focus in new stuff, but also think that we mostly
> create new stuff based on current scripts, so the better (readable and
> short) they are, the better and faster  we can create new stuff and the
> test will be easily done.
> As Phil pointed out, I learned PHP with webERP (I am computer engineer, so
> I had some background), but I bet 90% of developers find easier to
> understand a script of 300 lines instead of one of 600
>
> Well, we should move ahead, but the initial reason of this thread is still
> there:
> Should Rafael's work on TableRows be accepted or not?
> When we find something like the CalculateDemand (i just had to create
> another script using demand), should we create the function and "clean up"
> some scripts so they use the abstraction? or will the job be rejected?
>
> I think we the developers should know, and avoid the frustrating part of
> spending some time in a commit to see it reverted and not useful.
>
>
>
> Regards,
> Ricard
>
> 2014-09-11 10:39 GMT+08:00 ExsonQu <hex...@gm...>:
>
>> *Dear all,*
>>
>>            I agree with Phil that we should pay more attention to those
>> old
>> codes' (or called redundant?). The abstraction to avoid have at least some
>> merit that:
>>            1. If there is a bug in the code, it's very clear.
>>            2. I believe in most of time, it's fast.
>>            3. If we change these tested stable codes, it becomes green
>> code.
>> It introduce new risk to our users.
>>            4. And most of the time, it sacrifice the readability. Because
>> we
>> have to understand a new definition which seems intuitive to the author
>> but
>> others have to study it.
>>
>>           I think most of the time, I don't like the code style of webERP
>> because I cannot code fast. Its a hand-make style and not economic. But
>> the
>> style make those codes reliable and robust and fast. And it's very easy to
>> modify what you need to do is just to search those strings you need.
>>
>>           So lets focus on adding new features instead of those existed
>> codes or the coding convention, IMHO.
>>
>>           Best regards!
>>
>>           Exson
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://weberp-accounting.1478800.n4.nabble.com/TableRows-tp4657615p4657634.html
>> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>

Re: [WebERP-developers] TableRows()

[Pak R. <pak...@gm...>]

Hi all:

Agree that we need to focus in new stuff, but also think that we mostly
create new stuff based on current scripts, so the better (readable and
short) they are, the better and faster  we can create new stuff and the
test will be easily done.
As Phil pointed out, I learned PHP with webERP (I am computer engineer, so
I had some background), but I bet 90% of developers find easier to
understand a script of 300 lines instead of one of 600

Well, we should move ahead, but the initial reason of this thread is still
there:
Should Rafael's work on TableRows be accepted or not?
When we find something like the CalculateDemand (i just had to create
another script using demand), should we create the function and "clean up"
some scripts so they use the abstraction? or will the job be rejected?

I think we the developers should know, and avoid the frustrating part of
spending some time in a commit to see it reverted and not useful.



Regards,
Ricard

2014-09-11 10:39 GMT+08:00 ExsonQu <hex...@gm...>:

> *Dear all,*
>
>            I agree with Phil that we should pay more attention to those old
> codes' (or called redundant?). The abstraction to avoid have at least some
> merit that:
>            1. If there is a bug in the code, it's very clear.
>            2. I believe in most of time, it's fast.
>            3. If we change these tested stable codes, it becomes green
> code.
> It introduce new risk to our users.
>            4. And most of the time, it sacrifice the readability. Because
> we
> have to understand a new definition which seems intuitive to the author but
> others have to study it.
>
>           I think most of the time, I don't like the code style of webERP
> because I cannot code fast. Its a hand-make style and not economic. But the
> style make those codes reliable and robust and fast. And it's very easy to
> modify what you need to do is just to search those strings you need.
>
>           So lets focus on adding new features instead of those existed
> codes or the coding convention, IMHO.
>
>           Best regards!
>
>           Exson
>
>
>
>
>
>
>
>
>
>
> --
> View this message in context:
> http://weberp-accounting.1478800.n4.nabble.com/TableRows-tp4657615p4657634.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [WebERP-developers] More convenient feature for preparing goods in warehouse and confirm delivery

[ExsonQu <hex...@gm...>]

*Hi, Andrew,*

           Sorry for the late reply. 
           We've spent a lots of time to develop this parts. But it seems
more complex than what we thought before. And we cannot release it now due
to it's too complex and customized. It's not webERP's style-simple and
practical. 
            
           I think the big problem for webERP now is that these users in
warehouse and users in sales team have no channel to communicate which
lots/serial no have picked for those orders. A users from Britain has donate
some code to add those lots/serial no to sales orders comments. It seems a
big idea to solve this problem. But the version of he used is quite old, I
have to review those codes and ask other developers' opinion before I can
commit it to the trunk. 

           Best regards!

           Exson
            



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/More-convenient-feature-for-preparing-goods-in-warehouse-and-confirm-delivery-tp4657290p4657635.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] TableRows()

[ExsonQu <hex...@gm...>]

*Dear all,*

           I agree with Phil that we should pay more attention to those old
codes' (or called redundant?). The abstraction to avoid have at least some
merit that:
           1. If there is a bug in the code, it's very clear. 
           2. I believe in most of time, it's fast. 
           3. If we change these tested stable codes, it becomes green code.
It introduce new risk to our users.
           4. And most of the time, it sacrifice the readability. Because we
have to understand a new definition which seems intuitive to the author but
others have to study it. 

          I think most of the time, I don't like the code style of webERP
because I cannot code fast. Its a hand-make style and not economic. But the
style make those codes reliable and robust and fast. And it's very easy to
modify what you need to do is just to search those strings you need. 

          So lets focus on adding new features instead of those existed
codes or the coding convention, IMHO.

          Best regards!

          Exson

          
          

            

          



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/TableRows-tp4657615p4657634.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] TableRows()

[<ph...@lo...>]

There are many places where we could increase abstraction and I agree 
there is a happy medium/compromise position, we have quite a bit and 
there is a lot of scope for more.
Of course Andrew and Ricard both have valid ideas.
I really don't want bugs introduced for the sake of abstraction.
Can we focus on new stuff?


Phil



On 2014-09-10 12:26, gilberto dos santos alves wrote:
> +1 from me.
> 
> 2014-09-09 21:51 GMT-03:00 Pak Ricard <pak...@gm...>:
> 
>> Hi all:
>> 
>> Following on Andrew's POV, we calculate the demand of one item 10
>> times in webERP and it takes 94 lines of code (if I'm not wrong).
>> 
>> I think it is a much readable script if we have a function called
>> CalculateDemandForItem ($StockId, $Location) and we encapsulate the
>> 94 lines there.
>> 
>> Sharing Andrew's <OPINION>, we save 9 * 94 lines of repeated code
>> and we get a much readable script.
>> 
>> There are dozens of similar situations in webERP, where I think we
>> can improve readability and reduce the chances of bugs, as 1 fix
>> fixes all.
>> 
>> Hope we can find a reasonable point where all feel comfortable.
>> 
>> Regards,
>> Ricard
>> 
>> 2014-09-09 3:48 GMT+08:00 Andrew Galuski <aga...@re...>:
>> 
>> Would it be any different if the code was copied into an include
>> instead of a function and we replaced the lines of code with
>> 
>> include('includes/tablerow.inc');
>> 
>> This is what we do with header.inc and footer.inc. We don’t
>> repeat that code in every script (Thank goodness).
>> 
>> <OPINION>
>> 
>> I think a minimal level of abstraction would make changes less
>> daunting. If I know I can concentrate on business logic and not
>> formatting I would be willing to make more enhancements.
>> 
>> Enhancements might also be done more quickly, tested faster and be
>> more stable. An example is a recent change to introduce location
>> based security to WebERP that I submitted. I had seen in the forums
>> multiple times people looking to restrict access to locations within
>> a particular business function. Example Warehouse worked can see
>> inventory levels at Location A but not Location B. In order to make
>> this change I had to modify every script where there was a location
>> selection list.
>> 
>> I had to modify the code as follows:
>> 
>> BEFORE: $sql = "SELECT loccode, locationname FROM locations
>> 
>> AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM
>> locations
>> 
>> INNER JOIN locationusers ON
>> locationusers.loccode=locations.loccode AND locationusers.userid='"
>> . $_SESSION['UserID'] . "' AND locationusers.canview=1"
>> 
>> That line alone appears like 50+ times in 50+ files. The same code
>> to build the <select> takes around 15 lines of code before and after
>> that SQL that is nearly identical in every script.
>> 
>> If all of that code was in an include file or in a function I could
>> have added a feature people requested in less than 1 day instead of
>> 5 days. And testing it would have been a lot faster. If the logic
>> is in 1 place I can test my change in < 5 screens be confident it is
>> working. If I have to change 50 scripts I need to test all 50
>> scripts…Because even the smallest typo can make a script break.
>> 
>> Abstraction and reduced code can be a good thing
>> 
>> </OPINION>
>> 
>> Best Regards,
>> 
>> Andrew
>> 
>> FROM: Phil Daintree [mailto:ph...@lo...]
>> SENT: Tuesday, September 02, 2014 1:25 AM
>> TO: webERP Developers
>> SUBJECT: Re: [WebERP-developers] TableRows()
>> 
>> Ricard,
>> 
>> There are many many ways to reduce the amount of code in webERP -
>> we really could take loads out... but the sacrifice is readability -
>> I don't believe we would gain speed/efficiency.
>> If we made the tables a class as per Jonathan's idea we could take
>> out buckets of code - this would be the obvious extension of the
>> I don't want to change the code to increase abstraction ever - or
>> code that does the same thing a different way that could potentially
>> introduce new bugs. Nope - the effort should be not to reinvent what
>> we have, but to add functionality using the same blocks and
>> structure as we have.
>> 
>> I believe you learnt php from webERP - and are a living example as
>> to why the phil-osophy behind webERP's development style is one of
>> it's greatest strengths...
>> 
>> Phil
>> 
>> Phil Daintree
>> 
>> Logic Works Ltd - +64 (0)275 567890
>> 
>> http://www.logicworks.co.nz [1]
>> 
>> On 02/09/14 13:12, Pak Ricard wrote:
>> 
>> Hi Phil:
>> 
>> I saw with satisfaction the commit 6859 where Rafael used the
>> TableRows() functions in some scripts. Now, I saw this change was
>> reverted, and I can't see but good things about it (probably i'm
>> missing something).
>> 
>> These same 6 lines are repeated over and over webERP (probably over
>> 100 times), so if we get a change to reduce the number of lines and
>> still get a readable script, I think it's worth it.
>> 
>> Well just my 2 cents. I would love to know your POV (and any other
>> developer's) about it :-)
>> 
>> Regards,
>> 
>> Ricard
>> 
>> 
> ------------------------------------------------------------------------------
>> 
>> Slashdot TV.
>> 
>> Video for Nerds. Stuff that matters.
>> 
>> http://tv.slashdot.org/ [2]
>> 
>> _______________________________________________
>> 
>> Web-erp-developers mailing list
>> 
>> Web...@li...
>> 
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers [3]
>> 
>> 
> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>> 
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> [4]
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers [3]
> 
> ------------------------------------------------------------------------------
>  Want excitement?
>  Manually upgrade your production database.
>  When you want reliability, choose Perforce
>  Perforce version control. Predictably reliable.
>  
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> [4]
> _______________________________________________
>  Web-erp-developers mailing list
>  Web...@li...
>  https://lists.sourceforge.net/lists/listinfo/web-erp-developers [3]
> 
> --
> gilberto dos santos alves
> +55.11.98646-5049
> sao paulo - sp - brasil
> 
> 
> 
> Links:
> ------
> [1] http://www.logicworks.co.nz
> [2] http://tv.slashdot.org/
> [3] https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> [4]
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&amp;iu=/4140/ostg.clktrk
> 
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> 
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] TableRows()

[gilberto d. s. a. <gs...@gm...>]

+1 from me.

2014-09-09 21:51 GMT-03:00 Pak Ricard <pak...@gm...>:

> Hi all:
>
> Following on Andrew's POV, we calculate the demand of one item 10 times in
> webERP and it takes 94 lines of code (if I'm not wrong).
>
> I think it is a much readable script if we have a function called
> CalculateDemandForItem ($StockId, $Location) and we encapsulate the 94
> lines there.
>
> Sharing Andrew's <OPINION>, we save 9 * 94 lines of repeated code and we
> get a much readable script.
>
> There are dozens of similar situations in webERP, where I think we can
> improve readability and reduce the chances of bugs, as 1 fix fixes all.
>
> Hope we can find a reasonable point where all feel comfortable.
>
> Regards,
> Ricard
>
> 2014-09-09 3:48 GMT+08:00 Andrew Galuski <aga...@re...>:
>
>>  Would it be any different if the code was copied into an include
>> instead of a function and we replaced the lines of code with
>>
>> include('includes/tablerow.inc');
>>
>>
>>
>> This is what we do with header.inc and footer.inc.  We don’t repeat that
>> code in every script (Thank goodness).
>>
>>
>>
>> <OPINION>
>>
>> I think a minimal level of abstraction would make changes less daunting.
>> If I know I can concentrate on business logic and not formatting I would be
>> willing to make more enhancements.
>>
>> Enhancements might also be done more quickly, tested faster and be more
>> stable.  An example is a recent change to introduce location based security
>> to WebERP that I submitted.  I had seen in the forums multiple times people
>> looking to restrict access to locations within a particular business
>> function.  Example Warehouse worked can see inventory levels at Location A
>> but not Location B.  In order to make this change I had to modify  every
>> script where there was a location selection list.
>>
>> I had to modify the code as follows:
>>
>> BEFORE: $sql = "SELECT loccode, locationname FROM locations
>>
>> AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM
>> locations
>>
>>                                 INNER JOIN locationusers ON
>> locationusers.loccode=locations.loccode AND locationusers.userid='" .
>> $_SESSION['UserID'] . "' AND locationusers.canview=1"
>>
>>
>>
>> That line alone appears like 50+ times in 50+ files.  The same code to
>> build the <select> takes around 15 lines of code before and after that SQL
>> that is nearly identical in every script.
>>
>> If all of that code was in an include file or in a function I could have
>> added a feature people requested in less than 1 day instead of 5 days.  And
>> testing it would have been a lot faster.  If the logic is in 1 place I can
>> test my change in < 5 screens be confident it is working.  If I have to
>> change 50 scripts I need to test all 50 scripts…Because even the smallest
>> typo can make a script break.
>>
>>
>>
>> Abstraction and reduced code can be a good thing
>>
>> </OPINION>
>>
>>
>>
>> Best Regards,
>>
>> Andrew
>>
>>
>>
>> *From:* Phil Daintree [mailto:ph...@lo...]
>> *Sent:* Tuesday, September 02, 2014 1:25 AM
>> *To:* webERP Developers
>> *Subject:* Re: [WebERP-developers] TableRows()
>>
>>
>>
>> Ricard,
>>
>> There are many many ways to reduce the amount of code in webERP - we
>> really could take loads out... but the sacrifice is readability - I don't
>> believe we would gain speed/efficiency.
>> If we made the tables a class as per Jonathan's idea we could take out
>> buckets of code - this would be the obvious extension of the
>> I don't want to change the code to increase abstraction ever - or code
>> that does the same thing a different way that could potentially introduce
>> new bugs. Nope - the effort should be not to reinvent what we have, but to
>> add functionality using the same blocks and structure as we have.
>>
>> I believe you learnt php from webERP - and are a living example as to why
>> the phil-osophy behind webERP's development style is one of it's greatest
>> strengths...
>>
>>  Phil
>>
>>
>>
>> Phil Daintree
>>
>> Logic Works Ltd - +64 (0)275 567890
>>
>> http://www.logicworks.co.nz
>>
>> On 02/09/14 13:12, Pak Ricard wrote:
>>
>>  Hi Phil:
>>
>>
>>
>> I saw with satisfaction the commit 6859 where Rafael used the TableRows()
>> functions in some scripts. Now, I saw this change was reverted, and I can't
>> see but good things about it (probably i'm missing something).
>>
>>
>>
>> These same 6 lines are repeated over and over webERP (probably over 100
>> times), so if we get a change to reduce the number of lines and still get a
>> readable script, I think it's worth it.
>>
>>
>>
>> Well just my 2 cents. I would love to know your POV (and any other
>> developer's) about it :-)
>>
>>
>>
>> Regards,
>>
>> Ricard
>>
>>
>>
>>
>>  ------------------------------------------------------------------------------
>>
>> Slashdot TV.
>>
>> Video for Nerds.  Stuff that matters.
>>
>> http://tv.slashdot.org/
>>
>>
>>
>>
>>  _______________________________________________
>>
>> Web-erp-developers mailing list
>>
>> Web...@li...
>>
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>


-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

[WebERP-developers] Electronic Signature Device on web based systems

[Arwan <r1g...@gm...>]

Hi

is it possible to get an electronic signature on an invoice printed with web
hosted WebERP
from an electronic signature device that is located on the client PC ?

<http://weberp-accounting.1478800.n4.nabble.com/file/n4657630/esd.png> 

Sample Invoice with electronic signature from the electronic signature
device (ESD) at bottom

<http://weberp-accounting.1478800.n4.nabble.com/file/n4657630/esd-inv.png>  

Someone else in Mexico was asking about the same in 2006

http://weberp-accounting.1478800.n4.nabble.com/Mexico-RFC-Image-on-Invoices-td1479824.html#a1479824
<http://weberp-accounting.1478800.n4.nabble.com/Mexico-RFC-Image-on-Invoices-td1479824.html#a1479824>  



-----
WebTech Resources
Nairobi Kenya
+254 724659244
Email : in...@we...  
weberp.co.ke

--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Electronic-Signature-Device-on-web-based-systems-tp4657630.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] TableRows()

[Pak R. <pak...@gm...>]

Hi all:

Following on Andrew's POV, we calculate the demand of one item 10 times in
webERP and it takes 94 lines of code (if I'm not wrong).

I think it is a much readable script if we have a function called
CalculateDemandForItem ($StockId, $Location) and we encapsulate the 94
lines there.

Sharing Andrew's <OPINION>, we save 9 * 94 lines of repeated code and we
get a much readable script.

There are dozens of similar situations in webERP, where I think we can
improve readability and reduce the chances of bugs, as 1 fix fixes all.

Hope we can find a reasonable point where all feel comfortable.

Regards,
Ricard

2014-09-09 3:48 GMT+08:00 Andrew Galuski <aga...@re...>:

>  Would it be any different if the code was copied into an include instead
> of a function and we replaced the lines of code with
>
> include('includes/tablerow.inc');
>
>
>
> This is what we do with header.inc and footer.inc.  We don’t repeat that
> code in every script (Thank goodness).
>
>
>
> <OPINION>
>
> I think a minimal level of abstraction would make changes less daunting.
> If I know I can concentrate on business logic and not formatting I would be
> willing to make more enhancements.
>
> Enhancements might also be done more quickly, tested faster and be more
> stable.  An example is a recent change to introduce location based security
> to WebERP that I submitted.  I had seen in the forums multiple times people
> looking to restrict access to locations within a particular business
> function.  Example Warehouse worked can see inventory levels at Location A
> but not Location B.  In order to make this change I had to modify  every
> script where there was a location selection list.
>
> I had to modify the code as follows:
>
> BEFORE: $sql = "SELECT loccode, locationname FROM locations
>
> AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM
> locations
>
>                                 INNER JOIN locationusers ON
> locationusers.loccode=locations.loccode AND locationusers.userid='" .
> $_SESSION['UserID'] . "' AND locationusers.canview=1"
>
>
>
> That line alone appears like 50+ times in 50+ files.  The same code to
> build the <select> takes around 15 lines of code before and after that SQL
> that is nearly identical in every script.
>
> If all of that code was in an include file or in a function I could have
> added a feature people requested in less than 1 day instead of 5 days.  And
> testing it would have been a lot faster.  If the logic is in 1 place I can
> test my change in < 5 screens be confident it is working.  If I have to
> change 50 scripts I need to test all 50 scripts…Because even the smallest
> typo can make a script break.
>
>
>
> Abstraction and reduced code can be a good thing
>
> </OPINION>
>
>
>
> Best Regards,
>
> Andrew
>
>
>
> *From:* Phil Daintree [mailto:ph...@lo...]
> *Sent:* Tuesday, September 02, 2014 1:25 AM
> *To:* webERP Developers
> *Subject:* Re: [WebERP-developers] TableRows()
>
>
>
> Ricard,
>
> There are many many ways to reduce the amount of code in webERP - we
> really could take loads out... but the sacrifice is readability - I don't
> believe we would gain speed/efficiency.
> If we made the tables a class as per Jonathan's idea we could take out
> buckets of code - this would be the obvious extension of the
> I don't want to change the code to increase abstraction ever - or code
> that does the same thing a different way that could potentially introduce
> new bugs. Nope - the effort should be not to reinvent what we have, but to
> add functionality using the same blocks and structure as we have.
>
> I believe you learnt php from webERP - and are a living example as to why
> the phil-osophy behind webERP's development style is one of it's greatest
> strengths...
>
>  Phil
>
>
>
> Phil Daintree
>
> Logic Works Ltd - +64 (0)275 567890
>
> http://www.logicworks.co.nz
>
> On 02/09/14 13:12, Pak Ricard wrote:
>
>  Hi Phil:
>
>
>
> I saw with satisfaction the commit 6859 where Rafael used the TableRows()
> functions in some scripts. Now, I saw this change was reverted, and I can't
> see but good things about it (probably i'm missing something).
>
>
>
> These same 6 lines are repeated over and over webERP (probably over 100
> times), so if we get a change to reduce the number of lines and still get a
> readable script, I think it's worth it.
>
>
>
> Well just my 2 cents. I would love to know your POV (and any other
> developer's) about it :-)
>
>
>
> Regards,
>
> Ricard
>
>
>
>
>  ------------------------------------------------------------------------------
>
> Slashdot TV.
>
> Video for Nerds.  Stuff that matters.
>
> http://tv.slashdot.org/
>
>
>
>
>  _______________________________________________
>
> Web-erp-developers mailing list
>
> Web...@li...
>
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>

Re: [WebERP-developers] Required by date not correct in WO order

[gilberto d. s. a. <gs...@gm...>]

you are welcome.

2014-09-08 21:18 GMT-03:00 Pak Ricard <pak...@gm...>:

> Hi Gilberto:
> Thanks for the tips. I already tested it, and the problem is we are
> missing the value of the parameter ReqDate somewhere when we create a WO
> from the Suggested WO created by MRP.I believe it's a bug.
>
> Regards,
> Ricard
>
> 2014-09-08 22:25 GMT+08:00 gilberto dos santos alves <gs...@gm...>:
>
>> HI.
>> Please at [1] you could access environment for testes. See that
>> environment and make all POC (proof of concept) what you want. I already
>> verify if and it is working.
>> Another good reference is [2].
>> Have you created a mrp available calendar days (menu setup)?
>> Regards.
>>
>>
>>
>> [1] http://www.weberp.org
>> [2]
>> http://www.weberp.org/weberp/doc/Manual/ManualContents.php?ViewTopic=MRP
>>
>> 2014-09-07 22:56 GMT-03:00 Pak Ricard <pak...@gm...>:
>>
>>> Hi all:
>>>
>>> When we convert a MRP suggested WO into a real WO, the filed "Required
>>> by" is always set to 0000-00-00.
>>>
>>> Go reproduce this bug:
>>>
>>>    - Go to Manufacturing - MRP Suggested Work Orders
>>>    - Click Review
>>>    - In the list we can get the proper Due Date, but when we click on
>>>    "Convert" to create a real WO, this field is lost, even if it's passed as a
>>>    parameter.
>>>
>>> I can't find why. Could anyone take a look, please?
>>>
>>> many thanks,
>>> Ricard
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want excitement?
>>> Manually upgrade your production database.
>>> When you want reliability, choose Perforce
>>> Perforce version control. Predictably reliable.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Web-erp-developers mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>
>>>
>>
>>
>> --
>> gilberto dos santos alves
>> +55.11.98646-5049
>> sao paulo - sp - brasil
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>


-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

Re: [WebERP-developers] TableRows()

[Pak R. <pak...@gm...>]

Hi Phil:

Sorry I didn't understand. Is it finally OK to use functions / includes as
in the case of TableRows()?

If so, when should we use include or function?

Also, I found Tim's proposal for PrintARowOfTable() a really interesing
one. I'm particularly lost with html (which is way more cryptic than PHP),
so, if we can encapsulate some highly used part of code (as printing a row
of a table), I would be really happy.

I also think, the shorter the code, the easier it is to understand, if all
functions have a clear and long enough name.

Regards,
Ricard

2014-09-09 9:24 GMT+08:00 <ph...@lo...>:

> Preferable for really high use code as the user knows where to find it.
> I like to keep includes to a minimum too though. Some repetition of the
> code is a consequence ... I accept this of course.
>
> Phil
>
> On 2014-09-08 13:48, Andrew Galuski wrote:
> > Would it be any different if the code was copied into an include
> > instead of a function and we replaced the lines of code with
> >
> > include('includes/tablerow.inc');
> >
> > This is what we do with header.inc and footer.inc. We don't repeat
> > that code in every script (Thank goodness).
> >
> > <OPINION>
> >
> > I think a minimal level of abstraction would make changes less
> > daunting. If I know I can concentrate on business logic and not
> > formatting I would be willing to make more enhancements.
> >
> > Enhancements might also be done more quickly, tested faster and be
> > more stable. An example is a recent change to introduce location based
> > security to WebERP that I submitted. I had seen in the forums multiple
> > times people looking to restrict access to locations within a
> > particular business function. Example Warehouse worked can see
> > inventory levels at Location A but not Location B. In order to make
> > this change I had to modify every script where there was a location
> > selection list.
> >
> > I had to modify the code as follows:
> >
> > BEFORE: $sql = "SELECT loccode, locationname FROM locations
> >
> > AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM
> > locations
> >
> >  INNER JOIN locationusers ON locationusers.loccode=locations.loccode
> > AND locationusers.userid='" . $_SESSION['UserID'] . "' AND
> > locationusers.canview=1"
> >
> > That line alone appears like 50+ times in 50+ files. The same code to
> > build the <select> takes around 15 lines of code before and after that
> > SQL that is nearly identical in every script.
> >
> > If all of that code was in an include file or in a function I could
> > have added a feature people requested in less than 1 day instead of 5
> > days. And testing it would have been a lot faster. If the logic is in
> > 1 place I can test my change in < 5 screens be confident it is
> > working. If I have to change 50 scripts I need to test all 50
> > scripts…Because even the smallest typo can make a script break.
> >
> > Abstraction and reduced code can be a good thing
> >
> > </OPINION>
> >
> > Best Regards,
> >
> > Andrew
> >
> > FROM: Phil Daintree [mailto:ph...@lo...]
> >  SENT: Tuesday, September 02, 2014 1:25 AM
> >  TO: webERP Developers
> >  SUBJECT: Re: [WebERP-developers] TableRows()
> >
> > Ricard,
> >
> >  There are many many ways to reduce the amount of code in webERP - we
> > really could take loads out... but the sacrifice is readability - I
> > don't believe we would gain speed/efficiency.
> >  If we made the tables a class as per Jonathan's idea we could take
> > out buckets of code - this would be the obvious extension of the
> >  I don't want to change the code to increase abstraction ever - or
> > code that does the same thing a different way that could potentially
> > introduce new bugs. Nope - the effort should be not to reinvent what
> > we have, but to add functionality using the same blocks and structure
> > as we have.
> >
> >  I believe you learnt php from webERP - and are a living example as to
> > why the phil-osophy behind webERP's development style is one of it's
> > greatest strengths...
> >
> > Phil
> >
> > Phil Daintree
> >
> > Logic Works Ltd - +64 (0)275 567890
> >
> > http://www.logicworks.co.nz [3]
> >
> > On 02/09/14 13:12, Pak Ricard wrote:
> >
> >> Hi Phil:
> >>
> >> I saw with satisfaction the commit 6859 where Rafael used the
> >> TableRows() functions in some scripts. Now, I saw this change was
> >> reverted, and I can't see but good things about it (probably i'm
> >> missing something).
> >>
> >> These same 6 lines are repeated over and over webERP (probably over
> >> 100 times), so if we get a change to reduce the number of lines and
> >> still get a readable script, I think it's worth it.
> >>
> >> Well just my 2 cents. I would love to know your POV (and any other
> >> developer's) about it :-)
> >>
> >> Regards,
> >>
> >> Ricard
> >>
> >>
> >
> ------------------------------------------------------------------------------
> >>
> >> Slashdot TV.
> >>
> >> Video for Nerds. Stuff that matters.
> >>
> >> http://tv.slashdot.org/ [1]
> >>
> >> _______________________________________________
> >>
> >> Web-erp-developers mailing list
> >>
> >> Web...@li...
> >>
> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers [2]
> >
> >
> >
> > Links:
> > ------
> > [1] http://tv.slashdot.org/
> > [2] https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > [3] http://www.logicworks.co.nz
> >
> >
> ------------------------------------------------------------------------------
> > Want excitement?
> > Manually upgrade your production database.
> > When you want reliability, choose Perforce
> > Perforce version control. Predictably reliable.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> >
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [WebERP-developers] TableRows()

[<ph...@lo...>]

Preferable for really high use code as the user knows where to find it. 
I like to keep includes to a minimum too though. Some repetition of the 
code is a consequence ... I accept this of course.

Phil

On 2014-09-08 13:48, Andrew Galuski wrote:
> Would it be any different if the code was copied into an include
> instead of a function and we replaced the lines of code with
> 
> include('includes/tablerow.inc');
> 
> This is what we do with header.inc and footer.inc. We don't repeat
> that code in every script (Thank goodness).
> 
> <OPINION>
> 
> I think a minimal level of abstraction would make changes less
> daunting. If I know I can concentrate on business logic and not
> formatting I would be willing to make more enhancements.
> 
> Enhancements might also be done more quickly, tested faster and be
> more stable. An example is a recent change to introduce location based
> security to WebERP that I submitted. I had seen in the forums multiple
> times people looking to restrict access to locations within a
> particular business function. Example Warehouse worked can see
> inventory levels at Location A but not Location B. In order to make
> this change I had to modify every script where there was a location
> selection list.
> 
> I had to modify the code as follows:
> 
> BEFORE: $sql = "SELECT loccode, locationname FROM locations
> 
> AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM
> locations
> 
>  INNER JOIN locationusers ON locationusers.loccode=locations.loccode
> AND locationusers.userid='" . $_SESSION['UserID'] . "' AND
> locationusers.canview=1"
> 
> That line alone appears like 50+ times in 50+ files. The same code to
> build the <select> takes around 15 lines of code before and after that
> SQL that is nearly identical in every script.
> 
> If all of that code was in an include file or in a function I could
> have added a feature people requested in less than 1 day instead of 5
> days. And testing it would have been a lot faster. If the logic is in
> 1 place I can test my change in < 5 screens be confident it is
> working. If I have to change 50 scripts I need to test all 50
> scripts…Because even the smallest typo can make a script break.
> 
> Abstraction and reduced code can be a good thing
> 
> </OPINION>
> 
> Best Regards,
> 
> Andrew
> 
> FROM: Phil Daintree [mailto:ph...@lo...]
>  SENT: Tuesday, September 02, 2014 1:25 AM
>  TO: webERP Developers
>  SUBJECT: Re: [WebERP-developers] TableRows()
> 
> Ricard,
> 
>  There are many many ways to reduce the amount of code in webERP - we
> really could take loads out... but the sacrifice is readability - I
> don't believe we would gain speed/efficiency.
>  If we made the tables a class as per Jonathan's idea we could take
> out buckets of code - this would be the obvious extension of the
>  I don't want to change the code to increase abstraction ever - or
> code that does the same thing a different way that could potentially
> introduce new bugs. Nope - the effort should be not to reinvent what
> we have, but to add functionality using the same blocks and structure
> as we have.
> 
>  I believe you learnt php from webERP - and are a living example as to
> why the phil-osophy behind webERP's development style is one of it's
> greatest strengths...
> 
> Phil
> 
> Phil Daintree
> 
> Logic Works Ltd - +64 (0)275 567890
> 
> http://www.logicworks.co.nz [3]
> 
> On 02/09/14 13:12, Pak Ricard wrote:
> 
>> Hi Phil:
>> 
>> I saw with satisfaction the commit 6859 where Rafael used the
>> TableRows() functions in some scripts. Now, I saw this change was
>> reverted, and I can't see but good things about it (probably i'm
>> missing something).
>> 
>> These same 6 lines are repeated over and over webERP (probably over
>> 100 times), so if we get a change to reduce the number of lines and
>> still get a readable script, I think it's worth it.
>> 
>> Well just my 2 cents. I would love to know your POV (and any other
>> developer's) about it :-)
>> 
>> Regards,
>> 
>> Ricard
>> 
>> 
> ------------------------------------------------------------------------------
>> 
>> Slashdot TV.
>> 
>> Video for Nerds. Stuff that matters.
>> 
>> http://tv.slashdot.org/ [1]
>> 
>> _______________________________________________
>> 
>> Web-erp-developers mailing list
>> 
>> Web...@li...
>> 
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers [2]
> 
> 
> 
> Links:
> ------
> [1] http://tv.slashdot.org/
> [2] https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> [3] http://www.logicworks.co.nz
> 
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> 
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] Required by date not correct in WO order

[Pak R. <pak...@gm...>]

Hi Gilberto:
Thanks for the tips. I already tested it, and the problem is we are missing
the value of the parameter ReqDate somewhere when we create a WO from the
Suggested WO created by MRP.I believe it's a bug.

Regards,
Ricard

2014-09-08 22:25 GMT+08:00 gilberto dos santos alves <gs...@gm...>:

> HI.
> Please at [1] you could access environment for testes. See that
> environment and make all POC (proof of concept) what you want. I already
> verify if and it is working.
> Another good reference is [2].
> Have you created a mrp available calendar days (menu setup)?
> Regards.
>
>
>
> [1] http://www.weberp.org
> [2]
> http://www.weberp.org/weberp/doc/Manual/ManualContents.php?ViewTopic=MRP
>
> 2014-09-07 22:56 GMT-03:00 Pak Ricard <pak...@gm...>:
>
>> Hi all:
>>
>> When we convert a MRP suggested WO into a real WO, the filed "Required
>> by" is always set to 0000-00-00.
>>
>> Go reproduce this bug:
>>
>>    - Go to Manufacturing - MRP Suggested Work Orders
>>    - Click Review
>>    - In the list we can get the proper Due Date, but when we click on
>>    "Convert" to create a real WO, this field is lost, even if it's passed as a
>>    parameter.
>>
>> I can't find why. Could anyone take a look, please?
>>
>> many thanks,
>> Ricard
>>
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>
>
> --
> gilberto dos santos alves
> +55.11.98646-5049
> sao paulo - sp - brasil
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>

Re: [WebERP-developers] TableRows()

[Andrew G. <aga...@re...>]

Would it be any different if the code was copied into an include instead of a function and we replaced the lines of code with
include('includes/tablerow.inc');

This is what we do with header.inc and footer.inc.  We don't repeat that code in every script (Thank goodness).

<OPINION>
I think a minimal level of abstraction would make changes less daunting.  If I know I can concentrate on business logic and not formatting I would be willing to make more enhancements.
Enhancements might also be done more quickly, tested faster and be more stable.  An example is a recent change to introduce location based security to WebERP that I submitted.  I had seen in the forums multiple times people looking to restrict access to locations within a particular business function.  Example Warehouse worked can see inventory levels at Location A but not Location B.  In order to make this change I had to modify  every script where there was a location selection list.
I had to modify the code as follows:
BEFORE: $sql = "SELECT loccode, locationname FROM locations
AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM locations
                                INNER JOIN locationusers ON locationusers.loccode=locations.loccode AND locationusers.userid='" .  $_SESSION['UserID'] . "' AND locationusers.canview=1"

That line alone appears like 50+ times in 50+ files.  The same code to build the <select> takes around 15 lines of code before and after that SQL that is nearly identical in every script.
If all of that code was in an include file or in a function I could have added a feature people requested in less than 1 day instead of 5 days.  And testing it would have been a lot faster.  If the logic is in 1 place I can test my change in < 5 screens be confident it is working.  If I have to change 50 scripts I need to test all 50 scripts...Because even the smallest typo can make a script break.

Abstraction and reduced code can be a good thing
</OPINION>

Best Regards,
Andrew

From: Phil Daintree [mailto:ph...@lo...]
Sent: Tuesday, September 02, 2014 1:25 AM
To: webERP Developers
Subject: Re: [WebERP-developers] TableRows()

Ricard,

There are many many ways to reduce the amount of code in webERP - we really could take loads out... but the sacrifice is readability - I don't believe we would gain speed/efficiency.
If we made the tables a class as per Jonathan's idea we could take out buckets of code - this would be the obvious extension of the
I don't want to change the code to increase abstraction ever - or code that does the same thing a different way that could potentially introduce new bugs. Nope - the effort should be not to reinvent what we have, but to add functionality using the same blocks and structure as we have.

I believe you learnt php from webERP - and are a living example as to why the phil-osophy behind webERP's development style is one of it's greatest strengths...


Phil



Phil Daintree

Logic Works Ltd - +64 (0)275 567890

http://www.logicworks.co.nz
On 02/09/14 13:12, Pak Ricard wrote:
Hi Phil:

I saw with satisfaction the commit 6859 where Rafael used the TableRows() functions in some scripts. Now, I saw this change was reverted, and I can't see but good things about it (probably i'm missing something).

These same 6 lines are repeated over and over webERP (probably over 100 times), so if we get a change to reduce the number of lines and still get a readable script, I think it's worth it.

Well just my 2 cents. I would love to know your POV (and any other developer's) about it :-)

Regards,
Ricard




------------------------------------------------------------------------------

Slashdot TV.

Video for Nerds.  Stuff that matters.

http://tv.slashdot.org/




_______________________________________________

Web-erp-developers mailing list

Web...@li...<mailto:Web...@li...>

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

Re: [WebERP-developers] Required by date not correct in WO order

[gilberto d. s. a. <gs...@gm...>]

HI.
Please at [1] you could access environment for testes. See that environment
and make all POC (proof of concept) what you want. I already verify if and
it is working.
Another good reference is [2].
Have you created a mrp available calendar days (menu setup)?
Regards.



[1] http://www.weberp.org
[2] http://www.weberp.org/weberp/doc/Manual/ManualContents.php?ViewTopic=MRP

2014-09-07 22:56 GMT-03:00 Pak Ricard <pak...@gm...>:

> Hi all:
>
> When we convert a MRP suggested WO into a real WO, the filed "Required by"
> is always set to 0000-00-00.
>
> Go reproduce this bug:
>
>    - Go to Manufacturing - MRP Suggested Work Orders
>    - Click Review
>    - In the list we can get the proper Due Date, but when we click on
>    "Convert" to create a real WO, this field is lost, even if it's passed as a
>    parameter.
>
> I can't find why. Could anyone take a look, please?
>
> many thanks,
> Ricard
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>


-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

[WebERP-developers] Required by date not correct in WO order

[Pak R. <pak...@gm...>]

Hi all:

When we convert a MRP suggested WO into a real WO, the filed "Required by"
is always set to 0000-00-00.

Go reproduce this bug:

   - Go to Manufacturing - MRP Suggested Work Orders
   - Click Review
   - In the list we can get the proper Due Date, but when we click on
   "Convert" to create a real WO, this field is lost, even if it's passed as a
   parameter.

I can't find why. Could anyone take a look, please?

many thanks,
Ricard

Re: [WebERP-developers] Copy BOM fails - Solution

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

Thanks committed these changes

Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

On 05/09/14 06:23, rfthomas wrote:
> Andrew,
>
> Bin was also missing from the locstock SQL.  We have made the following
> changes:
>
> 		$sql = "INSERT INTO bom
> 					SELECT '".$NewStockID."' AS parent,
> 							sequence,
> 							component,
> 							workcentreadded,
> 							loccode,
> 							effectiveafter,
> 							effectiveto,
> 							quantity,
> 							autoissue
> 					FROM bom
> 					WHERE parent='".$StockID."';";
> 		$result = DB_query($sql, $db);
>
> 		if($NewOrExisting == 'N') {
> 			$sql = "INSERT INTO locstock
> 		      SELECT loccode,
> 					'".$NewStockID."' AS stockid,
> 					0 AS quantity,
> 					reorderlevel,
> 					bin
> 				FROM locstock
> 				WHERE stockid='".$StockID."'";
>
> 			$result = DB_query($sql, $db);
> 		}
>
>
>
>
> --
> View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Re-Copy-BOM-fails-Solution-tp4657618p4657619.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [WebERP-developers] Copy BOM fails - Solution

[rfthomas <rf...@as...>]

Andrew,

Bin was also missing from the locstock SQL.  We have made the following
changes:

		$sql = "INSERT INTO bom
					SELECT '".$NewStockID."' AS parent,
							sequence,
							component,
							workcentreadded,
							loccode,
							effectiveafter,
							effectiveto,
							quantity,
							autoissue
					FROM bom
					WHERE parent='".$StockID."';";
		$result = DB_query($sql, $db);

		if($NewOrExisting == 'N') {
			$sql = "INSERT INTO locstock
		      SELECT loccode,
					'".$NewStockID."' AS stockid,
					0 AS quantity,
					reorderlevel,
					bin
				FROM locstock
				WHERE stockid='".$StockID."'";

			$result = DB_query($sql, $db);
		}




--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Re-Copy-BOM-fails-Solution-tp4657618p4657619.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] Copy BOM fails - Solution

[Andrew G. <aga...@re...>]

Add this code at line 124 (Between  'as parent,' and 'component'

	'sequence,'



Best Regards,
Andrew Galuski
ResMart LLC.
817.615.2038 (Office)
817.821.0544 (Cell)
www.resmart.com


-----Original Message-----
From: rfthomas [mailto:rf...@as...] 
Sent: Thursday, September 04, 2014 1:12 PM
To: web...@li...
Subject: [WebERP-developers] Copy BOM fails

The copy BOM is failing with the following error being displayed:

Database Error 1136 : 
Column count doesn't match value count at row 1 Database SQL Failure : The SQL that failed was INSERT INTO bom SELECT 'AA-100L-2GM' AS parent, component, workcentreadded, loccode, effectiveafter, effectiveto, quantity, autoissue FROM bom WHERE parent='AA-100L-2G';




--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Copy-BOM-fails-tp4657617.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Web-erp-developers mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers