The issue comes up again and again where a user voids a Payables invoice and then realizes that the Invoice originated in the PO module, that the PO didn't open back up again as they expected and that their Accrued Purchases Account is out of balance. Would it be possible to include a new Payables setup option where we could choose to allow, warn or not allow this type of void?
We would like to suggest the ability to have a default bin assigned when entering transactions in the Item Transaction Entry window for IV
Dynamics GP 2015 Canadian Payroll garnishee deduction pay code not including the Additional Tax Deduction in the TD1 windowAs Dynamics GP Canadian Payroll recognizes the 'Additional Taxes' field on the Employee Tax Credits page to add to the 'Tax' deduction but garnishment deductions based on Net Wages will not recognize this setting. User would like to see the garnishment consider the 'Additional Taxes' field in the calculations so they can be exacting with every check.
If there is a large cash Receipts batch in GP, can we have the ability to automatically do a deposit by batch. It will save lot of time.
If deposit screen can be enhanced to deposit by various forms of payment
Distributions in Receivings Transaction Entry adding up instead of recalculating Overhead (From Manufacturing) when changing quantity on the receiptCurrently when a customer has manufacturing and sets up an item with Machine Fixed Overhead and Machine Variable Overhead, the distributions for that particular overhead are not calculating properly in Purchase Order Processing Receiving's Transaction Entry. Instead of recalculating the distribution when changing the quantity on the receipt, the distribution instead adds the new quantity overhead amount to what was there previously. This is effectively overstating the Overhead amounts for these entries, putting through an incorrect data condition.
You can Delete and Default Distributions to correct the OVHD Distribution amounts, but this is difficult if you are using an ISV to auto post items
When a PO Receipt is entered for the Item, and the PO Line Quantity is changed, the Distribution value for the PO Receipt is not properly calculated.
Machine Cost per Piece = $5.00
PO Receipt for Qty of 1 = $5.00 in Distribution for OVD
Do not exit PO Receipt
Change PO Receipt Qty to 2 = $15.00 in Distribution for OVD instead of $10.00
The system calculates that value as (1 + 2) or a qty of 3.
Do not exit PO Receipt
Change PO Receipt Qty to 5 = $40.00 in Distribution for OVD
The system calculates that value as (1 + 2 + 5) or a qty of 8.
Changing the Cost Basis and splitting the Cost Account results in an unbalanced GL entry when Fixed Assets is set to post in DetailScenario: A new asset is acquired via trade for an old asset. The old asset is retired with x$ proceeds that Debits a suspense account. New asset is created and x$ proceeds from trade is reflected in Internal Book distributions as Debit to suspense account.GL Posting routine picks up all correct distributions (Fixed Assets General Ledger Posting window). At the GL, two unbalanced Journal Entries are created where One would be expected. One Journal Entry has one line for x$ on suspense account and the second Journal Entry has the Depreciable Assets and Fixed Assets Clearing distributions.
Workaround edit distributions
Ability to allow Web Client users not able to post if Account Security is turned on. The user receives the error “Access denied/Account Missing”When trying to post journal entries from the Web Client it fails and the batch goes to recovery. They can process it out of recovery and post it from a desktop client with no problems.
This happens because account security is turned on
You either need to turn this off or post in rich client.
From the PO Entry window it's not possible to see what has been received and/or invoiced on the PO. Add a lookup to the menu or button that would display and allow drill-down to any related shipment or invoice documents posted against the PO.
It would be great from an adoption and learning point of view, if we could create a graphical user interface of the most common processes (ie. Month End Procedures / Procure to Pay / Quote to Cash / Time Entry to Payroll Run / PA Timesheet entry to Project Billing). QuickBooks does this extremely well and therefore we should not be surprised at the adoption of it. Too many programs these days are written from a programmer's perspective vs an entry level bookkeeper or accountant perspective.
The drilldown feature which contains the code to open specific forms from reports can be used to create such an interface.
The AP cheques printing should also allow by cheque number order. Currently its printing only by payment number.