A client reports three changes from previous versions that he wishes hadn't been made. I'm hoping you will tell me they were unintentional and will be rectified.

1) You can no longer leave the Expected Ship Date blank. What reasoning went into making that change?

2) It used to be that if a customer had a ShipTo code "blank" and no ShipTo code was specified as the default in the Entry Template, the "blank" ShipTo code would be used by default when entering an order. That is no longer the case. Now it ignores a "blank" ShipTo code

3) It used to be that when selecting a ShipVia from the list, you could type the first letter of an entry and it would jump to that entry. That no longer works. I understand you changed the field from a Combo Box to a Finder Field because you expanded the number of possible entries. Is this an unavoidable consequence?

Thanks

Steve

Support:

I'm OK with #1 and #2 is, as Steve says, an unavoidable side effect of adding more Ship Via's. But #2 is a problem because a lot of long-term Adagio users have Customers with a Ship To assigned a blank code which operates as a default Ship To location.

Hi Bruce,

#1 was made a requirement because EDI systems require an expected ship date. You can set a default value in the company profile on the Processing Options tab ("Expected Shipdate spread"). A site does can ignore the field if they so choose, but they cannot leave it empty.

#2 Can this be resolved by using GV-RW to clean up the file or setting the code to something other than "blank"? Just asking because relying on a blank code for some specific processing is probably not a good idea. I'll ask R&D to take a look.

#3 is an unavoidable side effect of moving from a combo-box to a Finder field.

Hi Andrew

Re #1 - It should be an option. Forcing someone to enter what they know is a bogus Expected Ship Date is a step backwards, not forwards. What percentage of Adagio OE users are integrated with EDI?

Re #2 - I guess I can use GV-RW to change the codes from "blank" to something else. But what about the OE History?

Better would be to use Toolkit for Adagio, but only for companies that already own it. And I wouldn't want to do that if you are going to restore the functionality back to the way it was. Which I hope you do now that you aware of the issue.

Steve

Hi Steve,

#1. They don't have to enter a value in the Expected Ship field. Skip the field on the template.

#2. It's probably worth waiting a bit before making any changes here.

Hi Andrew

#1 - Let me play with that and get back to you. They sometimes do want to use the Expected Ship field.

Steve

Hi Steve,

You can skip it in the tab sequence and still be able to click into it if it needs a specific entry.

BTW - if you want to be able to separate Orders where the Expected Ship is significant from those where it isn't, then set the spread to 0. Then you can exclude all orders where the expected ship = the order date in your Filter.

Hi all,

#1 - we also require an expected ship date to accommodate the new Auto-invoice orders function as it can select by Expected Ship Date, and blank dated orders would be skipped. The same for printing Order Confirmations and Picking Slips by date range, where Expected Ship Date can be used for selection.

Here's another complaint...

When entering a miscellaneous charge on an order, the default charge is the top one on the list. Before, you could put whichever charge you use most frequently at the top. Now, the list sorts alphabetically, so you can't easily control what appears at the top, especially if you want a certain description to appear on forms.

This is really slowing down data entry.

One idea is to allow a user to type in a letter when entering a misc charge and have it jump to the first matching item on the list. Still not ideal, but better.

Steve

Steve:

I had a client make the same observation. They edited the Miscellaneous Charge they wanted as default and put a "1" at the start of the Description. Not ideal but they are content for now.

I suggested this, but they didn't want the 1 to print on the form. We could have excised it by using an offset of 2 characters on the spec field, but that's a last resort.

Steve

One of the frequent requests made was to increase the number of available miscellaneous charges. Essentially removing the restriction means that the lookup must be through a Finder rather than a combo box. I'd suggest the solution adopted by Bruce for a short term fix.

It seems that storing a Default Misc Charge is now the most desirable change. Where would you expect such a default to be stored? It could be:

• In the company profile.
• On the customer.
• On the Ship to.
• On the entry template.
• On the territory.
• On some combination of the above (but then there would have to be a precedence sequence).

I vote for Entry Template.

Unfortunately, there is a not-small percentage of users for whom this improvement has no impact, but who are affected negatively by it. That's the theme of this thread. With an emphasis on "minor".

Steve

Andrew:

I agree with Steve, Entry Template

Thanks for your comments about the Misc Charge default. Indeed it would be helpful, especially now that there can be more than 10.

Just curious for those that have clients that use MultiCurrency, where misc charges can be saved with different price lists and currency codes, or even just sites that store different sets of misc charges by price list code, would you expect the associated currency and price list to come from the customer? Or the order? And because misc charges don't have '6-character codes' like other master records, a site with multiple lists would have to ensure that all are configured identically so that the desired code was loaded as the default, depending on the currency and price list.

It was questions in this area why a default misc charge did not make the cut in the initial release of 9.3A.

Support:

Miscellaneous charges and Price Lists codes.

One rule fits all users is not likely going to happen.

I see the dilemma. Let me think about it.

The issue with Blank Ship to codes has been fixed in OrderEntry 9.3A (180213) HF.

Another minor complaint - not sure if this has been discussed and if there is a solution.

Order Entry > Print Invoices seems to always default to "Yesterday". Can I not have this screen default to "All"?

We set the User Preferences to "Remember report settings". Even with "Exclude ranges" disabled, the Print Invoices screen does not remember that I last selected the option "All".

This is a nuisance for my client, and they would like to default the screen only once.

Hi Samuel,

Does your client also have the 'Remember Form Settings' option set in User Preferences? It is this setting that controls remembering options set when printing forms like invoices or order confirmations. When I set this, the selected date range, such as Today or This Week or All, is remembered for the next printing.

Excellent. No, this was not clicked on.
I should have remembered this. Glad that you are able to offer the answer we were looking for.
Thank you.

Back to point #1 - the Expected Ship date field. A client I just converted REQUIRES that the Expected Ship date sometimes be blank. Otherwise they have to cross it out on the picking slips.

No matter what suggestions I try above, I can't get it to save it blank.

What am I doing wrong? If I'm not doing anything wrong, this HAS to be changed back to the way it was.

Steve

Hi Steve,

What is the significance to your client between a picking slip with an "expected ship" date and one without? Can they tell the different on the Order? Can they use a Picking Slip specification that does not include the Expected Ship date?

Sorry, but we are unlikely to change this since the Expected Ship Date is a selection criteria for auto invoicing.

Andrew

Would you like to talk to my unhappy client? Believe me, there is a significance. Different specs won't work - they print ranges at the end of the day.

There needs to be a way to leave the expected ship date blank. According to the suggestions above, it's possible. Are the suggestions above wrong? Or am I doing something wrong?

Steve

Hi Steve,

I'm more than happy to talk to your unhappy client. There are now many more different ways to select documents to print. Perhaps there is a better method than selecting by range.

I read the thread and didn't see any indication of a method to blank the "Expected Ship" date. If it is possible, I'd expect the Delete key to clear the field.

But I'll ask R&D.

The issue is that they want the expected ship date field to be blank on the form. They always print ALL unprinted documents - they don't print by range.

I'll email you privately with the client info.

Steve