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

Question

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: 
 
 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 :) 
 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? 
 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, 
 Damien

Damien Pochon · Answer

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