web-erp-developers — Discussion on development of webERP

Re: [WebERP-developers] FormDesigner.php

[Mark <ma...@ri...>]

Keep it simple? Store it as text?

On 14/11/2013 13:11, TimSchofield1 [via webERP accounting] wrote:
> Hi Exson, the problem with putting the data into mysql is how to
> structure the data within the database, rather than how to move it
> into there.
>
> Thanks
> Tim
>
> On 14 November 2013 13:03, ExsonQu <[hidden email] 
> </user/SendEmail.jtp?type=node&node=4656876&i=0>> wrote:
>
> > *Dear all:*
> >
> >            I think I have no right to comment on this case since I 
> have not
> > understood how to use the form designer. I've tried it before, but 
> did not
> > master it. So I think the arguments come from how much benefit we 
> can get
> > from form designer. If there are more evidence about the advantage 
> of it we
> > can reach an agreement.
> >
> >            For point 4, I believe it's very convenient to store xml to
> > mysql. Just use LOAD xml INFILE. You can get more information here:
> > https://dev.mysql.com/doc/refman/5.5/en/load-xml.html
> > <https://dev.mysql.com/doc/refman/5.5/en/load-xml.html>
> >
> >             Maybe a tutorial is necessary for the form designer?
> >
> >             Thanks and best regards!
> >
> >             Exson
> >
> >
> >
> >
> >
> > --
> > View this message in context: 
> http://weberp-accounting.1478800.n4.nabble.com/FormDesigner-php-tp4656864p4656875.html
> > Sent from the web-ERP-developers mailing list archive at Nabble.com.
> >
> > 
> ------------------------------------------------------------------------------
> > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> > Free app hosting. Or install the open source package on any LAMP 
> server.
> > Sign up and see examples for AngularJS, jQuery, Sencha Touch and 
> Native!
> > 
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Web-erp-developers mailing list
> > [hidden email] </user/SendEmail.jtp?type=node&node=4656876&i=1>
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> -- 
> Course View Towers,
> Plot 21 Yusuf Lule Road,
> Kampala
> T   +256 (0) 312 314 418
> M +256 (0) 752 963 325
> www.weberpafrica.com
> Twitter: @TimSchofield2
> Blog: http://weberpafrica.blogspot.co.uk/
>
> ------------------------------------------------------------------------------ 
>
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> [hidden email] </user/SendEmail.jtp?type=node&node=4656876&i=2>
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the 
> discussion below:
> http://weberp-accounting.1478800.n4.nabble.com/FormDesigner-php-tp4656864p4656876.html 
>
> To start a new topic under web-ERP-developers, email 
> ml-...@n4...
> To unsubscribe from web-ERP-developers, click here 
> <http://weberp-accounting.1478800.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1484626&code=bWFya0ByaW90ZW50ZXJwcmlzZXMuY28udWt8MTQ4NDYyNnwxMjc3ODkxMjc5>.
> NAML 
> <http://weberp-accounting.1478800.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> 
>





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

Re: [WebERP-developers] FormDesigner.php

[Tim S. <tim...@gm...>]

Hi Exson, the problem with putting the data into mysql is how to
structure the data within the database, rather than how to move it
into there.

Thanks
Tim

On 14 November 2013 13:03, ExsonQu <hex...@gm...> wrote:
> *Dear all:*
>
>            I think I have no right to comment on this case since I have not
> understood how to use the form designer. I've tried it before, but did not
> master it. So I think the arguments come from how much benefit we can get
> from form designer. If there are more evidence about the advantage of it we
> can reach an agreement.
>
>            For point 4, I believe it's very convenient to store xml to
> mysql. Just use LOAD xml INFILE. You can get more information here:
> https://dev.mysql.com/doc/refman/5.5/en/load-xml.html
> <https://dev.mysql.com/doc/refman/5.5/en/load-xml.html>
>
>             Maybe a tutorial is necessary for the form designer?
>
>             Thanks and best regards!
>
>             Exson
>
>
>
>
>
> --
> View this message in context: http://weberp-accounting.1478800.n4.nabble.com/FormDesigner-php-tp4656864p4656875.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers



-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418
M +256 (0) 752 963 325
www.weberpafrica.com
Twitter: @TimSchofield2
Blog: http://weberpafrica.blogspot.co.uk/

Re: [WebERP-developers] FormDesigner.php

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

*Dear all:*

           I think I have no right to comment on this case since I have not
understood how to use the form designer. I've tried it before, but did not
master it. So I think the arguments come from how much benefit we can get
from form designer. If there are more evidence about the advantage of it we
can reach an agreement. 

           For point 4, I believe it's very convenient to store xml to
mysql. Just use LOAD xml INFILE. You can get more information here:
https://dev.mysql.com/doc/refman/5.5/en/load-xml.html
<https://dev.mysql.com/doc/refman/5.5/en/load-xml.html>  

            Maybe a tutorial is necessary for the form designer?

            Thanks and best regards!

            Exson

          



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

Re: [WebERP-developers] FormDesigner.php

[Tim S. <tim...@gm...>]

Hi Jo, we seem to be saying the same thing here. By using the form
designer you don't have to change any PHP files, and updating to new
scripts is easy. It is only the xml files that change. So instead of
maintaining separate PHP scripts for each client as Phil is suggesting
above, you just create a new xml file for each client. As I said in my
email earlier if someone can find a way of simply getting the data
into the database without creating lots of complex tables that would
be great, and then you wouldn't even need to maintain the xml files.

Thanks
Tim

On 14 November 2013 12:15, icedlava <ice...@gm...> wrote:
> Hi Tim
>
> On 14 Nov 2013, at 21:52, Tim Schofield wrote:
>
>> Surely this is a strength not a weakness? It means that each company
>> can have its own design and there is no need to be constantly changing
>> the code depending on which company is being used?
>
> I disagree on this point. For me it's truly time consuming especially if
> each client has different custom files for multiple forms (or other
> display pages). Now there is perhaps a minimum of 30 to 40 files i have
> to keep updated separately for a customer - minimum.  If any of those
> PHP files is updated in webERP, each has to be individually diffed
> against system file (to at least check and ensure correct changes with
> SVN) and changes applied. It also means i have to keep each client's
> weberp in separate custom branches to monitor the tracking and update of
> the main upstream repository of webERP.
>
> Having separate branches in scm makes it easier, but the individual
> files is a time killer.
>
> If this time can be reduced and we can provide easy, clean html/css
> files for display output that are override able in say a separate
> override folder outside of core webERP files, maintenance and upgrades
> becomes much easier. Even just having an override directory would be a
> huge saving.
>
> @sotandeka - I agree with him that we could contribute templates for
> reports - once the method/format (or database form) is decided. That
> might be a nice touch for webERP - a user contributed template
> repository. It would be good if they could be drop in, in an override
> directory as mentioned above.
>
> Anyway, just some ideas tossing around ...
>
> Happy to go with what is decided .
>
> Cheers,
> Jo
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers



-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418
M +256 (0) 752 963 325
www.weberpafrica.com
Twitter: @TimSchofield2
Blog: http://weberpafrica.blogspot.co.uk/

Re: [WebERP-developers] FormDesigner.php

[icedlava <ice...@gm...>]

