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

Hello community,

I'm exploring the new features of 10.1 (I know I'm not early :) ), especially the brand new "purchases" module.

My first thought was "wow Sugar is now going towards a full-blown ERP and now manages vendor purchases". 

Looking into the docs, I realise we're talking about customer purchases, in other words, orders. 

This generated new questions for me: 

  1. Why call this "purchases" when this term is mostly used for vendor purchases? "Orders" comes to mind more readily. In French it's even more disturbing as "Achats" is clearly the name of the team that handles vendors/procurement. I understand that from a customer's perspective they are indeed purchasing, but this tool is used by sales people who, well, sell :)
  2. For the moment I fail to see the added value of purchases vs RLIs. AFAIK records are not linked to the mother opportunity and do not have a status (ordered, delivery in progress, delivered, retired...). Is this interesting only for periodic orders, such as a monthly automatic renewal? Another use case I'm not seeing? 
  3. The automatic creation of purchases is great but my hunch is that most customers will not use them, so the "generate purchase" should be no by default. Easy enough to change, but it is going to cost minutes in most projects (or useless data storage and processing time). 

These are my thoughts, laid here for open discussion :)

Take care,


  • PLI in comparison to RLI looks like contract obligations versus forecasts. Those to be treated differently if someone estimates company value ;)

  • Hi ,

    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:,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!



  • 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.