Proposal For Integrating Magento with NetSuite Using Custom Created Endpoints.

Proposal summary

The Airport digital system’s Magento website with NetSuite integration is outlined in this proposal. We will consider the product, inventory, delivery schedule, sales order, customer, sales order status, customer order history, Product URL/Rebate Available, and Email Subscription in this current scope.

Requirement

Integrate NetSuite product, and inventory sales orders with NetSuite. For product integration, our client is willing to send all historical NetSuite products from NetSuite to Magento. Also, when creating a new product in NetSuite the same item the corresponding item needs to be created in Magento. The product integration will be one-way integration from NetSuite to Magento.

In inventory integration will be a schedule-based integration. The integration script needs to update Magento product’s inventory once a day. This will be a one-side integration from NetSuite to Magento. Also, the client willing to integrate the NetSuite delivery schedule in daily basis.

In the sales order sync, the client needs to sync magneto sales orders with NetSuite. This will be a one-side integration from Magento to NetSuite. Also, return the sales order status from NetSuite to Magento based on the request.

Customer order history, Product URL/Rebate Available, and email subscription integration are included in the current phase.

Our solution

For product integration (Real time integration from NetSuite to Magento)

This will be a one-way integration from NetSuite to Magento. The endpoint for the product integration will be provided by Magneto team.

We will create a suite script for product integration. This will be a user event script. When creating the new inventory items in NetSuite, the script will execute and send API request to the provided product endpoint. We fetch the saleable quantity from the location ” Product Distribution Center” (field internal id: 1). We consider the location available quantity is the sellable quantity.

Once the item created in NetSuite successfully in Magento. Must return success response with Magento product id. We will not consider the deletion and update scenario for the item integration.

The historical product is not included in this integration. For historical product integration, magneto team can utilise the CSV import functionality.

Note:

We Always consider the NetSuite location available quantity as saleable quantity in Magento.

For inventory integration (Scheduled based integration from NetSuite to Magento)

The endpoint for the inventory integration will be provided by the Magneto team. With the help of this endpoint, we have developed schedule-based integration scripts in NetSuite. This script will execute every one-hour time span.

In less than one day, we retrieve all items whose inventory availability changed in NetSuite. Once the items had been recognized, they were added to the Magneto using the inventory update API. It will help to maintain same quantity in NetSuite and Magento.

We fetch the saleable quantity from the location ” Product Distribution Center” (field internal id: 1). We consider the location available quantity is the sellable quantity.

Note:

We Always consider the NetSuite location available quantity as saleable quantity in Magento.

For Delivery Schedule (From NetSuite to Magento)

This will be a one-way integration from NetSuite to Magento. We expect the endpoints will be provided from the Magento technical team. In the NetSuite database we have created 4 data table for delivery schedules. The delivery schedule Database table list given below:

1. ZIP Codes

2. Routes

3. Shared Route Code

4. Capacity Calendar

Our plan for delivery schedule integration
We will achieve this Delivery schedule integration is using two different methods.

Method 1 (Schedule-based integration from NetSuite to Magento)
All delivery schedules will be pulled from NetSuite and sent to the Magneto. The delivery schedule can be sent using an endpoint that the magneto technical team will provide. We need an endpoint for sending the capacity calendar, shared route code, route table, and ZIP code.

For achieving this we will create a scheduled script and schedule this script once in a day. Additionally, the script will pull every piece of data from the relevant data table and push it into Magento with the help of Magento team given endpoint.

The specific identifier is found in the netsuite_internal_id field. This will aid in duplicate detection. We anticipate that the Magneto technical team will make bulk data transfer between NetSuite and Magento possible. The following sample JSON API request body is what we anticipate from Magento team.

Note:

On behalf of the Magento endpoint, we will create the JSON request body. The endpoint must utilise this request schema.

