web-erp-developers — Discussion on development of webERP

Re: [WebERP-developers] Running weberp on an Andrioid table

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

We had tested BitWebServer and some others.  They ran lighttpd, php and
MySQL.  The applications were useable.  We tested weberp, joomla and
phpmyadmin.  We were able to set-up any android system as a web server, but
suspect that such would not handle more than a couple of connections.  We
only tested under light loads and not all functionality, e.g. email.

We had no real interest in using a tablet or cell phone (they worked on cell
phone with no problems) as a server.

The tests were run on Android 2.3 on Sony Xperia X10 (Android 2.3 at least 3
years ago - webERP and Joomla testing), Samsung Galaxy S3 (android 4.4.2)
and Samsung Galaxy Note 8 (android 4.4.2).

We found the tools for software/web site development available on android
were too cumbersome to be of much use.

None of the devices were rooted or running any customized versions of
android.

Bob Thomas



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Running-weberp-on-an-Andrioid-table-tp4657674p4657675.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

[WebERP-developers] Running weberp on an Andrioid table

[R2-G <r2g...@gm...>]

Is it possible to run webweb locally on an android tablet ?
Useing any of the various php/MySQL servers available on
Google play under android apps ?

I have an android 4.2 tablet and would like to set up WebERP 
To run locally on the tablet. Is this even possible

Has anybody already done it ?
Which php/MySQL server was used ?




--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Running-weberp-on-an-Andrioid-table-tp4657674.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] AccountGroups.php. Questions about code.

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

I had tended to go with (a) because they are infrequent and cause 
trouble - I used the MiscFunction ContainsIllegalCharacters() but some 
think it was unecessarily restrictive as these characters can be dealt 
with using (b). But when it comes to editing these fields we need to 
bring back them back to raw form.

Phil

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

On 28/09/14 04:20, Rafael Chacón wrote:
> Hi,
>
> On AccountGroups.php, in line 320 we have:
>
> <td>' . htmlspecialchars($myrow['groupname'], ENT_QUOTES,'UTF-8') . '</td>
>
> but in lines 321 and 324 we have:
>
> <td>' . $myrow['sectionname'] . '</td>
> ...
> <td>' . $myrow['parentgroupname'] . '</td>
>
> The htmlspecialchars() function converts some predefined characters to 
> HTML entities [ & (ampersand) becomes &amp; " (double quote) becomes 
> &quot; ' (single quote) becomes &#039; < (less than) becomes &lt; > 
> (greater than) becomes &gt; ].
>
> My questions:
>
> 1. Is there any reason to use it in account-goup-name, but not in 
> account-section-name nor in account-parent-group-name ?
>
> 2. How often do you find these characters (ampersand, double quote, 
> single quote, less than, greater than) in those names ?
>
> My proposal: if these characters (ampersand, double quote, single 
> quote, less than, greater than) are very-very-low frequent in those 
> names, we can:
>
> a) Declare these characters as "invalid" and filter them in the 
> "input-procedure" (procedure used infrequently) and
> eliminate the use of the htmlspecialchars() function in the 
> "display-procedure" (procedure used frequently). Or,
>
> b) Convert/Unconvert these characters to store them as "HTML entities" 
> in the database in the "input-procedure" (procedure used infrequently) and
> eliminate the use of the htmlspecialchars() function in the 
> "display-procedure" (procedure used frequently) by using data "as-is" 
> in the database.
>
> Technical comments, opinions, suggestions?
>
> Best regards, Rafael.
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[WebERP-developers] AccountGroups.php. Questions about code.

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

Hi,

On AccountGroups.php, in line 320 we have:

<td>' . htmlspecialchars($myrow['groupname'], ENT_QUOTES,'UTF-8') . '</td>

but in lines 321 and 324 we have:

<td>' . $myrow['sectionname'] . '</td>
...
<td>' . $myrow['parentgroupname'] . '</td>

The htmlspecialchars() function converts some predefined characters to HTML
entities [ & (ampersand) becomes &amp; " (double quote) becomes &quot; '
(single quote) becomes &#039; < (less than) becomes &lt; > (greater than)
becomes &gt; ].

My questions:

1. Is there any reason to use it in account-goup-name, but not in
account-section-name nor in account-parent-group-name ?

2. How often do you find these characters (ampersand, double quote, single
quote, less than, greater than) in those names ?

My proposal: if these characters (ampersand, double quote, single quote,
less than, greater than) are very-very-low frequent in those names, we can:

a) Declare these characters as "invalid" and filter them in the
"input-procedure" (procedure used infrequently) and
eliminate the use of the htmlspecialchars() function in the
"display-procedure" (procedure used frequently). Or,

b) Convert/Unconvert these characters to store them as "HTML entities" in
the database in the "input-procedure" (procedure used infrequently) and
eliminate the use of the htmlspecialchars() function in the
"display-procedure" (procedure used frequently) by using data "as-is" in
the database.

Technical comments, opinions, suggestions?

Best regards, Rafael.

[WebERP-developers] Fxprice, Fxnet and Display total variance

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

*Dear all,*

          We found a  problem that the sum of invoice of line total is not
absolutely equal with the Display total amount of Invoice when foreign
exchange rate is not 1 for foreign currency. 

            The variance come from the transaction price recovered by
