Client Naming in AX

This question has suggested answer(s)

We are not AX users yet but are planning a migration in the next 12 months.  One area that has always been a challenge for us is naming clients in our system.  So many clients have subsidiaries who are, themselves, companies.  Our system only allows a single client name so we always struggle with the choice of using the main client name and keeping all the data together, or using the subsidiary name and losing the ability to roll up to the main client (the same can be said for governments and departments).

In AX, does the system allow for clients to be nested under a parent organization which would allow consolidated reporting but still allow discrete tracking?

I know this seems like a silly question but I can't seem to find documentation on this.  If someone here could point me to a solid source for documentation that would be helpful too (I don't mind helping myself).


All Replies
  • If by clients you mean customers, then you have quite a lot of options.

    Customers can have another customer as their "Invoice account".  While it is possible to have a customer point to another, and that one point to yet another, forming a tree hierarchy, the use Invoice account in this fashion does not accomplish much.  When creating a sales order, the Order account is the point of delivery, and the Invoice account is where the Account receivable (invoices) are posted, which creates a consolidated point for cash application and customer statements.  This is "billing" customer relationship in AX.  Note that these can all have different names and a large fan-in, allowing for many "stores" to roll up to one "corporate".  In addition to the primary name, you can override the addressing name, and customers can have multiple of each, so it is easy to have one name in AX for reporting and many others for the delivery tickets and invoices as needed.  

    If you have many companies (known as DataArea's in AX-speak) or Legal entities (internal organizations), each will probably have their own customer master (it can be shared, but let's pretend here that it's not).  Using Parties (a.k.a. the Global address book), customers across different internal companies can be reflections of a single Party, which can also include vendors.  For example, an external organization (Party) can be a customer in one of your manufacturing divisions, a vendor in another of your distribution divisions, and a customer in yet a 3rd of your divisions.  This relationship is above the billing relationship and forms the foundation of centralized payments.  If you owe that vendor, but that vendor owes you as well by virtue of them being a customer, these can be settled to each other through a process called Reimbursement.  Also if they send you a single large cheque you can apply this cash across many internal organizations using this relationship.  Another application of Party is to associate an employee as a vendor, i.e. for expenses.

    Parties can be associated with other parties through "relationships".  Example relationships are Acquired, Child, Competitor, Merged, Parent, Partner, Subsidiary, and many more.  Some of those relationships apply between an Organization and a Person, Org to Org, and Person to Person.  As you can imagine it is quite flexible and you can report on a nested relationship in any customized fashion you need.

    The primary reporting point for sales orders will be Order account.  Here are just a couple of examples of how you can "roll up" this data into natural hierarchies.  Additionally, there are many categorical reporting points, such as segments, sub-segments, customer classifications, customer groups, sales pools, and you can add more very easily.

    Hope this helps.