Proposal Summary
This proposal outlines a comprehensive solution for implementing an API endpoint that allows an external system to create a sales order in NetSuite. When the API is invoked by passing the required payload for sales order creation, a success response will be sent back if the order creation is successful, or a failure response will be returned in case of failures. The API will be able to perform validation checks if it fails to identify the customer or the item codes in NetSuite.
Requirement
Riverstone Tech requires an integration with NetSuite to create sales orders within NetSuite from their system upon sending the required order details via an API call.
This task involves building a REST API endpoint that allows external systems to create Sales orders in Netsuite.
The API must perform the following validations before creating the sales order
● Customer Name Check: Verify that the provided customer name exists in the system. If not, return an error response with the message: “The company ‘vendor_name’ is not in the system.”
● Product Code Check: Validate each product code in the order line items. If a product code is not found in the system, return an error response with the message: “‘product_code’ is not in the system.”
● Partial Success Handling: If the API is given multiple line items, it should process them individually. If some line items are valid while others are not, the API should Create the valid line items in Netsuite. Return a success message that indicates the number of successfully imported line items and the number of failed ones.
Deliverables
- API Development:
- We will develop a RESTful API that allows external systems to create Sales orders in NetSuite.
- Ensure compatibility with current business processes and NetSuite’s API requirements.
- Data Validation:
- Customer Name Check
- When the API is invoked, our script will execute to create a sales order in NetSuite. If a customer in NetSuite is not found with the vendor_name in the payload, the script execution halts, as we cannot proceed with creating a sales order without the customer. We will then return a failure response, indicating the absence of the customer in NetSuite.
- Sample Response:
{
“status”: “Failure”,
“message”: “The company ‘vendor_name’ is not in NetSuite.“
}
- The customer in NetSuite will be searched using the vendor_name provided in the payload. The vendor_name should match the ‘Company Name’ in NetSuite. If the customer’s email address is also provided, we can further refine the search for the customer.
- Product Code Check:
- When creating the sales order, all the item codes included in the payload will undergo validation. If none of the items listed in the payload are found in NetSuite, a sales order cannot be created, and a failure response will be returned with the message: “‘product_code’ is not in NetSuite. ”
- Sample Response:
{
“status”: “Failure”,
“message”: “‘product_code’ is not in NetSuite”,
“order_line_item”: [
{
“product_code”: “CORP-CD-309HS”,
“status”: ” not available “
},
{
“product_code”: “CD-9542CT”,
“status”: “not available”
}
]
}
- Each item will be searched in NetSuite based on the product code provided in the payload, ensuring it matches the item name/number (SKU) of the item stored in NetSuite.
- Each item line in the payload should include the location from where the item should be picked, packed, and shipped. This is a mandatory field in NetSuite for entering an item line into the sales order.
- Partial Success Handling:
- The API will process each line item independently, allowing for partial acceptance of the order if certain items meet validation criteria while others do not.
- Provide detailed feedback on which items were successfully processed and which were not.
- Sample Response:
{
“status”: “success”,
“message”: “Customer found.”,
“order_line_item”: [
{
“product_code”: “CORP-CD-309HS”,
“status”: “inserted”
},
{
“product_code”: “CD-9542CT”,
“status”: “not available”
}
]
}
- Error Handling and Response Codes:
- Implement comprehensive error handling to cover scenarios such as missing mandatory fields and database lookup failures.
- Use appropriate HTTP status codes to reflect the outcome of the API requests accurately.
Assumptions
- We assume that the customer’s name (vendor_name) provided in the payload will match the customer’s ‘Company Name’ in NetSuite.
- We assume that the item code provided in the payload will exactly match the item name/number stored in NetSuite.
- We assume that the item locations will be provided with the names ‘Hialeah Gardens, Florida’, ‘Irving, Texas’, ‘Columbus, Ohio’, as they are in NetSuite. The customer should provide the exact location names in the purchase order.
- We assume that upon creating the sales order in NetSuite, it should be saved in the status ‘Pending Approval’, and the Corp Design team will review the order and adjust the status accordingly.
- The integration that automatically creates sales orders in NetSuite will only function for existing customers and will not work for new customers that do not already exist in NetSuite.
- A sales order will be created in NetSuite if the script can identify the customer in NetSuite and if at least one of the items listed in the payload also exists in NetSuite.
- We assume that if the ‘unit_price’ of an item provided in the payload does not match the price of the item in NetSuite, we will adjust the item line’s price level to ‘Custom’. The ‘unit_price’ will then be set as the rate of the item in the NetSuite sales order during its creation.
- We assume that the details such as ‘CSR’, ‘
Risk
- If the customer name provided in the payload matches anything other than the exact ‘Company name’ of the customer in NetSuite, we may encounter difficulty identifying the customer due to the lack of accuracy in the name. This could potentially result in order failure, even if the customer exists in NetSuite.
- Similar limitations apply to the item code as well. The product_code provided in the payload must precisely match the item name/number stored in NetSuite.
- NetSuite custom RESTful APIs have a concurrency limitation; they can only execute 5 concurrent invocations. This means that if 6 invocations are made to the API endpoint simultaneously, only 5 of them will be considered for sales order creation, and the 6th one will be neglected and never executed.
Questions
- Can the customer address be provided with separate lines for country (using the exact country name), address line 1, address line 2, city, state, and ZIP code? In the sample payload shared initially, the customer address is provided in a single line. We would prefer to receive the address lines as separate parameters in the payload. Additionally, we expect the country to be in its exact name, and the state to be in its abbreviated form, as in the sample payload where Florida is given as FL.
Sample :
{
“purchase_order”: “17757”,
“invoice_date”: “DD/MM/YYYY”,
“Vendor_address”: {
“country”: “United States”,
“address1”: “6695”,
“address2”: “NW 36th Avenue”,
“city”: “Miami”,
“state”: “FL”,
“zip”: “33147”
},
“vendor_name”: “FRONT DESK OFFICE FURNITURE”,
“order_line_item”: [
{
“product_code”: “CORP-CD-309HS”,
“description”: “Seating, High back Sand Leather, Executive Chair”,
“qty”: 8,
“unit_price”: 230,
“amount”: 1840
},
{
“product_code”: “CD-9542CT”,
“description”: “Design:8 FT Boat Shape Conference Table”,
“qty”: 1,
“unit_price”: 541,
“amount”: 541
}
]
}