Hi guys,
I'm using Number Sequence for create of Sales Order through X , the code is like this :
NumberSeq numberSeq; numberSeq = NumberSeq::newGetNum(SalesParameters::numRefSalesId()); numberSeq.used(); salesTable.SalesId = numberSeq.num();
Everything looks fine for some time, but recently I'm often gets an error while running this to create new SO. in the message will say something like this:
And when I check, that number did already being used.
And as this error hit, I think it is put in the Status list and given status "Free", by looking at this form (the SO number sequence code, Administration > Status List).
But the question is why the code gets a number sequence that already being used in the 1st place ?
Because if I saw the timestamp of the createddate, in the list, SO-DT-000000486 put on 3/28/2023 10:04:07 AM, while this SO number already exist in the system 3/27/2023 2:20:09 PM ->
Is there something wrong in the code ? FYI, the number sequence it self is set to Continuous.
Hope I can have some idea what is wrong here.
Thanks,
Hi Lars,
I do agree with Martin that a continuous number sequence is not critical here. Although continuous is a standard feature, it is intended for vouchers, invoice numbers and number sequences used where there is a legal requirement to avoid any gap in the numbers. Out of the box, there is no coding which will mark a number to be reused when you delete a particular sales order. So, the continuous option is not supported by Microsoft for sales order numbers.
The application will reuse numbers if they are maintained in a status list. When looking at your coding, I wonder when the status list will be filled with numbers. This is usually only happening when you get a new number and set a parameter for _makeDecisionLater to true. This is not the case in your coding. The statement "numberSeq.used()" is for that reason also obsolete.
When there is support for a number to be reused (continuous), then when deleting a record, it will add the number to the status list.
In case you would use _makeDecisionLater and not set the number to "used", then a cleanup task will think that the number was reserved, but not actually used and will set it to reuse again.
Or you can take the advice from Martin and me to disable the continuous option, or you need to investigate when the numbers are being added in the status list to be able to solve your issue.
No, I'm not saying that there is no other way. I'm saying that using a non-continuous number sequence is better and that there is no point in spending time with the investigation if you can avoid the problem by using the better solution.
Hi,
Means to say there is no other way instead "not activate" Continues feature ? I feel this is very odd, since this is Microsoft feature and already being available long time ago, right ?
For the code, any common condition I should be aware of ? Since it is hard to explain here, the code to get the number sequence is the one I put in the thread, but where it is put is tough. It's in the class and in the middle of a process. The class it self is called from a custom RunBaseBatch class.
This is the code block of the Sales Order creation :
public SalesTable createSalesOrder (retailTable) { SalesTable salesTable; SalesLine salesLine; NumberSeq numberSeq; ttsbegin; numberSeq = NumberSeq::newGetNum(SalesParameters::numRefSalesId()); numberSeq.used(); salesTable.SalesId = numberSeq.num(); salesTable.initValue(); salesTable.CustAccount = retailTable.CustAccount; salesTable.initFromCustTable(); RetailChannelTable retailChannelTable; select firstonly retailChannelTable where retailChannelTable.RetailChannelId == retailTable.store; salesTable.RetailChannelTable = retailChannelTable.RecId; warehouse = InventLocation::find(RetailChannelTable.inventLocation); salesTable.InventSiteId = warehouse.InventSiteId; salesTable.InventLocationId = warehouse.InventLocationId; salesTable.InclTax = retailTable.IsTaxIncludedInPrice; salesTable.DeliveryDate = retailTable.transDate; salesTable.ReceiptDateRequested = retailTable.transDate; salesTable.ShippingDateRequested = retailTable.transDate; salesTable.DefaultDimension = retailTable.DefaultDimension; if (!salesTable.validateWrite()) { throw Exception::Error; } salesTable.insert(); . . . < sales line creation loop procedure > . . ttscommit; }
There are a bunch of method after this method like posting invoice etc, at the same time. but now it is stuck because sales order cannot create.
Understood about the critical piece of information, so can you tell what should I inform here or how ? Is the above enough ?
Thanks.
Them my recommendation is questioning the requirement. You don't want to cause problems just because someone wants and there is no real business reason.
I wouldn't spend time with reviewing the data, running number sequence cleanup and so on, if there is a chance that you can avoid the whole problem and improve performance (by making the sequence non-continuous).
I can't say whether your code is correct or not because you didn't tell us where you're using it, which is a critical piece of information.
Hi Martin,
Because I have requirement to make sure the number sequence is not skip actually. So I need to turn this on.
But in code wise is there any problem ?
Thanks
I strongly recommend avoiding continuous number sequences, unless there is a legal requirement to use them. They lead to degraded performance and may cause problems like your current one. Why exactly do you want to do that?
André Arnaud de Cal...
292,031
Super User 2025 Season 1
Martin Dráb
230,868
Most Valuable Professional
nmaenpaa
101,156