Shared Transactions - Shared Payments - Integrating with 3rd Party Software
Shared Payments: Integrating with 3rd Party Software
If you're trying to get shared payments 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 payments fields on your transactions (subsidiary and bank account) are integer fields rather than list/record fields, which will cause problems 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 payments is not able to reformat or reconfigure data coming from 3rd parties after it is in your NetSuite instance. Shared payments 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 payments. If that is the case, you will need to work with your 3rd party provider to ensure that the data that you wish to process is being pulled in correctly.
The Solution
If your 3rd party provider needs list/record fields to pull from, you'll just need to create two custom body fields for your instance that are list/record fields that your provider can pull from. If these custom transaction body fields have a particular ID naming convention, our system will automatically source the correct values over to the shared payment 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 body fields in NetSuite in order to do this part. You'll start by navigating to Customization > Lists, Records, & Fields > Transaction Body Fields. You will need 2 fields (one for subsidiary and one for bank account). 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 Payment Subsidiary | _nta_ng_shared_pmt_sub | List/Record | Subsidiary | Vendor Bill, Invoice, Journal Entry, Sales Order | Default Access Level = Edit, Default Level for Search/Reporting = Edit, OR give desired roles specific access. |
| [Provider Name] Shared Payment Bank Account | _nta_ng_shared_pmt_bank | List/Record | Bank Account | Vendor Bill, Invoice, Journal Entry, Sales Order | Default Access Level = Edit, Default Level for Search/Reporting = Edit, OR give desired roles specific access. |
Important notes about field setup:
- The ID column above shows the required suffix. When you create the field in NetSuite, the system will prepend
custbodyto the ID automatically (e.g., the full ID will becustbody_nta_ng_shared_pmt_sub). Do not change the suffix portion, or the system will not recognize the field. - The Label can be whatever you'd like. We recommend including your provider name so it's clear what the field is for.
- The Bank Account field is only necessary if you have the "Initiate Shared Payment from Source" setting enabled.
- The subsidiary field must be filled out on the transaction in order for the bank account field to appear.
How It Works
When these overwrite fields are present on a transaction form:
- The system will automatically use these fields instead of the native shared payment fields.
- The native (integer) fields will be hidden from the form automatically.
- On save, the values from these overwrite fields are written through to the native fields, so the shared payment process works as normal.
- On load, if the transaction already has a shared payment subsidiary set, the overwrite field will be pre-populated with the correct value.
When these overwrite fields are not present on a form, the existing behavior is unchanged — the system falls back to the standard mock field behavior.
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 payment fields, you'll need to show them on your preferred transaction forms. 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 them up. Either will work.
We would recommend exposing your custom fields and the standard shared payment fields while you're implementing, then hiding the custom fields when you're done implementing to avoid seeing repeated information.
