Cheryl Waswick SR SUPPORT ENG

Currently the VAT reports pull from the TX30000 tax table and reports are generated in the functional currency ID. (While most users are on a UK install and have GBP as their functional currency, this won't be a problem with the new digital tax filing requirements. ) However, you can install VAT on a U.S. install, in which GBP would not be your functional currency. With the new digital tax requirement, will there be an option to file in a multi-currency ID so you can still file from a U.S. install?

In the past, there were complaints about the Safepay file pulling the vendor's name from the vendor maintenance card, and not the actual name used on the check. So in GP 2016 R2, we added a new feature to now store the check name in the Payables table (PM30200.VNDCHNM) and directed Safepay to pull from this field instead of the vendor card. (but only was for PAYABLES checks.) Now we are having the same issue with PAYROLL checks, and the actual name used on the check is already stored in the payroll table (UPR30100.EMPLNAM) so half the work is already done. However, the Safe pay file is still reading from the Employee maintenance card and not pulling the actual name used on the payroll check. (This affects more than just employee's with name changes, because GP only prints a middle initial on the check, and the Safe pay file will pull the full middle name from the employee card, so can be a mismatch on many, many payroll checks.) Can you also direct Safe Pay to pull the employee name from the UPR30100 table for payroll checks, instead of the employee master record? Or have it truncate the middle initial just like it does when actual payroll checks print?

VAT Daybook was redesigned in GP 2016, and so now the VAT Daybook summary report returns highly inflated and incorrect totals (as compared to sum of the detailed transactions) if the DOCDATE on the data being pulled crosses a year and includes dates back to a year old. The summary report has this problem, but the detailed report does not. We need to get the summary report to be able to pick up any transactions from the TX30000 table that is not marked off, regardless of the date, and produce a correct total in the 'net sales/purchases' boxes on the summary report (Box 6,7,8,9). The totals on the VAT Daybook summary report and VAT Daybook detailed reports need to match, and be correct.

The 'CTX format for EFT is common but not an available file format in GP. The only field that cannot be achieved is a total of the addenda records in the DETAIL line. GP can count/sum records AFTER they are printed, but not before. If GP could total the addenda records in the DETAIL line, another file format could be achieved by that one field. Note: The work-around is to print 'one check per invoice' and then hard-code that field to 1, however, this is not ideal if the banks charge per line for your file.

Many banks are offering 'check printing' services and so users need to get a flat file of EFT payments from Dynamics GP. The file format requirements often have several addenda lines needed for company and payee information that the user can achieve with the IAT addenda 1-7 lines. However, the 'IAT addenda' line for REMITTANCE information is not coded. (Assume it was not an optional field on the initial IAT standard format.) So there are no lines that will pull in the remittance information (ie. invoices that make up the payment.). You can use the regular 'addenda' lines in GP, but then they print out of order and the bank will not accept the file. The IAT format needs to have an 'IAT ADDENDA' line after the IAT Addenda 7 line. This line should print one remittance record for each invoice that makes up the payment (just like the other addenda option).

When a vendor has credit memo's automatically applied during the checkrun process, a vendor can end up with a $0 payment. These payments have a remittance printed and update the EFT table (CM20202). However, when you generate the EFT file for Canadian formats, the RBC and CIBC formats exclude the zero dollar payments in the resulting EFT file. However the "National Bank of Canada' format INCLUDES the zero dollar payments and the bank is rejecting the file. The ask is to update the 'National Bank of Canada' format to exclude zero dollar payments like the other Canadian EFT formats do. (or provide an option to exclude them). The work-around is to put a trigger on the CM20202 table to delete $0 records when the record is inserted into the table, before generating the file. This is not a supported option.

A new copy/paste feature was added in 2020 Fall update for Dynamics GP to copy/paste in purchasing transaction and distribution records, much like the GL copy/paste features. However this is not compatible with AA, where as GL is. Please add the ability to copy in AA data for the distributions, like the GL copy/paste functionality has.

In the company setup options, there is an option for "Calculate tax rebates' which is used with payment terms. With this option on, the payment terms discount will correct the tax amount with the discount as well. This only works with functional currency. Our ask is that it also works with Multi-currency. If the invoice is in an originating currency, it will not post and fails validation. It says the discount available and discount taken amounts do not equal the actual amount. It's like it can't factor in the amount of the tax rebate with the discount to pass the validation. Perhaps many companies didn't use MC in the past so this was never coded, but MC is pretty much required now, so this company setup option should work with invoices in originating currencies too.