Electronic Invoicing Builder Kit

What is Builder Kit

You can use the Electronic Invoicing Builder Kit feature to meet the e-invoicing compliance requirements in countries supported by Avalara, and where NetSuite does not provide a localization support at present.

This enables you to use Avalara for E-Invoicing.

Important:

See E- Invoicing Mandate Definitions, for the list of e-invoicing mandates supported by Avalara.

Before using e-invoicing builder kit, ensure to check if your country is present in the list of countries with e-invoicing support provided by NetSuite.

Understanding Builder Kit

The Electronic Invoicing Builder kit enables you to implement the e-invoicing solution for your requirements. If the mandate is supported by Avalara, you can implement a working solution for it in your NetSuite account.

When you use Builder Kit to implement your e-invoicing solution, you set up following components:

  • For Outbound:

    • E-Document Template (with custom data source)

    • Document status processing of a sent e-document (with custom processing logic).

    • The Mandate definition- this enables you to fulfill a required mandate and own its implementation details.

  • For Inbound:

    E-Document Template (Custom Data source plugin implementation)- to process inbound e-documents that you receive through Avalara from networks like PEPPOL)

Note:

Outbound and Inbound can be set up independent to each other when you use Builder Kit to implement the e-invoicing solution.

After you implement the Builder Kit feature and the required local setup is completed, the standard E- Invoicing SuiteApp is ready. You must perform the following steps to use e-invoicing:

  • Generate e-documents for country mandate of your choice.

  • Send the document to networks like PEPPOL or tax authorities (supported by Avalara).

  • Sync the status of the same e-document back at NetSuite, after the e-document is sent on networks like PEPPOL or to tax authorities.

  • Receive and send transaction responses.

Components of the Electronic Invoicing Builder Kit

You should create and configure the following components of the Builder kit based on local requirements:

  • Mandate

  • E- Document Templates

  • Custom Plugin Implementations

    • Custom Data Source for E-document (Outbound)

    • Avalara Message Process Plugin Type

    • Inbound Custom Data Source Plugin Type

  • Starter Templates:

    The Builder kit feature provides starter templates that you can customize further and then use in the Builder kit to tailor the e-invoicing solution to your desired country and e-invoicing mandates.

    The starter template include:

    • Sample SuiteScript code for the custom plugin types. These can be used as a starting point and can be configured further.

    • E-Document Templates (FreeMarker Templates to generate Generic PEPPOL e-documents) which can be configured to enable:

      • Generation of a compliant e-document.

      • Sending the e-document to the concerned Tax Authorities or networks like PEPPOL (powered by Avalara).

      • Processing responses for tax authorities/Networks.

An additional step involved in the configuration of the Builder kit is creating the required Custom Fields and/ or Custom Records, for input and output values of the e-invoicing, depending on your mandate requirements. This is done using the standard NetSuite customization. For more information see, Customization Overview.

Using the Electronic Invoicing Builder Kit

To start using Builder Kit, please contact your account administrator to enable access for your NetSuite account.

Using Builder Kit in NetSuite Sandbox (optional)

If you have the NetSuite Sandbox account, you can configure Builder kit in sandbox first and do the required testing, to ensure your implementation works as expected. After configuring the components, they can be used in the production setup.

NetSuite sandbox allows you to test send your e-documents to Avalara sandbox which works with the test mode of the tax authorities / networks like PEPPOL, serving as the test environment for your e- Invoicing flow.

Prerequisites

Install the required SuiteApps:

  • Electronic Invoicing

  • NetSuite Electronic Business

  • License Client

Note:

The NSEB SuiteApp requires you to perform initial setup steps in production, before NSEB can be used in sandbox for testing. For more information see, NSEB Sandbox Quick Start

Configuring the components of Builder Kit

Configure the following components:

Create Plugin Implementation

You must have the Administrator role to create the plugin implementations.

You can create plugin implementations of below types using the samples provided as part of EI SuiteApp:

  • Avalara Message Process Plugin Type - for document status processing.

  • Custom Data Source for E-document - for outbound generation.

  • Inbound Custom Data Source Plugin Type - for inbound conversion.

To use samples, you can perform the following steps to create and copy them:

  1. Go to File Cabinet > SuiteBundles > Bundle 436209 > com.netsuite.electronicinvoicing > Sample Templates > Builder > Plugin Implementations

  2. Download the Plugin Implementations folder. It gets downloaded as a zip file.

  3. You can now upload the zip into the file cabinet folder of your choice. Create a folder under File Cabinet > SuiteScripts called My Builder Scripts.

  4. Go to My Builder Scripts and upload the zip file using the "Advanced Add" option.

  5. After the upload, you can go to the files under the plugins folder and rename them as per your choice, for identification while using these files to create Plug-in Implementations.

