- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
Bug in spsoGetNex tSONo?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-14-2011 07:35 AM
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:
- Ensure Use Same SO Number Range for Quotes and/or Use Same SO Number Range for Blankets is checked in Set Up SO Options.
- Open Enter Sales Orders and Quotes.
- Select Sales Order for Order Type.
- Get the next number (let's call it X).
- Take note of that number and click Cancel.
- Create a new sales order by entering X+1 in the number field.
- Enter a customer number.
- Change the status to Canceled and click Finish.
- 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.
Re: Bug in spsoGetNex tSONo?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-26-2011 10:53 AM
I tested this and could not duplicate the issue. What version of MAS 500 are you running (including the Product Update)?
Sage 500 ERP Design Analyst
Re: Bug in spsoGetNex tSONo?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-27-2011 07:54 AM
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.
Re: Bug in spsoGetNex tSONo?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-27-2011 02:49 PM
So that would make the key to the fix to not manually key in the SO# in step#6. ![]()
Sorry GopherGold! It has been a long day.
RKL eSolutions LLC
http://www.rklesolutions.com
Re: Bug in spsoGetNex tSONo?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-28-2011 08:17 AM
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
Sage 500 ERP Design Analyst
Re: Bug in spsoGetNex tSONo?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-28-2011 11:42 AM
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
Sage 500 ERP Design Analyst
Re: Bug in spsoGetNex tSONo?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-29-2011 01:30 PM
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:
- tciTranTypeCompany.NextTranNo = 2 for TranType = 801.
- There exists a record in tsoSalesOrdLog for TranNo = 2 and TranType = 801.
- There are no records in tsoSalesOrdLog for TranNo = 2 and TranType = 802 or 840.
- 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.
Re: Bug in spsoGetNex tSONo?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-29-2011 01:34 PM
I like your solution. If I had that much influence over my end-users' behavior, I'd have a lot more free time!
Re: Bug in spsoGetNex tSONo?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-29-2011 02:15 PM
Thank you for the information. I am not a developer but I will have this looked into!
Thanks,
Mari Carlise
MAS 500 Design Analyst
Sage 500 ERP Design Analyst
Re: Bug in spsoGetNex tSONo?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
12-27-2011 09:02 AM
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


