CustTable and VendTable sharing between company accounts

(0) Share

Report

Posted on by Pall Bjornsson

265

Hi,

I'm evaluating my options for sharing basic customer and vendor information between some, but not all of my companies. The purpose being a centralized and synchronized customer/vendor account number allocation and address information, with accounting related information stored within each company.

One option that seems to be feasible is to create a TableCollection containing CustTable and VendTable only and then create a Virtual Company for those accounts sharing these tables, using that new TableCollection.

Experimenting with that, I soon discovered the DirParty* tables, or the predefined DirPartyCollection TableCollection for global address book must also be assigned to that Virtual Company.

Anyway, my question is if this is common practice to share customer and vendor informaton, and if there are any serious complications to be expected if this path is chosen?

Palli

*This post is locked for comments

I have the same question (0)

All responses (10)

Answers (0)

Sort by

Denis Patrakov on at

Like (0)

Report
Copy link

Link copied!

I think it's a pretty common practice to share CustTable/VendTable though a virtual company; there might be some complications if you eventually find out that in different companies you need to use different settings for the same customer/vendor, f.e. credit limit, or ABC-classification, or something like that.

Was this reply helpful? Yes No
ShirleyA 45 on at

Like (0)

Report
Copy link

Link copied!

I think it has been common practice to share the customer and vendor information, especially prior to version 2009, but be sure to test if combining with the global address book functionality as that also depends on a virtual company to store the DirParty info. We have tested for demo purposes and it has worked, but have not used that combination in production.

Was this reply helpful? Yes No
Pall Bjornsson 265 on at

Like (0)

Report
Copy link

Link copied!

Hi and thank you both very much for the info.
I went for it and made an honest test. Turned out that there was a wall there that I hit pretty hard. We can live with customer/vendor groups that can easily be the same in all companies, and even global addresses.
The dimensions being stored within the CustTable/VendTable themselves is a show-stopper for this experiment, so for now, I will have to settle for those tables being in each companies dataset.
The purpose of this experiment was to guarantee that if customer A was created in one company and then the same customer was created in another company, then we need that customer to have the same CustomerID in both companies. We solved that in our old accounting software by having a corp-Customer and corp-Vendor tables where we first created that new customer (if it wasn't there already) with very basic information and only then the customer could be created in CustTable / VendTable in the "linked" companies.
Any idea for a smart solution to this problem that does not require me to share those tables in a virtual company ?
Palli

Was this reply helpful? Yes No
ShirleyA 45 on at

Like (0)

Report
Copy link

Link copied!

I wouldn't imagine the programming to create a trigger on the save function would be that difficult (but I am not a developer so of course I always think these things are easy). Then you could even create the other customer/vendor as a stopped vendor until additional information was populated. Otherwise, you could actually use the global address book functionality - you wouldn't have the same customer numbers in both companies but they would be linked via the address book ID.

Good luck!

Shirley

Was this reply helpful? Yes No
Denis Patrakov on at

Like (0)

Report
Copy link

Link copied!

What's the reason for a customer to have the same CustTable.AccountNum value in all "linked" companies? Do these companies trade with each other? Are their transactions consolidated in a separate company? Must a customer be created in all the "linked" companies at once or as necessary?
Of course it's quite handy to have the same AccountNum for a customer in all the "linked" companies but this is not the only option. You can also assign external code values to customers and match two customers from two different companies by their external code values. For instance, in a company A you can create an external code "CustomerId in company B". Then for a customer "ABC" in company A you can assign a value "XYZ" for the external code "CustomerId in company B" - in that case in a company A you can match a customer "ABC" with a customer "XYZ" from a company B. Such approach is employed in InterCompany trade in AX.
Besides you can customize AX to use the same approach you've used in your old accounting system but note that some settings (f.e. Addresses) use RecId as a foreign key and two CustTable records in two companies will have different RecIds even if they have the same AccountNum value. That is in case of a global address book if you set up an address for a customer "ABC" in a company A than this address will not be linked with a customer "ABC in a company B.

Was this reply helpful? Yes No
user5555 7,437 on at

Like (0)

Report
Copy link

Link copied!

Hi,

I would have you adviced by MS on this matter or look for standard functionality on virtual companies. How much companies are involved? I would not code any automatic copy or so for this.

I have been struggling quite a couple of days or even a week to insert an address through the partyTable. I have also seen partyid in combination with virtual companies and the sharing with the global address book. I would not touch it too much. The AX structure / code is too complicated and code is not run as you might expect.

Also using a 'trigger' to copy data from one table to another is not recommended: 1) the architecture of AX does not have triggers in the underlying database, so you are not following a design/ architecture patterns, but more over the commits and inserts/updates in the party id are fired at various parts of the code which gives you little control on when and what is fired without digging into every single code line. Since AX commits in a quite unpredicatable pattern and quite a lot for a single customer creation, you can expect many triggers to get fired.

