New Purchases feature in Q3 2020 10.1: name & added value

Hi Damien Pochon,

Thank you for asking an insightful question and prompting discussion. It is a good question. Full disclosure, I'm not in the Products group, but this is my take:

1. I'm sure you already know this - but you are free to rename any module to anything that you prefer: https://support.sugarcrm.com/Knowledge_Base/Studio_and_Module_Builder/Editing_a_Modules_Labels/#:~:text=Navigate%20to%20the%20Developer%20Tools,for%20the%20module(s).
   
   A consideration as to why not call it Orders to begin with - could be to avoid visual conflict with the number of systems which already have a custom module for Order data.
   
   Another reason could be to deliberately to avoid it being confused with order data - as orders do typically have the fields you've referenced, e.g. a status.
   
   
2. RLIs do not always represent Purchases - since every Opp can generate them. Only the Purchases module can be considered an accurate (within the context of the CRM) record of what the customer has bought.
   
   Creating a report of what a customer has bought should be easy - it should not require filters against Opp status etc, which is what reporting with RLIs currently requires.
   
   
3. To avoid automatic generation, you can turn off the "Generate Purchase" field in the Product Catalog for all your products. All RLIs inherit that field and use it for automatic generation. This is definitely recommended for scenarios where an ERP integration has been setup, or as you said, in scenarios where you don't want to use it.

The more fundamental undercurrent in your questions is this: why did we even make this module? Many CRM implementations have an ERP integration and bring in sales data already, so it is already possible to analyse customer spend by category already. Why add something that most people who value it, would already have?

What the Purchases module does is create a consistent schema for all such integrations in the future - which means if we want to run Sugar Discover over it to identify anomalies, or our new AI acquisition to make predictions, the data is already in a recognisable format. One of the big value points of a time aware system is how quickly you can gain insights from that data. A consistent, recognisable schema makes that a lot easier, since we know where the data is, how it'll look and be able to configure our models accordingly.

I'm definitely open to discussing this and understanding how everyone else sees this too!

Regards,

Adam

Hello Adam,

Thank your for your detailed answer. This helps a lot :)

Let's continue the discussion a little bit: 

1. Naming : 

Yes I can rename & add fields based on our customer's needs. I just felt that the naming and data structure we're not entirely clear out of the box. We clearly see that Sugar is on a journey from "all-purpose CRM framework" to "turnkey but customizable CX software". I for one welcome the change in Sell and Serve (not in Enterprise, though), but the needle needs to be set somewhere: how turnkey should it be? If it's "very turnkey", then most of the work should be done already based on best practices and the vision of the platform. 

Finally, how is the term "orders" more confusing with other parts of the system than "purchases"? 

2. RLI vs purchase: 

If an object does not bring additional information, then it's useless. I'd rather filter on RLI status than query another object. RLIs *should* be accurate, or the sales forecast wont.

It's a topic we're frequently discussing with our customers for, for instance, contracts. Should you put contract information on the opportunity or on a separate object? Most often, we use a contract when a different user/role needs to work on the object or there can be several contract for the same opp or several opps for the same contract. 

In the case of purchases, It was not entirely clear if there would be several purchases for the same opp.

Also I still don't understand why the Purchases and PLIs are not related to the original opp? There isn't even a reference for the PO? 

3. Automatic generation

Thanks for the tip, I'll look into this one. 

Hi Damien Pochon, apologies for missing your response here - only noticed it with Vincent replying below too.

1 - you are right in saying there is a balance to be found between being a prescriptive good/best practice, and being flexible enough to support a variety of business models. Upon further reflection, and a month more of customer conversation, I haven't found people to be finding the wording confusing (most people I've spoken to are happy with the idea that Orders belong in an ERP or a fulfillment system), so I think for now, I'm going to keep listening on this front.

2 - an advantage of a separate object here is that for customers who have an ERP integration to bring in actual sales, there is a specific place to put the data, with the knowledge that you're not touching modules which are used for forecasting/quote generation purposes... i.e. clear business demarcation around what purpose the different modules have.

Damien Pochon said:

Should you put contract information on the opportunity or on a separate object?

Contracts are an interesting topic to explore - and worthy of its own thread really - I've seen many different implementations of this concept, including the variants you've mentioned. I've seen that legal/support/finance often have an interest in this data, so depending upon the needs, the right place in Sugar is variable in my opinion, and there is not a consistent "always the right answer" answer.

Damien Pochon said:

In the case of purchases, It was not entirely clear if there would be several purchases for the same opp.

A single Opportunity can definitely result in multiple Purchase records. Let's say you sold a single opportunity for 10 CRM licenses and a support SLA. For many companies, both would be considered annually recurring services, and if the Product Catalog was configured accordingly, when you close that Opp, the related Account would gain 2x Purchase records and 2x PLIs as well.

I cannot speak to why that relationship with the Opp is not set if the records were generated automatically from it... but I don't think PO numbers belong on it - again I see that as being something the ERP/accounting package should own. 

Regards,

Adam

Hi Damien Pochon, apologies for missing your response here - only noticed it with Vincent replying below too.

1 - you are right in saying there is a balance to be found between being a prescriptive good/best practice, and being flexible enough to support a variety of business models. Upon further reflection, and a month more of customer conversation, I haven't found people to be finding the wording confusing (most people I've spoken to are happy with the idea that Orders belong in an ERP or a fulfillment system), so I think for now, I'm going to keep listening on this front.

2 - an advantage of a separate object here is that for customers who have an ERP integration to bring in actual sales, there is a specific place to put the data, with the knowledge that you're not touching modules which are used for forecasting/quote generation purposes... i.e. clear business demarcation around what purpose the different modules have.

Damien Pochon said:

Should you put contract information on the opportunity or on a separate object?

Contracts are an interesting topic to explore - and worthy of its own thread really - I've seen many different implementations of this concept, including the variants you've mentioned. I've seen that legal/support/finance often have an interest in this data, so depending upon the needs, the right place in Sugar is variable in my opinion, and there is not a consistent "always the right answer" answer.

Damien Pochon said:

In the case of purchases, It was not entirely clear if there would be several purchases for the same opp.

A single Opportunity can definitely result in multiple Purchase records. Let's say you sold a single opportunity for 10 CRM licenses and a support SLA. For many companies, both would be considered annually recurring services, and if the Product Catalog was configured accordingly, when you close that Opp, the related Account would gain 2x Purchase records and 2x PLIs as well.

I cannot speak to why that relationship with the Opp is not set if the records were generated automatically from it... but I don't think PO numbers belong on it - again I see that as being something the ERP/accounting package should own. 

Regards,

Adam