Sage MAS 90 and 200 Sage MAS 500 blogs Product Feedback Support Training
Reply
Contributor
GopherGold
Posts: 33
Registered: 03-12-2009
0

Bug in spsoGetNextSONo?

As a quick aside, it would be nice if there was a way to report possible bugs to Sage Support if one has the Bronze level plan.  In the past, I've submitted bugs through my reseller, but I feel like it went into a black hole.

 

 

This SP improperly returns a used SO num (TranType = 801) when UseSameRangeForBlankets and/or UseSameRangeForQuotes = 1.

 

This is easily duplicated through the UI:

 

  1. Ensure Use Same SO Number Range for Quotes and/or Use Same SO Number Range for Blankets is checked in Set Up SO Options.
  2. Open Enter Sales Orders and Quotes.
  3. Select Sales Order for Order Type.
  4. Get the next number (let's call it X).
  5. Take note of that number and click Cancel.
  6. Create a new sales order by entering X+1 in the number field.
  7. Enter a customer number.
  8. Change the status to Canceled and click Finish.
  9. Create a new sales order by clicking the Next Number icon in the toolbar. You will get the number just canceled (X+1), which is incorrect.

 

Sage Employee
MCarlise
Posts: 95
Registered: 07-24-2009
0

Re: Bug in spsoGetNextSONo?

I tested this and could not duplicate the issue. What version of MAS 500 are you running (including the Product Update)?

 

 

Mari Carlise
Sage 500 ERP Design Analyst
Contributor
GopherGold
Posts: 33
Registered: 03-12-2009
0

Re: Bug in spsoGetNextSONo?

Thank you for responding and looking into my report.

 

We are currently using v7.3 August 2010 Update.  As I recently upgraded, I still have a copy of the previous environment available: v7.05 April 2007 Update.  I have the same issue there as well (which I expected, since the stored procedure is identical across those versions).

 

When attempting to duplicate, did you type in the SO# in step #6?  That is key to this issue.  

 

 

Sage MAS Partner
jnoll
Posts: 420
Registered: 11-04-2008
0

Re: Bug in spsoGetNextSONo?

So that would make the key to the fix to not manually key in the SO# in step#6. :smileyvery-happy:

 

Sorry GopherGold! It has been a long day.

Joe Noll
RKL eSolutions LLC
http://www.rklesolutions.com
Sage Employee
MCarlise
Posts: 95
Registered: 07-24-2009
0

Re: Bug in spsoGetNextSONo?

 Yes, I did type in the SO#, (step 6). Let me try it on the version you are using. I'll let you know how it goes and if I cannot duplicate the issue, perhaps we can connect to further discuss the issue.

 

Thanks,

Mari

MAS 500 Design Analyst

Mari Carlise
Sage 500 ERP Design Analyst
Sage Employee
MCarlise
Posts: 95
Registered: 07-24-2009
0

Re: Bug in spsoGetNextSONo?

I tested this is 7.30 August 2010 PU and December 2010 PU and could not duplicate the issue. Both times I entered the next number, customer and then cancelled the order. The next sales order number I received was correct and incremented by 1.

 

I would verify you do not have any modifications to your system. Your Partner should be able to help you out. Sometimes it looks like you don't have any modifications, but you actually do (a lot are seamless).

 

Thanks,

Mari

 

Mari Carlise
Sage 500 ERP Design Analyst
Contributor
GopherGold
Posts: 33
Registered: 03-12-2009
0

Re: Bug in spsoGetNextSONo?

We have historically done modifications in-house.  As such, we just went through an upgrade and I did not make modifications to spsoGetNextSONo.  I think I this is the classic case of trouble reproducing errors.  Let's try a different approach.  Below is a code excerpt from the stored procedure that I believe is the source of the error:

 

 

		IF @_iTranType = 801
		BEGIN
			SELECT @_lRecordsFound = COUNT(*)
            FROM   tsoSalesOrdLog WITH (NOLOCK)
            WHERE  TranNo          = @_lPaddedNumberStr
            AND    TranType       =  801
            AND    CompanyID       = @_iCompanyID

			IF @_iUseSameRangeForBlanket = 1

				SELECT @_lRecordsFound = COUNT(*)
                FROM   tsoSalesOrdLog WITH (NOLOCK)
                WHERE  TranNo          = @_lPaddedNumberStr
                AND    TranType        = 802
                AND    CompanyID       = @_iCompanyID

			IF @_iUseSameRangeForQuote = 1

				SELECT @_lRecordsFound = COUNT(*)
                FROM   tsoSalesOrdLog WITH (NOLOCK)
                WHERE  TranNo          = @_lPaddedNumberStr
                AND    TranType        = 840
                AND    CompanyID       = @_iCompanyID
		END

 

 

Assume the following:

 

  1.  tciTranTypeCompany.NextTranNo = 2 for TranType = 801.
  2. There exists a record in tsoSalesOrdLog for TranNo = 2 and TranType = 801.
  3. There are no records in tsoSalesOrdLog for TranNo = 2 and TranType = 802 or 840.
  4. UseSameRangeForBlanket and/or UseSameRangeForQuote = 1.

Using these assumptions, the above code will return @_lRecordsFound = 0 at the end of the IF @_iTranType = 801 block.  In my testing, I added 

 

and @_lRecordsFound = 0

 

to both IF statements for blankets and quotes to achieve the correct result.

 

 

I hope this might help in reproducing the problem.  Again, thank you for your time - I really appreciate that you (Sage) are responsive to my questions on a user forum.

 

 

Contributor
GopherGold
Posts: 33
Registered: 03-12-2009
0

Re: Bug in spsoGetNextSONo?

I like your solution.  If I had that much influence over my end-users' behavior, I'd have a lot more free time!

Sage Employee
MCarlise
Posts: 95
Registered: 07-24-2009
0

Re: Bug in spsoGetNextSONo?

Thank you for the information. I am not a developer but I will have this looked into!

 

Thanks,

Mari Carlise

MAS 500 Design Analyst

Mari Carlise
Sage 500 ERP Design Analyst
Sage MAS 500 Customer
DGill
Posts: 218
Registered: 11-06-2008
0

Re: Bug in spsoGetNextSONo?

As GopherGold indicated this is a bug, we just bumped up against it as well and have no existing customizations on spsoGetNextSONo.  The logic flaw should be immediately apparent to a developer if they look at GopherGold's example.

 

Has this since been fixed in 7.4?

 

v 7.3.2