Author Topic: ORD.NUM.ASSIGN Bug?  (Read 5005 times)


  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
« on: July 03, 2007, 02:41:09 PM »
The SB+ paragraph ORD.NUM.ASSIGN is used throughout the Prelude app to generate the next sequential order number.  Today, while looking at this paragraph for a customer request, I stumbled across what appears to me to be a bug.  In this paragraph (at least in v19), there is logic to verify that the order key that has been generated does not reference an active order.  Problem is, if your order numbers are anything more involved than a sequential, unpadded number, this check does not work.

When an order number is sequentially generated, an accumulator in a CONTROL record is incremented.  Then, if there are any accoutrements (like padding, prefix, et al.), those are added on and the completed order number is returned in @VALUE.  Before returning this value, the following lines are executed:

  @RTN.FLAG = 0
  GOTO 1000

The GOTO 1000 causes a new number to be generated if the order exists in the active order file.  The problem, however, is the key that is being used to read the ORDER record; @PARMS(40)<1> has the sequentially assigned number, but it does not have padding or a prefix.  The completed order number is actually in the common variable @VALUE.  So I'm thinking this line should instead read:


Of course, being stock Prelude code I'm not about to go changing it without customer approval, but I figure if any Prelude folks are lurking in here, you might want to give that some attention.  Certainly, because the assignment of order numbers is sequential there's very little chance that this will manifest itself badly under normal circumstances.  However, is something wacky happens and the accumulators get reset for whatever reason, it would be good to know with certainty that this check is working properly.
« Last Edit: July 03, 2007, 04:06:48 PM by precisonline »
Accidents "happen"; success, however, is planned and executed.