A star appears when the vendor is the preferred vendor for a specific item.
Availability of the item is displayed. To display the quantity at the warehouse, simply hover over the available quantity.
Finally, a navigation button directs the user to the item layout.
Tab: Dependent Orders
Process: When clicking the Order All button, purchase orders and assembly orders (for subassemblies) are created. If an existing purchase order exists, then a new line will be added.
Problem: When an existing purchase order does exist and a new line is added, the grand total of the purchase order did not update.
]]>Escape closes the window (same behavior as before).
]]>This works when the BOM Tree is a stand alone product, but in Trayse Inventory there is now a Dependent Order that lists the various units that need to be purchased and the subassemblies that need to be assembled.
Now, the need to fulfill only considers what is on the shelf.
This is the old method of need to fulfill where the quantity available was added to the quantity that can be assembled. This example highlights that cases for the subassembly BLAC-PEA-08.
]]>Previously, the Order button disappeared when an order was placed. Now the button changes to a gray button, informing the user that the process is completed.
There was also an issue where the user could click the button when the Assembly Order was in a Canceled status. Now, when an Assembly Order is canceled, all of the Order buttons turn gray.
]]>Trayse Inventory now has dependent orders. These are orders that are associated with a final build. When you put together a kit or a manufactured item, the final product (a.k.a. finished good) requires other materials. Some of those materials are purchased from vendors and some are subassemblies that require their own Assembly Order. Failure to track this data will mean one of two things:
Both can be expensive.
Dependent orders allows the user to clearly track the needed materials and order in an appropriate time.
]]>Section: Subheader
There are now three information icons Allocated, On Order, and On Backorder. When those quantities fields have a value other than zero, this icon becomes active.
Clicking the icon will display the related orders that constitute this aggregate. A caret icon in the list enables users to navigate to a particular order.
Thanks to Jeff T. for pointing out this bug.
]]>Creating a PO line from the Item
The second is to use the Add button on the PO layout.
Creating a PO line from the PO
Although the results of the process should have been the same, regardless of where the PO line originated, there were slight differences. These have been fixed so the process now produces the same result.
]]>Vendor items with different units
This worked well when the units of measure where different. However, it was pointed out that when the units are the same, it did not work. That has been fixed.
Vendor items with different units
Thanks to LaVerne for pointing out this bug.
]]>Now, the process checks not only what is available (i.e. what is on the shelf), but also if any existing Assembly Orders are making that SKU and of those quantity being made, how many are available (in other words, how many are not on backorder).
This reduces unnecessary Assembly Orders and an unintended build up of stock.
]]>Now, during the Putaway process, a new Transaction record is created called "Received Reset". This decrements the On Hand value for a Receiving location before incrementing the On Hand value at the Putaway or Picking location.
Before:
After:
Now, Received On Order quantity is zero.
Documents are easily added via Drag and Drop. These are stored externally.
Added checkbox on the Shipping Address tab to auto-populate if the address is the same as the Billing Address.
• Moved unconnected base tables to the top left of the graph. Previously, they were intermixed with table occurrences that have relationships (TOGs) in order to maintain alphabetical order from top to bottom. Alphabetical order is still preserved, but divided among two distinct groups: those without relationships are at the top and those with relationships are below.
• Increased white space between TOGs for better readability.
]]>Card window: Item Location
When adding a new record, the script goes to the warehouse global field, awaiting user input. The field is a popup and behaves slightly differently on Windows than on Mac. On Windows, it appeared to populate the field, but it didn’t. Then, when moving to the next field, the warehouse global field appeared to clear. To rectify this appearance issue, the warehouse global field is no longer selected when adding a new location for an item.
]]>Card window: Menu
When adding a new item record, the process did not automatically create the necessary Quantity record for the total of all warehouses for that item.
]]>Card window: Vendor
When adding a Vendor for an item, all the fields are required, but the UI didn't indicate that.
]]>Changed the message for releasing a sales order. Message now includes the other records that were created, including (when appropriate) Assembly Orders, Purchase Orders, and Pick. Multiple Assembly Orders and Purchase Orders can be created on a single release. The message displays up to 3 of each order type. When there are more than 3, a 4th line includes the difference and a note to tell the user where to find them. For example, if 12 Assembly Orders were created, the message is:
ASSEMBLY ORDERS
AO10010
AO10011
AO10011
+9 more. See More…/Assembly Orders.
Added POs to Sales Order layout. When an item is added to a Sales Order and there are no available quantities, then that item is on backorder. A purchase order is created with this item added as a line. Previously, there was no way to navigate to this purchase order from the Sales Order layout. Users can now go to More…/POs from the Sales Order layout.
Both scripts get the last reference number of a particular order type. Since orders are based on a universal data model (i.e. all orders are built on one table) then the Serial Number in the data setup cannot be used.* The two scripts were created a month apart and each had a slightly different method and handled different use cases. One handled a UI process (i.e. the user created a new order record) and the other handled scripted processes (order records were created as part of a script).
*This is not entirely true. The presumption of Trayse Inventory is that your company would like to have a readable order number that is prepended with the order type abbreviation AND that these order numbers should be sequential. That is, purchase orders would have PO10001, PO10002, PO10003, etc. and Sales Orders would have SO10001, SO10002, SO10003, etc.
There is another option, which is to use the serial number feature of the field definition. This would remove sequencing within a given order type. Instead, order number might be PO10001, EO10002, SO10003, PO10006, EO10004, SO10005, PO10006, etc., or more simply 10001, 10002, 10003, 10004, etc. but among all order types.
]]>The On Order quantity was not updating when:
(This is using the Create PO button on the bottom right of the Item layout.)
Two scripts were altered:
Modifications to select warehouse ID… was necessary to fix the bug. Modifications to set the balance… is precautionary.
See log at bottom of those scripts for details.
]]>Added written instructions for adding a new menu item. Instructions are to the right of the visible layout, in Layout Mode.
Button pointed to “display receipt history for order” instead of “display pick history for order”.
Script: “display pick history for order” pointed to the Receipt History layout instead of the Pick History layout. Likewise, the single search criteria was
Set Field [ RECEIPT::orderID ; $orderID ]
Instead of
Set Field [ PICK::orderID ; $orderID ]
Custom dialog at the end of the script was also updated.
]]>Changed the Release to Picking… button to Release Sales Order. Picking is now by order. Batch picking has been removed. This is in preparation for creating an Assembly Order (a.k.a. Build Order, Production Order, Manufacturing Order, Work Order, etc.).
Script trigger passes a JSON object with a misspelled key (“Compnay Type” should be “Company Type”).
JSONSetElement ( "" ; ["Compnay Type" ; "Vendor" ; JSONString] ; ["Window Top" ; 160 ; JSONNumber] )
Should be
JSONSetElement ( "" ; ["Company Type" ; "Vendor" ; JSONString] ; ["Window Top" ; 160 ; JSONNumber] )
Note: Thanks to Humberto Becerra for finding this.
]]>The field LOCATION::location was not visible on the Location layout as it was a calculation field and can be seen in the sub-header section (a.k.a. light blue section). Added the location to the layout, below description and above zone.
Changed LOCATION::location to an auto-enter calculation, creating a string from zone, aisle, section, row, bin.
NOTE: Location should be modified to best suite your warehouse organization. Zone, aisle, section, row, and bin are commonly used, but may not be required in your situation. Customize as needed.
Created a card window for users to add a location via the Putaway layout. Previously, a user could add any alpha numeric string in the Actual Location field. If the string did not correlate to an existing location, it was added to the Location table. However, only LOCATION::location was updated and not the fields zone, aisle, section, row, or bin. Now, if a user enters a location that does not exist, a card window appears and offers the user a list of locations for that warehouse or the option of creating a new location.
The On Order and On Backorder fields in the Body part were in the wrong place (On Backorder was in column 4 and On Order in column 5).
]]>Adding a single vendor did not mark that vendor as the primary vendor.
Modified script so that the first vendor added is marked as the primary vendor. Otherwise, an item with a single vendor will not have a primary vendor.
]]>When deleting a vendor in the Item Vendor card window, the global variable $$itemID was cleared. This prevented the item ID from setting in the ITEMVENDOR table if the user added a new vendor while the card window was still open. (Closing and reopening the card window re-set the $$itemID.) $$itemID now persists while the card window is open, even when a vendor is deleted for a particular item.
]]>Creating a new PO line left an empty card window open.
]]>A button has been added to the home layout to remove the demo data that ships with Trayse Inventory. Obviously, this can be a very dangerous process. It’s great for removing demo data but you don’t want it to remove production data. Make sure to delete the temp scripts after removing the demo data. They are conveniently stored in a Temp folder in Script Workspace.
If the customer does not have a shipping address, then a card window will appear. This replaces the behavior where the user was taken to the customer’s record in the Company layout, which made it harder to return to the Sales Order layout.
If an SKU does not have any vendors associated with it, the Preferred Vendor section has a gray text that reads "Add vendors" along with a button that opens up the item-vendor card window.
Can now search for a Vendor from the Preferred Vendor field in Find Mode.
When clicking the Create PO on the Item layout, the script now opens the card window for the newly added line (parent window for the card window is the Purchase Order layout). The cursor is in the quantity ordered field, ready for the user to add a quantity.