Proposal Summary
This proposal is tailored to meet the specific requirements put forth by BigRig groups. This proposal encompasses a range of solutions designed to address each of their distinct needs effectively. The proposed solutions have been thoughtfully crafted to enhance efficiency, streamline processes, and meet the specific needs of BigRig groups. Also, this proposal is committed to providing solutions that align with BigRig’s objectives, ensuring a successful partnership for mutual growth and success.
Requirement 1
Item Field Customization in Transaction Records
Requirement for customizing the item field in transaction records. BigRig wants to improve the search functionality within the item field, allowing users to search and populate items based on description keywords. Additionally, the client requests the inclusion of filters such as product category, availability, and location in the search window.
Deliverable
This customization plan for NetSuite involves adding a custom button within the item sublist of a record. When this custom button is clicked by a user, it will redirect them to a custom page created specifically for this purpose.
The custom page will include a field where the user can enter a keyword, which will be used to filter items based on that keyword. Additionally, the custom page will provide additional filtering options, such as product category and location.
The primary goal of this customization is to allow users to efficiently select multiple items at once by applying specific filters to narrow down the results. Instead of manually searching through the entire item list, the custom page’s keyword and filters enable the user to quickly find the items they need.
The custom page is designed to allow users to filter and select items based on specific criteria. Here’s an elaboration of each component:
- Description Field: This field allows users to enter a keyword or search term. When the user enters a keyword, the custom page will search for items whose description contains the entered keyword. Once the user enters a keyword in the Description field, the custom page will display a list of items. This list includes all items whose description contains the keyword entered by the user. The user can use this filtered list to identify relevant items quickly.
- Product Category Field: The custom page also contains a dropdown field labeled “Product Category.” Users can choose a specific product category from the options available in the dropdown. Upon selection, the custom page will list all items that belong to the chosen product category.
- Location Field: Another dropdown field “Location” is available on the custom page. Users can choose a specific location from the options in the dropdown. The custom page will then display a list of items that available in the chosen location. This filter ensures that the items listed based on available at the specified location.
- Search button: This custom button. Once the user has entered the keyword in the Description field, chosen a Product Category or selected a Location, the user must then click the “Search” button to initiate a specific action or process. This button likely performs a search or filtering operation based on the entered criteria.
- Submit button: After the user has made their selections, the custom page includes a “Submit” button. This button serves as a trigger to finalize the item selection process and proceed to add the chosen items to the transaction or record.
Users can utilize any of these filters to narrow down the list of items displayed on the custom page. For instance, they can enter a keyword in the Description field, choose a specific Product Category, or select a Location.
“Click Selection to Add” Section: This section of the custom page displays a list of items that match the selected filters. These items are the filtered results based on the criteria specified by the user in the Description, Product Category or Location fields. Users can click on individual items listed in this section to add them to their selections.
“Current Selections” Section: Located on the right side of the custom page, the “Current Selections” section is designed to display the items that the user has chosen or selected from the “Click Selection to Add” section. As the user clicks on items in the “Click Selection to Add” section, those chosen items are dynamically updated and listed in the “Current Selections” section. The custom page includes a “Close icon” displayed next to each item that the user has selected and added to the “Current Selections” section.
The custom page will be providing users with the ability to remove selected items from their list before finalizing the addition to the transaction or record. After the user selects items using the available filters, they will now have the option to review their selections and make changes if needed. If the user decides not to include specific items in the transaction, they can utilize this removal option to remove those items from the list.
Assumptions
- The item list sorted in the order of available quantity.
- In the Description field of custm page We will check whether the entered keyword is contains in the sales description of item
- The value in Location filter is consider from the line level rather than inventory location.
- We set quantity value is 1 as default if choosed item does not available at any location.
Risks
- The real-time search and suggestion feature can cause additional processing on the server-side as it needs to continuously process and update the search results based on the user’s input. Depending on the complexity of the search and the amount of data to process, this can increase the page’s loading time.
- This functionality will be available only on UI.
Estimate Time
38 Hours
Requirement 2
Automatic Inclusion of Special Charge Items
Requirement for the automatic inclusion of special charge items based on the product category. BigRig wants specific items to be associated with certain product categories and be automatically populated when a related item is added. Additionally, there is a requirement to calculate specific measurements for the associated items based on the quantities of the primary item.
Deliverable
We will develop a new custom field named “Product Category” specifically for Other Charges items. This field will be of type list/record and it will use the “Product Category” list for selection. It will be mandatory for users to update the product category of each Other Charges item using this field.
Upon adding or modifying a item line, the system will dynamically add corresponding Other Charges items below the main item in real-time, based on the selected product category. For sales orders, only “Other Charges For Sales” items will be utilized, while for purchase orders, only “Other Charges for Purchase” items will be applied.
We will introduce an additional custom line level field to store the unique key of the associated Other Charges item’s Main Item line. This field will be disabled and not editable by users.
When editing an existing line, the system will automatically identify the relevant Other Charges line using the line unique key and proceed to update it accordingly. This ensures smooth and precise updates for Other Charges items.
The Other Charges item’s quantity will be automatically calculated based on the Main Item’s quantity and units. For instance, if the main item has a quantity of 1 and the unit is 10L, the Other Charges item’s quantity will be computed as 1 * 10 = 10.
We will develope these functionalities only for the sales orders and purchase orders. We will implement additional functionality to restrict the automatic addition and updating of Other Charges items after the Sales Order or Purchase Order has been fully invoiced or billed. Once an order has reached the fully invoiced/billed status, the system will no longer trigger any actions related to Other Charges items, ensuring that the data remains accurate and consistent with the final state of the order.
Assumptions
This proposed solution is based on the following assumptions:
- The Other Charges item amount is for 1 unit of measure (UOM).
- We assume the main item’s unit of measure (UOM) will be available in the item record.
- We will add the Other charge items only for the Inventory Items.
- If there are multiple Other Charges items available and they belong to the same product category, we will be adding a maximum of 2 Other Charges items.
- The functionality will be exclusively accessible through the user interface (UI).
- To link the product category, custom fields will be provided on the “Other Charges” item. BigRig will have the authority to update and maintain these fields as needed.
Questions
- As per the current solution, the script will work only when adding each item through the line level. The script does not add the Other charges when using “Add Multiple” button or creating/updating the orders through contexts other than the UI. Should we consider the “Add Multiple” button and other contexts as well? If yes, we cannot add the Other Charges in real-time; instead, we will add the Other Charges items during the save event of the Sales Order or Purchase Order.
Risks
- We will not add the Other Charges item while edit and save the sales orders/purchase orders. The Other charges item will be added only if the item line was added or edited.
Estimated Time
12 hours
Requirement 3
Dashboard Customization
Requirement for dashboard customization, specifically focusing on item sorting in the global search. BigRig wants to explore the possibility of sorting items listed in the global search based on quantity availability. Currently, when searching for a specific item using keywords, all items, regardless of availability, are displayed. BigRig requests a solution to sort the search results based on availability. If sorting within the global search is not possible, then requires a custom solution involving dashboard customization.
Deliverable
We are planning to incorporate a customization within the dashboard. The purpose of this customization is to present the inventory items in a clear and organized manner, with a primary focus on their available quantity based on the location. The items will be displayed, allowing users to easily identify the items with the highest available quantities.
In addition to the default sorting functionality, we will incorporate two filters within this customization. These filters will enable users to search for inventory items based on their description and location. By utilizing these filters, users will have the ability to refine their search and quickly locate specific items that match their criteria.
Assumptions
The proposed solution is based on the following assumptions:
- Currently, the dashboard exclusively displays inventory items while excluding any other item types. If necessary, we have the flexibility to incorporate additional item types in the future.
- Line count 10.
- Inactive items will be excluded from the display on the dashboard.
- We will be only providing the steps to add or publish search to the dashboard.
Estimated Time
6 hours
Requirement 4
Intercompany Management
Requirements for an intercompany management system. BigRig intends to purchase parts from one subsidiary for use by another subsidiary. And require a solution that allows the linking of intercompany purchase orders to sales orders and facilitates the flow between subsidiaries.
Deliverable
NetSuite Oneworld enables us to manage intercompany transactions and automatically generate elimination journal entries. The intercompany feature involves the following activities:
- Enable and setup the preferences related to the intercompany management.
- Setup Intercompany entities, chart of accounts and inventory items.
- Create intercompany purchase orders per subsidiary, as needed.
- Generate intercompany sales orders from intercompany purchase orders.
- Manage intercompany inventory transfers.
- Enter advanced intercompany journal entries for other intercompany transactions.
- Reconcile intercompany transactions.
- Run Intercompany Elimination from the Period Close Checklist.
- View the Intercompany Elimination report.
- User Training for Intercompany process in NetSuite (If required).
Assumptions
- A NetSuite OneWorld account with a feature to handle multiple currencies and subsidiaries is essential for intercompany processes.
- Update the existing chart of accounts or create a new chart of accounts to handle intercompany transactions.
- NetSuite allows us to create intercompany entities automatically or manually.
Risks
- The Intercompany feature cannot be disabled after it is enabled. This is true even if we have not created any intercompany entities or transactions.
Estimated Time
14 Hours
Requirement 5
Setting up Tax Code and Location in Transaction Line Levels
Requirement for adding tax codes and location based on the user’s role in transaction record line levels. Currently, the tax code is determined based on the customer’s province, but BigRig needs to change it to the user’s location based on their role. Additionally, the location should be automatically populated based on the user’s role.
e.g.: “Parts” for the parts-based role or “Tyre” for the tyre-based role.
Deliverable
Custom Record for Locations and Tax Codes: We will create a custom record to store location-specific tax codes. Each record will associate a location with its corresponding tax code.
Automatic Location Setting: During the creation of a transactions, the system will automatically set the location based on the current user’s role’s subsidiary. This ensures that the tax code is selected accurately, aligned with the user’s specific location.
Tax Code Population in Item Lines: When adding an item line to a transaction, the system will retrieve the appropriate tax code from the custom record based on the populated location. The tax code will then be automatically set for each item line, facilitating accurate tax calculations.
Restricting Tax Code Updates: We will develop these functionalities for the transactions. To maintain data integrity, after an order has reached the fully invoiced status or a standalone invoice has been fully paid, the system will prevent any further automatic tax code updates. This ensures that tax codes remain consistent and accurate in the final state of the order.
Assumptions
The proposed solution is based on the following assumptions:
- We assume that all users utilizing this customization will have the necessary permissions to access role and employee details to fetch location information.
- We will implement these functionalities for the Netsuite supported transactions records which are listed by BigRig.
- This will be supported only on UI.
Prerequisite
- Need the location and its corresponding Tax code details.
- Need list of the transactions for the implementing this custamization.
Questions
- If multiple users access and edit the same sales order, the system will not automatically update the location on each edit. As a result, the location will be updated only on the create context. The tax code might be populated based on the location during the edit, possibly leading to incorrect tax calculations. Could you please confirm the the location population only on the create context?
Risks
- A potential risk identified is related to the location setting during sales order creation. If multiple users access and edit the same sales order, the system will not automatically update the location on each edit. As a result, the location will be updated only on the create context. The tax code might be populated based on the location during the edit, possibly leading to incorrect tax calculations.
Estimated Time
12 hours
Requirement 6
Scheduling Monthly Sales Reports Based on Location
Requirement for scheduling monthly sales reports based on the location. BigRig needs to generate and send monthly sales reports for specific locations. The report should include sales and gross profit values and should be able to download it as an Excel file. Furthermore, the client requires that these reports be accessible only to the respective location managers.
Deliverable
To generate a monthly sales report categorized by location and dynamically schedule the report to be sent to managers based on their respective locations, we propose the following solution. Firstly, we will create a transaction saved search to gather the required data. However, since standard reports or saved searches alone cannot handle dynamic scheduling, we will implement a custom solution.
Our approach involves creating a new custom field within the location record. This field will allow us to select the appropriate manager for each location. By incorporating this custom field into the search results and email tab, we can meet our specific scheduling requirements effectively. This will ensure that the relevant managers receive the sales report promptly and tailored to their respective locations.
We believe this solution will provide the necessary flexibility and automation to streamline the reporting process and ensure the right managers receive the information they need in a timely manner
Similarly, the consolidated sales report will be sent to the specified person mentioned by BigRig.
Assumption
Based on the following assumptions, our proposed solution focuses
- We will consider only the invoice transaction for generating the report.
- The report will include both sales and gross profit values.
- It will be scheduled to run at the end of each month and automatically sent to the designated recipient in Excel format.
- There will be one manager for one location.
Estimated Time
10 hours
Requirement 7
Scheduling Min/Max Range Reports Based on Location and Alert Mechanism in purchase order
Requirement for scheduling Min/Max range reports for item availability based on location daily. Big wants to define minimum and maximum range values for each inventory item in the inventory details section or inline-level. When the available quantity at a specific location drops below the minimum range, a background report should be generated and emailed daily. In addition to the existing requirements of setting minimum and maximum range values for each inventory item and generating daily availability reports, BigRig has requested an alert mechanism to notify users when they attempt to purchase quantities that exceed the maximum range, considering the available quantity.
Deliverable
As a part of the feature implementation, two new fields, “Min” and “Max,” will be added to the item record. Users will have the ability to input values in these fields representing the desired minimum and maximum quantity for each item.
A search functionality will be implemented to identify items whose location based available quantity is less than the value specified in the Min field. The system will then schedule notifications to the respective persons responsible for these items, alerting them about the need for replenishment .
This feature enhances inventory management by proactively identifying items that fall below the desired minimum threshold and automating the notification process to ensure timely action is taken.
Alert Mechanism in purchase order
After adding an item to the purchase order, we will check the specified location at the line level. We’ll retrieve the available quantity at that location, along with the values from the “min” and “max” fields. Based on this information, we will determine the required quantity. If the quantity added in the purchase order does not match the required quantity, an alert will be shown to notify the user.
Assumptions
The proposed solution is based on the following assumptions:
- We are considering only Inventory items for scheduling process.
- The alert mechanism in the purchase order will be validated in both the editing and creation contexts.
- There will be no restriction for adding the line items inside the purchase order.
Estimated Time
14 hours
Requirement 8
Recurring Payments
Requirement for implementing a custom solution to process recurring payments every month. BigRig requires the ability to set up recurring payment details such as the amount, duration (in months), and specific dates for processing the payments. These recurring payments should be automatically applied to open invoices on the specified date for the designated number of months as specified by the customer
Deliverable
We will develop a custom record to capture recurring payment details for customers.
At the body level, the custom record will include the following fields:
- Owner of the Record: This field will primarily indicate the role responsible for managing these recurring payments.
- Payment Recurring Date: This date will be used to create payment records and debit the recurring amount. It will trigger the scheduled process for applying the amount to the respective invoices.
At the line level, the custom record will feature the following fields:
- Customer: This field will capture the name of the customer.
- Recurring Amount: The amount to be applied to invoices each month.
- Period: The number of months for which this payment method will recur.
- Is Matured: A check box to initiate the recurring process for each customer.
- Payment Details: A text field that will display the history of recurring payments. This field will be non-editable.
The managing role assigned to the recurring payment process will have view and edit permissions for the custom record. Upon creation, the authorized personnel can input the Payment Recurring Date and customer details, as depicted in the screenshot.
After saving the record, a scheduled functionality will run on the specified day each month. It will create payment records and apply the corresponding amounts to their respective invoices. The amounts will be distributed among the earliest created invoices for the given customer.
Invoices will be fully applied up to the limit of the recurring amount. Any unapplied invoices will remain open or partially applied until the next month’s recurring date.
Moreover, the option to stop the recurring process for a particular customer is available. The authorized personnel can check the “Is Matured” checkbox to halt the recurring functionality. Subsequently, in the following months, the recurring process will not be initiated.
If BigRig decides to resume the recurring process after a few months, they can recheck the “Is Matured” checkbox to reinitiate recurring payments. In this scenario, we will consider the newly updated amount and month periods based on the payment history. For instance, if the customer has a payment history for two months, and the updated value for recurring months is five, the recurring procedure will continue for the remaining three months with the new amount.
Once the recurring payments reach the limits defined by the history and the specified number of periods, the process will not be initiated further.
If BigRig needs to start a new cycle, the authorized personnel will need to create a new record for that customer.
Assumptions
The proposed solution is based on the following assumptions.
- Custom Record Management: The custom record will be exclusively managed by the authorized person, granting them full control over its contents and settings.
- Flexibility of Recurring Date: The recurring date can be modified as needed, allowing for adjustments based on changing requirements or preferences.
- Invoice Processing Order: Invoices will be processed based on the order of their creation for each specific customer, ensuring a systematic and organized approach to payment application.
- Invoice Selection Criteria: The solution will consider only open and partially applied invoices for processing, ensuring that outstanding payment obligations are appropriately addressed.
- Invoice Currency: The invoices will be issued in a single currency, eliminating the need for currency conversion during the payment application process.
- Customer-Specific Functionality.
- Open Invoice Status: Invoices that are not processed on each run will remain open until the next recurring date, allowing for subsequent payment application.
- Time Period for Processing: Invoices processed or considered for payment allocation will be within the period of one month from the past recurring date to the current recurring date.
Estimated Time
28 hours
Total Time
| Description | Time Required |
| Total estimated effort | 134 hours * |
*If any variations from the mentioned scope occur, the estimated hour will change.
*Production deployment not considered in this scope.