webERP Forum

Full Version: Internal Stock Request - Many Issues
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
InternalStockRequest.php

Clicking on table header column name does not sort data in columns.
Ignores the User-based DisplayRecordsMax value.
Prev / Next buttons do not work as they should.
Qty On Order / Available are wrong.

I got table column sorting to work by encapsulating the product data within TBODY tags.

While looking at this I see we have some inconsistencies in the way product tables and associated data is presented.

Nit-Picky again here but sure would be nice if we could somehow use the exact same code base for POs, SOs, Stock Movements, Stock Requests, etc.

Can this table code be somehow abstracted and moved to an include script so we only have to manage one script?
This post is related to: http://www.weberp.org/forum/showthread.php?tid=7918
Quantity issue is due to error on Line 685:

$sql = "SELECT SUM(purchorderdetails.quantityord-purchorderdetails.quantityrecd)*purchorderdetails.conversionfactor AS dem

Should be:

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

Reference DeliveryDetails.php and includes/SQL_CommonFunctions.inc.

Attached is my hack job for review which also includes an attempt to make the table look more like those in other scripts...

No luck with Prev / Next buttons though...
I tried to reconcile InternalStockRequest.php with SelectOrderItems.php but ended up with a mess.

I see no reason why these two scripts do not use the exact same code to build the products list.

I am VERY happy with webERP but little things like this are EXTREMELY frustrating...

How do we end up with wildly-varying scrips that do the same work?
(02-11-2018 05:39 AM)VortecCPI Wrote: [ -> ]I tried to reconcile InternalStockRequest.php with SelectOrderItems.php but ended up with a mess.

I see no reason why these two scripts do not use the exact same code to build the products list.
I'll have to come back around and cross check those. (recall the "multiple iterations" that it takes sometimes?)

(02-11-2018 05:39 AM)VortecCPI Wrote: [ -> ]I am VERY happy with webERP but little things like this are EXTREMELY frustrating...

How do we end up with wildly-varying scrips that do the same work?
Yes, I agree, it can tend to get frustrating.

"Wildly-varying scripts" ... This appears to be the "general nature" with many open-source projects that I've encountered when many "players" are involved from various backgrounds and coding skills. Some drop by, add one, two or a few features or more (which might sometimes be near "clones" of existing features -- you know, where a script is copied, renamed, and then altered for the new purpose), and then move on to whatever other interest(s), and things (duplicity, hacks, redundancies, etc.) simply tend to linger. Other reasons can be project leads that want certain things done the way that they want things done, which could be good or bad depending on the circumstances.
Paul, I believe the opening <tbody> tag should start after the row of column headings that have the 'ascending' class?

I'll investigate the P/N buttons.
(02-11-2018 05:39 AM)VortecCPI Wrote: [ -> ]How do we end up with wildly-varying scrips that do the same work?

Well it has been the policy of webERP from the start (and I agree with the reasoning) to have as little as possible abstracted from the individual scripts making them as self contained and readable as possible.

The problem is as Paul says that individual developers have their own ideas on how to implement stuff such as the searching for part numbers. There has been occasional discussions in the past on abstracting the item search code, but nobody has ever actually sat down and done some code as a discussion.

Tim
Tim,

Thank you for shedding some light on this and I can agree with the self-contained aspect. I still have to ask how and why code for can be so different for two scripts that show the exact same a product list table? I am a webERP novice and I recognized the table layout and selection functionality as soon as I saw it. Same with Prev / Next button code -- Why not use consistent code across all scripts? We can achieve the self-contained requirement while sharing common code, especially when it comes to things like Prev / Next functionality.

My biggest issue is that after implementing the Serial Number feature (my hack) I was halted by non-working Prev and Next buttons so I could not even use the script. While I realize this is an OSS product owners don't like to hear about non-working or partially-functioning code that keeps their business from being able to manage inventory.

I am absolutely thrilled with webERP and it has exceeded my every expectation thus far. However, the Prev and Next button thing set me off.

I can't thank you all enough for this product and your help so I apologize for any harsh words.

Paul
(02-11-2018 11:28 AM)TurboPT Wrote: [ -> ]Paul, I believe the opening <tbody> tag should start after the row of column headings that have the 'ascending' class?

I'll investigate the P/N buttons.

Paul,

I just did what I could to try to tidy it up but when I noticed the Prev / Next buttons didn't work I shifted gears but then had to quit. It is likely my hack job needs a lot of looking over to be deemed acceptable.

PB
Well the previous/next buttons are probably a good example of how this happens. As I remember they were implemented by me at the instigation of the ICT manager of a missionary organisation in Tanzania in just one script that he wanted the facility in. This was about 10 years ago so the majority of the scripts having the item search in were already written and out there.

Obviously the theory is that at this point they should have been added into all the other scripts but in the FLOSS world this doesn't always happen, especially with changes as big as this (it is a lot of scripts), I was travelling a lot at that time and it just wasn't feasible but I judged the changes to that one script were pushing out to others. Since then they have got into some new scripts that have been written, and some old ones have been changed. However when people write new scripts they tend to base them on scripts already written, and if they choose a script that doesn't have the prev/next buttons in to base their new script on then the new script won't have them.

As an admin it is hard to know what to do with functionality someone gives you that doesn't conform necessarily with the webERP way of doing things. A great example is the MRP system which a company wrote for themselves and sent into us. This was brilliant work and advanced webERP considerably. However there were many ways it didn't conform. If we had asked the author to re-write it as we wanted it almost certainly wouldn't have happened so at the time Phil and I took the decision to include it. There are still issues with it as you have recently pointed out with the planned orders scripts, yet I think it was the correct decision to include it.

I'm not saying that this is the correct way of going about things, but it is in my experience the way it happens.

Tim
Tim,

100% agreed on MRP piece. It is an amazing feature and we are all very lucky to have it included within webERP.

Again, I realize how easy it is to be a critic but I am doing so with the very best of intentions. I truly wish I was more proficient with PHP and had a lot of knowledge with respect to webERP but I have neither. If I did I would not have to bother the rest of you and I would simply provide the community with good working revisions to the code as the rest of you do. This is a part of my frustration as well -- I WANT to help A LOT but I can only help A LITTLE. I have authored some highly-complicated software solutions (CFD, FEA, AISC, ASME, Engineering, BoM Generation, Solid Model Generation, etc.) so I am no stranger to heavy-duty data, math, and logic but I am very weak with HTML and only a novice with PHP. I am getting better and better but I have several business to keep running and supporting so time for learning is scarce.

Again I want to say "Thank You" to all of you who put up with my nit-picky critiques but I especially want to to say "Thank You" for sharing webERP.

PB
Paul, valid criticisms courteously expressed are what helps make FLOSS projects better, so never worry about upsetting people and your assistance has already made webERP better.

Please continue with what you have been doing Smile
Pages: 1 2 3 4
Reference URL's