You can refer to the already sourced Transaction data available from Electronic Invoicing (refer to CDS data available from EI). If you need to override the available values, you can do it when implementing. If it is not required to override, you do not need to take any action and the values will be used during e-document generation, depending on the template mappings. Refer to the CDS data available from reference Outbound UBL CDS and add the missing or tweak the existing if needed, based on countries' requirement.

For more details on how to create plugin implementation, see Creating a Custom Plug-in Alternate Implementation.

Create Mandate Record

You must have the Administrator role to create the mandate record. A mandate record can be created using builder kit interface:

  • Go to Setup > E-Invoicing > Builder Kit

  • Create a Mandate record and set:

    • Name: Should be the mandate value supported by Avalara.

    • Plugin implementation script id of 'Avalara Message Process Plugin Type' type created in the previous step, for example- . customscript_msgprocess_belgium.

NSEB Setup

Setup the NetSuite Electronic Business SuiteApp in your sandbox account. For more details, refer to NetSuite Electronic Business Sandbox for the overview and NSEB Sandbox Quick Start for the steps.

Important:

To use NSEB in sandbox for testing, you must install NSEB first in production account, and perform the initial setup steps in production. For more information see, NSEB Sandbox Quick Start.

As part of the NSEB setup in sandbox, be sure to activate the mandate you created in the previous step. For more details see, Mandate Activation of Avalara Sandbox company.

Creating E- Document Templates using Builder Kit

You must have the Administrator role to create the e-document templates using Builder kit. You can use Builder Kit to create an E-Document Template with ready “starter” details which can be customized according to your needs.

You will need e-document templates to generate e-documents. Builder Kit helps you create e-document templates with standard/starter mappings and the custom data sourcing implementation, that you can further customize according to your needs.

Steps to create the E-document templates:

  1. Go to Setup > E-Invoicing > Builder Kit

  2. Enter the required details:

    • Name of the Builder E-Document Template.

    • E-Document Package you want the Template to reside in.

    • Subsidiaries you want the E-Document Template to be available for.

    • Outbound Details

      1. Outbound Starter – select the sample starting template with mappings.

      2. Outbound CDS – select the sample plugin implementation that sources the transaction data. You can select the CDS plugin implementation created in the first step.

      3. Apply Validations - check the box if validations are required to be triggered during e-document generation.

        For more information about validations, see Apply Validations Enabled

    • Inbound Details

      1. Inbound Starter – select the template that comes with default mapping. Current option is Inbound Generic PEPPOL, which helps you convert a PEPPOL E-Document.

      2. Inbound CDS – select the inbound custom data sourcing implementation.

      3. Inbound XSD – select the XSD option. This is a must.

  3. Click Save.

You will be redirected to the created E-Document Template, with the “Template for Outbound E- documents” and “Custom Data Source Plugin Implementation” already populated, based on your selection of Outbound Starter and Outbound CDS.

Similarly, if you provided a choice for Inbound Starter, Inbound CDS, and Inbound XSD, the newly created E-Document Template record contains “Field Mapping for Inbound E-documents” already populated, based on your selection.

You can always modify these field values in the created E-Document Template by navigating to the record by going to Setup > Electronic Invoicing > E-Document Templates.

Create the Required Custom Fields

The country mandate or network to which the e-documents are sent (for example- PEPPOL) might require associated values to be stored with an invoice, before the e-document is generated and sent, and after the e-document is sent.

You may need to "create custom fields" depending on your country mandate. These custom fields could be used by you for two different purposes:

  • Values that should be stored before e-document generation, and to be used during e-document generation:

    A custom transaction body field can be used to store values that can be sourced and used in the generated e-document using Outbound CDS.

    For example: a value associated with the invoice, required to be present in the generated e-document.

  • Values that should be stored as result of sending out an e-document:

    Custom transaction body fields can be used store the results of sending the e-document to tax authority or networks like PEPPOL.

    For example: Unique ID of document generated by tax authority, digital signatures etc.

Additional Setup for Inbound