Hi Tim

On 14 Nov 2013, at 21:52, Tim Schofield wrote:

> Surely this is a strength not a weakness? It means that each company
> can have its own design and there is no need to be constantly changing
> the code depending on which company is being used?

I disagree on this point. For me it's truly time consuming especially if 
each client has different custom files for multiple forms (or other 
display pages). Now there is perhaps a minimum of 30 to 40 files i have 
to keep updated separately for a customer - minimum.  If any of those 
PHP files is updated in webERP, each has to be individually diffed 
against system file (to at least check and ensure correct changes with 
SVN) and changes applied. It also means i have to keep each client's 
weberp in separate custom branches to monitor the tracking and update of 
the main upstream repository of webERP.

Having separate branches in scm makes it easier, but the individual 
files is a time killer.

If this time can be reduced and we can provide easy, clean html/css 
files for display output that are override able in say a separate 
override folder outside of core webERP files, maintenance and upgrades 
becomes much easier. Even just having an override directory would be a 
huge saving.

@sotandeka - I agree with him that we could contribute templates for 
reports - once the method/format (or database form) is decided. That 
might be a nice touch for webERP - a user contributed template 
repository. It would be good if they could be drop in, in an override 
directory as mentioned above.

Anyway, just some ideas tossing around ...

Happy to go with what is decided .

Cheers,
Jo

Re: [WebERP-developers] FormDesigner.php

[Tim S. <tim...@gm...>]

Hi Phil,

On 14 November 2013 08:54, Phil Daintree <ph...@lo...> wrote:
>
> 1. I feel that the form designer as it stands is very limited  - it is
> not easy to get the form designed exactly as you wish it to be ... there
> is a lot of trial and error and it is hit and miss - anyone messing
> around with formats using the form designer I am confident will come
> away cursing and frustrated.

The form designer was based on the Sage Line 100 form designer that I
happened to have a manual for sitting on my bookshelf at the time. It
does work, I know of many customers of ours who use it without coming
away cursing and frustrated, and I am confident they are not alone.
Yes of course it can be improved upon, all software can be improved
upon. This is open source, and you are welcome to improve on any
aspect of the code. The point I have made before is don't take out
code that is used by many users without putting in something better,
and that has at least the equivalent functionality.

It would be nice to have a pure WYSIWYG solution using JavaScript, but
at the time our policy was not to use JS in any major way.

> 2. Many businesses have unique requirements for their invoice layout ...
> say they wish to move the boxes to different places or different sizes
> with some new boxes, with different radius curves or square boxes,
> different fonts/sizes/colours have three images in different spots, with
> additional text explaining terms and conditions etc etc or put another
> way there really are the endless ways in which a business will wish to
> modify their invoice layout and the form designer ends up being a
> limitation rather than an advantage.

Yes it would be great to have the form designer extended to have these
things, why not add them?

> 3. To actually achieve the customised design that the customer actually
> really wants will still entail getting into the code and the code for
> form designer forms is WAY more complicated than the existing standard
> scripts - which are nice and readable with minimal abstraction, long
> variable names  etc etc ... it is actually quite easy to modify the
> standard scripts to make the layout exactly as the customer requires
> using the standard forms as a base.

Well changing the code has two big disadvantages. Firstly it creates a
massive headache on doing upgrades, requiring a level of knowledge of
patching files that is way above the ability of most business people.
Secondly many organisations have more than one company in their webERP
setup, and would like different formats for each company. One of the
principle aims of the form designer is to facilitate this, allowing
the same standard code to be used for all companies, but with a
different form layout for each.

> 4. The data for the reports is stored outside the database in xml files,
> creating another dependency on external data files. If we were to go
> with customisable reports I would prefer the data to come from the
> database like all other company data.

I agree with you the database is always the preferred place, but I
spent a long time trying to figure out how to design the database to
get this in. The only way I could see was complex and unwieldy whereas
the xml file is simple and easily understood. Surely we should say
that the data should be in the format that is most easily used and
understood rather than dogmatically saying it has to be in the DB
regardless of the complexity?

>
> Point 4 aside, I really do prefer the readable simple solution ... even
> though it appears to reduce the apparent functionality - actually it
> provides the ultimate in flexibility afforded by the much more
> approachable code.

Are we saying that webERP should be limited to ONLY those users who
feel comfortable modifying code? Surely it would also be good to have
a solution for those who don't?

>
> However, the key point I think you make Jo is this:
>
> "This then requires maintaining separate files for each client and
> maintenance/upgrades become more and more laborious."

Surely this is a strength not a weakness? It means that each company
can have its own design and there is no need to be constantly changing
the code depending on which company is being used?

>
> I do agree it would be super to address this problem which is not
> limited to just the reports, with some separate directory for modified
> scripts under the companies directory - which is looked for first before
> the standard script somehow to remove this issue. I am not sure how to
> implement this but I do think this would be a great addition and the
> better way to resolve this situation rather than creating complicated
> scripts to produce reports with very limited and awkward flexibility.

That would be great Phil, though it sounds complex to do. You are volunteering?

>
> Phil

Thanks
Tim




-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418
M +256 (0) 752 963 325
www.weberpafrica.com
Twitter: @TimSchofield2

Re: [WebERP-developers] FormDesigner.php

[Otandeka S. P. <sot...@gm...>]

My suggestion is that whoever designs a template for a report contributes
it to the code base and then a user is free to select one that they need
when wanting to print a report.
>From my experience, most of these report formats worldwide don't defer
much.

How come some M$ software that we use forces on us certain report formats
and we don't complain? :-) :-)


@sotandeka
Skype: sotandeka
Gmail: sotandeka




On Thu, Nov 14, 2013 at 12:23 PM, icedlava <ice...@gm...> wrote:

