We processed the 12/14/04 download yesterday.  Went into SO-N to convert the sales order to a work order.  This was a single sales order with one item on it.  An error message came up "CANNOT PROCESS SO: 6695 SINCE THE WORK ORDER SUFFIX GENERATED WILL SURPASS 999.  PLEASE CHANGE THE INCREMENT"
 
Pressed ok, and the same message came up for another sales order.  This went on through our whole open sales order file, then it created the work order we requested.  
 
1) our increments are set at 10
2) We generally only have one or two items per sales order.
3) We requested only 1 sales order for release, but it went through the whole file.
 
Please advise.
 
Thanks

Quote from aricon   on 01/11/05 at 09:21:34:

I'm sorry, but sounds like you are placing the responsibility of the programming team upon its users.  Standard debugging procedures will solve the majority of problems encountered during the programming process... as you say, TEST, TEST, TEST what has been changed to ensure something else didn't break.
 
It's not like we have a second server sitting around, nor have the time, to troubleshoot problems from what I expect, as should others, to be rudimentary upgrades.  Karen isn't the only person who has been burned by surprises like this, and I'm sure won't be the last.  I'll get down from the soap box now.

Dan,
 
The simple fact is that it is YOUR installation at the end of the day. It is YOUR business. It is YOU that suffers if there is something that doesn't work correctly that affects your ability to smoothly conduct business.
 
That is why in Enterprise systems implementations and in development projects and so on, when dealing with important or critical business systems, the user site has final responsibility to sign-off acceptance (AFTER testing) for upgrades, enhancements and patches.
 
Yes, it is the responsibility of the software developer or the development project PM or QA manager in the case of a custom development, to test as much as they REASONABLY can based upon what they consider to be the most likely and/or common configurations and usage scenarios. However, the fact is that any particular site may NOT conform to these testing standards and therefore things will be missed.
 
Also, as Lynn stated "we don't by any stretch claim to be perfect, we do a lot of testing".  
 
If you bough a new piece of critical machinery for the shop, would you just drop it on the floor, turn it on, and start running a critical and very expensive job for your largest customer through it? Or would you test it fairly extensively to make as sure as you could that it was set-up and calibrated correctly 1st??
 
Same thing
 
OK, done....

Sorry David, not the same.
 
Reality is: software is not perfect!! Sorry for the bad news, but there it is...
 
AND as software gets more and more complicated to try to meet the demands placed upon it, in particular the demands of more and more user configurability and "customization" and "personaliztion", there comes to be more and more and more different configurations to test. If you are prepared to pay the cost for a mid-range or higher solution to enable bigger budgets for the software company to do even more extensive testing then you can reduce the likliehood of significant problems.
 
However, DBA and EVO-ERP as a dirivitive, certainly do NOT fall into that budget category, so there is a very real limit to the amount of testing that can be realistically performed.
 
Additionally, the simple fact is that this software is written in an old line-editor code. It also does not have the "protection" from possible coding mistakes that a true relational database can provide (admitedly that is not a HUGE factor, but it can prevent some mistakes), and therefore it is somewhat easier for code in program A to have a negative impact upon the functionality of code in program T wayyyyy down the line, and the limited programming resources can only stretch just so far.
 
For your analogy of the lug bolts, well, simple fact is I have yet to hear of such a thing as a "user-defined lug bolt configuration". The technology of the lug bolt is VERY standardized, straightforward and pretty static therefore it is a more reasonable expectation to have it function pretty much the same for everyone ALL the time. And I would bet that the recall had nothing to do with the testing of the basic lug bolt, it was probably a manufacturing error.

Now THAT'S what I'm talking about....