|
Dennis, We do the drop ship process two years. only few problems is happened by user error operation. the detail procedure is . Order Entry---->Drop ship (please note the special item and special customer is allowed drop ship )------>purchase receipts (PUR550 DS)------->Drop shipment confirmation (BIL650)------->Billing Release (BIL500). if you need detail help,please email to me. Ping China ----- Original Message ----- From: <MacWheel99@aol.com> To: <BPCS-L@midrange.com> Sent: Tuesday, November 28, 2000 3:27 AM Subject: Re: Drop Ship & Purchase Orders > From Al Mac > BPCS 405 CD Rel-02 on AS/400 V4R3 mixed mode > > Dennis > > I am sorry that I do not have thorough solution to your challenge, merely > some ideas on the periphery, that you may already know about. > > I had several different ideas that MIGHT be able to help parts of your > problem & I hope the earlier posts got to you before the **** ADMIN problem > **** > > A) I talked about how to get at list of valid codes, and mentioned that your > comparative chart also needs to include record id, because there can be a > string of programs which at some point puts a "Z" in record indicating > "finished" but before the last step in the string. > > B) Dealing with weird stuff in general - standard check list in case > something obvious to me overlooked by you. Also attempted to evaluate > significance of PO LINES with non-standard sequence numbers. > > C) Other Clues here of abnormally terminated update sessions & how to try to > repair them. > > We do not do Drop Shipments. > > When volume messed up is low order of magnitude we use DFU to clean up > glitches in our BPCS data base, and on occasion have added an additional > logical to put the messed up data in a sequence that is easy for DFU access. > > There's an order in use flag > ECH HINUSE > HPH PHBUSY > > Other files may have similar fields that it would be useful to locate. > > My understanding is that when an order's details are included in a bunch of > files, some programs need unrestricted access to all portions of the order in > all files until they get done with their work on an order, so this in-use > flag logic is used to communicate between programs the fact that some program > is currently busy on the order ... checking & resolving this is first & last > thing program does for each order it needs access to, but if the user work > station has a disconnect, it might never get to the last step of unchecking > the in use flag. > > If someone is updating an order & their session goes south (e.g. PC), the > flag is not reset & no one can get into the order. I wrote a query to list > all orders that currently have their order in use & in the evening after > everyone has gone for the day there should be none set, but if any are, I use > DFU to unset them. > > Look at SYS-23 reorg menu SSAZ01-21 SYS993 for work stations involved ... is > anything messed up due to abnormally aborted session in middle of BPCS update? > > Searching combinations here when there are lots of work stations in the > system can be a bit tedious, and a lot of BPCS steps can be messed up without > appearing on this repair tool. I found it useful to DSPOBJD our BPCS *DTAARA > into an *OUTFILE then have an RPG program access each one & print them in a > chart so I can see which are messed up. > > When there is a known problem with a particular file, do a DSPFD of the > MEMBERS in it & see if there are work station members associated with the > users who were in the middle of the mess & if the contents there date back to > the scenario in question. Many programs use work station named work areas > prior to actually updating the master file & in an abort when we know how to > interpret this stuff (which I do not), there can be additional clues here. > > > From: DMunro@badgerminingcorp.com (Dennis Munro) > > > > AS/400 V4R4M0 - behind one set of ptf's from the current set, groups & cum > > - > > BPCS ver. 6.0.02 plf, full client/server, Mar'98 cum > > > > When entering drop shipments, I have one order whose corresponding HPH/HPO > > have invalid field contents & I cannot get to the order to finish the > > billing process. The po was receipted, a few lines here & a few there so > > they never noticed the extra lines????? > > > > I am comparing a "good" order & po set to the set "bad" I am having trouble > > with. They both are to the same customer/ship-to/item - just different > > dates. > > > > The "good" HPO purchase order detail contain the correct number of lines, > > which is 40 & they are numbered 1 through 40. > > The "good" HPO field PBUYC has a "7" & field PCLIN has "001". > > > > The "bad" HPO purchase order detail contains an incorrect number of lines, > > which is 55 & they are numbered 1 through 55. > > The "bad" HPO field PBUYC has a " ". > > The "bad" HPO field PCLIN has negative "029-" for order line 1. > > The "bad" HPO field PCLIN has negative "028-" for order line 2. > > The "bad" HPO field PCLIN has negative "027-" for order line 3. > > The "bad" HPO field PCLIN has negative "026-" for order line 4. > > The "bad" HPO field PCLIN has negative "025-" for order line 5. > > The "bad" HPO field PCLIN has negative "024-" for order line 6. > > The "bad" HPO field PCLIN has negative "023-" for order line 7. > > The "bad" HPO field PCLIN has negative "022-" for order line 8. > > The "bad" HPO field PCLIN has negative "021-" for order line 9. > > The "bad" HPO field PCLIN has negative "020-" for order line 10. > > The "bad" HPO field PCLIN has negative "019-" for order line 11. > > The "bad" HPO field PCLIN has negative "018-" for order line 12. > > The "bad" HPO field PCLIN has negative "017-" for order line 13. > > The "bad" HPO field PCLIN has negative "016-" for order line 14. > > The "bad" HPO field PCLIN has negative "015-" for order line 15. > > The "bad" HPO field PCLIN has positive "001" for order line 16. > > The "bad" HPO field PCLIN has positive "002" for order line 17. > > The "bad" HPO field PCLIN has positive "003" for order line 18. > > The "bad" HPO field PCLIN has positive "004" for order line 19. > > > > and etc. through line 39 > > > > The "bad" HPO field PCLIN has positive "025" for order line 40. > > > > For purchase order detail records 41 through 55, PCLIN has a -0-(zeros) in > > the field. > > > > The "bad" ECH field HSTAT is an "E" (have not found a list of valid codes) > & > > the "good" ECH has a "7". > > The "bad" ECL field LSTAT is an "E" & the "good" ECL has an "8". > > > > Any clues as to what I need to do so I can complete the drop ship process? > > > > > Or any clue as to what the operator may have done to give us our mess? > > > > Or any clue where the negative 29 comes in for the line number? > > > > Any clue how it can count right & get to 40 & leave the last 15 po detail > > records unsequenced? > > > > Rather confused this day before Thanksgiving here in the States & I was > > trying to end the week without any more problems???? > > > > I hope the abover makes sense because I'm not sure what we need to do to > > rectify this error before month end. > > > > Dennis Munro > > > > "I love deadlines. I especially like the whooshing sound they make as they > > go flying by." Dilbert's Words Of Wisdom: > > > > Badger Mining Corporation > > www.badgerminingcorp.com > > dmunro@badgerminingcorp.com > > (920) 361-2388 > > > MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac) > BPCS 405 CD Rel-02 mixed mode (twinax interactive & batch) on AS/400 @ > http://www.cen-elec.com > > +--- > | This is the BPCS Users Mailing List! > | To submit a new message, send your mail to BPCS-L@midrange.com. > | To subscribe to this list send email to BPCS-L-SUB@midrange.com. > | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. > | Questions should be directed to the list owner: dasmussen@aol.com > +--- +--- | This is the BPCS Users Mailing List! | To submit a new message, send your mail to BPCS-L@midrange.com. | To subscribe to this list send email to BPCS-L-SUB@midrange.com. | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: dasmussen@aol.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.