2

Since the address is a standard field, I'm assuming this process is pretty standard in setting it, but just in case, here's a very explicit explanation of how I'm updating it.

There are no standard fields on the Account for city, street, ZIP, etc...just the Address field. The only way to update this record in the interface is to double click the field area and it pops up with text fields for the street, city, ZIP, etc.

I want, on this update (After), to do other things. After some debugging, I found that when I update it and do system.debug(acc.BillingStreet), the street that I updated it to prints out correctly -- side note: BillingStreet doesn't appear on the list of standard fields...-- however, when I try system.debug(acc.BillingAddress), which should be all the components together, it's always null.

I can't imagine why it is null since it's the very thing that I'm updating. Here's the code for the trigger, but the issue has something to do with the address field, truly.

    trigger udtInvAddress on Account (After Update) {

    List<Order2__c> invoices;
    System.debug('This should go, at the very least');

    if(Trigger.isAfter){
        if(Trigger.isUpdate){

            //go through all of the accounts that this trigger effects
            for(Account acc : trigger.new){
                System.debug('HOW ABOUT THIS...?');
                System.debug(acc.BillingStreet);
                System.debug(Trigger.oldMap.get(acc.id).BillingStreet);
                    //separate all of the components of BillingAdress field in the account
                    Address addr = acc.BillingAddress;
                System.debug('ADDR = ' + addr);
                    String AccountStreet;
                    String AccountCity;
                    String AccountState;
                    String AccountZip;
                    String AccountCountry;
                    //only update address if a new address is actually entered
                    if(addr != null){
                        System.debug('The address is not null, so assign values');
                        AccountStreet = addr.street;
                        AccountCity = addr.City;
                        AccountState = addr.state;
                        AccountZip = addr.postalcode;
                        AccountCountry = addr.country;
                    }
                    //Query to find all matching invoices
                    System.debug('IS THIS THE PROBLEM?');
                     invoices = [SELECT Billing_City__c, Billing_State__c, Billing_Street__c, Billing_zip__c, Billing_Country__c FROM Order2__c WHERE Account_Name__c =:acc.ID];
                    for(Order2__c invoice: invoices){
                        System.debug(invoice.ID);
                        //update all of the fields with the updated information only if the new information is filled in.
                        if(AccountCity <> null){
                            invoice.Billing_City__c = AccountCity;
                        }
                        if(AccountState <> null){
                            invoice.Billing_State__c = AccountState;
                        }
                        if(AccountStreet <> null){
                            invoice.Billing_Street__c = AccountStreet;
                        }
                        if(AccountZip <> null){
                            invoice.Billing_zip__c = AccountZip;
                        }
                        if(AccountCountry <> null){
                            invoice.Billing_country__c = AccountCountry;
                        }

                    }


            }

        }

        update invoices;
    }


}
  • so your requirement is if account address is updated, it should update fetched invoices, right ? – sf_user Jan 24 '17 at 14:53
  • Yes -- however, I believe it is doing that, that isn't the issue...the code was mostly for context -- the issue is that if you notice where I assign ADDR to the address field, thats where it's null, which is the problem I'm addressing (pun not intended, hah.). The very thing I am doing that makes this fire at all is updating the address field. Why is it null? – Natalie Spatharakis Jan 24 '17 at 14:59
  • 1
    Address is compound field, hence you cannot access it directly. – Raul Jan 24 '17 at 15:07
  • 1
    FYI- You have a query inside a for loop which is a bad practice. Currently I am trying to understand the problem. – Raul Jan 24 '17 at 15:08
  • You can simply use Process builder for this requirement – Santanu Boral Jan 24 '17 at 15:11
2

Approach 1

Since Address in Compound field, you can simply fetch each Address attributes from Account object from the SOQL query and update invoice records like this:

trigger udtInvAddress on Account (After Update) {
List<Order2__c> invoices;
if(Trigger.isAfter && Trigger.isUpdate){            
     invoices = [SELECT Id, Account__r.BillingStreet, Account__r.BillingCity, 
     Billing_City__c, Billing_State__c, Billing_Street__c, 
     Billing_zip__c, Billing_Country__c FROM Order2__c 
     WHERE Account_Name__c =:Trigger.newMap.keySet()];
    for(Order2__c invoice: invoices)
    {
        System.debug(invoice.ID);
        //update all of the fields with the updated information only if the new information is filled in.
        if(invoice.Account__r.BillingStreet <> null){
            invoice.Billing_Street__c = invoice.Account__r.BillingStreet;
        }
        //update other fields

    }
    update invoices;
}

Moreover, your query needs to be bulkified and would be outside of for loop.

Approach 2

The use case can be simply be implemented by Process Builder. In this below picture I have shown you how Invoice Billing Street can be mapped with Account's Billing Street via Reference.

Update Invoice

The Account Address attributes can be picked up in the PB during field mapping like this:

Account Address fields

Since, without writing code, this functionality can be achieved, I will go by Process Builder.

  • Pretty much covered what I was going to write. Also +1 for making sure that query was pulled out of the loop. My only additional comments are that compound fields require using API v30 or later, and though it doesn't appear to be documented anywhere, in my testing, compound fields are not made available in trigger context variables. If I had to guess why, I'd say that Salesforce probably did this to prevent people from trying to edit them. – Derek F Jan 24 '17 at 15:32
  • it is not in loop, just check this – Santanu Boral Jan 24 '17 at 15:37
  • I know, I said that your code does not have a query in a loop, whereas the provided code in the question does. – Derek F Jan 24 '17 at 16:05
  • Yes, thats true – Santanu Boral Jan 24 '17 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.