> Hi Phil,
>
> Thanks for your feedback on the Form Designer. You know that I would
> agree with you on all the points made except perhaps point 4 regarding
> keeping the data in the database (granted data could be edited more
> easily but there may be other issues to address).
>
> Personally, I prefer to have (x)html/css in pure form with the addition
> of some variables that are required, with template selectable per
> company (if shared install).
>
> That would be ideal for me (I have some trial tempting for this that
> works ok). But, I'm not sure that webERP wants to go this way given that
> I have used templating engine (lightweight and fast one tho) that i have
> plugged in.
>
> Another way would be to have an override directory where the html/css
> layouts could be selected from and variables parsed in.
>
> There are also some ways to use the tcpdf lib in  a more natural
> html/css template (or other pdf lib that is based on css/html alone). I
> have not looked at applying these in webERP yet.
>
> I'm happy to help with whatever method people think will be best long
> term for webERP.
>
> Cheers,
> Jo
>
>
>
>
>
> On 14 Nov 2013, at 19:24, Phil Daintree wrote:
>
> > Giuys,
> >
> > I do see the advantage of the form designer, BUT .... webERP has
> > always
> > been intended for business people to be able to modify as one of the
> > fundamental goals.
> >
> > I have several points about this:
> >
> > 1. I feel that the form designer as it stands is very limited  - it is
> > not easy to get the form designed exactly as you wish it to be ...
> > there
> > is a lot of trial and error and it is hit and miss - anyone messing
> > around with formats using the form designer I am confident will come
> > away cursing and frustrated.
> > 2. Many businesses have unique requirements for their invoice layout
> > ...
> > say they wish to move the boxes to different places or different sizes
> > with some new boxes, with different radius curves or square boxes,
> > different fonts/sizes/colours have three images in different spots,
> > with
> > additional text explaining terms and conditions etc etc or put another
> > way there really are the endless ways in which a business will wish to
> > modify their invoice layout and the form designer ends up being a
> > limitation rather than an advantage.
> > 3. To actually achieve the customised design that the customer
> > actually
> > really wants will still entail getting into the code and the code for
> > form designer forms is WAY more complicated than the existing standard
> > scripts - which are nice and readable with minimal abstraction, long
> > variable names  etc etc ... it is actually quite easy to modify the
> > standard scripts to make the layout exactly as the customer requires
> > using the standard forms as a base.
> > 4. The data for the reports is stored outside the database in xml
> > files,
> > creating another dependency on external data files. If we were to go
> > with customisable reports I would prefer the data to come from the
> > database like all other company data.
> >
> > Point 4 aside, I really do prefer the readable simple solution ...
> > even
> > though it appears to reduce the apparent functionality - actually it
> > provides the ultimate in flexibility afforded by the much more
> > approachable code.
> >
> > However, the key point I think you make Jo is this:
> >
> > "This then requires maintaining separate files for each client and
> > maintenance/upgrades become more and more labourious."
> >
> > I do agree it would be super to address this problem which is not
> > limited to just the reports, with some separate directory for modified
> > scripts under the companies directory - which is looked for first
> > before
> > the standard script somehow to remove this issue. I am not sure how to
> > implement this but I do think this would be a great addition and the
> > better way to resolve this situation rather than creating complicated
> > scripts to produce reports with very limited and awkward flexibility.
> >
> > Phil
> >
> > Phil Daintree
> > Logic Works Ltd - +64 (0)275 567890
> > http://www.logicworks.co.nz
> >
> > On 14/11/13 03:20, icedlava wrote:
> >> Hi Rafael,
> >>
> >> I've also had to modify most forms such as sales invoice, statements,
> >> purchase orders, and more, and quite significantly for clients. Of
> >> course quickly and hard coded mostly for each.
> >> This then requires maintaining separate files for each client and
> >> maintenance/upgrades become more and more labourious.
> >>
> >> I think use of the form designer is sensible. I have not used
> >> something
> >> like this for some years but it seems preferable than the
> >> editing/hard
> >> coding i've been doing.
> >>
> >> There are some other methods i was thinking of and used in the past.
> >> However, as form designer is available and works, i'd be happy to
> >> assist
> >> to get it working for other forms if it is wanted.
> >>
> >> I had wondered if Form designer had been left and not used for
> >> invoices
> >> etc for a reason, pending some other method or just for lack of time.
> >>
> >> Thanks for your work Rafael.
> >>
> >> Cheers,
> >> Jo
> >>
> >>
> >>
> >>
> >> On 13 Nov 2013, at 23:43, Rafael Chacón wrote:
> >>
> >>> Hi,
> >>>
> >>> Unfortunately, in the past, I had to modify some forms such as the
> >>> sales-invoice and the purchase-order for an urgent specific
> >>> situation
> >>> (I
> >>> hard-coded them).
> >>>
> >>> Today, I am trying to turn these changes in general purpose changes
> >>> (configurable settings).
> >>>
> >>> Believe that the best way is to turn the forms modifiable
> >>> withFormDesigner.php.
> >>>
> >>> Comments? Suggestions?
> >>>
> >>> Regards, Rafael Chacon.
> >>>
> ------------------------------------------------------------------------------
> >>> DreamFactory - Open Source REST & JSON Services for HTML5 & Native
> >>> Apps
> >>> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API
> >>> Access
> >>> Free app hosting. Or install the open source package on any LAMP
> >>> server.
> >>> Sign up and see examples for AngularJS, jQuery, Sencha Touch and
> >>> Native!
> >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk_______________________________________________
> >>> Web-erp-developers mailing list
> >>> Web...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >>
> ------------------------------------------------------------------------------
> >> DreamFactory - Open Source REST & JSON Services for HTML5 & Native
> >> Apps
> >> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> >> Free app hosting. Or install the open source package on any LAMP
> >> server.
> >> Sign up and see examples for AngularJS, jQuery, Sencha Touch and
> >> Native!
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Web-erp-developers mailing list
> >> Web...@li...
> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
> >
> >
> ------------------------------------------------------------------------------
> > DreamFactory - Open Source REST & JSON Services for HTML5 & Native
> > Apps
> > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> > Free app hosting. Or install the open source package on any LAMP
> > server.
> > Sign up and see examples for AngularJS, jQuery, Sencha Touch and
> > Native!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

[WebERP-developers] Salesman respective report and invoice

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

*Dear all:*

               Thank you for your long time nice support!

              I've encountered some requirements to make the sales orders
and invoices and customers information reviewed only by the responsible
salesman. 

              I'm not sure if it's a general business requirements. If so,
I'd like to code it and commit it to the trunk.

              My solution is to add some constraints by the salesman in
those query sql, and add one token to review all reports and invoices and
customers data. 

               Any comments are highly appreciated!

               Thanks and best regards!

              Exson



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Salesman-respective-report-and-invoice-tp4656870.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] FormDesigner.php

[icedlava <ice...@gm...>]

Hi Phil,

Thanks for your feedback on the Form Designer. You know that I would 
agree with you on all the points made except perhaps point 4 regarding 
keeping the data in the database (granted data could be edited more 
easily but there may be other issues to address).

Personally, I prefer to have (x)html/css in pure form with the addition 
of some variables that are required, with template selectable per 
company (if shared install).

That would be ideal for me (I have some trial tempting for this that 
works ok). But, I'm not sure that webERP wants to go this way given that 
I have used templating engine (lightweight and fast one tho) that i have 
plugged in.

Another way would be to have an override directory where the html/css 
layouts could be selected from and variables parsed in.

There are also some ways to use the tcpdf lib in  a more natural 
html/css template (or other pdf lib that is based on css/html alone). I 
have not looked at applying these in webERP yet.

I'm happy to help with whatever method people think will be best long 
term for webERP.

Cheers,
Jo





On 14 Nov 2013, at 19:24, Phil Daintree wrote:

