Currently, in Accounts Payable, Processing, Void Checks After Posting, system allow voiding an AP check even if that check is already reconciled.

It is suggested that we should not allow this to happen. So we suggest to add the following Global Setup flag to AP Global Control:
Allow Voiding Reconciled AP Check?
The possible value is "Y" and "N". Default is "N". When a user try to void an AP check that has already been reconciled, system will now print proper error message in the void journal to indicate so without actually voiding it.

If user had determine a mistake was made at time of AP check reconciliation and we should allow void anyway, user can go ahead change the global setup flag to "Y" and proceed with voiding the reconcile AP check.

Proper warning message should be displayed in Global setup when user change the value to "Y". Also, during AP void check user interface, if system detect this global setup flag is set to "Y", a warning message will be given.

Currently, Elliott allow subscribing a management event by going to Global Setup, Press Detail Event button, and F5 key to insert the LCKEVENT - Record Lock Triggered Per Min. When a record lock over one minute is taking place, this event email can be sent to a specific person, like the admin of the organization.

It is suggested that this email should be sent to the offending user (the user who create the locking condition in the first place). The issue we had was that we know the offending user Windows login, but we do not know the Elliott corresponding user login. With Elliott V8, this dynamic is changed. In Elliott V8, we do track the Windows login ID. See attached screen.

So what we propose is to allow user to right click on Event Email tab, at the To, cc and bcc columns, allow the ability to add "Email by Windows User ID" and "Email by Elliott User ID". so the right click list will not be expanded like following:
System Variables ->
Owner E-mail
Triggered y E-mail
Primary eContact
Non-Blocked Primary eContact
*Email by Window User ID
*Email by Elliott User ID
Note the last two are proposed newly added option. If you choose one of them, then we ask the variables that contain the User ID. The system does not have intelligent to know which variables would contains the Windows or Elliott User ID, it is depending on the user to make the right decision. If you use this feature on an event does not provide Windows or Elliott User ID, then there's no way to make this work.

The return variable to the To, CC and BCC fields will look like:
@@WIN-USER-EM(REF-ID02)(@@
@@ELI-USER-EM(REF-ID03)@@
It is user's responsibility to identify which REF-ID contains the Windows User ID or Elliott User ID.

It is possible that this variable can not produce a valid email address. This can happen because:
(1) The offending user is on Elliott V7.x which we don't track the login Window user ID.
(2) The email address is not defined in password setup.
(3) The Windows or Elliott User ID is not found in the user list for some reason.
(4) The defined email address is not a valid email address.

In that case, system will not be able to return an email address back to this variable. If there are no email address for the event because of this, then this event email is simply not sent.

This feature will only work for V8 users.

In the situations where salesman gets control of another salesman customers, the new salesman can't see the old salesman invoices. There might be a situation where the new salesman takes control only on opened orders I suggest to have 3 levels of global security:
1. At Customer, Order and Invoice history. This is what currently Elliott supports. Salesman can see orders and invoices only if they match the Salesman on the customer file and the user security.
2. At Customer/open order level only. In this case salesman can see opened orders belong to the customer even if the salesman is not on the order but the order belongs to the customer of the salesman, but can't see invoices that don't belong to the salesman.
3. At Customer level. Salesman can see orders or invoices belong to the customer This will be useful if salesman is replacing a retired salesman.
In the perfect solution you can assign the Global setup on the Salesman level at the user security.

In order entry or sales desk, currently Elliott systems allow up to 3 salesman. Each salesman will need to have a percentage split with total 3 salesman percentage add up to 100%.

In some situations, it may be desirable to enter salesman 1 with 100% and salesman 2 and 3 with 0% for referencing purpose. In many cases, the commission needs to be handled outside of Elliott. As long as the system can provide the reference of all salesman on the order, the information can then be retrieve by tools like Crystal Report.

Let us know if this is something valuable to you.

Currently, the User Defined CSV Export column heading is predefined and is static. Sometimes a CSV layout is defined to compare current month, last month and prior month. For example, if current month is December, last month is November, prior month is October. In the layout, you can specify the month as "CP" = Current Period, LP=Last Period, PP=Prior Period. But You can't put December, November and October as the column headings, since next month the column headings will change. Therefore, it is proposed we support the following variables in the column heading:
* <MON>: The three digits month like Jan, Feb, Mar...etc.
* <MONTH>: The full month name like January, February....etc.
* <MM>: Two digits month like 01, 02...,11, 12.
* <YR>: The two digit year.
* <YEAR>: The 4 digit year.
* <TODAY>: System date in MM/DD/YY format.

These variables must be in upper case and can be combined with other constant or variables. If the column heading has any characters other than the above variables, the variable will be replaced by the appropriate "To" period month or year value.

If the "From" and "To" dates are the same, only one value will appear in the column heading. Ex: "<MONTH>, <YEAR>" would become November, 2020

If the "From" and "To dates are not the same, the column heading will show both dates. Ex: "<MON>/<YR> to " would become Sep/20 to Nov/20

Keep in mind that the maximum column heading in layout maintenance is 17 digits. You must define the heading including variables with less than 17 digits. It is not an issue If the translated result from variables yields a heading longer than 17 digits since the actual CSV heading has no limit.

In the column heading, we will offer "F7=Help with Variables" option which will display a window of the possible variables and how to combine them. Nothing will return back from F7.

In the attached example, the column heading of the following in December 2020 would be:
* Column 1: <TODAY> Item#
* Column 13: <MON> <YEAR>
* Column 14: <MON> <YEAR>
* Column 15: YTD <YEAR>
will become like:
* Column 1: 12/01/20 Item#
* Column 13: Dec 2020
* Column 14: Nov 2020
* Column 15: YTD 2020

The variable <TODAY> in the column heading is used to indicate the date when the CSV is created. But since we don't want to waste a column for that, we can put it in column 1 with item#. In theory, you can also make column 1 a constant column with no value and use <TODAY> in the column heading to display the heading as system date.

It is possible that a variable value can't be rendered. In that case, the variable will be kept as it is and display in the heading.

AP Transaction Processing - Add distribution level reference

Currently, AP Transaction Processing allows the entry of a Voucher Reference, which ultimately carries through to APDSTHST.APDSTHSTVOUCHERREF for every distribution made against that voucher.

Propose adding a distribution level reference, allowing a unique reference to be added for each distribution made against a voucher.

Add APTRXDST.NEWAPDISTREF
Add APDSTHST.APDSTHSTDIST_REF
Add both references to resultant APDISFIL record.

Expand AP Invoice Import Utility Detail Record Layout to include DIST_REF.

This is particularly useful when processing vouchers for credit card statements - which often contain a variety of charges which may require/benefit from a unique reference per distribution, as opposed to the single reference from the voucher entry itself.