• Ben Gabrielson

    We currently do not provide Bulk APIs. We do provide bulk services which allows you to upload large data sets using files.via the admin UI and you can push those files to a SFTP server for scheduled/automated processing. 

    I encourage you to create an Idea in the Idea Lab if you need this functionality and provide the supporting use case,

  • Ben Gabrielson

    It's unclear how Step 3 is expected to work. It's also unclear if the Partners are involved in the Approval Process from Step 2. What is the expected order of operations for Order conversion and how is the Order signal initiated and where is it sent? 

    Between Middleware, BML and our REST web services this all probably straightforward technically, but the business requirements need to be clearer. 

  • Ben Gabrielson

    Hi Lisa, thanks for jumping in!

    Today, there is no way to have multiple active price books on a quote. This is an intentional and important restriction because CPQ is usually integrated to a CRM system and most all CRMs have the same requirement for Opportunities. If CPQ had a mix of products across price books you'd get errors when syncing. Price books are also used by many people to restrict which products can be sold together and mixing price books could violate those business rules. 

    There are likely a number of CPQ features that could be used instead of multiple price books to give you the desired result. In the CPQ world a price book != a catalog. 

  • Ben Gabrielson

    The devil is in the details but those integrations should not be difficult. Technically this is viable, both as a point-to-point connection or via some middleware like OIC, but it will need to be balanced against the performance penalty of multiple real-time call outs. There are ways to design the solution to manage that like doing a nightly sync or breaking the call-outs up across multiple discrete actions.

  • Ben Gabrielson

    CPQ can support all these use cases and features.

    CPQ can support all the pricing requirements that are supported in OM pricing. You can use CPQ as an order capture solution and directly push orders from CPQ to AR/Finanicals (and any other system). Detailing the benefits of CPQ vs. OM is probably a bigger discussion than can be addressed in this forum. The simplest answer is the CPQ Cloud is is a mature enterprise-class sales quoting/sales ordering system tailored to the needs of a typical front-office and/or digital commerce user.

  • Ben Gabrielson

    This use case is fully supported by CPQ and I suggest you review the REST API documentation.

    These headless approaches are inherently custom and the designs tend to be customer specific, so detailed documentation on how to address this specific use case likely won't be available. But this is in fact well supported. 

  • Ben Gabrielson

    Good news, thanks for the update. Account Integrations are not migratable today, so they probably we missing. 

  • Ben Gabrielson

    If you haven't already done so, you should log an SR in MOS. 

    Most likely the URLs that were created in the Setup and Maintenance page for the CPQ Integration were built incorrectly. 

    Or the CPQ site you are using does not have the proper BMContext settings to work with a Fusion environment. 

  • Ben Gabrielson

    I would need a bit more detail on the flow here to give a good answer, but one somewhat common solution for ETO orders is to create a configurator that contains the specs. The sales rep enters those specs and adds it to the transaction which create a model-line. The engineer can then review the spec and price it. Later, the order is submitted to the back-end system and properly engineered, this can then be pushed back to the quote via a reconfigure operation (or as a replacement line). 

    Some other solutions use a "placeholder" part for the initial quote and price instead of a model, but the flow would be very similar. 

  • Ben Gabrielson

    Attached is a screenshot if the Oracle Adapter and it's CPQ extension package installed into a demo org. The customer can install the packages themselves in a sandbox org and see it first hand if they require. 

  • Ben Gabrielson

    It has passed. 

  • Ben Gabrielson

    If you haven't already done so, please log an SR for these 2 issues.

    We have tested and have never encountered issues with tracking protection. We're using an industry standard implementation of OAuth 2.0 here which should not trigger any filters. We certify this on the latest version the most common browsers as part of each release.

    The issue with user driven token generation should also be investigated. This is feature is commonly used by most customers and we have not had reports of the type of failure and unreliability you're describing. It's possible that upgrading to the latest version of the package (7.2) will resolve the issue, but using Skype sessions to manage this seems totally untenable. 


  • Ben Gabrielson

    What do you mean by "registering the payment method?"

    Account and Contact details are stored in OSC. Quotes and Sales Orders in CPQ, AR/Billing in Financials. If you only want to indicate the desired method of payment and pass that on to Billing with the Order details, you have a couple choices. 

    1. Store that preference on the Account or the Contact (both work, depends on if all contacts use the same method for an account or if they can be different per contact) and populate that early in the sales process and/or account registration process. Then import that preference to CPQ when the Quote is created and store it in CPQ. When the Quote is converted to an Order, pass that preference on to the Billing system. 

    2. Populate the payment preference in CPQ during the Quoting process prior to finalizing the Quote and converting it to an Order and sending to Billing. In this way the payment preference is a Quote/Order property instead of a Account/Contact property. This may be better if contacts are likely to change their method of payment from order to order. 

    If you're seeking something more involved like full end-to-end payment processing, allowing customers to enter their payment details and storing those details, then that falls outside of the scope of both OSC and CPQ. 

  • Ben Gabrielson

    Generally we don't recommend adding products directly to the Opportunity in CRM when using CPQ. CPQ is your product master and manages all the eligibility, pricing and validations for products to ensure the sales rep can only sell the items the business rules allow. 

    OSC does require that Revenue Lines exist as products in PIM so you must sync your parts from CPQ to PIM (or vice versa) before you can sync quotes/lines to your opportunities/revenue lines.  But users should not be adding products directly to the Opportunity and bypassing CPQ. 

    You can add Opportunity Lines using the Sales Catalog in OSC if you really want to, but this will require customization and duplicate maintenance to support things like importing revenue lines to CPQ, two-way sync of lines between OSC and CPQ, redundant checks on product eligibility/compatibility, redundant pricing calculations and/or real-time integration to the CPQ rating/pricing engine from OSC, etc. 

  • Ben Gabrielson

    Hi Heidi, looks like we forgot to get to this question in the session. Answering here so you have it. 

    1. This is available and will be posted to MOS very soon. 

    2. Dynamics supports 2 types of Opportunity Products, Price List Items and Ad Hoc items. The standard integration syncs all products as Ad Hoc items so the mapping between CPQ Parts and Dynamics Products is unneeded. In the next update we're going to document the process for manually creating and mapping Price Lists to CPQ Parts using the Partner Part ID fields in CPQ. Once that mapping is in place you can sync parts as Price List Items. This is possible today but requires additional implementation work and is not included in the standard package we provide. 

    3. Technically no. The BML integration can write pretty much anything to the Opportunity Products. The standard integration assumes that you are writing all your Quote Lines and nothing more, but it can be extended to sync items imported from another system in addition to CPQ Lines. Or you can sync those 3rd party parts to CPQ as ad hoc items and sync them to Dynamics. BML makes this really flexible. 

    4. There is no limitation on the entities that you can reference. We include mappings for those entities you reference, but you can add any entity here by populating that column in the data table. 

    5. This process is manual, but it's straightforward. Simply use a web service or bulk data services to create and update the records in both systems to populate the external ID values. There's a Oracle Quote entity in Dynamics that will need to be created and hung off the existing opportunities that the CPQ Transaction will point to and vice versa.