Hello Adagio Community,

We use OE 8.1D along with AR 9.0B. The issue I am confronted with is with the Salesperson field when entering a new order. This has always been a mandatory field; we could not leave the Header screen without entering a Salesperson code. Suddenly, this is no longer the case. The salesperson does not have to be entered to proceed with the order. I have checked the Order Entry Template and the Group settings and it all seems to be in order, with the field not being set to be skipped or anything.

I recently deleted a couple of salespersons and then had to add one back in order to view an old invoice, although I doubt that has any relevance.

I must be missing something. Any advice appreciated!

Thanks,
Jody

Hi Jody,

This changed in version 8.1D. This is the second line of the things 'fixed in version 8.1D' as outlined in the readme or the release notes:

The Salesperson field can now be left blank in documents. This may be desired in the case of credit notes.

Salespersons are required on orders and invoices to calculate commissions and such, but it is no longer an error if the salesperson field is left blank on any of the Order Entry document types.

Softrak Support:

I think R&D needs to re-think this "The Salesperson field can now be left blank in documents. This may be desired in the case of credit notes."

It is not very desirable, except maybe for credit notes. My guess is that most users would prefer the old method as it is very important that the correct salesperson gets credit for each order, esspecially if commissions are turned on.

On another note; why is this listed as a fix? Nothing was broken (that I'm aware of).

It should not have been an error to leave the field blank. Salesperson can be defaulted from the Customer record, Ship-to record and/or entry template. Some companies do not make use of this field at all.

I understand both sides of the issue.

I would like to suggest as a solution that the salesperson code be added to the list of fields that can be edited on an invoice. That way if a salesperson code is mistakenly left blank, it can be rectified after the fact.

Steve

We only allow you to edit fields that have no accounting impact. Salesperson codes are used in the calculation of the commission report, so cannot be changed after the invoice has been posted. How about creating a Filter that highlights Orders with no salesperson assigned in a bright color? That would make the error pretty obvious.

Hi Andrew

OK, then, how about only allowing the salesperson field to be edited if the "Analyze commission data" box is unchecked in Company Profile. Then it would have no "accounting" impact. I would venture to say that 99% of OE users do not use that function, even if it is turned on. I don't have a single client that does.

It's one thing to be able to identify orders with a blank salesperson field, but a totally different issue to be able to change a salesperson on an invoice after-the-fact. They are both nice, but the latter is a request I have received many times.

I would like to hear others' opinions on this.

Steve

Well, if there's no accounting impact, then you can change the salesperson field in SalesAnalysis. However, we'll look at the implications of allowing the change if the company profile option to track commissions is disabled.

Maybe a simpler solution would be an option to make the field "Manditory" or "Optional" when creating new orders.

The problem with editing the salesperson after the invoice has been posted is the fact that this change would then also need to be made in Sales Analysis (where it is used more often than it is for commission tracking).

We are trying hard to remove options of this nature from our products. As mentioned previously, there are defaults for this field in the customer, ship-to and order entry template records (settable by user), to make sure that this field is set. Finally, is a pretty simple mater to code a Filter to highlight an order that has not been coded correctly.

We'd just recommend making the change in the SalesAnalysis record.

Hi Andrew

I agree that the fewer the number of options to wade through, the better. I appreciate that you consider it a priority, too.

Making the change in the SalesAnalysis record is of course necessary. But there are users out there who don't use SalesAnalysis and still want to generate salesperson-based reports, using OE history. That's why I think it's important to be able to make the change in OE as well.

Steve

Hello Jodie,

You can't force an entry here but you can come close. In the Order Entry template, define a non-existent salesperson as the default salesperson. If you try to leave the header screen without changing it, you will get an error message asking you to choose a valid salesperson. Since it is easier to select a valid entry than to highlight the non-existent code and hit delete, the entry will probably never be left blank.

Rick McLeod
Sunbeam Specialties Inc.

Hi Rick,

That's a neat trick! Thanks.

Thanks for the info. All the comments were interesting, too. Just for the record, we liked it better before. We don't track commissions or assign salespersons by customer or ship-to. We have an open order desk and it can be really helpful to know who handled the initial customer contact. Just another thing I will now have to nag my reps about whereas before Adagio did it for me!

Rick, I tried this (thanks!) but cannot enter a non-existent salesperson in the template. I get a message "Please enter a valid salesperson" We use OE 8.1D where the salespersons are maintained in AR 9.0B, if this makes any difference. I would love to make this work!

Perhaps you could add a Salesperson XXXXXX in AR9.0 then adjust your template in OE and then delete Salesperson XXXXXX in AR 9.0

Hi Jody,

Entry Templates in Adagio Order Entry can also be defined in the Security Groups. It is possible - perhaps even desirable - to define a unique security group code for each of your users. From there, you can specify a valid salesperson code for each user via the entry template within the security group. I presume that each staff person in your company has a salesperson code defined in AR, and if not so then it may not be too cumbersome to set this up.

Especially in your case where the order desk is 'open', you would want the entry template to assign the salesperson code, rather than having to remembering to change it.

Before undertaking this type of change, you should first check to see how security is used in Adagio - not just in OE but over all the programs - because users can only be assigned a single security group code. Do you already grant each user their own customized security group access? Do you use specified levels such as admin-level or entry-level to which a number of users are assigned? Or do you even use security? These are a couple of questions to consider and you may want to discuss implications of change with your Adagio consultant.

Order Entry now tracks which Adagio user ID was used to create an order. This field can be added to the grid and used by GridView.

Hello Jodie,

The program now is more restrictive than when I first set this up. Now you have to define the salesperson in AR, then change the default in OE to this new salesperson in Group setup, Order Entry template and probably also under the Maintenance tab & OE template. Then go back to AR and delete the new salesperson before it is used. It will still remain as the default but give the error message when trying to leave the Header screen in OE without changing to a valid salesperson.

Regards,

Rick McLeod

Hello Jody,

Have your reps use different entry templates and make the salesperson field default to their ID from the entry template. Entry templates are set by security Group, so this would require you to create a separate Group for each use that takes orders.

Thanks to all! I used Rick's (and Michael's) work-around for this but learned a little more about security groups in the process, too. Thanks again.

Hello Jodie,

I set this up years ago when Adagio was less restrictive and it continues to work well through all of the updates. However, when I tried it now on the sample data, it gives many more error messages than we experience on our own data including error notifications trying to start a new order or cancel an existing one. It may not be ideal to start using our method now.

Regards,

Rick