No. Series Line DataPerCompany = No

Yachty

Hi all,
I'd like your input on the following idea. We have a client with a lot of companies. For the new NAV 2016 installation we would like to get around the old solution to make the No. Series Line table DataPerCompany = No because of locking issues and performance. Although, there is a need of having some Master Data with identical No. in several companies. We discussed the idea of duplicating the No. Series Line table for selected No. Series and make only this new table DataPerCompany = No and leave the Rest in standard with DataPerCompany = Yes.
Did somebody try this before or have thoughts on this idea? Your input is highly appreciated! Thx

Kowa

If you duplicate the tables as well as the NoSeriesMgt codeunit (-> NoSeriesMgt Cross-Co.) and link the two, it works fine and does cater for both requirements. I've been using that for years in a large project. There I also added a codeunit to pull nos. from other companies for certain cross-company documents. But all of this was not due to locking or performance issues, just to have unique nos. for intercompany processes. Locking behaviour will not improve that way.

Remco_Reinking

For those tables where you need to use the same No. Series for all companies, you have two options (as I see it):
1st option: Make sure the NoSeriesManagement will always run in the same Company. This can be achieved in two ways, one using startsession or a webservice call (but both are probably too slow).
- Second is to rewrite the NoSeriesManagement codeunit, so it is applies changecompany for the tables 308, 309 and 310, but only when needed. Thereby forcing to always use the same company as the leading no.series company.

2nd Opion: Indeed make a copy of the No. Series and No. Series Line. and the NoSeriesManagement. Those tables that should use these multicompany No. Series should have a little change, so they call this new codeunit. This solution takes more objects to change, but I think it is easier to develop.

ufuk

Making DataPerCompany=No doesn't resolve the locking issues and performance. In fact, it may cause more locking issue because a lock in a company will affect another company.

Yachty

This was not my question. I want to have it DataPerCompany = Yes for most of the No. Series because I want to avoid locking. But I need a DataPerCompany=NO type No Series for certain Masterdata.

Kishorm

"No. Series" is a single table - it ether has to be DataPerCompany = yes OR no - you can't have both.

BTW - I personally would never set this table to DataPerCompany=no

ufuk

Ahh, I misunderstood the question. Why you need to increase a master data number in another company? Assuming you want to do this for customer, customer nos in certain company will be like CUST0001, CUST007, CUST008... Do you really need to reserve each number across companies? Can setting this master data table's datapercompany=no be an option? I would prefer setting master data property rather than setting or replicating no. series line.

Yachty

Kishorm wrote: »

"No. Series" is a single table - it ether has to be DataPerCompany = yes OR no - you can't have both.

BTW - I personally would never set this table to DataPerCompany=no

That's why we wanted to duplicate the table...

Yachty

Unfortunately that's not an option as the posting groups will be different. But yes, customer is a candidate, but also t36... due to intercompany business connected with end customer orders...

ufuk wrote: »

Ahh, I misunderstood the question. Why you need to increase a master data number in another company? Assuming you want to do this for customer, customer nos in certain company will be like CUST0001, CUST007, CUST008... Do you really need to reserve each number across companies? Can setting this master data table's datapercompany=no be an option? I would prefer setting master data property rather than setting or replicating no. series line.

Kowa

If you duplicate the tables as well as the NoSeriesMgt codeunit (-> NoSeriesMgt Cross-Co.) and link the two, it works fine and does cater for both requirements. I've been using that for years in a large project. There I also added a codeunit to pull nos. from other companies for certain cross-company documents. But all of this was not due to locking or performance issues, just to have unique nos. for intercompany processes. Locking behaviour will not improve that way.

Remco_Reinking

For those tables where you need to use the same No. Series for all companies, you have two options (as I see it):
1st option: Make sure the NoSeriesManagement will always run in the same Company. This can be achieved in two ways, one using startsession or a webservice call (but both are probably too slow).
- Second is to rewrite the NoSeriesManagement codeunit, so it is applies changecompany for the tables 308, 309 and 310, but only when needed. Thereby forcing to always use the same company as the leading no.series company.

2nd Opion: Indeed make a copy of the No. Series and No. Series Line. and the NoSeriesManagement. Those tables that should use these multicompany No. Series should have a little change, so they call this new codeunit. This solution takes more objects to change, but I think it is easier to develop.

Yachty

Thx both, Kowa and Remco_Reinking
for your input. And Kowa you are thinking having approx 20 companies and thus 20 no. series line table in SQL would not improve locking behaviour. In theory it should but that's why I am asking, I want feedback from the field!

Kowa wrote: »

If you duplicate the tables as well as the NoSeriesMgt codeunit (-> NoSeriesMgt Cross-Co.) and link the two, it works fine and does cater for both requirements. I've been using that for years in a large project. There I also added a codeunit to pull nos. from other companies for certain cross-company documents. But all of this was not due to locking or performance issues, just to have unique nos. for intercompany processes. Locking behaviour will not improve that way.