Another side effect of triggers could also be that the trigger 'direction' is becoming unclear. What if A triggers a copy from A to B, and the trigger of B then assumes it should be triggered to copy the data back to A. Then you are in a endless loop.

And last but not least: how are deleted and updates processed from A to B?

I would look for a smart 'manual' job or if you want to have same accountnum's. Add the customer in company A and in company B and then do a rename through the AX table record or with a SQL script. If there are no transactions after the CustTable I think the AccountNum is only present at the CustTable only.

J.

Was this reply helpful? Yes No
Pall Bjornsson 265 on at

Like (0)

Report
Copy link

Link copied!

Hi guys,
Thank you all for your opinion.
To answer a few of the questions put forward, then the reason for having the same customer and vendor account numbers across all the companies is simpe: Accounting simplicity
These companies are all part of a corporation, where accounting is handled by a central department within the corporation. Having the same account numbers in all the companies for the same customer/vendor makes their life a lot easier.
Having some global/intercompany accountnumber they all relate to with different account numbers in each company is one way. Making sure they all get the same account number in all the companies is another way.
Through testing, I have now seen that sharing the CustTable/VendTable via virtual company will not work for us, so I have to choose another method. I don't want to go the trigger way, unless I have to. If I do, I would probably declare one of the companies being the master, somewhat like my solution for our old accounting software. That way I will not have the problem of triggering back and forth.
Palli

Was this reply helpful? Yes No
user5555 7,437 on at

Like (0)

Report
Copy link

Link copied!

Hi,

Can you explain this more?

"These companies are all part of a corporation, where accounting is handled by a central department within the corporation. Having the same account numbers in all the companies for the same customer/vendor makes their life a lot easier. "

You mean your vendors/ customers in AX are part of on corporation of that you are part of one corporation? Lets put a sample, maybe you can clarify more.

1. Vendors/ customers in AX are part of one corporation?

So Customera1, Customera2 and Customera3 belong all to CustomerMastera ?

So Customerb1, Customerb2 and Customerb3 belong all to CustomerMasterb ?

2. Your corporation has multiple companies?

So Company1, Company2, Company3 all belong to CompanyMaster? And customera1 belongs to company1 and customerb1 to company2 ?

J.

Was this reply helpful? Yes No
Pall Bjornsson 265 on at

Like (0)

Report
Copy link

Link copied!

Hi,
This is really very simple. We are a corporation of, say, 3 companies. Every individual company has it's own base of customers and vendors. Same person(s) are bookkeeping for all the companies.
As a minimum, we need a relation between the companies, so we can view status of, say, customerA total for the corporation. This could be accomplished by some mastercustomerID.
For convenience, and for simplicity of all procedures except creating a new customer/vendor, we want the same customerID for CustomerA in all the companies.
As an example, think of a customer list from two of those companies. With that list at hand, you would have to do further processing to be able to link the customers if they don't have the same customerID. You can of course do some programming and link them to the mastercustomerID, but still, if you only have it on paper, you're out of luck.
Having the same customerID in all the companies has, by former experience, proved to be very helpful in our environment, so that's where we are headed at the moment, unless we find a solution that will give us the same/similar results without much added overhead.
Palli

Was this reply helpful? Yes No
user5555 7,437 on at

Like (0)

Report
Copy link

Link copied!

Hi,

I advice you to talk to your partner or somebody specialized in the financial modules of AX. I have the feeling this is one of the advantages of having AX. I am thinking of financial dimensions connected to a customer, but maybe it is even more 'default' in AX by reconcillation totals of those companies into one financial statement so that the main entity of those companies (the corporation) knows exactly what the financial status of the company is.

Contact your partner or sent a private message to Dennis Slotboom. Maybe he is willing to give you paid or unpaid advice on this. Or look for an AX partner that has its customers base consisting of medium to large businesses. In large businesses it is more common to have more corporate accounts which all must report back to the holding (corporation).

If I would be the CFO of the corporation I would like to have the information reported realtime from all my underlying companies. If I would not be able to do this or use a tool like FRX on which expensive consultants have to work every year or for my monthly reporting I would not choose for an ERP like AX since than it is for me not an ERP system since it is still working as a stand alone system per company instead of globally. I sometimes also hear financial managers with SAP using all kind of special tools for this. It is more that they do not want to use features or do not know they exist. So they choose sophisticating tools to do it for them. After 6-10 weeks they can then report their year end balances. I think it is quite ridiculous not wanting automatic tools for this. An ERP system should be able to do this since it is a process that comes back at least once a year. Bookkeeping is a straightforward process which can be automated easily and should be done accurately. It must be that boring since everything is automated. Then you can have the people focus more on what the figures mean and what you can do with it, instead of having the people collect all this data to make it understandable information from it.

I am not a specialist, but it sounds like something you want a global ERP system for. If not, it opens doors for an ISV to add it to AX..but actually I would be surprised if AX cannot do this. I would then choose for SAP and have the proper people do a good reconcillation of my companies into the corporate account.

J.

Was this reply helpful? Yes No