I’ve been asked if we can do a cost + for pricing on a configured item.
So I suspect I’ll need to loop through the BOM using LINQ to get the cost of the materials and add to that number. It’s too bad we can’t get at the component cost as pricing is already there but oh well.
Has anyone done this and do you have the LINQ for it? I don’t really have an idea on where to start for this and I’m relatively new to LINQ.
Thanks
Most users do this in the Quote. They would do a Get Details in the Quote and after your Keep-When rules run, you can see the component costs and mark up the Quote from there. You’d have to do all the Keep-When logic in your Configurator and then get the costs through a UD Server Method.
Mark W.
Thanks Mark, but what happens if you don’t have to quote it first? Sounds like this way would force you to start with a quote?
Um, not to sound snarky but isn’t this what they’re doing? 
I mean, the Quote Details with the Manufacturing Details is really a nice tool to have. If you get the order, it’s easy to template and move to production.
Also, by using a Quote, you can copy the line down (configuration and all) and do several what-ifs…
Kind of but not always. Some of the customers have been ordering for so long that they don’t worry about a quote and just send in a PO or call with order details. But that may change if we go this route.
You’re right about everything, but we just don’t use those things like what-ifs. And we also tend to copy orders/lines.
We use the Quote module but NEVER send a quote out from it - OK, maybe spares. We just use it as a tool to check calculations. But our deals are big so we quote on nice heavy paper! 
I’m going to echo @Mark_Wonsil on this, completely. We do cost+ and have built in lookups and code into the configurator so the reps can see the cost/margin estimates from inside the configurator. While it looks nice, it is a total pain in the butt when working on them.
We send out quotes and we take PO’s for long standing customers, but our reps always do a quote, no matter what. All of our reporting for estimates/actuals and margins are based on the quote ‘get details’ data and the actual revenue and production costs.
And because everything that we sell is configured, we use quote entry as the configurator launch point. Converting to an order is a couple of clicks and while we have two folks who really don’t like it, every other aspect of the process is better/easier for it.
I personally would suggest that you build a little bit into quote entry rather than doing a BOM query.
If you revision (or modify MOM/BOMs at all), the quote/configurator data set will maintain revision data so your history will not get muddled up if you MOM/BOM changes next month and you are doing YTD reporting.
This is great info.
Thank you
Say you do do a rev change and you want all the older quotes to be updated, how do you handle that?
There is no mechanism to update ‘history’ when you alter a configurator. A quote simply has the configurator data set associated with the configurator at the moment it was configured. If you alter the configurator, you would need to re-open that quote and run the configurator again.
We took a painful amount of time to create a ‘core’ configurator data set that would never change, and that was common across all of our products (with only a minor amount of decoding at the BAQ level). The rest of the dataset for each product was specific to that product. That process then allows for consistent reporting even when we alter the configurator.
And then there is the giant denormalized data table we maintain for adding the configuration data to the EDA cubes and such (because all our sales reporting has to contain some of the configurator data) - but that’s a different topic.
Yes. That IS another topic as configuration data (or Inspection Data) is not yet available to SaaS customers since the XML fields are not exposed to the BAQ tooling. We spoke to @rich about it at Insights and waiting to hear what possible remedies there might be for the Cloud folks.
I forget - can you guys write SQL to your DB and fill a UD table?
If you can, there are two ways you can get around it and we can discuss both.
The problem is that because the configuration data set is user-defined, there is no generic way to parse the data sets across parts, part revisions, configurator revisions, etc. and therefore the data is useless in queries unless you have a fairly normalized data set like us.
I don’t think Rich or the guys will have anything to offer any time soon. I really hope they can come up with something, but it would almost have to be a new data model for the configurator data an a different storage/retrieval system in order to make it BAQ accessible.
Oh, I can certainly put the inputs into a UD table but then we’re right back to having the old PCInputValue table and storing everything twice. 
Right now, we’re stuffing “critical” inputs into the QuoteDtl to get us by but I’d like to do what you’re doing - how often is X selected, etc. Rich was actually looked surprised by the issue. He could think of a few solutions off the top of his head but he didn’t like any of them. I’m sure one was to create a view for every SaaS configurator use and use the XML syntax of SQL, which is what many on-prem users do. I understand the efficiencies of the new method but if cloud is the future for Epicor then they should be more like Microsoft and develop #cloudfirst.
Yep, twice it is, but I look at it differently. The PCValueSet tables hold the data for Epicor to work with. My UD table is de/re/normalized to be the data I need for reporting. The table is updated nightly and fields are calculated, parsed, converted, etc. so that my report BAQ is basically a giant select/filter.
It may be ‘twice’ but it’s not the same data 
And having a view for each configurator data set - no thank you. With 40+ data sets, that is a maintenance nightmare given the way our configurators change so often. I like our ‘common’ data set model and twice-stored data. It really does make reporting so much easier with little or no maintenance at all.
Hi Everyone, I’m finally back to to this piece. I’m able to get the standard costs out of the QuoteMtl using LINQ but only after running Mfg Details >> Get Details.
Does anyone know if Get Details can be triggered through a BPM or something else so users don’t have to do that step?
We’re trying to get to a total price calculation/field so that we can simply set the price for the line item without interaction.
Thank you
This is a little complicated as Mfg Details can ‘append’ and thus accumulate value giving you the wrong value. A proper BPM for this is on my to-do list also, but I can tell you that it 
looks possible by using the QuoteAsmImpl BO and calling the DeleteAll and GetDetails methods. You can run a trace file and use @josecgomez Trace Utility to view the trace and figure out the exact calls.
That’s actually exactly what I’m working on. I guess great minds think alike 
I haven’t worked with BO methods much before so I’m not sure if I’m supposed to read in the PreGetDetails and then do something with it?
I’ll just keep pushing forward and try to figure it out.
Yes we do. I started this months and months ago, but I think I overwrote it on my last Prod-To-Test copy. I can help if you get stuck. Our intention was to automate this process when a person marked the quote as quoted in order guarantee that it was done (some our our sales people forget things 
) and to make sure the values were correct when the Job was created. So my BPM will started by doing the DeleteAll first just to make sure.
I think you need to do the PreGetDetails in order to prep the DataSet record before you do GetDetails. Once you figure it out, post it here. There were a number of others who had asked about this before also.
It turns out the BO part of this is fairly straight forward. To have it happen at the right time, I have a pre-processing BPM on Quote.Update that enables a post-processing directive.
In Post-processing, I then call 4 BO Methods.
QuoteAsm.docx (470.9 KB)
This is excellent! And superbly documented 
!!! Thanks for posting.
As for the last bit, we need to figure out if we can send an extra parameter to the BO method for line# or part#. If we can’t then the data is in a data set, so I’m sure that one more widget of custom code could get us to the right DataSet.Row() that you need.
