4 votes1 comment · CMS - Suggestions for features and enhancements » Purchasing · Flag idea as inappropriate… · Admin →
If I understand your request correctly, you are saying you want CMS to consider the components of unsold kits as available stock, is that right?
If so, I think I need to understand how this would work for you. Even if you could see the component inventory as available in the report, from a process standpoint, CMS does not presently have a facility to break up these assembled kits into their components.
It is functionality we have considered adding to Kit Builder, where kits are constructed (removing inventory from components and adding it to the assembled kit.) The feature would be to deconstruct kits (or explode as we've affectionately referred to it), putting the components back into stock and removing the inventory from the assembled kit.
I'll also throw out the alternative to assembled kits which is our standard kit, those which pull stock at the time of order. With this type of kit the components remain in a shared inventory from which any kit can pull from them. That component allocation takes place when the item is added to the order. In this case the Items To Reorder report would work as requested, always showing total available regardless of the kits that may pull from its stock.
For clarity, the difference between an assembled kit and a standard kit that pulls inventory at order time is the Product checkbox seen here: https://www.screencast.com/t/qLbp0nE6
1 vote1 comment · CMS - Suggestions for features and enhancements » Fulfillment · Flag idea as inappropriate… · Admin →
Thanks for the suggestion. If it were purely for reporting purposes you could use on of the User Defined product fields and then write your custom report referencing that field. If you're not familiar with the User Defined fields, here is a screenshot of where they are in Setup and the Products pages - https://www.screencast.com/t/c1pn2l3Lx
There are a number of other fields that you may not be using that could also serve the purpose if you are already using all of the User Defined fields:
...or for a small amount of custom programming we could add the field for you.
I'd be interested to understand what kind of reporting you'd want affected by this seasonal flag. I get the concept of the flag certainly but not yet fully grasping what it would do for you.
If we went as far as adding a field just for this (or a date range, like we do with discounts) we should then consider if we want product uploads to your website(s) to take this into account, only uploading during their season, for example.
Let me know your thoughts.
0 votesunder review · 1 comment · CMS - Suggestions for features and enhancements » Customers · Flag idea as inappropriate… · Admin →
I don't think I'm seeing the same thing. Here is a short video showing my attempt to reproduce what you're reporting:
Can you explain how what you're seeing differs or how your steps are different?
0 votesunder review · 1 comment · CMS - Suggestions for features and enhancements » Fulfillment · Flag idea as inappropriate… · Admin →
Currently we're using a file method to communicate with Amazon (beta) and will transitioning off of that in favor of using their web services (AWS) that would allow CMS to communicate with Amazon directly without the use of files.
In a similar manner Walmart has functionality that allows you to upload and download orders in Excel from their Seller Center
or they also offer an API for direct communication
The latter is more complex and would require a dedicated CMS plug-in so that would be an option further down the road unless there is high demand for it. The Excel method, however, may be possible to work with sooner than later.
Let us know your Walmart order volume and get us a couple of sample order downloads from their Seller Center and we can advise on what your options are for optimizing the import/export.
1 vote2 comments · CMS - Suggestions for features and enhancements » Fulfillment · Flag idea as inappropriate… · Admin →
The imported (and unverified) orders have not yet been stored in our tables so traditional SQL queries would not be possible. I understand you're asking for "SQL-like" queries but thought we should get that on the table first.
I'll provide one example that came up not too long ago. We had a request to have a validation check for orders whose customer had an outstanding balance, and another when that customer was set to 'do not accept orders'. Here these are not elements of the order data that could be queried but instead referenced their matching customer...which is not yet know (established during verify). Here special code had to be written to establish the customer match so that the customer data could be queried.
In summary, without being able to do typical SQL queries, we've instead had to program validation checks unique to their purpose. While this doesn't currently lend itself to an adhoc query, I don't want to discount it either.
We should examine some examples that are driving this request. If we find that having access to X, Y, and Z would fit most of the need, it would be worth exploring to see if/how we could make that happen.
To start the process I'd encourage you to post back here with some examples of cases you're trying to handle better, and what elements you'd want in the query. Consider if these examples are representative of most of the foreseeable need, as much as that can be known. Can we get it down to small set of criteria (e.g. X, Y, and Z) that, if you had them, would largely address the need.
I will close by stating that generally it is not too difficult for us to add new (specific) validation checks. While we do charge custom programming for them, they are typically only two hours. Each year we add more and expect the list to continue to grow.
1 voteunder review · 1 comment · CMS - Suggestions for features and enhancements » Email · Flag idea as inappropriate… · Admin →
Good to understand this scenario. Shipment confirmations can be configured uniquely for each shipping method but not order confirmations, which I think is what we'd want to use.
We've been considering a revamp to how email confirmations are set up. Instead of making them order source specific, we'd instead have a list of order sources that you could select that this confirmation would be used for. We'd do similarly shipping methods for shipping confirmations and will now also look at doing the same for order confirmations.
3 votesunder review · 2 comments · CMS - Suggestions for features and enhancements · Flag idea as inappropriate… · Admin →
I like the approach although on its own it wouldn't seem to solve the workstation specific need.
Do just your remote users run on terminal service sessions or do your local users as well?
I ask because we store workstation specific settings in the registry which, for TS sessions, is shared among all users. This is where we'd store the workstation warehouse default if implemented. As long as the warehouse selection should be the same for all remote users, I think this approach will work.
Otherwise noting the limitations of the current method of workstation specific settings with TS so you can comment if this is something we'd have to change to make it work for your situation.
5 votes7 comments · CMS - Suggestions for features and enhancements · Flag idea as inappropriate… · Admin →
Thanks for the update on this Doug.
Presently we have the ability to assign SKUs to order sources for those we have integrations with such as CommerceV3 and Magento.
This assignment of SKUs to order sources allows you to control which products get uploaded to which sites, so you could run multiple sites with different or shared products (a single SKU could be assigned to any or all import sources.) That is the rub though in that it only works for sources that we have integrations with.
I'll explore the possibility of support non-integration SKU:source assignments and the addition of a field dedicated to that site's product code there. As you'll see in the screenshot, we've already started adding source specific fields such as the product URL (coming in the next release.)
Worth moving this into a separate Suggestion if there are other related changes desired.
Acknowledging your reporting comment but I'm having troubles getting past the idea of not having a unique vendor sku per CMS SKU and in what situations or frequency that is required. If it occurs, it seems it would be the exception to the rule and, if so, I'm not sure it warrants the amount of work needed to build it into SKU Wizard or that anyone else would need it. If you disagree, can you give me a better sense of the situations in which you or a vendor wouldn't need their vendor sku codes to be unique?
That said, I recognize that even if this is not needed often, you have a lot of SKU's per product and is cumbersome to manage. If it helps, a simple SQL statement can be used to update all of the SKU's for a product to the same vendor sku:
Set PRIMSUPSKU = 'xxxx'
Where PROD_CODE = 'widget'
This field was intentionally omitted from the those that could be copied in the SKU Wizard. We believed its value would have to be unique for each SKU (size/color combination).
Are there cases where a vendor does not have a uniquely identifying code (vendor sku) for each size/color and you'd want the same vendor sku for each size/color combo in CMS?
3 votesunder review · 1 comment · CMS - Suggestions for features and enhancements · Flag idea as inappropriate… · Admin →
We do this now for dropship items but, since you mention doing this for back ordered items, I read that you're wanting a similar processing option for back ordered stocked items.
Like dropships, this process could result in multiple PO's generated for that order as the items could be from different vendors.
Can you elaborate on what differentiates when you'd want to generate PO's for a single order vs the current more general handling of creating PO's for resupplying your stock and/or multiple orders?
In part I'm trying to understand if there is a set of rules we should consider to trigger PO creation (like we do for dropships).
I also question if this should be an option from Fulfillment Manager>Back Orders to generate PO's for selected orders.
It would be helpful again to just understand when/why to create PO's just for a specific order.
4 votesunder review · 1 comment · CMS - Suggestions for features and enhancements » ToDos · Flag idea as inappropriate… · Admin →
Not the first time this has come up but first we've seen it on User Voice. The way we've thought about it thus far has been two tiered:
1) Allow an employee to be able to see ToDo's they have created for others, not just those they own.
2) Have an employee permission that would allow the view/editing of ToDo's owned by others, even if they did not create them. This is more of a management function vs #1.
Please post you comments on how this aligns with your expectation/need or how else you might visualize the solution.
12 votesunder review · 1 comment · CMS - Suggestions for features and enhancements » Customers · Flag idea as inappropriate… · Admin →
To clarify this request for other voters:
There is a CMS (workstation-specific) setting called 'Save Column Order & Width in Find Customer' that allows you to reorganize the columns and their widths in the search results when using Find Customer. If the setting is not used, search results will always be displayed using CMS's default.
Another means of search for a customer is the automatic search that takes place as you start entering a new customer into Order Entry or the Contact Manager. CMS displays a list of 'Candidates' of names in your mail list that could match the one you are typing in. More of a reactive search vs a proactive search.
The request here is to allow changes to the search results in the candidates list to also be governed by the above setting, retaining the column order and widths for future searches on that workstation.
19 votesunder review · 1 comment · CMS - Suggestions for features and enhancements » Fulfillment · Flag idea as inappropriate… · Admin →
We had considered adding this to CMS in January 2015 when the carriers started applying dimensional rating to ground services. It was hard to anticipate how much it would be needed and, as it turned out, there wasn't much demand at the time. That is starting to shift now with USPS offering cubic pricing to some shippers in our space so we are taking a fresh look at what it would take to add this.
I agree though that it would appear to consist of creating a list of commonly used packages and their dimensions so they could easily be selected in a combo in the Manifest instead of having to enter the dimensions each time. I'm hoping we can also incorporate package identification by barcode to make the selection easier. In many cases the boxes already have barcodes on them (e.g. Priority Mail) and the shipping clerk is often already using a scanner - http://wiki.newhavensoftware.com/index.php/Shipping_Station_-_Best_Practices#Shipping_Best_Practices
1 voteunder review · 1 comment · CMS - Suggestions for features and enhancements » Purchasing · Flag idea as inappropriate… · Admin →
CMS does have two user-defined fields for products that may fit the bill. See my example here - http://screencast.com/t/ybZ8Dc0kLAF
On a related note, CMS also allows you to set an expiration date on inventory lots during the receiving of purchase orders. See - http://screencast.com/t/uGJySAeymxKD
Noting this expiration date field is not currently available in Stock Manager to be set for inventory received manually (not through Purchasing). That would seem to be a reasonable enhancement for us to make if it was needed.
3 votesunder review · 1 comment · CMS - Suggestions for features and enhancements » Customers · Flag idea as inappropriate… · Admin →
Some clarification on the request:
Proformas use their own numbering system, prefaced by a P, that helps distinguish them from real orders.
Presently when a proforma order is saved as a completed order, the proforma order number is not retained and CMS assigns a new sequential numerical order number to it.
While CMS knows that the order was converted from a proforma and there is evidence of this in the History tab of the orders' customer record, there are situations where it would be helpful to be able to retrieve that order by its original proforma order number.
This request would be for CMS to retain that original proforma order number after its conversion to a completed order and allow for searching based on it (much like we do for reforderid for imported orders.)
2 votes2 comments · CMS - Suggestions for features and enhancements » Customers · Flag idea as inappropriate… · Admin →
Yes, this would be possible.
If we were to act on this it seems we should do it wherever notes are available in CMS including:
*Contact Manager/Order Entry - Primary Notes
*Order Entry Invoice and Internal Notes
*Purchasing - PO Notes to Vendor and Internal
Probably not necessary in places like Products - Tech Info and Web Text, for example, but comment if you feel otherwise or if there are other places this timestamp would be needed.
I've seen this implemented elsewhere with a button that you'd click to insert the timestamp as a prefix or suffix to your notes. This would be an easy implementation but it's then incumbent on the user to click the button lest the notes be added with no timestamp. Please consider that (may be situations where that's preferred) and comment if this approach is acceptable or if you'd not want to allow notes to be added without a timestamp.
A bit more complex is the question of what to do when someone is editing notes, not just adding a comment. If/how would you envision that being timestamped? I think this leads back to just adding a button to insert the timestamp if/when desired but let me know if you agree.
0 votesunder review · 1 comment · CMS - Suggestions for features and enhancements » Purchasing · Flag idea as inappropriate… · Admin →
CMS supports two styles of attribute selection. One is just for the selection of size/color and the other adds a column for filling in a quantity as well. The former is more often used in B2C situations where a customer is just ordering a single item. The latter is more often used in B2B where the customer is ordering multiples of the same product in different sizes/colors. I'll share screenshots of each for comparison:
Either could be a great addition to the purchasing system but wanted to see which you prefer.
The options w/o qty would be much easier to implement and maybe we'd start there as a first iteration if you thought that would be a useful step forward.
2 votesunder review · 2 comments · CMS - Suggestions for features and enhancements » Customers · Flag idea as inappropriate… · Admin →
TAPI stands for Telephony Application Programming Interface so it is in fact what you're asking for. It's a industry standard of sorts for integrations with phone systems.
If we were to pursue phone system integration, it would likely be not for a specific system but instead to support the TAPI standard.
You'd want to check if your phone system was "TAPI compliant" to see if it could work with this feature.AdminRuss - NewHaven Software (Product Manager, NewHaven Software) shared this idea ·
I'd like to provide some related information and current capabilities to provide some context for whatever enhancement may be pursued.
Shipping and billing addresses are stored with the order data. In some cases they may be saved with the customer as well if the option was selected in Order Entry to make the Ship or Bill address the default for the customer. Even with that though, those addresses may change over time.
The request here would to expand the 'Retrieve a Saved Order' options to include elements of the billing and shipping address as they appeared on the order (not as the current customer defaults.)
In cases where the order was a "multi-ship" type order (where the recipient(s) was not the same as the buyer), and you have CMS configured to create customer records for multi-ship recipients, you'd be able to find their customer record. A copy of the order can be found in both the buyer and recipient's History (although frequency and spending is only updated for the buyer.)
Also, the Advanced tab of Retrieve a Saved Order provides an option to search for order by ship-to last name. This generates a report finding all orders that have recips with that last name regardless of if they were saved as new customers.
2 votesunder review · 2 comments · CMS - Suggestions for features and enhancements » Payments · Flag idea as inappropriate… · Admin →
Two issues at hand here:
1) The ability for CMS to store/recall multiple credit card numbers for a customer
2) Storing or flagging a credit card for use on subscription orders
This request will focus on #1. The second issue is dependent on #2 but is also dependent on CMS making the distinction between types of orders (e.g. there is no such thing technically as a subscription order, as far as CMS is concerned currently.)
We've been looking at Authorize.net's CIM solution which allows for tokenized payments to be stored with a customer record. This would fit the bill and do so without increasing your PCI vulnerability...but would require Authorize.net, for better or worse.
1 voteunder review · 1 comment · CMS - Suggestions for features and enhancements » Payments · Flag idea as inappropriate… · Admin →
To clarify the use case for this request, orders placed online are typically always approved for the full amount of the order. Once the order downloads into CMS, and if the bill-delayed option is not used, CMS will reduce the amount of the payment to match what can ship today. For orders that are fully future shipped or back ordered, this new payment amount is zero.
Noting that despite the payment being lowered to zero, the customers available funds are still being held in conjunction with the originally website-obtained authorization.
If the order is fulfilled before the authorization expires, CMS will use that authorization to capture any funds due for the initial fulfillment. If that authorization has expired or the authorization has already been used for a previous fulfillment on this order, a new authorization will be obtained.
That said, there may be two scenarios where you'd want to handle these charges differently:
1) companies that do a lot of future ships where they know they typically are not fulfilling before that the auth will expire, it may be desirable to instead have the authorizations for zero dollar payments reversed to free up the customer's available credit line
2) your account with your processor is set to automatically reverse authorizations after X days. Once these authorizations are reversed by the processor, which is not communicated to CMS, any subsequent attempt to capture them will fail.
This feature request would have CMS automatically reverse the authorization in situations where the payment was reduced to zero, addressing both of the issues above.