Shared Transactions Integrating with 3rd Party Software

If you're trying to get shared transactions to work with a 3rd party AP provider (Stampli, RAMP, etc.) that is pulling fields from NetSuite and sourcing them into their own system, this is the article for you.

The Problem

Our native shared transactions line fields on your journal entries, bills, and other transactions are integer fields rather than list/record fields, which will cause problem for these providers; they rely on fields being list/record fields that they can pull values from and post values to. We needed to develop these fields as integer fields because of NetSuite system requirements, but we've built a way around this issue into our product.

Subject to 3rd party provider transaction processing

Shared transactions is not able to reformat or reconfigure data coming from 3rd parties after it is in your NetSuite instance. Shared transactions can only work with the data it is given. It is possible that the data coming in from a 3rd party may be configured in a way that is unusable by shared transactions. If that is the case, you will need to work with your 3rd party provider to ensure that the data that you wish to allocate is being pulled in correctly.

These instructions only apply to what we call a 1:1 allocation; filling out a different subsidiary, department, class, or location for a transaction to be moved to (or a combination of any of these) rather than where they are originally coded to. These are the fields that are integer numbers. Shared transactions templates are list/record fields, so this does not apply to them. They should be able to be used by your 3rd party provider.

The Solution

If your 3rd party provider needs list/record fields to pull from, you'll just need to create a few custom fields for your instance that are list/record fields that your provider can pull from. If these custom transaction line fields have a particular ID naming convention, our system will automatically source the correct values over to the allocation fields and work the same way it normally does.

You'll first need to create the custom fields, then provide the field IDs to your 3rd party software team, and finally customize your forms to decide what displays to users within NetSuite.

Creating Custom Fields (PLEASE READ CAREFULLY)

You'll need to have permission to create custom transaction line fields in NetSuite in order to do this part. You'll start by navigating to Customization > Lists, Records, & Fields > Transaction Line Fields. You will need 4 different fields for this (one for each standard segment). The fields MUST be set up according to the table below, or it will not work.

Label	ID	Type	List/Record	Applies To	Access
[Provider Name] Shared Transaction Subsidiary (Line)	_nta_ng_subsidiary	List/Record	Subsidiary	Expense, Purchase Item, Sale Item, Journal, Expense Report	Default Access Level = Edit Default Level for Search/Reporting = Edit OR give desired roles that should be accessing this field specific access to the field.
[Provider Name] Shared Transaction Department (Line)	_nta_ng_department	List/Record	Department	Expense, Purchase Item, Sale Item, Journal, Expense Report	Default Access Level = Edit Default Level for Search/Reporting = Edit OR give desired roles that should be accessing this field specific access to the field.
[Provider Name] Shared Transaction Class (Line)	_nta_ng_class	List/Record	Class	Expense, Purchase Item, Sale Item, Journal, Expense Report	Default Access Level = Edit Default Level for Search/Reporting = Edit OR give desired roles that should be accessing this field specific access to the field.
[Provider Name] Shared Transaction Location (Line)	_nta_ng_location	List/Record	Location	Expense, Purchase Item, Sale Item, Journal, Expense Report	Default Access Level = Edit Default Level for Search/Reporting = Edit OR give desired roles that should be accessing this field specific access to the field.

Again, if you do not set up these fields with the IDs listed above, the integration will not work.

Once you add these custom fields, the original shared transactions line-level allocation fields will be hidden by script.

When these new fields are added, our scripts will hide the out-of-the-box shared transactions line-level allocation fields and only display the custom fields. This is so that you don't have a data mismatch between the two fields, and to reduce clutter. You'll want to make sure you're aware of and appropriately modify any existing memorized transactions or CSV import templates to reflect this change to the new custom field.

Provide Fields to 3rd Party Software Team

This part is easy. Your administrators or implementation team for the 3rd party software likely will need to know the field IDs that you've given to these fields. You can give them the IDs in your system, or even just give them the table in this article. That should get them everything they need.

Customize Forms in NetSuite

You may customize your transaction forms in NetSuite if you would like to see these custom fields that you've created. This isn't necessary if you don't want to; the system will automatically pull from your custom fields whether you show them on your transaction forms or not. However, if you want to see what your 3rd party system sends into NetSuite and then what our scripts copy over from your custom fields to the standard Shared Transactions fields, you'll need to show them on your preferred journal entry form. You can either do this by going to Customization > Forms > Transaction Forms and editing your transaction forms there, or you can go to your custom fields and "Save and Apply to Forms" as you set up those transaction line fields. Either will work.

We would recommend exposing your custom fields and the standard shared transactions fields while you're implementing, then hiding the custom fields when you're done implementing to avoid seeing repeated information.

Was this article helpful?