function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Piyush Sharma 6Piyush Sharma 6 

Opportunity trigger error, Incompatible element type Id for collection of Account

Hi
I have created a trigger but it giving me this error on Line:7.
Error:Incompatible element type Id for collection of Account
Please help.
trigger getOptyAmt on Opportunity (after insert, after update) {
    	List<Account> accntId = new List<Account> ();
    	Integer optyAmt;
    	Account accId;
    for(Opportunity opty: Trigger.new) {
        if(opty.AccountId != null) {
            accntId.add(opty.AccountId);
        }
    }
    for(Opportunity opty: [select Id from opportunity where account in: accntId]) {
        optyAmt = opty.Amount;
        accId = opty.AccountId;
        accId.Total_Opportunity_Amount__c =+ optyAmt;
    }
}

 
Best Answer chosen by Piyush Sharma 6
Amit Chaudhary 8Amit Chaudhary 8
Hi Piyush Sharma 6,

Can you please let us know what you are try to do with above trigger. I hope you are try to rollup Opp Amount on Account If yes then there are two option for same
1) Create rollup summery field no need to create trigger
2) Try below code.
trigger RollUpSummery on Opportunity (after delete, after insert, after update) 
{
    Set<id> SetAccountId = new Set<id>();
    List<Account> AccountToUpdate = new List<Account>();

    if(Trigger.IsInsert || Trigger.isUpdate)
    {
        for (Opportunity opp : Trigger.new)
        {
            SetAccountId.add(opp.Accountid);
        }
    }
    if ( Trigger.isDelete) 
    {
        for (Opportunity opp : Trigger.old)
        {
            SetAccountId.add(opp.Accountid);
        }   
    }

    for (Account acc : [select Id, Name,Total_Opportunity_Amount__c, (select id,Amount from Opportunities) from Account where Id IN :SetAccountId]) 
    {
        Integer sumOpp = 0;
        List<Opportunity> lstOpp = acc.Opportunities;
        for(Opportunity opp : lstOpp)
        {
            sumOpp= sumOpp+Integer.valueOf(opp.Amount);
        }
        
        acc.Total_Opportunity_Amount__c= Decimal.valueOf(sumOpp);
        AccountToUpdate.add(acc);
    }
	if(AccountToUpdate.size() > 0 )
	{
		update AccountToUpdate;
	}
}
If you want to learn about Trigger then please try below trailhead module
1) https://developer.salesforce.com/trailhead/module/apex_triggers

Please check below post Trigger best pratice
1) http://amitsalesforce.blogspot.in/2015/06/trigger-best-practices-sample-trigger.html

1) One Trigger Per Object
A single Apex Trigger is all you need for one particular object. If you develop multiple Triggers for a single object, you have no way of controlling the order of execution if those Triggers can run in the same contexts

2) Logic-less Triggers
If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org.

3) Context-Specific Handler Methods
Create context-specific handler methods in Trigger handlers

4) Bulkify your Code
Bulkifying Apex code refers to the concept of making sure the code properly handles more than one record at a time.

5) Avoid SOQL Queries or DML statements inside FOR Loops
An individual Apex request gets a maximum of 100 SOQL queries before exceeding that governor limit. So if this trigger is invoked by a batch of more than 100 Account records, the governor limit will throw a runtime exception

6) Using Collections, Streamlining Queries, and Efficient For Loops
It is important to use Apex Collections to efficiently query data and store the data in memory. A combination of using collections and streamlining SOQL queries can substantially help writing efficient Apex code and avoid governor limits

7) Querying Large Data Sets
The total number of records that can be returned by SOQL queries in a request is 50,000. If returning a large set of queries causes you to exceed your heap limit, then a SOQL query for loop must be used instead. It can process multiple batches of records through the use of internal calls to query and queryMore

8) Use @future Appropriately
It is critical to write your Apex code to efficiently handle bulk or many records at a time. This is also true for asynchronous Apex methods (those annotated with the @future keyword). The differences between synchronous and asynchronous Apex can be found

9) Avoid Hardcoding IDs
When deploying Apex code between sandbox and production environments, or installing Force.com AppExchange packages, it is essential to avoid hardcoding IDs in the Apex code. By doing so, if the record IDs change between environments, the logic can dynamically identify the proper data to operate against and not fail

Let us know if this will help you

Thanks
Amit Chaudhary

All Answers

Amit Chaudhary 8Amit Chaudhary 8
Hi Piyush Sharma 6,

