US Field numbers in standard object

lagerberg · 2010-01-11

I have a need to use part of the US Sales tax functionality in a WW database. I do not need any US specific tables, but rather some of the fields that are added to standard objects as part of the US localization.

It seems possible to create the needed fields via a merge import.
The numbers are in the range 10.000 +.

Now, the question is - will the customer be able to run / use these modified objects?
I have seen elsewhere that fields are not subject to the same restrictions as other objects when it comes to numbering. Is that correctly understood? Is this stated in the documentation somewhere?

I have run tests with the customer license, and it does seem to work, but I'd really like to have it verified that this is normal behaviour. Any help would be appreciated!

Marije_Brummel · 2010-01-11

Yes this will work, the license does not check fieldnumbers.

lagerberg · 2010-01-11

Thats was quick! Many thanks!

ara3n · 2010-01-11

Instead of merging sales tax, and it's a huge number of objects you will need to merge. Identifying them will be harder.

I suggest to just test sales tax in W1 version first and see if it fulfills the requirements. If they do, then you don't need to merge the objects.

lagerberg · 2010-01-11

Hi Rashed,
thanks for the input. Actually I believe I do have the Sales Tax objects from the WW version already in my DB, and I need a couple of more fields because we are linking to a third party application (AVATAX) that use the US localization.

To be specific - they are having call points at places that don't exist in my code, and I guess that I need to begin with adding these call points. I have had some success so far, so hopefully it will work out!

The main thing I'm stumbling on now is that they are using a record parameter from a table in the 10.000 number series, and since my customers license cannot run in that range, I guess I need to have a modified version of the Avatax add-on.

Or is there a way I can change what record they are referencing with access to their code?

ara3n · 2010-01-11

Your license should have access to their add-on. If you don't then you should request that to be added to your license, so that you can change their code to reference another field in 50K range.

lagerberg · 2010-01-12

Yes I agree, but I'm not sure on whether they will allow access to their code. Do you know what's common practice? Is it usually the case that you do have access? We have got access in a couple of other cases with other products but I'm not sure what the common practive is.

Having access would completely solve my dilemma...

ara3n · 2010-01-12

Here in US, If I implement any Addon, it's added to my license to be modified, If Not, we don't implement those addons.

I know in europe it may be different, and here in US there are some addons that do not want to allow partners to modify their addons, but loose sale, because they don't understand the way of navision.

lagerberg · 2010-01-12

I have put in a question if I can have access, we'll see how it goes.
Many thanks for your help anyway!

DenSter · 2010-02-11

ara3n wrote:

here in US there are some addons that do not want to allow partners to modify their addons, but loose sale, because they don't understand the way of navision.

Like the way that a certain company's verticals will not be released to other partners

ara3n · 2010-02-11

DenSter wrote:

ara3n wrote:

here in US there are some addons that do not want to allow partners to modify their addons, but loose sale, because they don't understand the way of navision.

Like the way that a certain company's verticals will not be released to other partners

Yep, those certain companies don't sell their solution to other solution centers.

And I guess you don't implement them as well.

DenSter · 2010-02-11

It was implemented before the customer switched partners

US Field numbers in standard object

Comments

Categories