{

“capacity_calendar”: [

{

“route”: [],

“share_route”: [],

“zip_code”: []

{

“route”: [],

“share_route”: [],

“zip_code”: []

{

“route”: [],

“share_route”: [],

“zip_code”: []

}

]

}

Method 2 (Real time integration from NetSuite to Magento)

When occur the changes in Capacity Calendar table in NetSuite must be updated in the Magento database as well. For achieving this the Magento technical team must provide an endpoint. We will send an API request to Magento whenever the data in the NetSuite Capacity Calendar table changes.

We only pay attention to changes in CURRENT CAPACITY and DAILY MAXIMUM CAPACITY fields.

For this real-time integration, a user event script will be created and deployed to a custom record on the Capacity calendar. We will use the provided API endpoint by the Magento team to send the updated values of the DAILY MAX CAP and CURRENT CAPACITY field to the magneto.

We expect the API request JSON body is given below:

{

“internal_id”: “integer”,

“daily_max_capcity”: “inetger”,

“current_capacity”: “integer”

}

For sales order and customer integration (Real time integration from NetSuite to Magento)

This will be a one-way integration from Magento to NetSuite. We will provide an API endpoint for sending sales data from Magento to NetSuite. Also, this endpoint allows you to get the NetSuite AHA DOCUMENT NUMBER for a Magento sales order.

Using the Restlet script, we will create an API endpoint. The Magento technical team must send the sales order data payload as a POST API request when processing an order in Magento. We’ll design the API request body (payload) for endpoint. The request body must contain the customer information, sales order body level information, and item level information.

When Magento sent the POST API request to the endpoint. The customer’s email address is evaluated by our script. Verify NetSuite’s customer existence. If a customer with the same email address is already in NetSuite, we will create a sales order for them. If they don’t, we will first create a customer in NetSuite, before creating a sales order for them.

Note:

This will be a one-way integration from Magento to NetSuite.
For getting AHA DOCUMENT NUMBER from NetSuite, The Magento team will send GET request in the same endpoint provided sales order creation. We expect this request 30 minutes later the sales order is created in NetSuite. Also, there must be a parameter called getAhaDocumentNumber = True.
We only create sales order in NetSuite no update and deletion are consider.

Sales Order Status (Real time integration from NetSuite to Magento)

This will be a one-way integration from NetSuite to Magento. To retrieve the status of a sales order from NetSuite, we will provide an API endpoint. Each time the Magento development team submits an API request. Using the AHA document number field, we will identify the sales order in NetSuite and return the details for that order’s line-level and body-level information.

Sales order body Level information

ORDER #

AHA DOCUMENT NUMBER
TRANSACTION DATE
SALES LOCATION
SALES ASSOCIATE

Sales order Line Level information

ITEM
MAGENTO LINE ID
ITEM DESCRIPTION
QUANTITY
RATE

AMOUNT
REQ DEL DATE
SCHED DEL DATE
ROUTE

Note:

This will be a GET API request, the API request must contain “AHA DOCUMENT NUMBER” number as parameter with parameter name “AHADocNum=”.
We will not consider the split line functionality in this sales order status update.
We are not considering the item lines which is manually added by users by editing the Magento sales orders.

Customer Order History (schedule-based integration from NetSuite to Magento)

This will be a one-way integration from NetSuite to Magento. We anticipate that the API endpoint will be supplied by the Magneto team.

We will locate offline sales orders made for Magento customers using this endpoint. Only offline sales orders that are produced within 24 hours of the script’s execution time are taken into account. The Magento team must provide the Magento order id once the sales order has been successfully created in Magento.

Note:

Magneto team must provide API endpoint for creating sales orders in Magento.
We will not send item level discount and promotions to Magento.
We only send line-item details and body level derails and summary box details.
We will not consider promotions for creating sales order in Magento.

Customer Level information

FIRST NAME
LAST NAME
MIDDLE NAME
EMAIL ADDRESS

CELL PHONE
SUBSCRIBE ON FUTURE PROMOTIONS

Sales order body Level information

ORDER #
AHA DOCUMENT NUMBER

TRANSACTION DATE
SALES LOCATION
SALES ASSOCIATE

Sales order Line Level information

ITEM

Magento Unique line id (This will help us to identified order line in Magento when sending order status.)
ITEM DESCRIPTION
QUANTITY
RATE
AMOUNT

REQ DEL DATE
SCHED DEL DATE
ROUTE

Product URL/Rebate Available (Schedule based integration from NetSuite to Magento)

This will be a one-way integration from NetSuite to Magento. We expect that the Magento technical team will offer the API endpoint. Using this endpoint, we will prepare the scheduled script. This script will run once in a day.

The script will fetch all inventory item details and send to the Magento. We assume that the endpoint has capability for sending following field.

Product ID
Image URL (from RWS)
Rebate Available/Not Available.

We expecting the following request body from Magento team.

{
    productData : [{
                              productid: string,
                              inageUrl: string,
                              rebateAvailble: boolean(true/false)
},
{
                              productid: string,
                              inageUrl: string,
                              rebateAvailble: boolean(true/false)
},
{
                              productid: string,
                              inageUrl: string,
                              rebateAvailble: boolean(true/false)
},
{
                             productid: string,
                             inageUrl: string,
                             rebateAvailble: boolean(true/false)
}]

}

Email Subscription (Schedule based integration from Magento to NetSuite)

This will be a one-way integration from Magento to NetSuite. The endpoint for sending the Email subscription flag will be provided by us. The customer record in NetSuite will be the endpoint’s intended target. The JSON request body for the API will be created. As shown below, the body of the API request.
{
     firstName: string,
     lastName: string,
     middleName: string
     emailAddress: string,
     mobileNumber: integer,
     subscribeValue: boolean(true/false)
}
We will use the email address or mobile number to identify customers when Magento makes a request. In NetSuite, the SUBSCRIBE ON FUTURE PROMOTIONS field (internalId: custentity2) will be marked if the customer is present.

Assumption

Assumptions for sales order and customer sync:

This will be a one-way integration from Magento to NetSuite.
We will not consider the historical sales order integration from Magento to NetSuite and NetSuite to Magento.
We only create sales order record in NetSuite, no update and deletion will be considered.
Only creation of customer records in NetSuite no update and deletion will be consider.
We will not consider the Historical customer integration from Magento to NetSuite and NetSuite to Magento.

We include inactive customers for detecting customer availability in NetSuite. If a customer with the same email address is an inactive state (inactive checkbox is true). Then we will activate that customer then create sales order.
We always create a customer as individual person (individual radio button is true)
We will not consider the tax rate for items. When creating a Magento sales order, we always specify that certain items are not taxable.
We are not expecting discount and promotions for the Magento sales orders.
We will include options in the API payload, to provide all of NetSuite’s mandatory fields. We expect the item level and body level mandatory field must include in the API request.

For setting values in the list fields when creating sales orders in NetSuite, we need exact field values without any typos or NetSuite internal id values. We anticipate the Magento team providing these values.
If there is any error that occurs while processing Magento sales orders in NetSuite. we will send an error response. The Magento technical team will handle this error.

The mandatory fields in sales order body level:

DRIVER CALL AHEAD & TEXT CELL NUMBER
BILL TO SELECT

SHIP TO SELECT
SALES LOCATION
DELIVERY INSTRUCTIONS
PROPERTY TYPE
HOUSE TYPE

DELIVERY FLOOR LEVEL
NUMBER OF STAIRS
TYPE OF DELIVERY
LABOR REQUIREMENTS
FUEL TYPE

Magento order ID.
PAYMENT METHOD

The mandatory fields in sales order item level:

Location

Item id
Quantity
Amount
Magento Unique line id (This will help us to identified order line in Magento when sending order status.)
REQ DEL DATE

ROUTE

The mandatory fields in customer creation:

Name
Billing and shipping Address.

EMAIL (FOR ALL COMMUNICATION)
CELL PHONE
SUBSCRIBE ON FUTURE PROMOTIONS
Magento customer ID

Assumptions for inventory sync:

We fetch the sellable quantity from the location ” Product Distribution Center” (internalid : 1). We consider the location available quantity is the sellable quantity.
We will not consider the historical product master data integration.
We assume the endpoint will provide from Magento team.
We will not consider the Service Items, Download Items, Gift Certificates, Discount Items, Subtotal Items, Markup Items, Payment Items, Item Groups, Kit/Package Items, Assembly Items and Non inventory items for the inventory sync.

Assumptions for product sync:

We fetch the sellable quantity from the location ” Product Distribution Center” (internalid : 1). We consider the location available quantity is the sellable quantity.
We assume the endpoint will provide from Magento team.
We will not consider the Service Items, Download Items, Gift Certificates, Discount Items, Subtotal Items, Markup Items, Payment Items, Item Groups, Kit/Package Items, Assembly Items and Non inventory items for the product sync

Assumptions for sales order status:

We only consider Magento created sales orders for sales order status update.

We will not consider the split line functionality. Also, we will not consider user manually added item lines for the status update.
We expecting the AHA DOCUMENT NUMBER for identify the sales order. This must be included in the API GET request.
If there is no order with the provided AHA DOCUMENT NUMBER, we will return error code. This must be handled by magneto technical team.

Assumptions for product URL/Rebate available:

We assume that in NetSuite, the SKU (ITEM NAME/NUMBER) will represent as the product id.

The “VIEW ON WEBSITE” field in NetSuite corresponds to the Image URL (internal id: custitem1).
The “REBATE AVAILABLE” field in NetSuite corresponds to the Rebate Available/Not Available status (internal id: custitem39).
We anticipate that the Magneto technical team will offer the capability of adding multiple items to a JSON request body. The following illustration.
We will only consider the inventory items in this endpoint.
We will not consider the Service Items, Download Items, Gift Certificates, Discount Items, Subtotal Items, Markup Items, Payment Items, Item Groups, Kit/Package Items, Assembly Items and Non inventory items for the product sync

The magneto technical team must be preparing the request body for sending bulk item data. Like the sample given in our solution section.

Assumptions for customer order history:

The magneto team must provide endpoint for sending sales order details.
We will not provide item wise discount and promotion.

Assumptions for email subscription:

Must follow the JSON request body described in our solution section for sending data for an email subscription.

Questions to NetSuite side

Question regarding the product integration:

The sellable quantity is quantity available in the “Product Distribution Center” location?

Question regarding the inventory integration:

The sellable quantity is quantity available in the “Product Distribution Center” location?

Question regarding sales order integration:

There was only one subsidiary called “Airport Appliance, Inc.” in the NetSuite sandbox account. With this subsidiary, we always create customers in NetSuite. Is that correct?
We always create sales order for customer without checking duplicate billing and shipping address. Is that correct?
In the last discussion you have mentioned the tax are not applicable for the items in NetSuite. If there any chances for order level taxes? If tax is existed on the sales order level, how can we handle this in sales order creation?

Is there any shipping cost available for the Magento orders? If so, please advise us as to how to handle this when creating sales orders in NetSuite.
Is it possible in Magento to apply promotions and discounts at the item level as well as the order level? If so, please advise us as to how to handle this when creating sales orders in NetSuite.

Question regarding the email subscription:

What can we do if NetSuite doesn’t have any customers at the given phone number or email address?

Risk

If NetSuite endpoint return the errors. The Magento technical team must handle these errors.

We are expecting concurrency error when sending more than 5 request to NetSuite side endpoint. The Magento team must confirm the request status after sending API request.

Leave a comment Cancel reply