> Giuys,
>
> I do see the advantage of the form designer, BUT .... webERP has 
> always
> been intended for business people to be able to modify as one of the
> fundamental goals.
>
> I have several points about this:
>
> 1. I feel that the form designer as it stands is very limited  - it is
> not easy to get the form designed exactly as you wish it to be ... 
> there
> is a lot of trial and error and it is hit and miss - anyone messing
> around with formats using the form designer I am confident will come
> away cursing and frustrated.
> 2. Many businesses have unique requirements for their invoice layout 
> ...
> say they wish to move the boxes to different places or different sizes
> with some new boxes, with different radius curves or square boxes,
> different fonts/sizes/colours have three images in different spots, 
> with
> additional text explaining terms and conditions etc etc or put another
> way there really are the endless ways in which a business will wish to
> modify their invoice layout and the form designer ends up being a
> limitation rather than an advantage.
> 3. To actually achieve the customised design that the customer 
> actually
> really wants will still entail getting into the code and the code for
> form designer forms is WAY more complicated than the existing standard
> scripts - which are nice and readable with minimal abstraction, long
> variable names  etc etc ... it is actually quite easy to modify the
> standard scripts to make the layout exactly as the customer requires
> using the standard forms as a base.
> 4. The data for the reports is stored outside the database in xml 
> files,
> creating another dependency on external data files. If we were to go
> with customisable reports I would prefer the data to come from the
> database like all other company data.
>
> Point 4 aside, I really do prefer the readable simple solution ... 
> even
> though it appears to reduce the apparent functionality - actually it
> provides the ultimate in flexibility afforded by the much more
> approachable code.
>
> However, the key point I think you make Jo is this:
>
> "This then requires maintaining separate files for each client and
> maintenance/upgrades become more and more labourious."
>
> I do agree it would be super to address this problem which is not
> limited to just the reports, with some separate directory for modified
> scripts under the companies directory - which is looked for first 
> before
> the standard script somehow to remove this issue. I am not sure how to
> implement this but I do think this would be a great addition and the
> better way to resolve this situation rather than creating complicated
> scripts to produce reports with very limited and awkward flexibility.
>
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890
> http://www.logicworks.co.nz
>
> On 14/11/13 03:20, icedlava wrote:
>> Hi Rafael,
>>
>> I've also had to modify most forms such as sales invoice, statements,
>> purchase orders, and more, and quite significantly for clients. Of
>> course quickly and hard coded mostly for each.
>> This then requires maintaining separate files for each client and
>> maintenance/upgrades become more and more labourious.
>>
>> I think use of the form designer is sensible. I have not used 
>> something
>> like this for some years but it seems preferable than the 
>> editing/hard
>> coding i've been doing.
>>
>> There are some other methods i was thinking of and used in the past.
>> However, as form designer is available and works, i'd be happy to 
>> assist
>> to get it working for other forms if it is wanted.
>>
>> I had wondered if Form designer had been left and not used for 
>> invoices
>> etc for a reason, pending some other method or just for lack of time.
>>
>> Thanks for your work Rafael.
>>
>> Cheers,
>> Jo
>>
>>
>>
>>
>> On 13 Nov 2013, at 23:43, Rafael Chacón wrote:
>>
>>> Hi,
>>>
>>> Unfortunately, in the past, I had to modify some forms such as the
>>> sales-invoice and the purchase-order for an urgent specific 
>>> situation
>>> (I
>>> hard-coded them).
>>>
>>> Today, I am trying to turn these changes in general purpose changes
>>> (configurable settings).
>>>
>>> Believe that the best way is to turn the forms modifiable
>>> withFormDesigner.php.
>>>
>>> Comments? Suggestions?
>>>
>>> Regards, Rafael Chacon.
>>> ------------------------------------------------------------------------------
>>> DreamFactory - Open Source REST & JSON Services for HTML5 & Native
>>> Apps
>>> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API 
>>> Access
>>> Free app hosting. Or install the open source package on any LAMP
>>> server.
>>> Sign up and see examples for AngularJS, jQuery, Sencha Touch and
>>> Native!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk_______________________________________________
>>> Web-erp-developers mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>> ------------------------------------------------------------------------------
>> DreamFactory - Open Source REST & JSON Services for HTML5 & Native 
>> Apps
>> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
>> Free app hosting. Or install the open source package on any LAMP 
>> server.
>> Sign up and see examples for AngularJS, jQuery, Sencha Touch and 
>> Native!
>> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native 
> Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP 
> server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and 
> Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] FormDesigner.php

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

Giuys,

I do see the advantage of the form designer, BUT .... webERP has always 
been intended for business people to be able to modify as one of the 
fundamental goals.

I have several points about this:

1. I feel that the form designer as it stands is very limited  - it is 
not easy to get the form designed exactly as you wish it to be ... there 
is a lot of trial and error and it is hit and miss - anyone messing 
around with formats using the form designer I am confident will come 
away cursing and frustrated.
2. Many businesses have unique requirements for their invoice layout ... 
say they wish to move the boxes to different places or different sizes 
with some new boxes, with different radius curves or square boxes, 
different fonts/sizes/colours have three images in different spots, with 
additional text explaining terms and conditions etc etc or put another 
way there really are the endless ways in which a business will wish to 
modify their invoice layout and the form designer ends up being a 
limitation rather than an advantage.
3. To actually achieve the customised design that the customer actually 
really wants will still entail getting into the code and the code for 
form designer forms is WAY more complicated than the existing standard 
scripts - which are nice and readable with minimal abstraction, long 
variable names  etc etc ... it is actually quite easy to modify the 
standard scripts to make the layout exactly as the customer requires 
using the standard forms as a base.
4. The data for the reports is stored outside the database in xml files, 
creating another dependency on external data files. If we were to go 
with customisable reports I would prefer the data to come from the 
database like all other company data.

Point 4 aside, I really do prefer the readable simple solution ... even 
though it appears to reduce the apparent functionality - actually it 
provides the ultimate in flexibility afforded by the much more 
approachable code.

However, the key point I think you make Jo is this:

"This then requires maintaining separate files for each client and 
maintenance/upgrades become more and more labourious."

I do agree it would be super to address this problem which is not 
limited to just the reports, with some separate directory for modified 
scripts under the companies directory - which is looked for first before 
the standard script somehow to remove this issue. I am not sure how to 
implement this but I do think this would be a great addition and the 
better way to resolve this situation rather than creating complicated 
scripts to produce reports with very limited and awkward flexibility.

Phil

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

On 14/11/13 03:20, icedlava wrote:
> Hi Rafael,
>
> I've also had to modify most forms such as sales invoice, statements,
> purchase orders, and more, and quite significantly for clients. Of
> course quickly and hard coded mostly for each.
> This then requires maintaining separate files for each client and
> maintenance/upgrades become more and more labourious.
>
> I think use of the form designer is sensible. I have not used something
> like this for some years but it seems preferable than the editing/hard
> coding i've been doing.
>
> There are some other methods i was thinking of and used in the past.
> However, as form designer is available and works, i'd be happy to assist
> to get it working for other forms if it is wanted.
>
> I had wondered if Form designer had been left and not used for invoices
> etc for a reason, pending some other method or just for lack of time.
>
> Thanks for your work Rafael.
>
> Cheers,
> Jo
>
>
>
>
> On 13 Nov 2013, at 23:43, Rafael Chacón wrote:
>
>> Hi,
>>
>> Unfortunately, in the past, I had to modify some forms such as the
>> sales-invoice and the purchase-order for an urgent specific situation
>> (I
>> hard-coded them).
>>
>> Today, I am trying to turn these changes in general purpose changes
>> (configurable settings).
>>
>> Believe that the best way is to turn the forms modifiable
>> withFormDesigner.php.
>>
>> Comments? Suggestions?
>>
>> Regards, Rafael Chacon.
>> ------------------------------------------------------------------------------
>> DreamFactory - Open Source REST & JSON Services for HTML5 & Native
>> Apps
>> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
>> Free app hosting. Or install the open source package on any LAMP
>> server.
>> Sign up and see examples for AngularJS, jQuery, Sencha Touch and
>> Native!
>> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk_______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] FormDesigner.php