Can you please let us know what you are try to do with above trigger. I hope you are try to rollup Opp Amount on Account If yes then there are two option for same
1) Create rollup summery field no need to create trigger
2) Try below code.
trigger RollUpSummery on Opportunity (after delete, after insert, after update) 
{
    Set<id> SetAccountId = new Set<id>();
    List<Account> AccountToUpdate = new List<Account>();

    if(Trigger.IsInsert || Trigger.isUpdate)
    {
        for (Opportunity opp : Trigger.new)
        {
            SetAccountId.add(opp.Accountid);
        }
    }
    if ( Trigger.isDelete) 
    {
        for (Opportunity opp : Trigger.old)
        {
            SetAccountId.add(opp.Accountid);
        }   
    }

    for (Account acc : [select Id, Name,Total_Opportunity_Amount__c, (select id,Amount from Opportunities) from Account where Id IN :SetAccountId]) 
    {
        Integer sumOpp = 0;
        List<Opportunity> lstOpp = acc.Opportunities;
        for(Opportunity opp : lstOpp)
        {
            sumOpp= sumOpp+Integer.valueOf(opp.Amount);
        }
        
        acc.Total_Opportunity_Amount__c= Decimal.valueOf(sumOpp);
        AccountToUpdate.add(acc);
    }
	if(AccountToUpdate.size() > 0 )
	{
		update AccountToUpdate;
	}
}
If you want to learn about Trigger then please try below trailhead module
1) https://developer.salesforce.com/trailhead/module/apex_triggers

Please check below post Trigger best pratice
1) http://amitsalesforce.blogspot.in/2015/06/trigger-best-practices-sample-trigger.html

1) One Trigger Per Object
A single Apex Trigger is all you need for one particular object. If you develop multiple Triggers for a single object, you have no way of controlling the order of execution if those Triggers can run in the same contexts

2) Logic-less Triggers
If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org.

3) Context-Specific Handler Methods
Create context-specific handler methods in Trigger handlers

4) Bulkify your Code
Bulkifying Apex code refers to the concept of making sure the code properly handles more than one record at a time.

5) Avoid SOQL Queries or DML statements inside FOR Loops
An individual Apex request gets a maximum of 100 SOQL queries before exceeding that governor limit. So if this trigger is invoked by a batch of more than 100 Account records, the governor limit will throw a runtime exception

6) Using Collections, Streamlining Queries, and Efficient For Loops
It is important to use Apex Collections to efficiently query data and store the data in memory. A combination of using collections and streamlining SOQL queries can substantially help writing efficient Apex code and avoid governor limits

7) Querying Large Data Sets
The total number of records that can be returned by SOQL queries in a request is 50,000. If returning a large set of queries causes you to exceed your heap limit, then a SOQL query for loop must be used instead. It can process multiple batches of records through the use of internal calls to query and queryMore

8) Use @future Appropriately
It is critical to write your Apex code to efficiently handle bulk or many records at a time. This is also true for asynchronous Apex methods (those annotated with the @future keyword). The differences between synchronous and asynchronous Apex can be found

9) Avoid Hardcoding IDs
When deploying Apex code between sandbox and production environments, or installing Force.com AppExchange packages, it is essential to avoid hardcoding IDs in the Apex code. By doing so, if the record IDs change between environments, the logic can dynamically identify the proper data to operate against and not fail

Let us know if this will help you

Thanks
Amit Chaudhary
This was selected as the best answer
NahuelNahuel

I would change 

List<Account> accntId = new List<Account> ();

for
List<Id> accntId = new List<Id> ();

And try again, your trigger should work. :) But as Amit mentioned, you can create a Rollup Field without code when using a Master-Detail relationship like Account -> Opportunities.

Good Luck!
IshwarIshwar
trigger getOptyAmt on Opportunity (after insert, after update) {
    	set<Id> accntId = new set<Id> (); // Changed from List to Set of Id
    	Integer optyAmt;
    	Id accId; // Changed from Account to Id
    for(Opportunity opty: Trigger.new) {
        if(opty.AccountId != null) {
            accntId.add(opty.AccountId);
        }
    }
    for(Opportunity opty: [select Id from opportunity where accountId in: accntId]) { // Changed account to accountId
        optyAmt = opty.Amount;
        accId = opty.AccountId;
        accId.Total_Opportunity_Amount__c =+ optyAmt;
    }
}

Try this. It should work.
Eric PepinEric Pepin
As Nahuel mentions above, you are strying to store an Id (opty.AccountId) in a List of Accounts (List<Account> accntId), thus the type mismatch.