stockmoves.price * exchange rate. The price has been got via div by exchange
rate before. 
            The affected lines around 266-267:
           	((1 - stockmoves.discountpercent) * stockmoves.price * " .
$ExchRate . " * stockmoves.qty) AS fxnet,
								(stockmoves.price * " . $ExchRate . ") AS fxprice,
             Total amount are from debtortrans which on line around 1073:
              $DisplayTotal =
locale_number_format($myrow['ovfreight']+$myrow['ovgst']+$myrow['ovamount'],$myrow['decimalplaces']);

            The solution maybe to retrieve price from sales orders directly.
But there is risk for this. Since we have no features to prevent from sales
orders deleting after goods delivered. And there maybe other potential
problem for this. 
             Any comments are highly appreciated for this.

            Thanks and best regards!

            Exson

                 




--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Fxprice-Fxnet-and-Display-total-variance-tp4657671.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] Bug? MRP for WO at reqdate instead of startdate

[opto <bu...@op...>]

I still fully support what I wrote two years ago:

1) MRP must be for start of WO, not for end of WO. Components must be
available when I start manufacturing.

2) It would be preferable to have lead time for components. If they cost
20.000 EUR, I do not want to order them before wo start if I only need them
after 12 weeks (optimise flow of capital funds)

3) History of wo changes is required by German and European product laws.

I think I provided a bug fix for 1) in 2012.
2) We have lead time for parts I buy. how about defining myself as supplier
for those parts I produce, define the item, then I have the field for the
lead time and can even use that on my own components.
So for all manufactured components, I would either use 0 or the time from:
supplier:myself/mycomponent/leadtime

Klaus



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-tp4651206p4657670.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] BOMs.php Location Defaults

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

*Dear all,*
 
      According to the email from Tim, I've retrieved the discussion about
BOM enhancement. Following is the link:
      
http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-td4651206.html#a4655134
<http://weberp-accounting.1478800.n4.nabble.com/Bug-MRP-for-WO-at-reqdate-instead-of-startdate-td4651206.html#a4655134>  
      
       It's a wonderful idea!

       Best regards!

       Exson



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

Re: [WebERP-developers] BOMs.php Location Defaults

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

*Hi, Bob,*
         
          Thank you for your reply.
           Do you use the MRP in webERP? Do you keep the old version BOM and
know the product produced by which BOM version? Is the BOM needed to be
approved?
           If these question have answers, we do not need to add a BOM
header. 
           Concerning to traceability purpose, webERP provide lots of
powerful traceability features. It is a piece of cake to solve the problem
what you mentioned since webERP provided lot/batch control, serial no
control even perishable control (expiry date control, there is a great
potential for this). 
          Currently, it's lack of a convenience script to retrieve the
outgoing lot/serial no via invoice no. But there is a workaround for this.
          For a manufacturing company, the currently urgent issue is to make
BOM more controllable and traceable. 
          Best regards!

          Exson




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

Re: [WebERP-developers] BOMs.php Location Defaults

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

Exson,

To implement a BOM header is straight forward.  We can until the resources
become available, leave the BOM table the same and add a BOMHeader table. 
Initially such would be used to provide static information that would be the
default for the BOM table (BOMDetail) and used mainly in BOMs.php.

Moving forwards, we need to put together a proposal to be reviewed of
integrating concepts of traceability and revision control into WebERP. 
Currently, we can not readily determine which devices in the field contain
items from batches or serialized items.  There are times when a batch of
material has defects and all items made utilizing such needs to be isolated. 
Examples would be faulty semi-conductors and material not conforming to
material specifications, i.e. bad melt.  We will investigate if there is
sufficient information in the data base to answer such queries.

We would like to differentiate product variations but still be able to use a
minimal product code for quoting, shipping and invoice; but
manufacture/purchase to a specific product revision.

We recognize that there is a lot of capability and information in WebERP. 
Some of the items can possibly be accomplished by user discipline, proper
set-up of the database, and well documented process.

Bob Thomas 



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

Re: [WebERP-developers] BOMs.php Location Defaults

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

There are a number of standards and guidance documents.  The following is an
overview of the FAA requirements:

https://www.faa.gov/aircraft/air_cert/design_approvals/media/CPI_guide_II.pdf

http://www.faa.gov/documentLibrary/media/Advisory_Circular/AC%2021-43.pdf

FDA Medical Device Quality Systems:

http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/PostmarketRequirements/QualitySystemsRegulations/default.htm

A search through Wikipedia for ISO9000 and AS9100 will yield links to many
associated standards.

The best practices are not industry specific.  Traceability is required by
all DOD, FAA, FDA and most tier 1 manufacturers.  Our business deals across
all of these.  We need to maintain pedigree of all parts sold and have
strict process revision control.

You will see that there is a great amount of flexibility (hand waving), but
one failure causes the customer to re-examine all documentation, process and
quality and the vendor must generate an acceptable remediation plan to be
implemented moving forwards.




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

Re: [WebERP-developers] BOMs.php Location Defaults

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

*Hi, Bob*

          I think the root reason is that we have no head data control like
PO, SO. Tim has provide a solution before although he have no time to code
it. But it cannot be found now. 
          I have interesting to develop it to make the BOM management more
feasible to most users' requirement.
           
         Best regards!

         Exson



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

Re: [WebERP-developers] BOMs.php Location Defaults

[Dale S. <dal...@sh...>]

