Export and import account data

One of the Oracle Commerce items that can be exported and imported is accounts.

This enables you to export or import any accounts that you may have configured in your environment, as outlined in Import and Export Catalog Items and Inventory. When you export or import account data, you are generating or adding a list of accounts and their members.

Note that account-based storefronts may not be activated in your environment.

Account export and import fields

The following account-based commerce fields can be exported or imported:

Field Types	Description
Name	The name of the account.
Description	A description of the account.
Classification	This field is used to identify the type of account.
Account Type	Indicates the type of account such as company, division, department or group.
Contract Information	The information includes fields such as contract ID, terms, name, description, catalog, site and price list used.
Account Details	Account details such as DUNS number, logo, VAT reference number, unique ID and tax reference number.
Addresses	These fields include shipping and secondary addresses of the account. Note that the AccountV2 plug-in provides the format supported by the Integration Cloud Service.
Address type	An optional property. The value is validated when provided against the setup values. The shipping and secondary addresses include the address type field.
Payment Information	This field includes payment methods. Note that payment method types are not required fields, and therefore must be manually added to an account before shoppers can use the field. Additionally, the Boolean property, which is set to true by default, useAllPaymentMethodsFromSite, allows you to obtain the method from the site, as opposed to individual accounts. Note that if the property is set to true, it will override any methods set through the UI.
Shipping Information	This field includes shipping methods. Shipping method type is not a required field and must be manually added to an account before shoppers can use the field. The useAllShippingMethodsFromSite Boolean property allows you to obtain the method from the site, as opposed from individual accounts. Note that if the property is set to true, the existing shipping methods in the repository will be deleted and any shipping methods passed in during import will be ignored. When a new principal account is created, the property is set to true when the property has not been set and there are not shipping methods contained within imported data.
Members	Identifies members of the account.
Approval Settings	Indicates if the account has approval settings and delegated approval administrators. These settings are site specific.
Site Information	The siteOrganizationproperties property is a map that sets information for the site and organization, such as approval, contract, order price limits, delegated administrators and payment information, as described above.

Account import validation

During the import, the system verifies that the account name or the ID provided in the import file is actually in the repository. If the account name or ID in the given row is found, the repository item is updated with the data provided in the import file. If no data is found in the repository, a new account is created.

The following validations are performed for accounts:

• The DUNS number contains 9 digits.
• The account logo is valid.
• The contract ID is valid.
• Members added to the account have the profile type b2b_user.
• The phone number, company, address, city, state, country, and postal code have been provided.
• The postal code is valid.
• The country and state combination are valid.
• The name of the account cannot be “root.”
• The ID of the parent organization is valid.
• All site level fields are valid.
• The shipping and payment methods are valid and are associated with the site.
• The address type is validated against the setup values.

Approval settings during import

When accounts are configured with a list of approvers, specific validations occurs:

• A member cannot be removed from an organization if that member is the last active approver in the organization and approval is required, or the organization has at least one order that is either in the pending_approval or the pending_approval_template state.
• An organization’s order price limit cannot be updated when delegated approval management is active and the current value of the order’s price limit is different than the repository data.
• An organization’s approval required attribute cannot be updated if delegated approval management is active and the current value of the approval required is different than the repository data.
• You cannot activate an organization’s approval required attribute if no member of the organization has approval authorization.
• Approvals are site-specific and must reference a valid site.

Account email triggers during import

While performing an import, if a member is added or removed from an organization, an email is triggered, notifying you of the new status. To trigger emails during the import, send the specific email template as a parameter in the request payload. The following example shows how you would identify using an organization_assigned template:

{
  "fileName": "accountImport.json",
  "id": "Accounts",
  "format": "json",
  "mode": "standalone",
  "params": {
    "memberAssignmentEmailTemplate": "organization_assigned_v1"
  }
}

Account email triggers in multiple site environments

When working in a multiple site environment, an email is triggered during import that contains all of the site URLs related to the account and profile. Note that up to five sites are listed per account. Additionally, account changes, role updates, approval information, and password information is also included in the email, if applicable. All event information is displayed in a table that identifies the changes that occurred.

When you add a new member to an organization, an email with the name of previous organizations and roles, if any, are added.

Work with sub-accounts

Sub-accounts can be created and updated using the parentOrganization field. An account can have a single parent account, as well as its own sub-accounts. A principal account, or one that does not have any parent account, cannot inherit any properties. There is no fixed number of account hierarchy levels.

Note: When a new business account is created as a sub account (that is, as the child account of another account in an account hierarchy) there is no limit to the depth of the hierarchy, but sub accounts inherit account properties only up to the 14th level.

Sub-accounts can inherit the following derived organization properties if the sub-accounts properties are not specifically designed:

• derivedUniqueId
• derivedDunsNumber
• derivedOrganizationLogo
• derivedVatReferenceNumber
• derivedTaxReferenceNumber
• derivedDescription
• derivedType

Sub-accounts can be moved under other accounts if there are no circular references between the accounts. Additionally, a sub-account cannot be set to a parent account of itself. Each sub-account should have its ancestor organization details updated to provide account information. Note that a root account cannot be associated to another account either as a parent account or as a sub-account.

When working with shipping and payment methods in a sub-account and site pair, the sub-account-based methods and the use of site- based methods are either both inherited or not inherited. For example, the sub-account shipping methods and the use of all site shipping methods properties are both inherited together and cannot be inherited individually. The inherited state of the these sub-account and site pairs are determined by the Boolean properties useAllShippingMethodsFromSite and useAllPaymentMethodsFromSite. The values used in the API will override those set in the UI.

Account email triggers when account is deactivated

When performing an import, if an account is deactivated, an email is triggered to notify you of the change of the account’s status. To trigger emails during the import, process, send the specific email template as a parameter in the request payload. The following example shows how you would use the accountDeactivatedEmail template:

{
  "fileName": "accountImport.json",
  "id": "Accounts",
  "format": "json",
  "mode": "standalone",
  "params": {
    "accountDeactivatedEmailTemplate":"organization_deactivated_v1"
  }
}

Note that when an account has a contract for a specific site, moving an existing account to be a sub-account of that specific site will cause an email to be sent to all members of the sub-account. This is because the contract for the site is inherited. This also occurs if a new account is created as a child of an account using the API, and contacts are added in that same API call.

For detailed information on account configuration and working with accounts, refer to Understand accounts, contacts, and contracts.