This support is implemented through the use of the Customer Type File Maintenance, field “6. Use Different Identity” to indicate whether a customer type is drop ship or not.
When users answer “Y” to the field “6. Use Different Identity,” then the application will prompt the second question asking if the user wishes to use customer attribute “_IDENTITY” for identity address if attribute “_IDENTITY” has been setup. The attribute “_IDENTITY” should have the following fields:
Ref-1: Company Name
Ref-5: Phone No.
Users can either answer “Y” or “N” to use the “_IDENTITY” attribute question. The value will be saved in a new field in the Customer Type table. If the “_IDENTITY” attribute is not set up, then the application will not prompt for this question and the field will always have an “N” value (any value other than “Y” implies “N”).
If the user answers “N” to the “_IDENTITY” attribute question, then the identity information is saved in the Customer Type record.
If the user answers “Y,” then the identity information is saved in the Customer Attribute “_IDENTITY.” If the customer attribute is not defined, the company name and address as set up in the Customer File will be used.
This method is more flexible than using one single Customer Type DROP to represent drop ship because now you can have multiple drop-ship customer types. Also, it is more flexible since the Customer Address (used for A/R purposes) does not have to be the same as Customer Identity Address (used for consumer relationship by drop-ship customer).
Drop-ship orders are only allowed for customers with the proper Customer Type and can be entered for any warehouse.
The Company Name, Address 1, 2, 3 and Phone No will print in place of the Customer File name on any invoice form for that customer. You must set option 6. Print Co Name On Invoice in COP Setup to be able to print the indentity name and address on the invoice.
All drop-ship customers should be assigned the invoice form base on Customer File field “36. Invoice Form” to print after successful shipping verification. This form will be generic and could be formatted as a packing list for the consumer. The main issue to be considered is the invoice laser form template. Currently, the Elliott Print Option window defaults to the invoice laser form template based on the workstation ID. Since the same shipping verification station can process various kind of orders, including regular orders and drop-ship orders, each order processed may need to use a different type of laser form. The invoice printing application will dynamically change the workstation ID and result in a different default on the laser form template.
To accomplish this, a new Global Setup flag has been added under COP-Func -> Invoice Printing:
35. DropShip CusTp to Use Inv Form# as WS Prefix? The default value is “N” for backwards compatibility. If the flag is set to “Y,” then during the invoice printing for one order only (not applicable to batch invoice printing), the invoice printing application will look up the customer type to determine if this is a drop-ship order. If so, the workstation prefix will be the customer invoice form.
For example, if the normal workstation ID is “JOHN” and the customer invoice form is “56,” the Invoice Print Option window will use the workstation ID “56JOHN.” This allows users to choose a default laser invoice template for the workstation “56JOHN.”
If this is a regular order and customer type is not a drop ship, then the workstation ID will be “JOHN.”
The benefit of this method is that you can have different laser invoice form templates for different Invoice form numbers per customer. This allows you to generate a custom-made laser invoice (packing list) per customer.
The drawback is that you will have to set up different combinations of invoice form numbers workstation by workstation. For example, if you have 10 different shipping workstations, then each time you introduce a new drop-ship laser form template, you will need to go to these 10 different shipping workstations to set up the default for the first time one by one.
How does this feature handle the ability to enter any Bill-To and Ship-To address information on the order header while referencing the Bill-To account for payment? We currently have Global Setup flags in the Order Header Screen for the following:
12. Allow Manually Override of Ship To Address?
13. Allow Manually Override of Bill To Address?
Global Setup now allows the user to specify whether the Ship To and Bill To Addresses can be overridden for drop-ship customers. If the user answers “N” to these two flags, the application will prompt another question in the window:
Allow override for Drop Ship Customer Type? The default is “N." If set to “Y,” then the system will allow the override of bill-to or ship-to addresses for drop-ship customer types, even though these two flags are set to “N.” The end result is that flag 12 and 13 will be displayed as follows if their value is set to “N":
12. Allow Manually Override of Ship To Address? N Drop Ship Y
13. Allow Manually Override of Bill To Address? N Drop Ship N
On the other hand, if these two flags are set to “Y,” then there’s no need to prompt for the Drop Ship question. Therefore, it will be displayed as follows:
12. Allow Manually Override of Ship To Address? Y
13. Allow Manually Override of Bill To Address? Y
This change will allow the user to enter the Ship To or Bill To address for a drop-ship customer via Order Entry, Copy Order, Sales Desk, Recurring Orders, Sales Order Import, and via web services. If the drop-ship flags are set to N, this is also enforced in these applications.
For customers running the Firearms Enhancement, only Non-BATF controlled items can be entered on drop-ship orders. This is controlled via the Exclude BATF options in the Product Category and the Item User Defined files. When entering an order for a drop-ship customer, the system will check for a valid FFL License. If no license is found or the license is expired, then the system will only allow the entry of non-BATF controlled items. If the user attempts to enter an order for a BATF controlled item, the system will either stop the entry or put the order on hold. This is controlled via option 6. Allow Entry Serial Itm For Invalid/expired FFL in Global Setup. If the order is imported the order will be placed on hold once the picking ticket is printed. If the order is generated from web services, the order will be placed on hold.
Programs Modified: ARCUSTYP.FD, NSCTLFIL.FD, NSCTLFIL.W30, ARTYPMNT, NSCTLMN5, NSCTLINI, CP30S2, SYDIFFID, CP0101, CPORDIMP, CP0102, CPQUOSCN, CPRECHDR