Dear Christian, 

The approach hinges on crucial details. 
In any case, I check the pricing order in IFS online documentation, so this is the base for me.
I am working with apps 9 but as far I can see in our IFS Cloud environment there are no diffrences in pricing matter.

My key considerations
Sales Part and Sales Price Groups:

• Need to determine the grouping of sales parts with sales price groups (1:1 relation).
• Creation of price lists per sales price group.

Customer Master Data and Price Groups:

• Explore the necessity of grouping customers with price groups in customer master data (1:1 relation).
• Ability to add multiple price lists to a price group.

How are your points 1-4 dependent on each other? Is the hierarchy as listed?
My Notes on your points:

1. The easiest way would be to maintain the sales price in the sales part, as “the base”. If no price list/contract/campagne is found, the sales price is taken from the sales part page.
   OR
   If you want to use a cost set for sales price calculation, then base price + price list is needed in this case. Asign a price group with this price list to customer master data.
2. This price would take precedence over the one at point 1, right? Add this price list to Customer/Order/Price list per Price Group, adhering to the pricing hierarchy.
3. Since the IFS pricing does not go down the addess level of a customer, this is a hard one. How is a customer with several regional locations organised in your customer master data? One or multiple customer IDs? Maybe splitting makes sense…?
   Depends on sales parts in point 1 and/or 2 customer agreements needed here.
   To keep an overview in the agreement it is the best to have only one customer agreement per customer.
4. How do you invoice projects? Project invoice or “normal” customer invoice? I am not aware of the possibilities with project invoicing.
   Since a project is time-limited/ special condition, I would make a customer agreement. Also here, depending on previous points, a campaign may be necessary as the next higher level of hierarchy if the sales part is listed in an agreement at point 3.

I hope my input helps. Have a good day ahead!

Best, Lidija

Thanks for the reply @LKACH! I am a colleague of Christian so we are both very invested in this topic. 

 A few follow-up questions/clarifications on bullet 3 & 4:

3. Since the IFS pricing does not go down the addess level of a customer, this is a hard one. How is a customer with several regional locations organised in your customer master data? One or multiple customer IDs? Maybe splitting makes sense…?
   Depends on sales parts in point 1 and/or 2 customer agreements needed here.
   To keep an overview in the agreement it is the best to have only one customer agreement per customer.  
   1. We have set this up as 1 customer however we are debating if it is necessary to split the customer up into several customers. However, this then comes with the question if we should use a customer hierarchy or not and how this will affect our business control and financial follow-up that is based on our current 1 customer set-up.
4. How do you invoice projects? Project invoice or “normal” customer invoice? I am not aware of the possibilities with project invoicing.
   Since a project is time-limited/ special condition, I would make a customer agreement. Also here, depending on previous points, a campaign may be necessary as the next higher level of hierarchy if the sales part is listed in an agreement at point 3.
   1. We are using work orders (and not projects) and sending an invoice through a invoice preview on the work order and then a customer order when we send it out to our third party distribution partner. DId that make sense? The current suggested solution we are exploring is using a service contract and connect a customer agreement when these “adhoc” projects occur. 

A quick chip in here … Could you use “Invoice Customer” so you have your regional customers set up as separate customers but all have the same “Invoice Customer” ?

Hi @PRODQ !

Thank you for jumping in! This may be a solution, however we are in IFS cloud so I do believe this may be a different structure.

If we were to set-up several customers we have been advised to set-up several regional customers but use the “main” customer’s invoice information on the invoicing tab on the customer card. Maybe this is the same solution but with cloud terminology?

Do you have any insights in how we are limited when it comes to several customers with the same association no? I am a bit worried that we are setting up “dummy” regional customers and we do not have all the necessary data to do this. 

Best regards, 

Lydia

I would agree on not being comfortable with “dummy” customers.  I’m hoping the structure is the same as we are currently heading towards Cloud!

I think you’re right about Cloud terminology and we are talking about the same thing.  

Just looking at an example, the ‘Invoice Customer’ looks like it’s still there as I’d expect.  

There’s also something called “Customer Hierarchy” which I’ve just spotted.  Help page reads as follows.  I don’t know if this is something for you to investigate?

 

Handle Customer Hierarchy

Explanation

A customer hierarchy is a graphical method of grouping companies for review. The parent company will be on the top level with all affiliated companies beneath in the required number of levels. Note that a customer can be connected to only one hierarchy.

You can create new hierarchies and include new companies in an existing hierarchy. You can also remove a separate company from a hierarchy as well as an entire branch or sub-branch. It is also possible to convert an existing hierarchy into a new one consisting of a branch of the original one by selecting a new root company, i.e. the tree structure above the new root company will be deleted.

The customer hierarchy is used to retrieve price and/or discount information if it is lacking in the customer entry itself. The retrieval will follow a general priority order.

Prerequisites

All companies that will be included in a customer hierarchy must have been entered as customers.

System Effects

A tree structure of a group of companies is created.

In our test Cloud environment we have multiple real customers with the same Association number.  I’m not sure if there’s any functionality driven off it.  It may just be an ‘information’ field

Linda

Dear Lydia

Your first point one. Yes you are right, the financial follow-up is affected if case of splitting the customer. In accounts receivables there is a filter option called “Customer Group” where you can organise you search results and print statement of account. But that is certainly not everything and you would have to check throughout how it could affect your analyses here.

Your second point. If you manage your projects with WO then it is well worth testing this scenario with service contracts, good idea!

Best, Lidija