[Tim S. <tim...@gm...>]

The form designer used to work for invoices but Phil took it out at
some stage I think.

I have the xml file somewhere so it could be put back in.

Tim

On 13 November 2013 14:20, icedlava <ice...@gm...> wrote:
> Hi Rafael,
>
> I've also had to modify most forms such as sales invoice, statements,
> purchase orders, and more, and quite significantly for clients. Of
> course quickly and hard coded mostly for each.
> This then requires maintaining separate files for each client and
> maintenance/upgrades become more and more labourious.
>
> I think use of the form designer is sensible. I have not used something
> like this for some years but it seems preferable than the editing/hard
> coding i've been doing.
>
> There are some other methods i was thinking of and used in the past.
> However, as form designer is available and works, i'd be happy to assist
> to get it working for other forms if it is wanted.
>
> I had wondered if Form designer had been left and not used for invoices
> etc for a reason, pending some other method or just for lack of time.
>
> Thanks for your work Rafael.
>
> Cheers,
> Jo
>
>
>
>
> On 13 Nov 2013, at 23:43, Rafael Chacón wrote:
>
>> Hi,
>>
>> Unfortunately, in the past, I had to modify some forms such as the
>> sales-invoice and the purchase-order for an urgent specific situation
>> (I
>> hard-coded them).
>>
>> Today, I am trying to turn these changes in general purpose changes
>> (configurable settings).
>>
>> Believe that the best way is to turn the forms modifiable
>> withFormDesigner.php.
>>
>> Comments? Suggestions?
>>
>> Regards, Rafael Chacon.
>> ------------------------------------------------------------------------------
>> DreamFactory - Open Source REST & JSON Services for HTML5 & Native
>> Apps
>> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
>> Free app hosting. Or install the open source package on any LAMP
>> server.
>> Sign up and see examples for AngularJS, jQuery, Sencha Touch and
>> Native!
>> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk_______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers



-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418
M +256 (0) 752 963 325
www.weberpafrica.com
Twitter: @TimSchofield2
Blog: http://weberpafrica.blogspot.co.uk/

Re: [WebERP-developers] FormDesigner.php

[icedlava <ice...@gm...>]

Hi Rafael,

I've also had to modify most forms such as sales invoice, statements, 
purchase orders, and more, and quite significantly for clients. Of 
course quickly and hard coded mostly for each.
This then requires maintaining separate files for each client and 
maintenance/upgrades become more and more labourious.

I think use of the form designer is sensible. I have not used something 
like this for some years but it seems preferable than the editing/hard 
coding i've been doing.

There are some other methods i was thinking of and used in the past. 
However, as form designer is available and works, i'd be happy to assist 
to get it working for other forms if it is wanted.

I had wondered if Form designer had been left and not used for invoices 
etc for a reason, pending some other method or just for lack of time.

Thanks for your work Rafael.

Cheers,
Jo




On 13 Nov 2013, at 23:43, Rafael Chacón wrote:

> Hi,
>
> Unfortunately, in the past, I had to modify some forms such as the
> sales-invoice and the purchase-order for an urgent specific situation 
> (I
> hard-coded them).
>
> Today, I am trying to turn these changes in general purpose changes
> (configurable settings).
>
> Believe that the best way is to turn the forms modifiable 
> withFormDesigner.php.
>
> Comments? Suggestions?
>
> Regards, Rafael Chacon.
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native 
> Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP 
> server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and 
> Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk_______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[WebERP-developers] Statement of Cash Flows

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

Hello,

Any of you have created a Statement of Cash Flows using the webERP ?

Anyone interested in participating to do this script? In use it?

Regards,

Rafael Chacon

[WebERP-developers] FormDesigner.php

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

Hi,

Unfortunately, in the past, I had to modify some forms such as the
sales-invoice and the purchase-order for an urgent specific situation (I
hard-coded them).

Today, I am trying to turn these changes in general purpose changes
(configurable settings).

Believe that the best way is to turn the forms modifiable withFormDesigner.php.

Comments? Suggestions?

Regards, Rafael Chacon.

[WebERP-developers] Statement of changes in equity

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

Hello,

Any of you have created a Statement of Changes in Equity using the webERP ?

Regards,

Rafael Chacon

[WebERP-developers] Statement of cash flows

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

Hello,

Any of you have created a Statement of Cash Flows using the webERP ?

Regards,

Rafael Chacon

[WebERP-developers] Error in payments.php

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

Hi all:

Something went wrong in Payments.php since revision 5820 until 6381 as now
it accounts incorrrect payments to supplier in non-functional currency.

Now (with latest version):

   - Select a supplier (not in functional currency)
   - Make a payment to this supplier from a bank account in the same
   currency as supplier
   - In gltrans it records the amount in foreign currency, not the
   equivalent in fucntional one, :-(

Example: Functional currency USD
Supplier in IDR ( 1 USD = 10.000 IDR)
Pay to supplier in IDR from bank account in IDR for 1.000.000 IDR
If you check balance sheet now... the value of your IDR account in USD
(functional currency) is -1.000.000 USD instead of -100 USD hwich can
bankrupt your morale quite fast

Tracking back, rev 5820 works OK, so some change just broke the thing.

Regards,
Ricard

Re: [WebERP-developers] Is it a right constraint for sales order?

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

*Dear all:*

            It's done. If you do not satisfy with the text to explain the
purpose of checkbox, please revise it freely.

           Thanks and best regards!

           Exson



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Is-it-a-right-constraint-for-sales-order-tp4656839p4656858.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] Is it a right constraint for sales order?

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

*Dear all:*

           Thank you for your comments. I'll find sometime to code it -- Add
a checkbox for it within this week. I think the original design make sense.
But it'll frustrate users when they incidentally set their categories as raw
materials. 

         Thank you again for your opinion! Really appreciated it!

          Best regards!

          Exson



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Is-it-a-right-constraint-for-sales-order-tp4656839p4656857.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] Stock Categories Properties issues

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

Back home in sunny NZ with team DaintreeNZ :-)

Phil

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

