Arnie,

Your coding looks perfect! This brings back memories of the older versions of BPCS where in order to convert the date you had to execute subroutine $ROME and then $POPE to convert the date to a *DAYS value. I can see why the system would be confused based upon your example causing the system to look "backwards".


Dan Sweeney - Sr Technical Consultant
PHOENIX Business Consulting, Inc.
Cell: 860.490.6712
www.phoenixbcinc.com
 


-----Original Message-----
From: bpcs-l-bounces+dsweeney=phoenixbcinc.com@xxxxxxxxxxxx [mailto:bpcs-l-bounces+dsweeney=phoenixbcinc.com@xxxxxxxxxxxx] On Behalf Of Bud North
Sent: Friday, April 02, 2010 1:51 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: Re: [BPCS-L] Planned orders with Bad release dates

Arnie,

I believe there were several posts regarding this a couple of months ago suggesting the issue might be DRP150 - Shipping Calendar Maintenance. My recollection of the situation was that DRP150 had been set up years ago and not maintained. Once out of date, your planned order dates don't calculate correctly. I believe the solution was to either update DRP150 or clear all the entries in DRP150 as it is not required for DRP to function properly.

I am not a technical person - so can't comment on your code changes - but if the issue can be solved based on the above standard use of BPCS/LX, I would generally not recommend code changes.

It appears you are using the list correctly - Welcome! If this wasn't an old post as I mentioned above, then I missed something recently and hope the above helps.

Bud North, CPIM
Phoenix Business Consulting
Cell: 508-572-9701
Email: bnorth@xxxxxxxxxxxxxxxx


date: Fri, 2 Apr 2010 19:38:23 +1300
from: Arnie Flangehead <arnie.flangehead@xxxxxxxxx>
subject: Re: [BPCS-L] Planned orders with Bad release dates

Hi All

New to the list. Hope I'm using it correctly. Anyway, I have an answer to
the problem of planned order dates going years into the past.

There is some extraneous code in DRP500, which I have commented out below:

0868.70 C* Do until a work day is found
0868.80 C*
0868.90 C WORKDY DOUEQ YESX
0869.00 C* Days to YMD
0869.10 C*
0869.20 C Z-ADD ROMEX W1FDTE
0869.30 C EXSR DATE6
0869.40 C Z-ADD W1TDTE SCYMD
0869.50 C*
0869.60 C MOVE DEFWHS CALWHS
0869.70 C EXSR S923
0869.80 C*
0869.90 C*
0870.00 test C**** Z-ADD ROMEX W1FDTE
0870.10 test C**** EXSR DATE5
0870.20 test C**** W1RTN IFEQ 'E'
0870.30 test C**** Z-ADD W1FDTE ROMEX
0870.40 test C**** ELSE
0870.50 test C**** Z-ADD W1TDTE ROMEX
0870.60 test C**** ENDIF
0870.70 C*
0870.80 C*
0870.90 C* If not a work day go back 1 day

This is from the V8.2 program. The code is in subroutine N2278A and
hopefully I've included enough context for anyone to find it.

Problem is that ROMX is already a *DAYS value at this point, so putting it
through DATE5 will usually result in the return flag being set to 'E' and
therefore nothing happens, but occasionally a *DAYS number can be
interpreted as a date. For instance 40206, which is 29-Jan-2011 will be
interpreted as being [200]40206 in cymd format and so will return 37656,
being 06-Feb-2004.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.