Skip to main content
Netsuite supports both calculations and sync. Netsuite calculations are not implemented in the commenda logical backend, we built a plugin that each customer needs to install.

​
Sync:

We sync the following data models (through Rootfi and logical backend, same as other integrations): **Netsuite Payment Vouchers: (**INVOICES, INVOICE_CREDIT_NOTES, CASH_REFUNDS, CASH_SALES) We follow the following hierarchy:
  • Invoice-level SHIPPING (extracted from Rootfi webhook payload)
  • customer-level default shipping (retrieved via Rootfi passthrough)
  • invoice-level BILLING (extracted from Rootfi webhook payload)
  • customer-level default billing (retrieved from Rootfi passthrough)
When extracting an address from the rootfi webhook payload, we discard the address if raw_data is not present on the payload, but we never actually use the raw_data field. If there is exactly one customer-level shipping address or customer-level billing address, we do not seem to consider them unless they are explicitly set to default. But test this to see how the integration actually works. Customers: CONTACTS We extract the customer-level shipping address and billing address from the webhook payload’s raw_data field.
  • If the shipping address is set, we set the contact shipping address to the webhook payload shipping address.
  • If the billing address is set, we set the contact billing address to the webhook payload billing address
  • If the billing address is set but the shipping address is not set, we set the contact shipping address to the webhook payload *billing *address

​
Calculations:

Address resolution for calculations is both divergent from the Rootfi/ Commenda implementation, and contains several questionable implementation decisions that do not align with the sales tax API or with our best practices. The code is heavily dependent on netsuite internal details. We start by defining a ‘complete address’ as one with address line 1 and country set, where the country is not “IN”. We then try to extract the invoice shipping address with several different calls to netsuite internals that I don’t understand. These netsuite internals all need to be individually audited, because a lurking bug in any one would be unlikely to surface for any given customer. We pick the first non-null one of these addresses, regardless of whether it is a “complete address” as defined above. If the first non-null of the addresses is a “complete address”, we select it as our calculation address, otherwise we discard the other non-null shipping addresses and continue. We then do exactly the same for invoice billing address. If that also fails, we load the customer record and attempt to retrieve its billing address. If that succeeds, and is “complete”, we return it. Otherwise, we do a bunch of stuff I don’t understand to get a “fallback” address.