On 07/11/13 19:56, Pak Ricard wrote:
> Sure Phil, that's why I asked ;-). I will keep them in stockmaster, 
> until we all find a good solution for properties and can be 
> transferred easily and safely.
>
> Are you already back in NZ or still in UK?
>
> Regards,
> Ricard
>
>
> 2013/11/7 Phil Daintree <ph...@lo... 
> <mailto:ph...@lo...>>
>
>     Hi Ricard,
>
>     I am not really keen to have these dimensions as separate fields
>     in the stock master. Every installation has a requirement for
>     other fields - dimensions really don't make sense for example for
>     freight, bank charges, consultancy, dry cleaning or any service
>     related items. I know we already have some redundant fields in
>     stock master depending on what the item is. However, this is
>     really what the properties are for.
>     If you wish to have dimensions in your stockmaster table then I
>     think it may be best to have these in your version only.
>
>     Hope you understand
>
>     Phil
>
>     Phil Daintree
>     Logic Works Ltd -+64 (0)275 567890  <tel:%2B64%20%280%29275%20567890>
>     http://www.logicworks.co.nz
>
>     On 06/11/13 15:38, Pak Ricard wrote:
>>     Hi Phil:
>>
>>     After checking and thinking for few days, it seems ugly to keep
>>     these dimensions in porperties, as we don't have any bullet proof
>>     way to compare them and be sure we transfer the data to the
>>     correct one. names can change, users can forget to update all the
>>     names for 1 same property between categoreies, etc...
>>
>>     Seems too risky for me.
>>
>>     I coded the 3 dimesions as fields in stockmaster. If you agree, I
>>     can commit it to SVN.
>>
>>     Regards,
>>     Ricard
>>
>>
>>     2013/11/1 Phil Daintree <ph...@lo...
>>     <mailto:ph...@lo...>>
>>
>>         No I don't think so we will have to check for the same label
>>         as you suggest... unless anyone else has any smart ideas?
>>
>>         Phil
>>
>>         Phil Daintree
>>         Logic Works Ltd -+64 (0)275 567890  <tel:%2B64%20%280%29275%20567890>
>>         http://www.logicworks.co.nz
>>
>>         On 01/11/13 19:09, Pak Ricard wrote:
>>>         Hi Phil:
>>>
>>>         The detail t solve then is: How we detect if a category
>>>         property "is the same" as another category property in
>>>         another category? The table definition has a stkcatpropid
>>>         but it's auto_incrment, so we can't use it as key. Label is
>>>         the best candidate if it's used as a code, so in all
>>>         categories, label should be exactly the same.
>>>
>>>         is there any other way to solve it?
>>>
>>>         Regards,
>>>         Ricard
>>>
>>>
>>>         2013/11/1 Phil Daintree <ph...@lo...
>>>         <mailto:ph...@lo...>>
>>>
>>>             Well I think you are right we probably should have
>>>             implemented weight and volume as category properties as
>>>             they are not really relevant to some items particularly
>>>             service items. To deal with changing stock categories
>>>             correctly I think the correct way is to copy the
>>>             category properties across if they are not already set
>>>             up against the new category and then the item category
>>>             properties can come across correctly too then to the new
>>>             category item properties.
>>>
>>>             Phil
>>>
>>>             Phil Daintree
>>>             Logic Works Ltd -+64 (0)275 567890  <tel:%2B64%20%280%29275%20567890>
>>>             http://www.logicworks.co.nz
>>>
>>>             On 01/11/13 17:23, Pak Ricard wrote:
>>>>             Hi all:
>>>>
>>>>             We are facing a problem with Stock categories
>>>>             properties and would like to ind a good solution for
>>>>             everybody as now we keep the dimensions of stockid as a
>>>>             property in table stockcatproperties.
>>>>
>>>>             Problem comes when an item changes stock category
>>>>             (quite often in our case), as we loose the data stored
>>>>             in stockcatproperties (because the stockcatproperties
>>>>             are linked with categoryid).
>>>>
>>>>             A solution comes rewriting all stockcatproperties, so
>>>>             if stockcatproperties.label is equal in the new
>>>>             categoryid assigned to the stockid, then we copy all
>>>>             the values to the new stkcatpropid
>>>>
>>>>             Another solution can be adding the field size into
>>>>             stockmaster. All physical items have a size (by
>>>>             definition). Services, software, etc no, but also do
>>>>             not have net weight, volume, etc and we kkep this info
>>>>             in stockmaster anyway.
>>>>
>>>>             I think the most logical and universal solution is this
>>>>             second one, as the first one will have problems if
>>>>             label is not written exactly the same way, etc etc.
>>>>
>>>>             Does everybody agree or there's any other option I'm
>>>>             missing here?
>>>>
>>>>             Regards,
>>>>             Ricard
>>>>
>>>>
>>>>             ------------------------------------------------------------------------------
>>>>             Android is increasing in popularity, but the open development platform that
>>>>             developers love is also attractive to malware creators. Download this white
>>>>             paper to learn more about secure code signing practices that can help keep
>>>>             Android apps secure.
>>>>             http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>>>
>>>>
>>>>             _______________________________________________
>>>>             Web-erp-developers mailing list
>>>>             Web...@li...  <mailto:Web...@li...>
>>>>             https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>
>>>
>>>             ------------------------------------------------------------------------------
>>>             Android is increasing in popularity, but the open
>>>             development platform that
>>>             developers love is also attractive to malware creators.
>>>             Download this white
>>>             paper to learn more about secure code signing practices
>>>             that can help keep
>>>             Android apps secure.
>>>             http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>>             _______________________________________________
>>>             Web-erp-developers mailing list
>>>             Web...@li...
>>>             <mailto:Web...@li...>
>>>             https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>
>>>
>>>
>>>
>>>         ------------------------------------------------------------------------------
>>>         Android is increasing in popularity, but the open development platform that
>>>         developers love is also attractive to malware creators. Download this white
>>>         paper to learn more about secure code signing practices that can help keep
>>>         Android apps secure.
>>>         http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>>
>>>
>>>         _______________________________________________
>>>         Web-erp-developers mailing list
>>>         Web...@li...  <mailto:Web...@li...>
>>>         https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>>         ------------------------------------------------------------------------------
>>         Android is increasing in popularity, but the open development
>>         platform that
>>         developers love is also attractive to malware creators.
>>         Download this white
>>         paper to learn more about secure code signing practices that
>>         can help keep
>>         Android apps secure.
>>         http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>         _______________________________________________
>>         Web-erp-developers mailing list
>>         Web...@li...
>>         <mailto:Web...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>>
>>
>>     ------------------------------------------------------------------------------
>>     November Webinars for C, C++, Fortran Developers
>>     Accelerate application performance with scalable programming models. Explore
>>     techniques for threading, error checking, porting, and tuning. Get the most
>>     from the latest Intel processors and coprocessors. See abstracts and register
>>     http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>
>>
>>     _______________________________________________
>>     Web-erp-developers mailing list
>>     Web...@li...  <mailto:Web...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>     ------------------------------------------------------------------------------
>     November Webinars for C, C++, Fortran Developers
>     Accelerate application performance with scalable programming
>     models. Explore
>     techniques for threading, error checking, porting, and tuning. Get
>     the most
>     from the latest Intel processors and coprocessors. See abstracts
>     and register
>     http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Web-erp-developers mailing list
>     Web...@li...
>     <mailto:Web...@li...>
>     https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] Stock Categories Properties issues

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

Sure Phil, that's why I asked ;-). I will keep them in stockmaster, until
we all find a good solution for properties and can be transferred easily
and safely.

Are you already back in NZ or still in UK?

Regards,
Ricard


2013/11/7 Phil Daintree <ph...@lo...>

