A client was showing me today her procedures for turning orders into invoices. It was cumbersome, even with the shortcut keystrokes. We came up with some suggestions for making it MUCH faster.

Their orders are mostly transferred from quotes in SalesCQ and are ready to invoice "as is". Even though the option in OrderEntry Profile "Default shipped as ordered" is enabled, CQ doesn't respect this, and quotes transfer with a zero shipped quantity. Getting CQ to respect the setting would be an enormous time-saver.

Once all items are marked as shipped, it would be a major time-saver if the OK button becomes the default button.

Through trial and error, I was able to figure out a way to make the OK button the default. I enabled Skip Field for every field on the OE Header tab. But that's not a very practical solution, and it only speeds things up if the items are already marked as shipped.

To summarize, I propose two changes - 1) that CQ respect the OE setting, and 2) that the OK button be the default if all items are marked as shipped.

This may seem minor to the average reader, but if it saves 5 seconds per order, and there are 100 orders per day, then we are talking 8 minutes per day saved.

Steve

Hi, Steve,

I've entered both of your suggestions for R&D.

Question: I just want to confirm that you are using the Ship All button in OE and that it's after doing that, that you are suggesting the OK button become active.

Hi Steve,

Setting the quantity shipped normally requires validation that sufficient quantity exists in inventory. Order Entry does this when the user sets the quantity shipped and saves the order. Are you suggesting that SalesCQ do the same validation when the quote becomes an order? If that validation fails, it would require a lot more interaction with the user to correct the problem.

Hi Bob

It's a good question. As part of the transfer, CQ should pop a box informing the user that not all items were marked as shipped due to a lack of stock in the location. But not if inventory is allowed to go negative, or if OE is standalone.

I think this is what a user would expect when "Default shipped as ordered" is enabled.

Softrak - yes, they are using the Ship All button (Alt-I).

Steve

Hi Steve,

We use our Link2Systems software, Link2WebStore to accomplish the same required transfer from SalesCQ to OE..

In our situation, the client sales are downloaded from the webstore as orders (quotes) into SalesCQ (as a landing zone), and to qualify the orders that can be shipped, we use a Gridview that can be customized as many rules as can be dreamt up.

The export XLS from Gridview imports the orders from SalesCQ into OE and closes out the completed orders in SalesCQ.

I know this sounds like a lot of work for saving 8 minutes (in your scenario) but for our clients using this solution with web orders from several hundred to thousands (daily), the Link2WebStore is slick.

So there is a solution out there for your requirements, already. But will require additional licencing.

We also requested for a more efficient interface years ago for Sales CQ to OE, but could not wait.

Best,
Brian

Hi Brian

Thanks for the reply, but what you are suggesting is a workaround, not a solution. The difference is that a workaround is unnecessarily cumbersome while a solution is intuitively elegant. I don't want Softrak to think they are off the hook.

On a similar topic, another client imports their web orders directly into OrderEntry, about 300 per day. They have a catchall customer in Adagio "WEB" where all of the orders land. When they turn each order into an invoice, there is about 6 seconds of waiting, with all Profile settings optimized, to pull up an order and post it as an invoice, because of the number of transactions for customer "WEB". Without that wait, it would take 5 seconds per order instead of 11.

They own Adagio Toolkit, and I have suggested that they could speed this up by merging customer WEB into WEB2 each month to move the transactions out of the way, and then create a new WEB customer. They will be trying this soon. But I wonder if there is a way to avoid this workaround.

Steve

A disadvantage of allocating all web orders to a single customer is that the one customer gets a disproportionate number of transactions. Make sure that period end is run to move those transaction to history.

How about using "WByymm" as the customer number, and changing it every month? Or better yet, actually assign a real customer code so that sales can be properly tracked.

Period End is not the answer because the problem is happening in OrderEntry, not Receivables.

As for the suggestion about using new customer numbers each month, it would require a programming change to the export utility from the website. Also, it would make it much harder to look up historical invoices.

The problem with trying to assign each customer a unique code is that this website is a retail website and it doesn't validate the customer information. So you would end up with repeat customers appearing multiple times in the database if you tried to match on email addresses or phone numbers. Or if you tried to match on the address, you would end up with multiple customers in the same apartment building being lumped together as one. You would be amazed at how "creative" web customers are in filling out the email/phone and even name fields (think "Superman")!

In addition to taking orders on their website, this client also has a separate entity that sells via Amazon, and since Amazon handles all of their order processing, they import those orders as invoices into Adagio Invoices. For that entity, they do set up a separate customer in the format "WByymm" for each two-week payment period, so that the amount Amazon remits exactly matches the balance due to my client (and the customers are set up as Balance Forward to make it easy to apply payments).

Getting Adagio to work for companies that do business via Amazon, including tracking inventory quantities, is a challenge I've taken on. If anyone wants to learn how this client does it, email me at steve@sschwartzcpa.com.

Steve

Hi Steve,

I assume by the comment "all setting optimized" that you've made sure that OE is not doing either a credit check or a check for duplicate reference (PO) numbers for the customer. Both of those processed require reading all the customer transactions.

Since you are importing orders, couldn't you default the customer code in the import template and just change that every month?

I'm surprised it's taking 6 seconds to load an order. How many lines are typically being loaded for each order? How much memory is in the server and workstation? Would you be willing to upload a copy of the data? Perhaps we could improve the performance.

Hi Andrew

Yes to your assumption.

Before we go any further on this, let's see if the client notices any performance improvement when they merge customer WEB into WEB2 at the end of the month. If they don't, then I'll have to look for another explanation.

I'll post back when I find out (and I will have the other answers to your questions if necessary).

Steve