About the Address Subrecord
The address subrecord has certain qualities that are unique. These characteristics can make the process of interacting with the address subrecord different from other subrecords. For details, see the following sections:
See also Scripting Transaction Shipping and Billing Addresses.
Billing and Shipping Addresses Can Be Sourced from Other Records
With most subrecord types, an instance of the subrecord is unique to the record where it was created. However, in some cases, a single address subrecord instance can be referenced by multiple records.
For example: You can create multiple addresses for an entity. If you later create a transaction for that entity, you can use one of the addresses defined on the entity record as the shipping or billing address for the transaction. For this reason, setting a value for a shipping or billing address is in some cases slightly different from the way that you set other address summary fields. For details, see Addresses Can Be Sourced from Entity Records.
The Address Subrecord Can Have Custom Forms
Compared with other subrecords, the address subrecord is unique in that you can create custom entry forms for it. For example, you may want to create custom forms for different countries.
If your account has multiple address forms, and if you are not seeing the expected results, the reason could be related to the form. In particular, if your script is using dynamic mode, the first value you set on the subrecord form should be country. The reason is that if you set a value for country that differs from the default, the form resets when the country value changes. Therefore, as a best practice, set the country value first.
The Override, Phone, and Zip fields of the address subrecord are not exposed as search filters from the customer record.
Address Data Is Summarized on the Parent Record
With most types of subrecords, details that you enter on the subrecord are not summarized on the parent record when you view it in the UI. You have to open the subrecord in its own window to view its data.
The address subrecord is an exception to this rule. After you enter details into an address subrecord and return to the main view of the record, typically the system displays a summary of the details you entered. For example, in the following screenshot, subrecord data is summarized in the Address column.
This summary represents the value of one field on the address subrecord called addrtext. This value is created through the use of a template and generated from other values entered on the subrecord, such as the values for the city and state fields. Each address form can have its own template for determining the addrtext value. You can view the template for any address form by viewing its record at Customization > Forms > Address Forms.
An error in the addrtext field does not necessarily signify an error in the other values saved to the subrecord. If an error exists in the summary, review the template to make sure that it is capturing the values you intend.
To view the values for all of the fields on the subrecord, do one of the following:
-
Use one of the following methods to retrieve the subrecord: getCurrentSublistSubrecord(), getSublistSubrecord(), or getSubrecord(). For an example, see Retrieving an Address Subrecord Example.
-
In the UI, open the subrecord for editing in its own window.
Client Scripts Attached to the Address Subrecord
Client scripts attached to address subrecords on transaction records may execute on the server and on the client. Be aware that this is expected behavior. For logic in a client script attached to an address subrecord to execute only one time, wrap the logic in an if statement that immediately exits the script on the server. For example:
if (typeof document!=='undefined') {
// client script logic
}
If a client script attached to an address subrecord loads the N/currentRecord Module, the script fails. Although you cannot load the N/currentRecord Module in a client script that is attached to the address subrecord, you can obtain currentRecord from context.currentRecord:
define([],function(){
function saveRecord(context){
var currentRecord = context.currentRecord;
return true;
}
return {
saveRecord: saveRecord
}
});
See currentRecord.CurrentRecord.
You can attach client scripts to custom entry forms, custom transaction forms, or custom address forms. See Attaching a Client Script to a Form.
For information about client scripts, see SuiteScript 2.x Client Script Type.