You need to sign in to do that
Don't have an account?
map custom Lead lookup field (Product__c) to Oppty Product
I added a custom lookup field (Product__c) to the Lead object and need to map it to the Opportunity standard field. I have the code to add the Pricebook Entry to the Opportunity Line Item, but I cannot get the Product2Id from my custom lookup field (Lead.Product__c)
How do I get the Product ID (or Pri
trigger trgLeadConvert on Lead (after update)
{
for(Lead l : Trigger.new)
{
if(l.IsConverted && l.convertedOpportunityId != null)
{
Opportunity oppty = [Select o.Id, o.Description from Opportunity o Where o.Id = :l.ConvertedOpportunityId];
// add an opportunity line item...
OpportunityLineItem oli = new OpportunityLineItem();
oli.OpportunityId = oppty.Id;
oli.Quantity = 1;
oli.TotalPrice = 100.00;
// THIS IS I NEED HELP!!!!
//oli.PricebookEntryId = l.Product__c.PricebookEntry.Product2Id;
//oli.PricebookEntryId = l.Product__c.Id;
insert oli;
}
}
}
Pricebook Entry is a child of Products, and therefore can't be referenced the way you're attempting to do so. Instead, you'll need a trigger like this (tested):
Take a look and let me know what you think.
All Answers
Pricebook Entry is a child of Products, and therefore can't be referenced the way you're attempting to do so. Instead, you'll need a trigger like this (tested):
Take a look and let me know what you think.
sfdcfox,
Thank you very much! That worked very well. And the code is very simple, concise and makes sense.
The bottom line is that I need to load the IDs in memory & then do a "join" on those IDs, using the Map object (pricebookentries).
Question:
Why is the standard pricebook object called pricebook2?
Steps.
The standard pricebook and product objects were changed to Pricebook2 and Product2, respectively, because they made some changes to the API that were incompatible with older clients. In order to allow older clients to still use the API, they simply made a new copy of the objects with the appropriate changes. These objects replicate changes made in one to the other so they are always in synch. This all happened quite a few years ago, and is really quite unremarkable in nature. Just know that the "2" suffix exists for the sake of client compatibility.
You'll find that most triggers in salesforce.com will follow this very same pattern; I call this the "aggregate-query-update" design, and most triggers will follow this design fairly closely. Keep this code handy, as you'll probably be using a very similar design in future triggers. It seems you're catching on pretty quickly with triggers, so you shouldn't have too many more problems, but do feel free to ask if you need any more assistance. That's what the community is here for.
Thanks again, the "aggregate-query-update" pattern will is useful to know. Is there a site that lists all of the SFDC design patterns that I should know?
There's plenty of blogs out there; just check the users of the most frequent responses. I myself am working on a blog of my own, where I hope to eventually list all the patterns, and other tips and tricks. This method I outlined, however, is probably the most common design pattern. You can use it for rollup summary triggers, data copy triggers, data translation triggers (i.e. converting country names to standard formats), validation triggers, and other common use cases. It's only when you get to the esoteric cases where you'll find you need a different design pattern. I'm going to have to sit down and think about it, but I'm sure I myself will have a list available soon.