Inbound e-documents can be supported by implementing the following Builder kit created components:

  • E-Documents Templates (Inbound)- Be sure to configure the Inbound Details when creating the E-Document Template using Builder Kit. For more information, see Creating E- Document Templates using Builder Kit.

  • You must create the Plugin Implementation to resolve/select/set the Vendor based on custom logic. Create a custom plugin implementation of type “Inbound Custom Data Source Plugin Type”.

Using Builder Kit in NetSuite Production

For Sandbox Users

When you have the components (plugin implementations and templates) ready after your modifications (if any) and verified to be working in your NetSuite sandbox (optional), you will be ready to use the components in your Builder Kit setup in your Production accounts.

If you have implemented and tested Builder kit components in Sandbox, store a copy of the plugin implementations, modified templates (if any), and related customizations, so that you can create/reuse it in Production.

For Non- Sandbox Users

You can implement the components similar to sandbox steps, and test with zero value or one cent invoices.

The following are the steps to use Builder Kit in Production:

Customizing Electronic Invoicing Builder Kit Templates

After you have used the Electronic Invoicing Builder kit to create E-Document Templates, you can customize them using SuiteScript and FreeMarker, to generate the format of document required (fro example- PEPPOL BIS 3.0 and similar UBL based documents).

You can also customize how the result of sending an e-document (the document reference number, allotment number, QR code etc. corresponding to the sent e-document) is tagged with the corresponding invoice and other transactions in NetSuite, using Avalara Message Process Plugin Implementation.

Sourcing custom data for e-documents

You can include custom data in generated e-documents, by implementing Custom Data Source plugin implementation in SuiteScript and use them in the E-Document Templates. Builder Kit provides sample PEPPOL custom data source plugin implementation that can be used as a reference.

Understanding the Outbound CDS Plugin Implementation

The Custom Data Source Plugin Implementation (CDS) is a custom plugin type that you can implement by creating plugin implementations. The plugin implementation you create should fully define the interface’s function inject. It should contain the logic executed by an interface’s function inject that will:

  • Return the data sourced using SuiteScript that is expected to be present in the generated e- document.

  • The Mandate that the document is being generated for.

More details about the interface:

Functions

inject(params)

Params

{String} params.transactionId

{Object} params.transactionRecord

{Object} params.transactionDataCollection (optional)

Returns

{Object} result

{render.DataSource} result.alias

{string} result.format

{Object | Document | string} result.data

{string} result.data.mandate

{Object | Document | string}

result.data.transaction - Custom data can be returned here.

{Object} result.result (optional)

{Boolean} result.result.success (optional)- It can be used to cause failure in generation. Useful when want to abort the generation process. Optional and defaulted to true if omitted.

{string} result.result.eiAuditTrailMsg (optional)- This appears on the E-Document Audit Trail of transaction.

Transaction Data Collection

The computed transaction object is available only for templates created through the builder kit interface. This object is available as a part of "Outbound CDS Plugin" params.

It is useful for plugin authors looking for transaction related data including its entity and subsidiary information.

Note:

Transaction Data Collection is available for Invoice, Credit Memo and Cash Refund transaction types only.

The following is the table containing the information about transaction data collection keys and its source:

Upcoming Common Data Object Structure

S no.

CDS Key

Internal ID/Source

Label

1

transactionDetails.typeCode

Can be provided in CDS

Default Value- Credit Memo(381), Any other transaction (380)

N/A

2

transactionDetails.ublVersionId

Can be provided in CDS

Default Value- 2.1

N/A

3

transactionDetails.taxScheme

Can be provided in CDS

Default Value- VAT

N/A

4

transactionDetails.customizationId

Can be provided in CDS

Default Value- urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0

N/A

5

transactionDetails.profileId

Can be provided in CDS

Default Value- urn:fdc:peppol.eu:2017:poacc:billing:01:1.0

N/A

6

transactionDetails.mainDetails.tranId

tranid

Bill-Reference No.Invoice-Invoice #

7

transactionDetails.mainDetails.tranDate

trandate

Date

8

transactionDetails.mainDetails.dueDate

duedate

Due Date

9

transactionDetails.mainDetails.memo

memo

Memo

10

transactionDetails.mainDetails.otherRefNum

otherrefnum

PO #- Invoice

11

transactionDetails.mainDetails.startDate

startdate

Start Date - Invoice

12

transactionDetails.mainDetails.endDate

enddate

End Date - Invoice

13

transactionDetails.mainDetails.type

type

Invoice- invoice

CreditMemo- creditmemo

-

14

transactionDetails.mainDetails.terms

terms