> On Sep 22, 2014, at 9:27 AM, rfthomas <rf...@as...> wrote:
> 
> The BOM now carries a location and workcenter on each record.  There should
> be a header and detail for BOM's, so that the defaults for the whole BOM may
> be set and maintained in one place.
> 
> Our business needs to maintain control on BOMs per US DOD, and other US and
> foreign country traceability and configuration control requirements.

Hi Bob, is your business required to meet specific formal standards? Which ones? I'm always interested in a good standards document to review! ;-)

Regards,
Dale

> 
> If by location a BOM differs, i.e. items utilized differ or manufacturing
> method differs outside of certain strict parameters, then it is not the same
> inventory item.  The usual convention is to keep the main inventory code the
> same and for this marginally different BOM, add a part revision code, a
> routing code and a routing revision code.  Inventory code example:
> 
> <part code>_<design revision>_<routing>_<Routing process revision>
> 
> BLISC_010_A_001
> 
> It is recognized that properly handling equivalent parts, i.e.
> BLISC_010_A_001 and BLISC_010_B_120 are interchangeable items, i.e. all
> BLISC_010.  The customer would order BLISC_010 and higher level BOMs would
> reference BLISC_010.  The actual build/sale operation would then pull any
> parts with a code starting with BLISC_010 irrespective of routing and
> routing revision,
> 
> In any case the current BOMs.php does not allow for defaults for location or
> workstation, but merely shows the first location and workcenter in
> alphabetical order.
> 
> In order to have a reasonable default location, i.e. the
> DefaultFactoryLocation, we have changed BOMs.php around line 705 as follows:
> 
>        while ($myrow = DB_fetch_array($result)) {
>            if (isset($_POST['LocCode']) AND $myrow['loccode']==$_POST['LocCode']) {
>                echo '<option selected="selected" value="';
>            } else {
>                if($myrow['loccode']==$_SESSION['DefaultFactoryLocation']) {
>                    echo '<option selected="selected" value="';
>                } else {
>                    echo '<option value="';
>                }    
>            }
> 
> The code should/could be further modified to use the loccode and code (field
> name on BOM table for WorkCenter) of the first member of the BOM as the
> default.
> 
> Bob Thomas
> 
> 
> 
> --
> View this message in context: http://weberp-accounting.1478800.n4.nabble.com/BOMs-php-Location-Defaults-tp4657663.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[WebERP-developers] BOMs.php Location Defaults

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

The BOM now carries a location and workcenter on each record.  There should
be a header and detail for BOM's, so that the defaults for the whole BOM may
be set and maintained in one place.

Our business needs to maintain control on BOMs per US DOD, and other US and
foreign country traceability and configuration control requirements.

If by location a BOM differs, i.e. items utilized differ or manufacturing
method differs outside of certain strict parameters, then it is not the same
inventory item.  The usual convention is to keep the main inventory code the
same and for this marginally different BOM, add a part revision code, a
routing code and a routing revision code.  Inventory code example:

<part code>_<design revision>_<routing>_<Routing process revision>

BLISC_010_A_001

It is recognized that properly handling equivalent parts, i.e.
BLISC_010_A_001 and BLISC_010_B_120 are interchangeable items, i.e. all
BLISC_010.  The customer would order BLISC_010 and higher level BOMs would
reference BLISC_010.  The actual build/sale operation would then pull any
parts with a code starting with BLISC_010 irrespective of routing and
routing revision,

In any case the current BOMs.php does not allow for defaults for location or
workstation, but merely shows the first location and workcenter in
alphabetical order.

In order to have a reasonable default location, i.e. the
DefaultFactoryLocation, we have changed BOMs.php around line 705 as follows:

		while ($myrow = DB_fetch_array($result)) {
			if (isset($_POST['LocCode']) AND $myrow['loccode']==$_POST['LocCode']) {
				echo '<option selected="selected" value="';
			} else {
				if($myrow['loccode']==$_SESSION['DefaultFactoryLocation']) {
					echo '<option selected="selected" value="';
				} else {
					echo '<option value="';
				}	
			}

The code should/could be further modified to use the loccode and code (field
name on BOM table for WorkCenter) of the first member of the BOM as the
default.

Bob Thomas



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

[WebERP-developers] Fwd: Re: Performance 4.11.3

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

Hi Bob,

Yes, I thought of that and figured that the audit trail maintenance 
really a part of the DB maintenance routine, so I've moved it inside 
that section. Now session.inc has been carved up and the DB checks, 
GetConfig, the exchange rate stuff has all been put into the user login 
script and is only ever checked on login. Previously it was trying to 
purge every page which was  a bit silly as your experience highlighted. 
I've also added an index to transactiondate as the query should not take 
that long and it was a mistake to query on transactiondate without 
having an index to play with.

The shipment default quantity to the balance of the order could be a 
useful addition (I am not sold on it though - I expect most would be 
happy for it to default the balance of the order) - just needs someone 
to code it - not much to it really.

I am keen to have a look at scripts where we could alter the default 
locations. There have been some changes here recently with Ricard's new 
field in locations which flags if the location should be available as a 
factory to make stuff or no. Would the user's default location not be 
the normal default? We need to be specific about the scripts that need work.

Great feedback as always - thanks Bob.

Phil

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

On 20/09/14 01:48, Robert Thomas wrote:
>
> Tim, Gilberto and Phil,
>
> Thank you for your help in solving our performance problem.  I and our 
> users are very happy with the system’s performance.
>
> This performance issue was evident on my system due to its slow 
> response handling a “large” audit trail.  Such could potentially 
> become a problem for other users.  Could all of the system maintenance 
> type functions be removed from session,inc and placed where it is only 
> executed once, possibly on login?
>
> We make a significant number of edits to the sources every time a new 
> version of WebERP is released.  Some of these changes involve 
> customization of forms, e.g. quotation, invoice, packing slips, 
> checks, etc. that are specific to our business.  Others involve 
> corrections or enhancements to WebERP that are applicable to all 
> systems (I can make the changes to the code and submit but would 
> prefer to have such moderated):
>
> ·We rarely ship/invoice complete orders.  The current shipping/invoice 
> function defaults to shipping the total order quantity.  A customer 
> order typically has 20 to over 100 different items all with unique 
> quantities.  Exson very kindly provided simple changes to 
> DefineCartClass.php:
>
> Around line 490 change:
>
>                                 if ($Controlled==1){
>
> $this->QtyDispatched = 0;
>
> } else {
>
> $this->QtyDispatched = $Qty - $QtyInvoiced;
>
> }
>
> To:
>
> $this->QtyDispatched = 0;
>
> We expect that other organizations would find this change in the 
> invoice function useful.  Would it be possible to add:
>
> Invoice quantity default to be quantity outstanding [Y/N] (default Y – 
> current WebERP default)
>
> To the system parameters and then check the appropriate $_Session[‘…’] 
> variable in DefineCartClass.php?
>
> ·Location defaults.  In general the tests for location are not working 
> properly and the first location in alphabetical order is displayed as 
> the default location.  We have a number of locations: Ltron, MRB, 
> NorwH, RMA, Star, …  I have posted our changes for these defaults on 
> the WebERP nabble board.
>
> For our business, the default location to issue stock to a work order 
> should be the location of the work order. Unless context suggests a 
> different default, the location should default to the default 
> manufacturing location as set in the system parameters.  An example of 
> how such can cause a problem, one of our people in the shop had the 
> default displayed as the first location, Ltron, by mistake selected 
> MRB (Material Review Board), instead of NorwH (default manufacturing 
> location and where the inventory was stored).  If NorwH, the work 
> order location, had been defaulted such an error would not have 
> occurred.  The “missing” material caused a customer shipment to be late.
>
> MRB and RMA are new locations.  MRB (Material Review Board) is where 
> suspected defective material from vendors and manufacturing is stored 
> and addressed.  RMA is where returned customer items are stored and 
> handled.
>
> Sincerely,
>
> Robert F. Thomas
>
> *cid:image001.gif@01C71ABB.312C1E90*
>
> 44 Industrial Way
> Norwood, MA USA 02062
> (Office Phone - (781) 329-9200
> *mail to: rf...@as...
>
>

Re: [WebERP-developers] StockStatus.php Quantity on Order wrong

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

Thanks Bob - fixed.

Phil

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

On 20/09/14 07:02, rfthomas wrote:
> We order many items where tehre are conversions required between the vendor
> units and our units.  For example we inventory washers by piece but order
> then by package.  The package contains 100 washers.
>
> We enter the conversion into the order, ordering 1 package.  The order
> detail shows 100 pieces ordered.  Aside from StockStatus.php, all displays
> properly show the quantity on order being 100 pieces.  StockStatus.php
> incorrectly multiplies by the conversion factor on the order detail record,
> showing 10,000 pieces on order.
>
> Lines 177 & 178 have been changed to:
>
> 		$sql="SELECT SUM(purchorderdetails.quantityord -
> 							purchorderdetails.quantityrecd)
>
> the quantity on order is now properly displayed.
>
>
>
> --
> View this message in context: http://weberp-accounting.1478800.n4.nabble.com/StockStatus-php-Quantity-on-Order-wrong-tp4657660.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

[WebERP-developers] StockStatus.php Quantity on Order wrong

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

We order many items where tehre are conversions required between the vendor
units and our units.  For example we inventory washers by piece but order
then by package.  The package contains 100 washers.

We enter the conversion into the order, ordering 1 package.  The order
detail shows 100 pieces ordered.  Aside from StockStatus.php, all displays
properly show the quantity on order being 100 pieces.  StockStatus.php
incorrectly multiplies by the conversion factor on the order detail record,
showing 10,000 pieces on order.

Lines 177 & 178 have been changed to:

		$sql="SELECT SUM(purchorderdetails.quantityord -
							purchorderdetails.quantityrecd)

the quantity on order is now properly displayed.



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/StockStatus-php-Quantity-on-Order-wrong-tp4657660.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

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

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

Thanks Tim,

Looks good to me
Not sure why you haven't committed this yourself though? Let me know if 
you want me to do it for you?
We've had this discussion before and it gets boring for everyone .... 
you still have access to the code.



On the abstraction issue... yes some abstraction makes sense and we have 
plenty already. I am not into making a function for every little bit of 
html we echo though as I feel the presentation code adds context. I 
don't wish to debate this ... again!
A common customer search function though might be a useful in 
SQL_CommonFunctions.inc

Phil

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

On 19/09/14 04:13, Tim Schofield wrote:
> While waiting for Phil's ruling on this I have redone
> CustomerInquiry.php in what I think is a more readable way, that
> always has the same number of columns no matter what the transaction,
> and changed the original code to comply with the guidelines.
>
> Am attaching the new script,
> Tim
>
> On 17 September 2014 12:15, Tim Schofield <tim...@gm...> wrote:
>> Hi Phil, still no polite or useful reply to this. I think it is
>> important for us developers to have a ruling on what can and what
>> cannot be abstracted.
>>
>> Yours in anticipation,
>> Tim
>>
>> On 16 September 2014 11:05, Tim Schofield <tim...@gm...> wrote:
>>> Phil,
>>>
>>> Do you stand by your comments that the stock search should be
>>> abstracted to a function in SQLCommonFunctions.inc?
>>>
>>> Thanks
>>> Tim
>>>
>>> On 16 September 2014 09:53, Phil Daintree <ph...@lo...> wrote:
>>>> Hola Rafael,
>>>>
>>>> As we have corresponded off list, I know that these comments within will
>>>> be no surprise to you - but for the benefit of anyone else.
>>>>
>>>>
>>>> On 16/09/14 07:31, Rafael Chacón wrote:
>>>>> Hi All,
>>>>>
>>>>> *** ABOUT CustomerInquiry.php: ***
>>>>>
>>>>> 1. The problem: In some web-browser, incomplete table-rows
>>>>> ("<tr></tr>" tags with less quantity of columns) causes an unexpected
>>>>> behaviour (e.g. blanks and misaligned columns). E.g. Android
>>>>> 3.0.31/Navigator (Personal comment: I promote this ERPs as an ERP that
>>>>> can be run in a small device and can be run anywhere with a slow
>>>>> Internet connection, therefore it must run fine and fast).
>>>>>
>>>> Well I am not sure all the screens are so good on smaller devices.
>>>>
>>>>
>>>>> 2. The goal: fix this problem, document it, and have a code easy to
>>>>> understand for a newcomer (Personal comment: the last is the most
>>>>> difficult task. We can not "reset" our memory about the code to test
>>>>> if it is easy to understand for a newcomer).
>>>>
>>>> Yes it is subjective - but consistency with existing code and strict
>>>> adherence to the conventions/style as per
>>>>
>>>> http://www.weberp.org/CodingConventions.html
>>>>
>>>> should cover it.
>>>>
>>>>> 3. What I did: I decomposed the code to understand it. After that, I
>>>>> reassembled. The result is one section with the constant part [format
>>>>> string and other components like html-links and called parameters
>>>>> (names) ]; that is BaseInfo, CreditInvoice, Allocation,
>>>>> PreviewInvoice, PreviewCredit and GLEntries section. And an other
>>>>> section with the variable part ("parameters"), where we can see the
>>>>> table-row structure. The main problem is still make evident the HTML
>>>>> table structure.
>>>>>
>>>> The problem with that though is that is that it ended up with a LOT of
>>>> changed code and the actual fix was obscured. Much better I think to
>>>> evolve with just the code necessary to effect the bug fix
>>>>
>>>>
>>>>> 4. Secondary effects:
>>>>>
>>>>> 4.1. Regroups and comments the initial basic lines of script
>>>>> (includes/session.inc, $Title, $ViewTopic, $BookMark,
>>>>> includes/header.inc). Even without much impact, the purpose is to
>>>>> ensure that these lines are uniformly in all scripts that require it.
>>>>>
>>>> All great contributions these.
>>>>
>>>>
>>>>> 4.2. Deletes $tableheader variable. This variable is defined in line
>>>>> 253 and only used in next line (line 271). Nowhere else is used that
>>>>> variable. I think it's better to remove it to simplify the code and,
>>>>> theoretically(*), to become more fast the code.
>>>>>
>>>> Yep - if used several times it messes with the table sorting javascript
>>>> anyway.
>>>>
>>>>> 4.3. Regroups some echo string functions. Instead of some consecutive
>>>>> echo language constructors, regroup them in only one instruction to
>>>>> simplify code. I think it makes the code easier to understand.
>>>>>
>>>> Me too - probably reduces the work of the parser too.
>>>>
>>>>> 4.4. Adds the ascending class to Data, Type, Number and Reference
>>>>> columns. I found that some people look for an operation (line) seeking
>>>>> it by transaction date (over half of the time), type, number and
>>>>> reference (by customer's purchase order reference or by payment
>>>>> reference). This is a new feature to help users, and it is a lack if
>>>>> we compare CustomerInquiry.php with SupplierInquiry.php
>>>> Yep  worthwhile for most scripts
>>>>> 4.5. $RootPath and $Theme in the "Constant Section". Those variables
>>>>> always hold the same values throughout the time this script runs.
>>>>> For clarity, I think it is better to separate those "constant
>>>>> variables" from the each row variables (printf parameters section).
>>>>>
>>>> Not quite sure what you mean here?
>>>>
>>>>> 5. Help wanted:
>>>>>
>>>>> 5.1. "Constant Section" variable names. Because those variables
>>>>> (BaseInfo..., CreditInvoice..., Allocation..., PreviewInvoice...,
>>>>> PreviewCredit... and GLEntries...) have more work than only format the
>>>>> string between the table-datacell tags ("<td></td>"),  I "feel" that
>>>>> the suffix "FormatString" can conduct to an error. Comments? Suggestions?
>>>>>
>>>> Can't these variables be made to have the correct number of cells
>>>> ("<td></td>") ? My impression is that this is all that is required to
>>>> fix this script?
>>>>
>>>>> 5.2. "TD..." suffix. We need to show evident the quantity of columns
>>>>> in a table-row (pairs of "<td></td>" inside a "<tr></tr>"). I am not
>>>>> happy adding "_TD..." suffix, but I can not think of another idea.
>>>>> Comments? Suggestions?
>>>> I wasn't keen on the TD suffixes and initially didn't get what they
>>>> were. Better off just to make the variables have the correct number of
>>>> cells.
>>>>> 5.3. Any suggestion to  have a code easy to understand for a newcomer.
>>>>>
>>>> Follow
>>>>
>>>> http://www.weberp.org/CodingConventions.html
>>>>
>>>> rigorously. Of course this is just my take on this and the way much of
>>>> the code is laid out as far as possible. If some of it isn't then
>>>> changes to bring it in line are most welcome.
>>>>
>>>> Every so often someone comes up with a bright idea to change the way the
>>>> code is.
>>>>
>>>> I am not interested re-writing the code a different way.
>>>>
>>>> I am interested in bug fixes and new functionality.
>>>>
>>>> However, I took Andrew's point that abstracting some code to functions
>>>> would make some changes easier and use less characters and there is a
>>>> middle ground with abstraction. I think we have a reasonable compromise
>>>> - and I make no apology for erring on the side of readability - it is a
>>>> core goal.
>>>>
>>>> Phil

Re: [WebERP-developers] webERP accountant standard

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

Great points Phil.
WebERP allows you to make Journal Entries. IFRS, GAAP, others tell you whether or not you should make THAT specific journal entry.
How I would view it.


Sent from my BlackBerry 10 smartphone
  Original Message
From: ph...@lo...
Sent: Tuesday, September 16, 2014 9:48 PM
To: webERP Developers
Reply To: webERP Developers
Subject: Re: [WebERP-developers] webERP accountant standard


IFRS - US GAAP - IAS are all frameworks of accounting standards.
Published accounts are audited based on one or other specific framework
for compliance.
Accounting standards dictate things like the disclosure requirements in
published sets of accounts, or when to consolidate or use equity
accounting when, when to provide for warranty, treatment of intangible
assets, the treatment of leases as capital to show the value of the
assets on the balance sheet etc etc etc. All of these treatments can be
accomodated within webERP and often don't involved webERP. e.g. webERP
has the flexibility to record depreciation at any rates, or to
capitalise assets or intangibles or not, or provide for warranties or
not. The specific accounting policies and treatments are not limited by
the webERP.

This is a poor explanation I think, but hopefully you understand.

Phil



On 2014-09-16 18:32, ExsonQu wrote:
> *Hi, Phil,*
>
>         Thank you for your always great work for webERP.
>
>         I've received a question from my website, the user ask if he
> use
> International Financial Reporting Standards for accounting, Is there
> any
> modification needed?
>
>        I remember you've mentioned it about it, but cannot find it now.
>
>        Could you find time to answer this question?
>
>        Best regards!
>
>        Exson
>
>
>
> --
> View this message in context:
> http://weberp-accounting.1478800.n4.nabble.com/webERP-accountant-standard-tp4657651.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] webERP accountant standard

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

IFRS - US GAAP - IAS are all frameworks of accounting standards. 
Published accounts are audited based on one or other specific framework 
for compliance.
Accounting standards dictate things like the disclosure requirements in 
published sets of accounts, or when to consolidate or use equity 
accounting when, when to provide for warranty, treatment of intangible 
assets, the treatment of leases as capital to show the value of the 
assets on the balance sheet etc etc etc. All of these treatments can be 
accomodated within webERP and often don't involved webERP. e.g. webERP 
has the flexibility to record depreciation at any rates, or to 
capitalise assets or intangibles or not, or provide for warranties or 
not. The specific accounting policies and treatments are not limited by 
the webERP.

This is a poor explanation I think, but hopefully you understand.

Phil



On 2014-09-16 18:32, ExsonQu wrote:
> *Hi, Phil,*
> 
>         Thank you for your always great work for webERP.
> 
>         I've received a question from my website, the user ask if he 
> use
> International Financial Reporting Standards for accounting, Is there 
> any
> modification needed?
> 
>        I remember you've mentioned it about it, but cannot find it now.
> 
>        Could you find time to answer this question?
> 
>        Best regards!
> 
>        Exson
> 
> 
> 
> --
> View this message in context:
> http://weberp-accounting.1478800.n4.nabble.com/webERP-accountant-standard-tp4657651.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

[WebERP-developers] webERP accountant standard

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

*Hi, Phil,*

        Thank you for your always great work for webERP.

        I've received a question from my website, the user ask if he use 
International Financial Reporting Standards for accounting, Is there any
modification needed?

       I remember you've mentioned it about it, but cannot find it now. 

       Could you find time to answer this question?

       Best regards!

       Exson



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

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

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

Hola Rafael,

As we have corresponded off list, I know that these comments within will 
be no surprise to you - but for the benefit of anyone else.


On 16/09/14 07:31, Rafael Chacón wrote:
> Hi All,
>
> *** ABOUT CustomerInquiry.php: ***
>
> 1. The problem: In some web-browser, incomplete table-rows 
> ("<tr></tr>" tags with less quantity of columns) causes an unexpected 
> behaviour (e.g. blanks and misaligned columns). E.g. Android 
> 3.0.31/Navigator (Personal comment: I promote this ERPs as an ERP that 
> can be run in a small device and can be run anywhere with a slow 
> Internet connection, therefore it must run fine and fast).
>

Well I am not sure all the screens are so good on smaller devices.


> 2. The goal: fix this problem, document it, and have a code easy to 
> understand for a newcomer (Personal comment: the last is the most 
> difficult task. We can not "reset" our memory about the code to test 
> if it is easy to understand for a newcomer).


Yes it is subjective - but consistency with existing code and strict 
adherence to the conventions/style as per

http://www.weberp.org/CodingConventions.html

should cover it.

>
> 3. What I did: I decomposed the code to understand it. After that, I 
> reassembled. The result is one section with the constant part [format 
> string and other components like html-links and called parameters 
> (names) ]; that is BaseInfo, CreditInvoice, Allocation, 
> PreviewInvoice, PreviewCredit and GLEntries section. And an other 
> section with the variable part ("parameters"), where we can see the 
> table-row structure. The main problem is still make evident the HTML 
> table structure.
>

The problem with that though is that is that it ended up with a LOT of 
changed code and the actual fix was obscured. Much better I think to 
evolve with just the code necessary to effect the bug fix


> 4. Secondary effects:
>
> 4.1. Regroups and comments the initial basic lines of script 
> (includes/session.inc, $Title, $ViewTopic, $BookMark, 
> includes/header.inc). Even without much impact, the purpose is to 
> ensure that these lines are uniformly in all scripts that require it.
>

All great contributions these.


> 4.2. Deletes $tableheader variable. This variable is defined in line 
> 253 and only used in next line (line 271). Nowhere else is used that 
> variable. I think it's better to remove it to simplify the code and, 
> theoretically(*), to become more fast the code.
>

Yep - if used several times it messes with the table sorting javascript 
anyway.

> 4.3. Regroups some echo string functions. Instead of some consecutive 
> echo language constructors, regroup them in only one instruction to 
> simplify code. I think it makes the code easier to understand.
>

Me to - probably reduces the work of the parser too.

> 4.4. Adds the ascending class to Data, Type, Number and Reference 
> columns. I found that some people look for an operation (line) seeking 
> it by transaction date (over half of the time), type, number and 
> reference (by customer's purchase order reference or by payment 
> reference). This is a new feature to help users, and it is a lack if 
> we compare CustomerInquiry.php with SupplierInquiry.php

Yep  worthwhile for most scripts
>
> 4.5. $RootPath and $Theme in the "Constant Section". Those variables 
> always hold the same values ​​throughout the time this script runs. 
> For clarity, I think it is better to separate those "constant 
> variables" from the each row variables (printf parameters section).
>

Not quite sure what you mean here?

> 5. Help wanted:
>
> 5.1. "Constant Section" variable names. Because those variables 
> (BaseInfo..., CreditInvoice..., Allocation..., PreviewInvoice..., 
> PreviewCredit... and GLEntries...) have more work than only format the 
> string between the table-datacell tags ("<td></td>"),  I "feel" that 
> the suffix "FormatString" can conduct to an error. Comments? Suggestions?
>

Can't these variables be made to have the correct number of cells 
("<td></td>") ? My impression is that this is all that is required to 
fix this script?

> 5.2. "TD..." suffix. We need to show evident the quantity of columns 
> in a table-row (pairs of "<td></td>" inside a "<tr></tr>"). I am not 
> happy adding "_TD..." suffix, but I can not think of another idea. 
> Comments? Suggestions?

I wasn't keen on the TD suffixes and initially didn't get what they 
were. Better off just to make the variables have the correct number of 
cells.
>
> 5.3. Any suggestion to  have a code easy to understand for a newcomer.
>

Follow

http://www.weberp.org/CodingConventions.html

rigorously. Of course this is just my take on this and the way much of 
the code is laid out as far as possible. If some of it isn't then 
changes to bring it in line are most welcome.

Every so often someone comes up with a bright idea to change the way the 
code is.

I am not interested re-writing the code a different way.

I am interested in bug fixes and new functionality.

However, I took Andrew's point that abstracting some code to functions 
would make some changes easier and use less characters and there is a 
middle ground with abstraction. I think we have a reasonable compromise 
- and I make no apology for erring on the side of readability - it is a 
core goal.

Phil

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

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

Hi All,

*** ABOUT CustomerInquiry.php: ***

1. The problem: In some web-browser, incomplete table-rows ("<tr></tr>"
tags with less quantity of columns) causes an unexpected behaviour (e.g.
blanks and misaligned columns). E.g. Android 3.0.31/Navigator (Personal
comment: I promote this ERPs as an ERP that can be run in a small device
and can be run anywhere with a slow Internet connection, therefore it must
run fine and fast).

2. The goal: fix this problem, document it, and have a code easy to
understand for a newcomer (Personal comment: the last is the most difficult
task. We can not "reset" our memory about the code to test if it is easy to
understand for a newcomer).

3. What I did: I decomposed the code to understand it. After that, I
reassembled. The result is one section with the constant part [format
string and other components like html-links and called parameters (names)
]; that is BaseInfo, CreditInvoice, Allocation, PreviewInvoice,
PreviewCredit and GLEntries section. And an other section with the variable
part ("parameters"), where we can see the table-row structure. The main
problem is still make evident the HTML table structure.

4. Secondary effects:

4.1. Regroups and comments the initial basic lines of script
(includes/session.inc, $Title, $ViewTopic, $BookMark, includes/header.inc).
Even without much impact, the purpose is to ensure that these lines are
uniformly in all scripts that require it.

4.2. Deletes $tableheader variable. This variable is defined in line 253
and only used in next line (line 271). Nowhere else is used that variable.
I think it's better to remove it to simplify the code and,
theoretically(*), to become more fast the code.

4.3. Regroups some echo string functions. Instead of some consecutive echo
language constructors, regroup them in only one instruction to simplify
code. I think it makes the code easier to understand.

4.4. Adds the ascending class to Data, Type, Number and Reference columns.
I found that some people look for an operation (line) seeking it by
transaction date (over half of the time), type, number and reference (by
customer's purchase order reference or by payment reference). This is a new
feature to help users, and it is a lack if we compare CustomerInquiry.php
with SupplierInquiry.php

4.5. $RootPath and $Theme in the "Constant Section". Those variables always
hold the same values ​​throughout the time this script runs. For clarity, I
think it is better to separate those "constant variables" from the each row
variables (printf parameters section).

5. Help wanted:

5.1. "Constant Section" variable names. Because those variables
(BaseInfo..., CreditInvoice..., Allocation..., PreviewInvoice...,
PreviewCredit... and GLEntries...) have more work than only format the
string between the table-datacell tags ("<td></td>"),  I "feel" that the
suffix "FormatString" can conduct to an error. Comments? Suggestions?

5.2. "TD..." suffix. We need to show evident the quantity of columns in a
table-row (pairs of "<td></td>" inside a "<tr></tr>"). I am not happy
adding "_TD..." suffix, but I can not think of another idea. Comments?
Suggestions?

5.3. Any suggestion to  have a code easy to understand for a newcomer.

---
(*) Insignificant gain: a fraction of absolute value function duration and
some bytes.

Best regards, Rafael.


2014-09-15 13:26 GMT-06:00 Rafael Chacón <raf...@gm...>:

> Hi Exson,
>
> Please don't worry about this. I understand, I've also done it because he
> was in a hurry. What I am looking for is the reason for "des-commit".
> Specifically: If there is a bug or the code can be improved, I want to
> learn to prevent the recurrence of these errors; It is not fun to have
> people working on weekends or holidays for nothing.
>
> Best regards, Rafael.
>
> 2014-09-14 5:20 GMT-06:00 ExsonQu <hex...@gm...>:
>
> Hi, Rafael,
>>
>>           Sorry for make the revision not to discuss with you.
>>           The reason why I reverse it back is that I've found error
>> notices
>> that some parameters are fewer then required for the printf(). And at the
>> mean time I think some new TD definitions make it hard to understand the
>> business meaning of those codes although the code become short.
>>            I should have a discussion with the author who have revised
>> before I revert it.
>>           I apologize for not having a discussion.
>>           Best regards!
>>           Exson
>>
>>
>>
>> --
>> View this message in context:
>> http://weberp-accounting.1478800.n4.nabble.com/CustomerInquiry-php-W3C-html-code-tp4657643p4657646.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] CustomerInquiry.php W3C html code.

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

Hi Exson,

Please don't worry about this. I understand, I've also done it because he
was in a hurry. What I am looking for is the reason for "des-commit".
Specifically: If there is a bug or the code can be improved, I want to
learn to prevent the recurrence of these errors; It is not fun to have
people working on weekends or holidays for nothing.

Best regards, Rafael.

2014-09-14 5:20 GMT-06:00 ExsonQu <hex...@gm...>:

> Hi, Rafael,
>
>           Sorry for make the revision not to discuss with you.
>           The reason why I reverse it back is that I've found error notices
> that some parameters are fewer then required for the printf(). And at the
> mean time I think some new TD definitions make it hard to understand the
> business meaning of those codes although the code become short.
>            I should have a discussion with the author who have revised
> before I revert it.
>           I apologize for not having a discussion.
>           Best regards!
>           Exson
>
>
>
> --
> View this message in context:
> http://weberp-accounting.1478800.n4.nabble.com/CustomerInquiry-php-W3C-html-code-tp4657643p4657646.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] AddTextWrap cuts lines before the line-end.

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

if you post your "localised" we can run it on some our environment for
tests and you can see what is going on.
Please your environment / plataform is important to know things like
what is language and locale variables.
regards.

2014-09-13 23:29 GMT+02:00, Rafael Chacón <raf...@gm...>:
> Hi,
>
> I have a "localised" version of "PrintCustTransPortrait.php". It prints
> stockmoves.narrative across some columns (from "Description" to "Net").
>
> The problem: In some cases, AddTextWrap cuts the lines before the end line
> (see enclose).
>
> Does anyone have any idea what is causing this or how to correct it?
>
> Best regards, Rafael.
>


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

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

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

Hi, Rafael,

          Sorry for make the revision not to discuss with you. 
          The reason why I reverse it back is that I've found error notices
that some parameters are fewer then required for the printf(). And at the
mean time I think some new TD definitions make it hard to understand the
business meaning of those codes although the code become short. 
           I should have a discussion with the author who have revised
before I revert it. 
          I apologize for not having a discussion. 
          Best regards!
          Exson



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