Proposal Summary
This proposal outlines the scope and approach for implementing a NetSuite customization that automates the population of both the body-level Ship Date and the line-level Estimated Ship Date (EST. Ship Date) on Sales Orders identified as e-commerce. The goal is to streamline order processing and ensure consistent, calendar-aware shipping commitments. The logic will be applied only during Sales Order creation, and the script will explicitly populate both fields without checking if the values are already present.
Detailed Requirements
E-commerce Sales Order Criteria
The automation will apply to Sales Orders that meet all the following conditions:
•Source: The order must be created via Web Services (i.e., from an integrated ecommerce platform like Amazon or Shopify).
•Trigger Context: The logic will be executed only during the create context of the Sales Order (i.e., when the order is first saved in the system).
Ship Date Population Logic
When an order meets the above criteria, the system will perform the following:
•Ship Date Calculation:
o The Order Date (trandate) will be taken as the base.
o The Ship Date will be calculated as Order Date + 1 day, excluding weekends and country-specific holidays.
•Fields to Populate:
o Body-level Ship Date: The main shipping date at the Sales Order header.
o Line-level Estimated Ship Date (EST. Ship Date): The shipping date at each line-itemlevel.
•Scope of Update:
o Both fields will be explicitly set by the script, regardless of whether they are already populated.
o There will be no validation check to skip already populated fields.
2.3. Country-wise Calendar Configuration
•Work Calendar Creation:
o Four NetSuite work calendars will be created for:
▪United States
▪China
▪Germany
▪Australia
•Holiday Configuration:
o Holiday dates must be provided by the client for each country.
o These calendars will be used to ensure that calculated ship dates do not fall on holidays or weekends.
•Subsidiary Mapping:
o Each Sales Order will be matched to a calendar based on its subsidiary’s country.
High Volume Sales Order Handling
•Real-time Script:
o Runs immediately after a Sales Order is saved.
o Efficient for orders with a manageable number of line items (typically under 100).
•Scheduled Script (Backup Processor):
o Automatically detects and updates orders that failed to process due to large line volumes or system limits.
o Ensures completion of ship date population even when the real-time script is skipped or partially fails.
•Trigger for Scheduled Script:
o A custom flag or log will be used to track unprocessed orders for reprocessing by the scheduled script.
Scope of Work
This section outlines what is included in the project to achieve the requested automation of Sales Order ship dates for e-commerce orders.
1.Work Calendars Setup
a. We will create four separate holiday calendars in NetSuite, one for each country where Magswitch operates: United States, China, Germany, and Australia.
b. These calendars will include national holidays, which you will provide, and will be used to ensure ship dates do not fall on non-working days.
2.Automatic Ship Date Population –Real-Time
a. When a Sales Order is created through your e-commerce integration (Web Services), our solution will:
i. Automatically calculate the next working day (order date + 1 day, skipping weekends and holidays).
ii. Set this calculated date as both the order-level Ship Date and the linelevel Estimated Ship Date.
b.This logic will run immediately when the order is saved.
Handling High-Volume Orders –Backup Script
a. NetSuite has built-in usage limits when performing many operations at once.
If an order has more than 100 line items, the system may not allow the realtime script to complete successfully.
b.To handle this, we will also create a scheduled backup script that runs in the background and:
i. Detects orders where ship dates were not set due to system limits.
ii. Automatically completes the ship date update process later without user intervention.
c.This ensures that no orders are left incomplete, even if they contain a large number of items.
Testing and Deployment
a. We will first set everything up in your test environment (Sandbox) and verify that all scenarios work correctly.
b.We will assist your team in reviewing and testing the automation.
c.Once approved, we will move the solution to your live system and ensure everything runs smoothly.
Support and Documentation
a.We will provide guidance during testing and deployment.
b.We will share a clear document outlining how the solution works, including which orders it applies to and how it calculates ship dates.
Assumptions
•E-commerce orders can be accurately identified by source field.
•Client will provide public holiday details for each country.
•Work calendars will be manually created and aligned with the subsidiaries.
•The logic does not consider existing values and sets both fields unconditionally.
•This automation does not update ship dates if orders are edited after creation.
•Once a Web Sales Order is created in NetSuite, the existing customization automatically sets both the body-level Ship Date and each Line Item (LI) Ship Date to one day after the Order Date (i.e., Order Date + 1).
•If the LI Ship Date is manually modified after the order is created, the customization does not override the user input. The manually entered date remains unchanged.
•It is assumed that there is no additional or separate customization currently in place that auto-populates the LI Ship Date beyond the existing logic applied at the time of order creation.
•The current customization does not validate whether the LI Ship Date is already set on the Sales Order. It directly applies the Order Date + 1 logic during the initial creation of the Web Sales Order.
Risks
•Incorrect flagging of orders as e-commerce may lead to undesired script execution.
•Missing or outdated holiday data may result in incorrect ship date calculation.
Notes
The scope and the provided estimate are based on the anticipation, expectation, and understanding through our discussions and email. If the scope change/additional feature development identified during actual development will be treated as change request.
Estimated Effort
The following timeline is based on the estimated hours for implementation. The schedule is subject to change based on the complexity of requirements and availability of resources:48hours
The estimate includes Project management, risk analysis, system analysis, development, unit testing, regression testing, documentation, and deployment. The rate is calculated based on our master service agreement.