Terms

15

transactionDetails.mainDetails.createdFrom.tranId

createdfrom

(value after #)

Created From - Invoice

16

transactionDetails.mainDetails.createdFrom.tranDate

trandate

("Created From" transaction's date)

Date

17

transactionDetails.mainDetails.salesRep.name

salesrep

Sales Rep

18

transactionDetails.mainDetails.salesRep.phone

phone

("Sales Rep" Phone)

Phone

19

transactionDetails.mainDetails.salesRep.email

email

("Sales Rep" Email)

Email

20

transactionDetails.mainDetails.currencyISOCode

symbol

("Currency" ISO Code)

ISO Code

21

transactionDetails.mainDetails.billAddress.addressee

addressee

("Bill Address" Addressee)

(fallback to Entity's default address's Addressee)

Addressee

22

transactionDetails.mainDetails.billAddress.line1

addr1

("Bill Address" Address 1)

(fallback to Entity's default address's Address 1)

Address 1

23

transactionDetails.mainDetails.billAddress.line2

addr2

("Bill Address" Address 2)

(fallback to Entity's default address's Address 2)

Address 2

24

transactionDetails.mainDetails.billAddress.line3

addr3

("Bill Address" Address 3)

(fallback to Entity's default address's Address 3)

Address 3

25

transactionDetails.mainDetails.billAddress.city

city

("Bill Address" City)

(fallback to Entity's default address's City)

City

26

transactionDetails.mainDetails.billAddress.zip

zip

("Bill Address" Zip)

(fallback to Entity's default address's Zip)

Zip

27

transactionDetails.mainDetails.billAddress.state

state

("Bill Address" State)

(fallback to Entity's default address's State)

State

28

transactionDetails.mainDetails.billAddress.countryISOCode

country

(Transaction billing address country ISO Code)

(fallback to Entity's default address country's ISO Code)

Country

29

transactionDetails.mainDetails.headerDiscount.rate

discountrate

Rate

30

transactionDetails.mainDetails.headerDiscount.taxRate

N/ANote: Field not available, can be populated via CDS

 

31

transactionDetails.mainDetails.headerDiscount.taxCode

N/ANote: Field not available, can be populated via CDS

 

32

transactionDetails.mainDetails.headerDiscount.total

discounttotal

Discount Item

33

transactionDetails.mainDetails.shippingAndHandling.rate

N/ANote: Field not determined, can be populated via CDS

 

34

transactionDetails.mainDetails.shippingAndHandling.taxRate

N/A

Note: Field not determined, can be populated via CDS

 

35

transactionDetails.mainDetails.shippingAndHandling.taxCode

N/ANote: Field not determined, can be populated via CDS

 

36

transactionDetails.mainDetails.shippingAndHandling.total

altshippingcost, althandlingcost

(Sum of above fields)

Shipping Cost, Handling Cost

37

transactionDetails.mainDetails.amountsSummary.subTotal

subtotal

Subtotal

38

transactionDetails.mainDetails.amountsSummary.taxExclusiveAmount

 

Total, Tax Total

39

transactionDetails.mainDetails.amountsSummary.amountPaid

amountpaid

-

40

transactionDetails.mainDetails.amountsSummary.netPayable

Invoice - amountremainingtotalbox

Credit Memo - amountremaining

Other transactions - total

Amount Due,

Total

41

transactionDetails.mainDetails.amountsSummary.taxTotal

taxtotal

Tax Total

42

transactionDetails.mainDetails.amountsSummary.total

total

Total

43

transactionDetails.lineDetails[].name

item

(Text of Item column from Item sublist on transaction)

 

44

transactionDetails.lineDetails[].description

description

(Description column from Item sublist on transaction)

 

45

transactionDetails.lineDetails[].itemType

itemtype

(from Item sublist on transaction)

 

46

transactionDetails.lineDetails[].lineNumber

 

 

47

transactionDetails.lineDetails[].quantity

quantity

(Quantity column from Item sublist on transaction)

 

48

transactionDetails.lineDetails[].rate

rate

(Unit Price column from Item sublist on transaction)

 

49

transactionDetails.lineDetails[].amount

net amount after considering charge/allowances

(Amount column from Item sublist on transaction)

 

50

transactionDetails.lineDetails[].taxCodeId

taxcode

(Tax Code column from Item sublist on transaction)

 

51

transactionDetails.lineDetails[].taxRate

taxrate

(Tax Rate column from Item sublist on transaction)

 

52

transactionDetails.lineDetails[].peppolTaxCategoryCode

custrecord_psg_ei_peppol_tax_catg_code

(Tax Code "Peppol Tax Category Code")

 

53

transactionDetails.lineDetails[].baseAmount

amount

(Amount column from Item sublist on transaction)

 

54

transactionDetails.lineDetails[].lineDiscountDetails[].rate

(Available when Line Discount is present)

rate

(Unit Price column from Item sublist on transaction)

 

55

transactionDetails.lineDetails[].lineDiscountDetails[].amount

(Available when Line Discount is present)

amount

(Amount column from Item sublist on transaction)

 

56

transactionDetails.lineDetails[].lineMarkupDetails[].rate

(Available when Line markup is present)

rate

(Unit Price column from Item sublist on transaction)

 

57

transactionDetails.lineDetails[].lineMarkupDetails[].amount

(Available when Line markup is present)

amount

(Amount column from Item sublist on transaction)

 

58

transactionDetails.taxCategoryDetails[].taxableAmount

N/A

Note: can be populated via CDS

 

59

transactionDetails.taxCategoryDetails[].taxAmount

N/A

Note: can be populated via CDS

 

60

transactionDetails.taxCategoryDetails[].peppolTaxCategoryCode

N/A

Note: can be populated via CDS

 

61

transactionDetails.taxCategoryDetails[].taxExemptionCode

N/A

Note: can be populated via CDS

 

62

transactionDetails.taxCategoryDetails[].taxExemptionReason

N/A

Note: can be populated via CDS

 

63

transactionDetails.taxCategoryDetails[].taxRate

N/A

Note: can be populated via CDS

 

64

entityDetails.companyName

companyname

(Entity's Company Name)

Company Name

65

entityDetails.peppolId

custentity_psg_ei_peppol_id

(Entity's Peppol ID)

 

66

entityDetails.entityId

entityid

(Entity's ID)

 

67

entityDetails.accountNumber

accountnumber

(Entity's Account Number)

 

68

entityDetails.contactDetails.name

entityid

(Entity's Primary contact name)

(fallback to Entity's first contact name)

Name column

(From Contacts sub record under "Relationships" subtab on Entity)

69

entityDetails.contactDetails.phone

phone

(Entity's first contact phone)

(fallback to Entity's first contact phone)

Phone column

(From Contacts sub record under "Relationships" subtab on Entity)

70

entityDetails.contactDetails.email

email

(Entity's first contact email)

(fallback to Entity's first contact email)

Email column

(From Contacts sub record under "Relationships" subtab on Entity)

71

entityDetails.taxRegNum

Legacy

vatregnumber

(Customer's vat reg number)

SuiteTax

entitytaxregnum (from transaction)

defaulttaxreg

(Customer's tax reg number)

Tax Reg. Number

72

subsidiaryDetails.name

OW

name

("Subsidiary" name)

SI

companyname

(Company Information "Company Name")

Name

73

subsidiaryDetails.legalName

legalname

("Subsidiary" legalname )

Legal Name

74

subsidiaryDetails.peppolId

custrecord_psg_ei_peppol_id

("Subsidiary" Peppol ID from it's EI subsidiary preference record )

Peppol ID

75

subsidiaryDetails.address.addressee

addressee

OW("Subsidiary" Main address Addressee)

SI("Company Information" Main address Addressee)

Addressee

76

subsidiaryDetails.address.line1

addr1

OW("Subsidiary" Main address Address 1)

("Company Information" Main address Address 1)

Address 1

77

subsidiaryDetails.address.line2

addr2

OW("Subsidiary" Main address Address 2)

SI("Company Information" Main address Address 2)

Address 2

78

subsidiaryDetails.address.line3

addr3

OW("Subsidiary" Main address Address 3)

SI("Company Information" Main address Address 3)

Address 3

79

subsidiaryDetails.address.city

city

OW("Subsidiary" Main address City)

SI("Company Information" Main address City)

City

80

subsidiaryDetails.address.zip

zip

OW("Subsidiary" Main address Zip)

SI("Company Information" Main address Zip)

Zip

81

subsidiaryDetails.address.state

state

OW("Subsidiary" Main address State)

SI("Company Information" Main address State)

State

82

subsidiaryDetails.address.countryISOCode

country

("Subsidiary" Main address country)

SI("Company Information" Main address country ISO Code)

Country

83

subsidiaryDetails.taxRegNum

Legacy OW

federalidnumber

("Subsidiary" federalidnumber)

Legacy SI

employerid

(from Company Information)

SuiteTax

subsidiarytaxregnum

(Subsidiary/Company tax registration number from transaction)

 

84

subsidiaryDetails.currencyISOCode

symbol

("Currency" ISO Code of Subsidiary)

ISO Code

85

subsidiaryDetails.baseCurrencyTaxDetails.taxTotal

(key available when subsidiary currency is not matching with transaction currency)

taxtotal * exchangerate

(exchangerate from transaction)

 

86

subsidiaryDetails.baseCurrencyTaxDetails.totalIncludingTax

(key available when subsidiary currency is not matching with transaction currency)

total * exchangerate

(exchangerate from transaction)

 

87

subsidiaryDetails.baseCurrencyTaxDetails.totalExcludingTax

(key available when subsidiary currency is not matching with transaction currency)

(total - taxtotal) * exchangerate

(exchangerate from transaction)

 

Note:

All of the above keys represent default mapping or values which can further be overwritten in the Outbound CDS as per the requirement. For usage refer, pl_starter_generic_outbound_cds.js (Folder: File Cabinet > SuiteBundles > Bundle 436209 > com.netsuite.electronicinvoicing > Sample Templates > Builder > Plugin Implementations).

Sourcing a value from custom record

For example, when implementing the Custom Data Sourcing plugin implementation, a search, query, or (least preferred) record load can be performed to source a custom data.

It can then be included at certain key in the object returned by the plugin implementation:

at object returned at customDataSources[0].data.transaction.

For example: customObj.myvalue = “value”;

                              return {
                customDataSources: [
                    {
                        format: render.DataSource.OBJECT,
                        alias: "avalara_cds",
                        data: {
                            mandate: mandate,
                            transaction: customObj,
                        },
                    },
                ],
                result: {
                    success: true,
                    eiAuditTrailMsg: "", //EI puts a default message if the CDS is returned successfully
                },
            }; 

                
Using Script execution logs for logging and debugging

After customizing the plugin implementation stater to suit your needs, you can test your changes by generating e-documents with the templates. To help with debugging, N/log Module and log.debug(options) can be used. The logs can be inspected under following script:

  • Customization > Scripting > Scripts

  • Set the filter to TYPE: Suitelet

  • View script ID customscript_ei_generation_service_su

Be sure to set the Script Deployment to Log Level DEBUG, when using log.debug(options).

Appendix: Sample outbound CDS plugin implementation for PEPPOL e-documents.

You can locate the sample outbound CDS plugin implementation for PEPPOL e-documents in your File Cabinet:

Documents > File > File Cabinet > SuiteBundles > Bundle 436209 > Sample Templates > Builder > Plugin Implementations > pl_starter_generic_outbound_cds.js

Modifying Template Mapping

Adding tags, and mapping additional values returned from Outbound CDS plugin implementation.

After the E-Document Templates are created using builder kit, you may modify the outbound template by editing the Template for Outbound E-documents field in the E-Document Template.

You can add additional XML tags that reference data returned by Custom data source Plugin Implementation type set in Custom Data Source Plugin Implementation field of the same E-Document Template record.

Writing Avalara Message Process Plugin Type

To sync the status and related updates about an e-document after it is generated and sent, you will need to implement a custom plugin of type “Avalara Message Process Plugin Type”.

  • Appendix: Sample Avalara Message Process plugin type implementation.

    You can see a sample plugin implementation by navigating to:

    Documents > File > File Cabinet > SuiteBundles > Bundle 436209 > Sample Templates > Builder > Plugin Implementations > pl_starter_avalara_message_process.js

  • Customizing the sample to add a value to custom transaction body field. The sample plugin implementation should implement function processRequestStatus

                        -   
    
    {Object} params
    -   {Object} params.transaction
    -   {Object} params.docStatusPayload { companyId, obnControlNumber id, events: "array<Event>", status, events[].message, events[].responseKey (optional)} 
    
                      
  • Using Script execution logs for logging and debugging.

After customizing the plugin implementation stater to suit your needs, you can test your changes by generating e-documents with the templates. To help with debugging, N/log Module and log.debug(options) can be used.

The logs can be inspected under following script:

  • Customization > Scripting > Scripts

  • Set the filter to TYPE: RESTlet

  • View script ID customscript_ei_update_transaction_rl

Ensure to set the Script Deployment to Log Level DEBUG, when using log.debug(options)

General Notices