System-generated internal IDs and custom external IDs can be shared among records
belonging to the same high-level group. Therefore, when referencing a record using RecordRef, providing the system internal ID or custom external ID without specifying the record type is sufficient to uniquely identify the record within a given group.
The following list provides examples of these high-level groups and some of the records belonging to each group:
•
Entities: contact, customer, employee, group, partner, vendor•
Transactions: invoice, journal entry, customer deposit, check•
Items: inventory item, markup item, payment item, serialized inventory item•
Activities: task, event, phone call•
Support: campaign, case, event, solution, taskWorking with Fields in Web Services
NetSuite records contain standard body fields and custom fields. Standard fields are those that come with all NetSuite accounts. In Web services, a record’s standard body fields are its attributes, for example: Customer.email, SalesOrder.salesRep. Standard fields must be of one of the following logical types.
Vendor Payment Win Loss Reason Record Type
Type Description
String Corresponds to the xsd:string type in the XML Schema Int Corresponds to the xsd:int type in the XML Schema Double Corresponds to the xsd:double in the XML Schema
Boolean Corresponds to the xsd:boolean type in the XML Schema and has valid values of true or false. If not explicitly set to either true or false, then set as false.
Datetime Corresponds to the xsd:dateTime type in the XML Schema which conforms to the ISO 8601 standard.
RecordRef Corresponds to the RecordRef type in the XML Schema. References an nsKey value for any other record in the system including system defined constants that are controlled by the system.
Enum Corresponds to a specific type defined as an enum in the XSD that represents system constants that are also available in the UI.
Records, Fields, Forms, and Sublists in Web Services
Working with Fields in Web Services
52
Custom fields are those that have been created by NetSuite users to customize their accounts. Custom fields can be added to an account using SuiteBuilder point-and-click customization tools. They can also be added through the SuiteTalk add operation. Custom fields must be one of the types defined in Custom Field Types. Note that on business records, custom fields are contained in the customFieldList property. For more details, see CustomFieldList.
Also note that if you are getting unusual results in your Web services queries, it may be that a standard field has been customized. Additionally, a record can have any number of custom fields that may differ in their behavior when manipulated through Web services, versus when they are manipulated through the NetSuite UI.
The following are some general guidelines to consider when working with both standard and custom fields.
•
Regardless of whether a standard field is set as mandatory in a custom form, the “requiredness” of the field is the same as it was originally (entry forms only -- transaction forms honor custom requiredness settings). For more information on NetSuite form types, see Custom Forms in the NetSuite Help Center.•
Customizations made to standard fields are not honored in Web services. The field behaves as it would with no customization done. For example, even if a standard field is set as disabled, it is still settable via Web services.•
If a standard field is set to NOT show in the UI, it is still settable via Web services. In the UI, these fields are not settable although the values are returned in search results.•
Custom display only (inline) and disabled fields are settable even though these areNOT settable through the UI. For information on field display types, see Setting Display Options for Custom Fields in the NetSuite Help Center.
•
Custom hidden fields are gettable and settable in Web services. In the UI, custom fields defined as hidden are not settable and are not returned.•
Defaulted fields that are set to blank on a Web services update will stay blank on update.Note:
If you are unfamiliar with NetSuite custom fields, it is recommended that you see Custom Fields in the NetSuite Help Center. This section describes the purpose and general characteristics of each custom field type, which will help you when working with the SuiteTalk customization API (described in Customization in the NetSuite Help Center).WsEnum Corresponds to a specific type defined as an enum in the XSD that represents system constants that are NOT available in the UI.
List A List references a type that is a list and should be explicitly defined in the in the XML Schema as a type. A list can either be null (if it’s an optional field), or it must contain at least one entry unless otherwise noted.
CustomFieldList
Most business records that are exposed through Web services have one or more custom fields attached to it. These custom fields are contained in the customFieldList property on each record. The customFieldList property is an array of CustomFieldRef.
Note:
The Disable Mandatory Custom Field Validation preference determines whether a required custom field with no data provided throws an error, or is accepted as a null value. For more information on this preferences, see Setting Company-wide Preferences.The following is an example that contains an excerpt of the SOAP body for a list of custom fields. It shows that the record associated with the SOAP contains two custom fields, both of which are referenced in the customFieldList property on the record.
<customFieldList>
<customField internalId=”CUSTEVENT1” xsi:type=”IntCustomFieldRef ”> <value>12</value>
</customField>
<customField internalId=”CUSTEVENT2” xsi:type=”MultiSelectCustomFieldRef ”> <value>peter</value>
<value>paul</value> <value>mary</value> </customField>
</customFieldList>