>  Hi Ricard,
>
> I am not really keen to have these dimensions as separate fields in the
> stock master. Every installation has a requirement for other fields -
> dimensions really don't make sense for example for freight, bank charges,
> consultancy, dry cleaning or any service related items. I know we already
> have some redundant fields in stock master depending on what the item is.
> However, this is really what the properties are for.
> If you wish to have dimensions in your stockmaster table then I think it
> may be best to have these in your version only.
>
> Hope you understand
>
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz
>
> On 06/11/13 15:38, Pak Ricard wrote:
>
> Hi Phil:
>
>  After checking and thinking for few days, it seems ugly to keep these
> dimensions in porperties, as we don't have any bullet proof way to compare
> them and be sure we transfer the data to the correct one. names can change,
> users can forget to update all the names for 1 same property between
> categoreies, etc...
>
>  Seems too risky for me.
>
>  I coded the 3 dimesions as fields in stockmaster. If you agree, I can
> commit it to SVN.
>
> Regards,
> Ricard
>
>
> 2013/11/1 Phil Daintree <ph...@lo...>
>
>>  No I don't think so we will have to check for the same label as you
>> suggest... unless anyone else has any smart ideas?
>>
>> Phil
>>
>> Phil Daintree
>> Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz
>>
>>   On 01/11/13 19:09, Pak Ricard wrote:
>>
>> Hi Phil:
>>
>>  The detail t solve then is: How we detect if a category property "is
>> the same" as another category property in another category? The table
>> definition has a stkcatpropid but it's auto_incrment, so we can't use it as
>> key. Label is the best candidate if it's used as a code, so in all
>> categories, label should be exactly the same.
>>
>>  is there any other way to solve it?
>>
>> Regards,
>> Ricard
>>
>>
>> 2013/11/1 Phil Daintree <ph...@lo...>
>>
>>>  Well I think you are right we probably should have implemented weight
>>> and volume as category properties as they are not really relevant to some
>>> items particularly service items. To deal with changing stock categories
>>> correctly I think the correct way is to copy the category properties across
>>> if they are not already set up against the new category and then the item
>>> category properties can come across correctly too then to the new category
>>> item properties.
>>>
>>> Phil
>>>
>>> Phil Daintree
>>> Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz
>>>
>>>  On 01/11/13 17:23, Pak Ricard wrote:
>>>
>>>  Hi all:
>>>
>>>  We are facing a problem with Stock categories properties and would
>>> like to ind a good solution for everybody as now we keep the dimensions of
>>> stockid as a property in table stockcatproperties.
>>>
>>>  Problem comes when an item changes stock category (quite often in our
>>> case), as we loose the data stored in stockcatproperties (because the
>>> stockcatproperties are linked with categoryid).
>>>
>>>  A solution comes rewriting all stockcatproperties, so if
>>> stockcatproperties.label is equal in the new categoryid assigned to the
>>> stockid, then we copy all the values to the new stkcatpropid
>>>
>>>  Another solution can be adding the field size into stockmaster. All
>>> physical items have a size (by definition). Services, software, etc no, but
>>> also do not have net weight, volume, etc and we kkep this info in
>>> stockmaster anyway.
>>>
>>>  I think the most logical and universal solution is this second one, as
>>> the first one will have problems if label is not written exactly the same
>>> way, etc etc.
>>>
>>>  Does everybody agree or there's any other option I'm missing here?
>>>
>>> Regards,
>>> Ricard
>>>
>>>
>>>  ------------------------------------------------------------------------------
>>> Android is increasing in popularity, but the open development platform that
>>> developers love is also attractive to malware creators. Download this white
>>> paper to learn more about secure code signing practices that can help keep
>>> Android apps secure.http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Android is increasing in popularity, but the open development platform
>>> that
>>> developers love is also attractive to malware creators. Download this
>>> white
>>> paper to learn more about secure code signing practices that can help
>>> keep
>>> Android apps secure.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Web-erp-developers mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Android is increasing in popularity, but the open development platform that
>> developers love is also attractive to malware creators. Download this white
>> paper to learn more about secure code signing practices that can help keep
>> Android apps secure.http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Android is increasing in popularity, but the open development platform
>> that
>> developers love is also attractive to malware creators. Download this
>> white
>> paper to learn more about secure code signing practices that can help keep
>> Android apps secure.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and registerhttp://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>

Re: [WebERP-developers] Is it a right constraint for sales order?

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

Just to add to this - the only place I can think of where there is a 
distinction between raw materials and finished goods is used is for the 
selection of items for sales. So this flag on the stock categories is 
really only used for this purpose. If you have stock that is expected to 
be sold in its current form then best to make this a finished goods 
category. I accept there may be rare occassions where a raw material may 
wish to be sold - and that is why I am recommending a checkbox on the 
item search form. As icedlava notes you can always enter any item code 
into the quick entry screen to sell it - but as Klaus notes this is not 
obvious and possibly not even documented.

Phil

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

On 06/11/13 23:24, Tim Schofield wrote:
> Hi Klaus, raw materials have to be in separate stock categories
> anyway, and so they would only ever end up in the search if the user
> selected that category, or chose 'All Categories'. I am not sure I see
> the use case for this and it seems to me that it just complicates
> things with check boxes. However if thats what people want and someone
> is prepared to code it then thats fine.
>
> Thanks
> Tim
>
> On 06/11/2013, opto <bu...@op...> wrote:
>>> Well you only get a plethora if you type vague search criteria in :-)
>>
>> my secrtary might type in such a vague search.
>> And it is her and inexpereinced users I want to protect from being
>> overwhelmed by input or just choosing the wrong one because there are too
>> many similiar choices.
>>
>>
>> As for solutions:
>> I object an individual checkbox if it is the only one . Too many
>> complications (steps) to make something visible for the nexperienced user.
>> Also, it is too much work to occasionally makes those items visible that I
>> forgot to check (or want visble only one time).
>>
>> A separate stockcategory might work if no conflict with BOMs. But still, it
>> needs the advance decision whether I want a raw material sellable.
>>
>> Perfect would be an individual checkbox for those raw mateial I want to be
>> sellable always on the list, and a global checkbox to make all visible, if
>> today I sell just the one that is not individually checked.
>>
>> otherwise, for a single sales of cooling liquid, I need to set the checkbox
>> for this item, sell it, go back and revert the check box. A lot of work for
>> a single sale of some components.
>>
>>
>> Klaus
>>
>>
>>
>> --
>> View this message in context:
>> http://weberp-accounting.1478800.n4.nabble.com/Is-it-a-right-constraint-for-sales-order-tp4656839p4656851.html
>> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models.
>> Explore
>> techniques for threading, error checking, porting, and tuning. Get the most
>>
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>

Re: [WebERP-developers] Stock Categories Properties issues

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

Hi Ricard,

I am not really keen to have these dimensions as separate fields in the 
stock master. Every installation has a requirement for other fields - 
dimensions really don't make sense for example for freight, bank 
charges, consultancy, dry cleaning or any service related items. I know 
we already have some redundant fields in stock master depending on what 
the item is. However, this is really what the properties are for.
If you wish to have dimensions in your stockmaster table then I think it 
may be best to have these in your version only.

Hope you understand

Phil

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

