emeadaxsupport: Where is the System ID number sequence used? Will it run out?

[Blog bot]

Источник: http://blogs.msdn.com/b/emeadaxsuppo...t-run-out.aspx
==============


I was asked some questions recently about the "System ID" number sequence in AX - I don't think this information was available anywhere else so I'll share it through this post:

Q: Where is the BASI_1 number sequence (which is the "System ID" specified in the basic module) used? It seems to be increasing a lot will it run out? What is the limit?

A: This number sequence is used for all sorts of general purpose numbering in the application - specifically it's used for any fields using the extended data type ParmId. Below is a list of tables that use ParmId to give you an idea of where it's used, purchase and sales ordering are two of the really common areas.

Table:
AssetDepBookJournalParmPost,
BOMParmReportFinish,
CustConfirmJour,
CustConfirmSalesLink,
CustInvoiceJour,
CustInvoiceSalesLink,
CustPackingSlipJour,
CustPackingSlipSalesLink,
CustPaymManParmTrans,
CustQuotationConfirmJour,
CustQuotationConfirmSalesLink,
CustQuotationJour,
CustQuotationSalesLink,
InventParmQuarantineOrder,
InventPickingListJour,
InventPickingListJournalLink,
InventPickingListJournalTable,
InventPickingListLink,
InventSumDateTable,
InventSumDateTrans,
InventTransferParmLine,
InventTransferParmTable,
LedgerJournalParmPost,
ProdParmSplit,
ProjInvoiceJour,
ProjInvoiceParmTable,
PurchParmLine,
PurchParmSubTable,
PurchParmTable,
PurchParmUpdate,
SalesParmLine,
SalesParmSubTable,
SalesParmTable,
SalesParmUpdate,
SalesQuotationParmLine,
SalesQuotationParmSubTable,
SalesQuotationParmTable,
SalesQuotationParmUpdate,
SalesShippingStat,
VendInvoiceJour,
VendInvoicePurchLink,
VendPackingSlipJour,
VendPackingSlipPurchLink,
VendPurchOrderJour,
VendPurchOrderPurchLink,
VendReceiptsListJour,
VendReceiptsListPurchLink,


Drilling into this a bit further, essentially any X++ code where we use CompanyInfo::numRefParmId(), is using this number sequence, searching the AOT for code containing numRefParmId you can see exactly where it's being used. Commonly with a piece of code like this:

this.parmId(NumberSeq::newGetNum(CompanyInfo::numRefParmId()).num());

Searching the AOT reveals there are a few other non-parmId places which use this number sequence. There are also a few other EDTs which extend parmId and so they use the same number sequence:

EDT: EventRuleId extends ParmId
EDT: EventRuleRelId extends ParmId
EDT: ProdParmId extends ParmId

The logic around sales and purchase orders is that a parmId is used for each selection of orders posted - so if one order is posted in one process it'll use one parmId, and if 100 orders are posted in one process it'll use one parmId for the whole batch. The high number of daily numbers used in a specific customer's environment suggests that most of the time their orders are being posted singly, posting in batches (doesn't have to be a batched process necessarily, even interactively it's possible to select multiple orders to post) would decrease the number used by a factor of the number of orders per batch.

Having said that, there should be no need consider reducing consumption of the numbers. The maximum value for the highest number to be used in the number sequence is 2,147,483,647, this is the limit for a signed integer (-2,147,483,648 to 2,147,483,647). The field itself used for ParmId is 20 characters, so in combination with the remaining 10 characters there are a huge number of values available for use.

With very high volumes of transaction using this sequence then I would suggest a strategy such as suffixing the sequence with the year: ##########_2011, and periodically it can be extended to allocate another 2,147,483,647 set of numbers.

If demand was to increase dramatically in the future, this can scale up by increasing the frequency the sequence is updated, if the sequence was updated once per year that allows approximately 5.8 million per day, if it was updated once every 6 months that allows 11.8 million per day and if it was updated once per quarter then it allows 23.5 million per day. Of course this is just theoretical, scaling up the transaction volume by a factor of 10 would also require scaling of the related infrastructure and hardware - at least right now to think about only number sequences in that context is a bit of a moot point - safe to say it is expandable.



--author:Tariq Bell--editor:Tariq Bell--date:24/05/2011


Источник: http://blogs.msdn.com/b/emeadaxsuppo...t-run-out.aspx