Electronic Invoicing Builder Kit

• What is Builder Kit

• Understanding Builder Kit

• Components of the Electronic Invoicing Builder Kit

• Using the 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)

• Prerequisites

• Configuring the components of Builder Kit

• Using Builder Kit in NetSuite Production

• Customizing Electronic Invoicing Builder Kit Templates

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

• Create Mandate Record

• NSEB Setup

• Creating E- Document Templates using Builder Kit

• Create the Required Custom Fields

• Additional Setup for Inbound

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 don't 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:

• Create Plugin Implementation:

  See, Create Plugin Implementation

• Create Mandate Record:

  See, Create Mandate Record

• NSEB Setup:

  You must complete the NetSuite Electronic Business SuiteApp setup in your production account. For more details, refer to NetSuite Electronic Business Overview for the overview and Avalara Managers Guide for the steps.

  Important:

  If you have already setup NSEB in sandbox for testing, you must already have NSEB installed in your production account, and the initial setup steps already performed in production. You should resume setup in production from Avalara Company Creation or Avalara Mandate Activation steps.

  As part of the NSEB setup in production, ensure to activate the mandate you created in the previous step. Refer to Avalara Mandate Activation for more information.

• Creating E-Document Templates using Builder Kit:

  See, Creating E- Document Templates using Builder Kit

• Create the Require Custom Fields:

  Create the Required Custom Fields

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

• Modifying Template Mapping

• Writing Avalara Message Process Plugin Type

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