On 06/11/13 15:38, Pak Ricard wrote:
> Hi Phil:
>
> After checking and thinking for few days, it seems ugly to keep these 
> dimensions in porperties, as we don't have any bullet proof way to 
> compare them and be sure we transfer the data to the correct one. 
> names can change, users can forget to update all the names for 1 same 
> property between categoreies, etc...
>
> Seems too risky for me.
>
> I coded the 3 dimesions as fields in stockmaster. If you agree, I can 
> commit it to SVN.
>
> Regards,
> Ricard
>
>
> 2013/11/1 Phil Daintree <ph...@lo... 
> <mailto:ph...@lo...>>
>
>     No I don't think so we will have to check for the same label as
>     you suggest... unless anyone else has any smart ideas?
>
>     Phil
>
>     Phil Daintree
>     Logic Works Ltd -+64 (0)275 567890  <tel:%2B64%20%280%29275%20567890>
>     http://www.logicworks.co.nz
>
>     On 01/11/13 19:09, Pak Ricard wrote:
>>     Hi Phil:
>>
>>     The detail t solve then is: How we detect if a category property
>>     "is the same" as another category property in another category?
>>     The table definition has a stkcatpropid but it's auto_incrment,
>>     so we can't use it as key. Label is the best candidate if it's
>>     used as a code, so in all categories, label should be exactly the
>>     same.
>>
>>     is there any other way to solve it?
>>
>>     Regards,
>>     Ricard
>>
>>
>>     2013/11/1 Phil Daintree <ph...@lo...
>>     <mailto:ph...@lo...>>
>>
>>         Well I think you are right we probably should have
>>         implemented weight and volume as category properties as they
>>         are not really relevant to some items particularly service
>>         items. To deal with changing stock categories correctly I
>>         think the correct way is to copy the category properties
>>         across if they are not already set up against the new
>>         category and then the item category properties can come
>>         across correctly too then to the new category item properties.
>>
>>         Phil
>>
>>         Phil Daintree
>>         Logic Works Ltd -+64 (0)275 567890  <tel:%2B64%20%280%29275%20567890>
>>         http://www.logicworks.co.nz
>>
>>         On 01/11/13 17:23, Pak Ricard wrote:
>>>         Hi all:
>>>
>>>         We are facing a problem with Stock categories properties and
>>>         would like to ind a good solution for everybody as now we
>>>         keep the dimensions of stockid as a property in table
>>>         stockcatproperties.
>>>
>>>         Problem comes when an item changes stock category (quite
>>>         often in our case), as we loose the data stored in
>>>         stockcatproperties (because the stockcatproperties are
>>>         linked with categoryid).
>>>
>>>         A solution comes rewriting all stockcatproperties, so if
>>>         stockcatproperties.label is equal in the new categoryid
>>>         assigned to the stockid, then we copy all the values to the
>>>         new stkcatpropid
>>>
>>>         Another solution can be adding the field size into
>>>         stockmaster. All physical items have a size (by definition).
>>>         Services, software, etc no, but also do not have net weight,
>>>         volume, etc and we kkep this info in stockmaster anyway.
>>>
>>>         I think the most logical and universal solution is this
>>>         second one, as the first one will have problems if label is
>>>         not written exactly the same way, etc etc.
>>>
>>>         Does everybody agree or there's any other option I'm missing
>>>         here?
>>>
>>>         Regards,
>>>         Ricard
>>>
>>>
>>>         ------------------------------------------------------------------------------
>>>         Android is increasing in popularity, but the open development platform that
>>>         developers love is also attractive to malware creators. Download this white
>>>         paper to learn more about secure code signing practices that can help keep
>>>         Android apps secure.
>>>         http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>>
>>>
>>>         _______________________________________________
>>>         Web-erp-developers mailing list
>>>         Web...@li...  <mailto:Web...@li...>
>>>         https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>>         ------------------------------------------------------------------------------
>>         Android is increasing in popularity, but the open development
>>         platform that
>>         developers love is also attractive to malware creators.
>>         Download this white
>>         paper to learn more about secure code signing practices that
>>         can help keep
>>         Android apps secure.
>>         http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>         _______________________________________________
>>         Web-erp-developers mailing list
>>         Web...@li...
>>         <mailto:Web...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>>
>>
>>     ------------------------------------------------------------------------------
>>     Android is increasing in popularity, but the open development platform that
>>     developers love is also attractive to malware creators. Download this white
>>     paper to learn more about secure code signing practices that can help keep
>>     Android apps secure.
>>     http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>
>>
>>     _______________________________________________
>>     Web-erp-developers mailing list
>>     Web...@li...  <mailto:Web...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>     ------------------------------------------------------------------------------
>     Android is increasing in popularity, but the open development
>     platform that
>     developers love is also attractive to malware creators. Download
>     this white
>     paper to learn more about secure code signing practices that can
>     help keep
>     Android apps secure.
>     http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Web-erp-developers mailing list
>     Web...@li...
>     <mailto:Web...@li...>
>     https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] Is it a right constraint for sales order?

[Tim S. <tim...@gm...>]

Hi Klaus, raw materials have to be in separate stock categories
anyway, and so they would only ever end up in the search if the user
selected that category, or chose 'All Categories'. I am not sure I see
the use case for this and it seems to me that it just complicates
things with check boxes. However if thats what people want and someone
is prepared to code it then thats fine.

Thanks
Tim

On 06/11/2013, opto <bu...@op...> wrote:
>>Well you only get a plethora if you type vague search criteria in :-)
>
>
> my secrtary might type in such a vague search.
> And it is her and inexpereinced users I want to protect from being
> overwhelmed by input or just choosing the wrong one because there are too
> many similiar choices.
>
>
> As for solutions:
> I object an individual checkbox if it is the only one . Too many
> complications (steps) to make something visible for the nexperienced user.
> Also, it is too much work to occasionally makes those items visible that I
> forgot to check (or want visble only one time).
>
> A separate stockcategory might work if no conflict with BOMs. But still, it
> needs the advance decision whether I want a raw material sellable.
>
> Perfect would be an individual checkbox for those raw mateial I want to be
> sellable always on the list, and a global checkbox to make all visible, if
> today I sell just the one that is not individually checked.
>
> otherwise, for a single sales of cooling liquid, I need to set the checkbox
> for this item, sell it, go back and revert the check box. A lot of work for
> a single sale of some components.
>
>
> Klaus
>
>
>
> --
> View this message in context:
> http://weberp-accounting.1478800.n4.nabble.com/Is-it-a-right-constraint-for-sales-order-tp4656839p4656851.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
>
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>


-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418
M +256 (0) 752 963 325
www.weberpafrica.com
@TimSchofield2
Blog: http://weberpafrica.blogspot.co.uk/

Re: [WebERP-developers] Is it a right constraint for sales order?

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

>Well you only get a plethora if you type vague search criteria in :-) 


my secrtary might type in such a vague search.
And it is her and inexpereinced users I want to protect from being
overwhelmed by input or just choosing the wrong one because there are too
many similiar choices.


As for solutions:
I object an individual checkbox if it is the only one . Too many
complications (steps) to make something visible for the nexperienced user.
Also, it is too much work to occasionally makes those items visible that I
forgot to check (or want visble only one time).

A separate stockcategory might work if no conflict with BOMs. But still, it
needs the advance decision whether I want a raw material sellable.

Perfect would be an individual checkbox for those raw mateial I want to be
sellable always on the list, and a global checkbox to make all visible, if
today I sell just the one that is not individually checked.

otherwise, for a single sales of cooling liquid, I need to set the checkbox
for this item, sell it, go back and revert the check box. A lot of work for
a single sale of some components.


Klaus



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Is-it-a-right-constraint-for-sales-order-tp4656839p4656851.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.