Configurator Document Rules

Hi everyone,
We have twenty fairly complex configurators, all of which, because we work in the quote most of the time, generate a cost and price by querying the part, opr tables etc in UD methods. My problem is that these costs are stored in UD fields on the quote for reporting purposes mainly, so that we can see that the costs that the configurator calculated match the costs that the system creates once the jobs are created. This all works fine all the while the configurators are run individually, but if one is called as a child, in the BOM of another the values stored in the UD fields are way out. My question is, as I am storing these values via the document rules, firstly is this the best way? and secondly which configurator’s document rules are the ones that are stored, should I only trigger one set of document rules in situations like this?
Any help / advice would be much appreciated.
Thanks

Adrian.

Hello Adrian,

Have you looked at what is in the PcInValue table? Create a quick BAQ, browse the table and see if that doesn’t already have what you want, including the values at each level. Document rules update documents (Orders, Quotes, Jobs, etc.) but the actual values of each input are stored in this table. This is how Epicor knows the previous values when one runs the Reconfigure routine.

Mark W.

Hi Mark,

Thank you for your response. I must admit I have not tried that. I seem to
remember a long while ago an Epicor consultant advised against using the Pc
tables. In your experience is there any risk in doing so?

Best regards

Adrian.

Hi Adrian,

I don’t believe there is any risk to reading the PC- tables for reporting purposes like you would like to do. In the Vantage and E9 era, I heard of users writing their own configurator GUIs (or using an online one since Epicor didn’t have a web-configurator at that time) and they would populate the PC-Input tables. At that time, one might get away with that but I wouldn’t to it in E10.

Separately, using the Configurator to create a PartRev didn’t store the results of the configuration in the PcInputs table but that may have changed in 10.1.

Cheers,

Mark W.

Thanks for your help and advice Mark. Much appreciated.

Adrian.