Proposal For Splitting a sales order into Multiple Invoices when invoicing

OTGN-823

Proposal summary

This proposal describes Splitting a sales order into Multiple Invoices when invoicing in Netsuite.

Requirement 

Users will manually create a sales order, combining previous open sales orders for its back ordered items (No automation required here). But once the new sales order (combined one) gets created we have to close the item lines on the respective parent sales orders. 

When the items in this new SO are shipped, based on the PO# lines need to generate the invoices separately.

Subsidiary condition: AU, NZ.

Our Solution

Background Information

NZ Subsidiary

A scheduled script Upload Orders to NZ Server – Scheduled is used to connect with SFTP server host named sftp.fliway.com and send data to the server.  This scheduled script is scheduled every 15 minutes a day. The script loads the results from the Orders to be Sent to JJ OTGN-324  and uploads the sales order data to the server. The search Orders to be Sent to JJ OTGN-324 is used to get sales order data with subsidiary OX Tools NZ – New Ownership, status Pending fulfillment and location NZ – Auckland Warehouse and NZ – Auckland Quarantine.

The scheduled script Download IF and process – Fly way EDI – Scheduled downloads the data from the server and creates Item fulfillment and Invoice. This scheduled script is scheduled every 15 minutes a day.

AU Subsidiary

Currently, the scheduled script Axima Connector is used to connect with an FTP server host named ftp.axima.com.au and send data to the server.  This scheduled script is                scheduled every 15 minutes a day. The script loads the results from the customsearch_ords_sent_to_3pl_3  and uploads the sales order data to the server. The search customsearch_ords_sent_to_3pl_3 is used to get sales order data with subsidiary OX Tools AU, status Pending fulfillment and location Axima NSW, AU – Axima WA, OX Tools NZ – Old Ownership, Auckland Warehouse, Maungaturoto Warehouse, NZ Warranty Claims, NZ Write Off Location, VAN Ben Foster, Wellington Warehouse.

The scheduled script Import Shipments from FTP_AXIMA downloads the data from the server and creates Item fulfillment and Invoice. This scheduled script is scheduled every 15 minutes a day. 

Prerequisites

  • Need credentials to connect to the Test server. Then only we can test the working of the entire process.
  • Need to add a custom column field in Sales Order and Invoice to store the Parent PO#

Description of the task

Our Solution is to create a new transaction line field named PO#(free form text field) in the item line of the sales order, where the user needs to enter the Customer Order number(internal id: otherrefnum) of the parent sales order when they create the summarized SO. And this field will also be applied to the invoice record. We assume the PO# for each sales order will be unique per customer.

We will deploy a script which will trigger the save action of the sales order. Based on the PO# in the item line, the script will load the parent sales order and close the corresponding item line in the parent sales order. This script will trigger only in the creation of sales orders, not the update of sales orders.

We will have to update the current scheduled scripts  Download IF and process – Fly way EDI – Scheduled (for NZ subsidiary) and Import Shipments from FTP_AXIMA (for AU subsidiary) to create separate invoices for different parent sales orders based on the PO# in the item line. The item quantity in the invoice will be set based on the back ordered quantity in the parent sales order.

Risk

  1. We expect only  25 unique PO# in single combined sales order. We can update only 25 different sales orders using the real time script due to the governance issue. 

If there is any chance to add more than 25 PO# in single combined sales order, then we will have to use a scheduled process and the effort will vary accordingly.

  1. We assume PO# is unique for each sales order per customer.
  2. If the parent sales order’s customer order number is added to the PO# field in the item line of the sales order, then script will close the corresponding item lines in the parent sales order that have back-ordered quantity greater than zero.
    – If the parent sales order has multiple backordered item lines for the same item, then the script will close all those lines.

– The Item lines to be closed on the parent SO will not be compared based on the Quantity on the combined SO

  1. Users have to enter the single PO# in the sales order item line(Exact match will be considered to identify the Parent SO). So they have to add separate item lines in combined sales orders for the same items in different parent sales orders
  2. We are considering only sales orders with status Pending fulfillment for this customization.
  3. The proposed solution may not work as expected if the process goes to a third layer.

For Example : Parent SO > Combined SO > Next Combined SO

  • If the user enter the PO # of the “Parent SO” in the “Next Combined SO”, then Item line closing will not happen in “Combined SO”
  • If the user enter the PO # of the “Combined SO” in the “Next Combined SO”, then invoice creation will not be happen based on the Customer PO# of the Paret SO

Alternative solutions

  1. User need to enter the “Combined SO” in the “Next Combined SO” creation and need to update the PO# column by editing the SO to process the invoice correctly
  2. We will have to include two Column field for PO #, one is for Parent SO and the other one is for Combined SO.

So OX needs to use a unique PO# internally for the combined SO and that can be used as identity the previous SO

This is not included in this scope

Leave a comment

Your email address will not be published. Required fields are marked *