Package Creation Logic
From NewHaven Software Wiki
Russ horton (Talk | contribs) (→Package Rules) |
Russ horton (Talk | contribs) (→Gift Orders) |
||
| (2 intermediate revisions not shown) | |||
| Line 3: | Line 3: | ||
=Package Rules= | =Package Rules= | ||
| - | The primary goal of CMS's package logic is to determine/create the fewest possible number of packages required to complete the order. The rules below explain how that is done. We opt for the fewest number of packages because | + | The primary goal of CMS's package logic is to determine/create the fewest possible number of packages required to complete the order. The rules below explain how that is done. We opt for creating the fewest number of packages because you'd never want to have too many packages on an order. CMS requires all packages be set as shipped before setting its invoice as shipped (which usually also controls when the invoice's card can be charged.) You also wouldn't want to have to manually remove the extra packages. |
| + | |||
| + | CMS communicates on the warehouse document (invoice or pick ticket) what those packages are and, should they need additional packages/labels, on the CMS Manifest screen it is just a matter of clicking the Dupe button to add another package to the order. This duped package contains all of the package detail from the order so you'd only need to weigh the package and you can print the label. Similar options exist if you are shipping from within UPS Worldship, FedEx ShipManager or other carrier systems but generally they will not be as efficient as using the CMS Manifest screen. | ||
The rules CMS uses to determine if an item can go into an exiting package or if a new one is required is: | The rules CMS uses to determine if an item can go into an exiting package or if a new one is required is: | ||
* item's ship method | * item's ship method | ||
| - | * item's ship date (date scheduled to ship) | + | * item's ship date (date scheduled to ship) or arrival date (if used) |
* item's recipient | * item's recipient | ||
* item's flag for 'ship in own box' | * item's flag for 'ship in own box' | ||
| Line 18: | Line 20: | ||
In a single order, each line item could be shipping by different methods, shipping on different dates or shipping to different recipients. Those plus the item flag that indicates an item cannot ship with others (ships in own box) dictates when items can be combined in a package with other such items. | In a single order, each line item could be shipping by different methods, shipping on different dates or shipping to different recipients. Those plus the item flag that indicates an item cannot ship with others (ships in own box) dictates when items can be combined in a package with other such items. | ||
| - | When '''all''' are equal and the item is not set to ship in own box, it will be added to the first existing package CMS finds that matches all of the same criteria. If any are different or it is set to ship in own box, CMS will create a new package for that item. | + | When '''all''' are equal and the item is not set to ship in own or new box, it will be added to the first existing package CMS finds that matches all of the same criteria. If any are different or it is set to ship in own/new box, CMS will create a new package for that item. |
| - | Back-ordered | + | Back-ordered and drop ship items are placed in their own "virtual packages" (a fake package used as a place-holder for package data needed when the real package is created on fulfillment) that will be created since CMS cannot know if these items on the order can or will ship together. Future ship items, on the other hand, will be placed into the same package if it meets the same criteria for date and everything else. Your system may not be configured to create/show virtual packages however in which case no packages would be displayed until fulfillment. (see Setup>fulfillment options>shipping) |
This logic is true for both hand-entered and imported orders. Perhaps an important point to make is the CMS will always use this logic to create packages for imported orders. We do not expect or allow the order source (call center, website, etc.) to decide which items will be going into which packages and thus do not support package relationships in our XML/imports. | This logic is true for both hand-entered and imported orders. Perhaps an important point to make is the CMS will always use this logic to create packages for imported orders. We do not expect or allow the order source (call center, website, etc.) to decide which items will be going into which packages and thus do not support package relationships in our XML/imports. | ||
| Line 39: | Line 41: | ||
=Gift Orders= | =Gift Orders= | ||
| + | ==Version 8.0 or earlier== | ||
For orders with multiple recipients (aka multi-ship orders) each recipient is stored with its package. If you need to remove a recipient from a multi-ship order, simply remove its items from the order. When you save the order CMS will remove any empty packages from the order and thus the recipient will also be removed. The side-effect of this of course is to make sure you have items assigned to any recipients that you don't want dropped from the order when saving. | For orders with multiple recipients (aka multi-ship orders) each recipient is stored with its package. If you need to remove a recipient from a multi-ship order, simply remove its items from the order. When you save the order CMS will remove any empty packages from the order and thus the recipient will also be removed. The side-effect of this of course is to make sure you have items assigned to any recipients that you don't want dropped from the order when saving. | ||
| + | |||
| + | ==Version 9.0 or later== | ||
| + | In CMS 9.0 you can delete the recipient from the order and all its items and packages will also be automatically removed. The exception to this is if you've deleted the last recipient on the order and, in this case, you'll have the option to keep that recipient's items and associate them instead with the purchaser (handy if you didn't intend for this order to be a multi-ship.) | ||
| + | |||
| + | Unlike 8.0 and earlier, CMS will store recipients with the order even if they have no items. This allows for some greater flexibility in how you enter very large gift orders. Don't be afraid to save your work along the way and come back to finish the order later if needed. No information will be lost. | ||
Current revision as of 00:11, 30 April 2013
Contents |
Overview
When adding an item to an order, how does CMS know if it needs to create a new package or decide which existing package to place it in? This article will explain the logic CMS uses and the various factors that impact CMS's use of packages.
Package Rules
The primary goal of CMS's package logic is to determine/create the fewest possible number of packages required to complete the order. The rules below explain how that is done. We opt for creating the fewest number of packages because you'd never want to have too many packages on an order. CMS requires all packages be set as shipped before setting its invoice as shipped (which usually also controls when the invoice's card can be charged.) You also wouldn't want to have to manually remove the extra packages.
CMS communicates on the warehouse document (invoice or pick ticket) what those packages are and, should they need additional packages/labels, on the CMS Manifest screen it is just a matter of clicking the Dupe button to add another package to the order. This duped package contains all of the package detail from the order so you'd only need to weigh the package and you can print the label. Similar options exist if you are shipping from within UPS Worldship, FedEx ShipManager or other carrier systems but generally they will not be as efficient as using the CMS Manifest screen.
The rules CMS uses to determine if an item can go into an exiting package or if a new one is required is:
- item's ship method
- item's ship date (date scheduled to ship) or arrival date (if used)
- item's recipient
- item's flag for 'ship in own box'
- item's flag for 'requires new box' (CMS 9.0 or later)
NOTE: Items that are configured as does not ship will not be added to packages.
Explanation
In a single order, each line item could be shipping by different methods, shipping on different dates or shipping to different recipients. Those plus the item flag that indicates an item cannot ship with others (ships in own box) dictates when items can be combined in a package with other such items.
When all are equal and the item is not set to ship in own or new box, it will be added to the first existing package CMS finds that matches all of the same criteria. If any are different or it is set to ship in own/new box, CMS will create a new package for that item.
Back-ordered and drop ship items are placed in their own "virtual packages" (a fake package used as a place-holder for package data needed when the real package is created on fulfillment) that will be created since CMS cannot know if these items on the order can or will ship together. Future ship items, on the other hand, will be placed into the same package if it meets the same criteria for date and everything else. Your system may not be configured to create/show virtual packages however in which case no packages would be displayed until fulfillment. (see Setup>fulfillment options>shipping)
This logic is true for both hand-entered and imported orders. Perhaps an important point to make is the CMS will always use this logic to create packages for imported orders. We do not expect or allow the order source (call center, website, etc.) to decide which items will be going into which packages and thus do not support package relationships in our XML/imports.
When Package Logic is Used
This package logic is applied each time an invoice is created. Examples include new orders, fulfillment (back order and future ship) invoices and exchanges. In a situation where you have multiple items on back order, CMS will place them each into their own (virtual) package. When they fulfill, however, CMS re-applies the package creation logic for the fulfillment invoice. There you'd see the items that are being fulfilled at that time go into the same package...provided they should based on the earlier explanation of our package logic.
CMS will drop empty packages when you save the order. Through the course of editing an order you may move items into other packages, have recipients with no items, etc. In these cases, if the package is empty, there is no reason to save it and it will be deleted but not until order save. At that moment, CMS will also renumber the packages for the invoice so the package numbers are sequential, starting from 001.
There are no rules for creating new packages based on weight, qty or other criteria. Such rules, including those user-defined, may be considered in future CMS versions. Please submit any such requests to NewHaven Software for consideration. If considering such rules, however, remember that you are far better off with too few packages (more can be easily be created in the CMS Manifest or your shipping software) than with too many (invoice shipped date won't get set until all packages are shipped.)
Modifying Package Assignments
As a rule CMS does not expect operators to decide which items will ship in which boxes or determine how many boxes will be required. So, in most cases, you should not have to pay any attention to the package assignments. In cases where you do need to have control over the package numbers, you can manually manipulate the packages items are assigned to.
Until an item is shipped, you may manually reassign items to new or different packages. Once an item or its invoice has been marked as shipped, these fields will become locked and no further edits to packages are allowed. Bear in mind the comment in the section above which suggests that you are better served by having too few packages on the order than you are by having too many. If you're ever unsure, err on the side of too few packages and let the warehouse determine how many are needed.
Manual reassignment of items to packages can be done on the Items screen of Order Entry. There, in the field 'Package #' you can select from existing package numbers or use the + button to create a new package.
Gift Orders
Version 8.0 or earlier
For orders with multiple recipients (aka multi-ship orders) each recipient is stored with its package. If you need to remove a recipient from a multi-ship order, simply remove its items from the order. When you save the order CMS will remove any empty packages from the order and thus the recipient will also be removed. The side-effect of this of course is to make sure you have items assigned to any recipients that you don't want dropped from the order when saving.
Version 9.0 or later
In CMS 9.0 you can delete the recipient from the order and all its items and packages will also be automatically removed. The exception to this is if you've deleted the last recipient on the order and, in this case, you'll have the option to keep that recipient's items and associate them instead with the purchaser (handy if you didn't intend for this order to be a multi-ship.)
Unlike 8.0 and earlier, CMS will store recipients with the order even if they have no items. This allows for some greater flexibility in how you enter very large gift orders. Don't be afraid to save your work along the way and come back to finish the order later if needed. No information will be lost.
