Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Picking List: only the first item of an order is printed
01-15-2018, 08:56 AM
Post: #31
RE: Picking List: only the first item of an order is printed
My apologies Paul, you are correct PDFPickingLists.php is referenced from that file, must be my advanced age catching up on me Smile

In fact I also have it referenced from SelectSalesOrder.php but I am not sure that is correct I will look into that tomorrow. Sorry about that,

Tim
Visit this user's website Find all posts by this user
Quote this message in a reply
01-16-2018, 01:24 PM (This post was last modified: 01-16-2018 03:08 PM by TurboPT.)
Post: #32
RE: Picking List: only the first item of an order is printed
You could be right about the PDFPickingLists.php file "needing to go"...

It appears that the GeneratePickingList.php file has virtually similar handling (similar queries, etc), so the link mentioned in previous posts should most likely point to this file instead?

The PDFPickingList.php file refers to the original pickinglists and pickinglistdetails tables, in both of our copies, which is likely NOT desired given Andrew's new[er] tables and scripts for this area, correct?

=======

Where I stand now:
  1. I did a basic trial run with the 'Generate' script against the one order (with one stock item) that I have in my system at the moment. At first I thought the PDF output appeared to be 'whacked', and might require some 'tweaking', but then I realized that I had not copied the updated PickList.xml file. A quick recheck of the PDF output was OK. (whew!)
  2. I'll be populating the two old tables with some data so that I can test the two migration queries that I've created. If this goes well, then I believe that all this handling will be ready for a trial run. [Of course, this implies that any other supporting scripts are ready as well]

After a brief migration test, it appears that I do not need to migrate column pickinglistdetails.pickinglistlineno:

Code:
table pickreqdetails (
detailno int not null auto_increment, -> pickinglistdetails.pickinglistlineno

...as detailno is an auto_increment in the new table. The 'pickinglistlineno' was populated with a variable value with INSERTs to the old pickinglistdetails table in the PDFPickingLists.php file.
Find all posts by this user
Quote this message in a reply
Yesterday, 02:47 PM (This post was last modified: Yesterday 03:04 PM by TurboPT.)
Post: #33
RE: Picking List: only the first item of an order is printed
Tim, ( I noted that you fixed the link references to the old PDFPickingList.php at your repo Smile )

I'm going to have to back-track on some of those scripts from the zip. (if not cross-check them all)

Although item 2 in my previous post is OK, but then there was trouble with an order having more than 1 line item:
  1. When generating the pick entries, I was getting an error after the first entry when the script was inserting the pick details. After about 40 minutes or so debugging, there was a variable storing a SELECT query result getting clobbered by an INSERT query result to the same variable name. After checking that reference at your repository, that issue was already fixed.
  2. Then after I fixed that matter, after the picklist PDF generated, an order where I have 31 items printed on 30 pages!!? (basically 1 line item per page, with some other minor artifacts) This seems to be a similar problem that HDeriauFF originally reported as the first post of this thread.

After checking your repository history of the GeneratePickingList.php, there were fixes applied to this file (and some of the other related scripts as well) back in Oct, 2014 by agaluski. So the zip file must have been from a time before those updates?

Anyway, I locally applied some of the PDF handling from the Generate script, and THEN the 30 page PDF reduced back to 3 pages, having about 13 line items on the first two and the remainder on the last.

SO, there will be a little more delay on this matter, for I'll have to retrieve each script file in the zip from Tim's repo, and then diff the files that already exist to "manually merge" any updates to match current web-erp code changes since 2014. Even files that do not currently exist have to be checked for certain code changes from the past too.

Know that on the surface, this does not appear to be too big a deal for keeping changes specific to the picklist handling, but will unfortunately take time for the comparing/merging/updates, and re-tests. Looking at some of the lines that I originally updated a few files from the zip do not appear to be present in the other repo files, so this effort might be eased, somewhat. (there are about 25 files in the zip)

I'm glad that I did not "blindly commit" any of those changes, for it would have been a BIG mess! Tongue
Find all posts by this user
Quote this message in a reply
Yesterday, 06:39 PM
Post: #34
RE: Picking List: only the first item of an order is printed
(Yesterday 02:47 PM)TurboPT Wrote:  Tim, ( I noted that you fixed the link references to the old PDFPickingList.php at your repo Smile )
Well you had spotted the bug so I fixed my code Smile
Quote:I'm going to have to back-track on some of those scripts from the zip. (if not cross-check them all)
You need to cross check all of the scripts. As you have said they are 3 1/2 years old, you should never blindly commit anything to SVN.
Quote:Although item 2 in my previous post is OK, but then there was trouble with an order having more than 1 line item:
  1. When generating the pick entries, I was getting an error after the first entry when the script was inserting the pick details. After about 40 minutes or so debugging, there was a variable storing a SELECT query result getting clobbered by an INSERT query result to the same variable name. After checking that reference at your repository, that issue was already fixed.
  2. Then after I fixed that matter, after the picklist PDF generated, an order where I have 31 items printed on 30 pages!!? (basically 1 line item per page, with some other minor artifacts) This seems to be a similar problem that HDeriauFF originally reported as the first post of this thread.

After checking your repository history of the GeneratePickingList.php, there were fixes applied to this file (and some of the other related scripts as well) back in Oct, 2014 by agaluski. So the zip file must have been from a time before those updates?
This is why I sent you the link to our companies github repository so you can check the latest code we have committed. We commit fixes and improvements to scripts most days so I don't remember if we committed something 39 months ago Wink
Quote:Anyway, I locally applied some of the PDF handling from the Generate script, and THEN the 30 page PDF reduced back to 3 pages, having about 13 line items on the first two and the remainder on the last.

SO, there will be a little more delay on this matter, for I'll have to retrieve each script file in the zip from Tim's repo, and then diff the files that already exist to "manually merge" any updates to match current web-erp code changes since 2014. Even files that do not currently exist have to be checked for certain code changes from the past too.

Know that on the surface, this does not appear to be too big a deal for keeping changes specific to the picklist handling, but will unfortunately take time for the comparing/merging/updates, and re-tests. Looking at some of the lines that I originally updated a few files from the zip do not appear to be present in the other repo files, so this effort might be eased, somewhat. (there are about 25 files in the zip)

I'm glad that I did not "blindly commit" any of those changes, for it would have been a BIG mess!
As I said, never blindly commit changes, especially if they were 3 1/2 years old!!
Quote: Tongue
Visit this user's website Find all posts by this user
Quote this message in a reply
Today, 06:06 AM (This post was last modified: Today 06:12 AM by TurboPT.)
Post: #35
RE: Picking List: only the first item of an order is printed
(Yesterday 06:39 PM)falkoner Wrote:  As I said, never blindly commit changes, especially if they were 3 1/2 years old!!
No trouble with that here, as I like to actually test/try changes/features whenever possible.

Although I know that it's not the case, your post #18 seemed to imply an urgency on this matter (though I agree it is high, as this is a nice feature to have), so I'm offering updates on the progress (good or bad) while working this through.

I know that HDeriauFF is eager to use this feature.
Find all posts by this user
Quote this message in a reply
Today, 06:13 AM
Post: #36
RE: Picking List: only the first item of an order is printed
No, that post was just enquiring what progress there was. From a personal perspective it makes no odds to me but I know the original poster was interested in it being available. I was just a bit concerned that your post implied you might have "committed blindly"
Visit this user's website Find all posts by this user
Quote this message in a reply
Today, 06:39 AM
Post: #37
RE: Picking List: only the first item of an order is printed
Thank you guys for working hard on this. I spent on my end several days (and nights) working on it trying to see where the problem was, with no avail. The issue seems to be much bigger than I initially thought.
Yes my client really needs this picking list function.

Thanks!
Find all posts by this user
Quote this message in a reply
Today, 12:21 PM (This post was last modified: Today 12:30 PM by TurboPT.)
Post: #38
RE: Picking List: only the first item of an order is printed
Tim, how critical is the stockcosts "picture" which is not part of the sourceforge trunk?

I crossed an error in the PickingLists.php script, so far, as this table does not exist, and appears to be an entire feature of its own that was added some time ago in your repo?
There are 30 occurrences (12 of these due to entries on the same line), found in 4 files in Andrew's zip.

There are 58 total file references (57 PHP, 1 SQL) across the repo, based on searching for 'stockcosts'.

I could likely strip the stockcosts references out of what I have, for now, to be applied later as a separate feature based on the scope of the changes that would be involved? Thoughts on this aspect?
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)