We have found Stief Group's 3rd party Purchase Orders for Adagio rather archaic in the handling of drop ship adresses a real hindrance. Unlike the easy enter on the fly of a drop ship address in Adagio Order Entry, Purchase Orders requires a drop ship address code causing mountains of stored addresses to be saved. In the event that you choose to delete any of the drop ship codes the addresses are lost on the associated PO. As a company that does a fair amount of one time drop ships we hope the author of this software will take this inadequacy seriously in their near term updates.

I'll bring your concern to their attention.

Hi Andrew:

Appreciate your concern.
I spoke to Brian a couple of months ago. It was a dissapointing conversation.

Thanks,
Jeff

Hello Jeff,

OK - I had a chance to think about this (and also discussedc it with Brian - who's in Vancouver this week) last night , and I think that the current approach is the right one. PO's are typically for locations of your business (unlike order entry which is dealing with customers), so maintaining those addresses in a table is the correct approach. Adding an entire address block to each and every PO Header would consume enormous amounts of disk space and negatively affect performance of the product for all the other users.

Since you can add drop ships on the fly - just don't bother looking at the table that's maintained (although this does represent a customer list for you).

Hi All,
We did talk with Jeff to explore the options available and understand his situation with drop shipments. Sometimes we do not necessarily agree with a user's issue. Sorry if that makes a disappointing conversation.

In our design, we have to consider backwards compatibility issues and data storage issues. The database design uses a table to link the drop shipments. The drop shipment addresses can be added on the fly but are not actually stored on the PO. As such, they are referenced and if you change a drop shipment address on the table, all previous direct references are affected.

In Jeff's situation, his sales orders are drop shipped to unique (one off) ship to locations, so his "ship to" table will be almost a direct relationship to his sales orders, and will grow large in proportion to his sales volume.

We still believe our design best deals with this type of situation and the majority of drop ship situations where the table may be at most possibly 20 different locations.

We will be adding a feature to the ship to function where we will copy in the customer address from Receivables to an assigned Ship to code, to minimize the amount of data entry in these sitations and promote purchasing efficiency. We will also be adding a warning message advising users that modifying or deleting ship to addresses, will affect previous referenced Purchase Orders, both current and historical. As well as an inquiry to view the ship to table easily.

We still welcome comments and suggestions, as we collaborate with users, dealers, Softrak, and other developers to improve our Purchase Orders for Adagio product. Thank you for your input.

Brian Stief
President
Purplesoft