The UK Governments Making Tax Digital initiative has started to be piloted and will be in affect within a year.
More info on the initiative;
The checkbook register runs very slowly after it was moved from a regular table in report writer to a temp table. The code to populate this temp table likely needs to be optimized because it takes up to 5 minutes just to run the report and I assume customers with higher volumes will take even longer.
When creating a new year in the Fiscal Periods Setup window, the system assumes the next year when defaulting the First Day/Last Day dates. If a client is adding history after going live, they may need to add historical years. Suggested update: read the year field to decide what First Day/Last Day to default.
The Business Activity Statement (BAS) Report system does have a 7A field for deferred GST which becomes enabled when you import a BAS form previously exported from the Electronic Commerce Interface (ECI) software. This field is usually pre-populated by the ATO and so is only activated once a BAS form has been imported.
Basically the 7A figure is supplied by the ATO and does not come from anywhere in Microsoft Dynamics GP.
Because of this it only gets populated when you import the form from the ECI software (which also populates the info behind that expansion button).
Dynamics GP populates the data and then you export back to the ECI software.
The issue is that ECI software was replaced by the ATO Business Portal website and you don't import and export the XML files anymore
Thus it would be nice if we make this field editable to the customer on the window. They would as a minimum like to manually edit field 7A on the BAS form.
When a batch edit list is printed and interrupted, it can cause the batch to be put into batch recovery. When the batch is recovered, GP thinks that the batch was "posting" and finishes the posting process. This causes batches to post without workflow approval and can cause issues if the user has not had time to review the batch.
The Batch Recovery process should not post the batch, but rather finish printing the Edit List or the interruption of the Edit list printing process should not put the batch in batch recovery.
Right now you can prevent duplicate checks in AP but you can't prevent duplicate checks between AP and Misc checks. I would like to see no duplicate checks by bank account so it would include both Misc and AP checks.
In the SafePay file there is no field to include a 'Rule-Off Date'. The only way to populate a date to show end of the current month is to set that field as TEXT and hard-code in the appropriate month-end date. This would require this client to manually update that 'Rule-Off Date' at the start of each month.
Having this functionality available in the SafePay file as a date option would be more efficient than manually having to change the file before sending to the bank. The 'Rule-Off Date' was required by the bank.
Bank transfers create 2 records in the CM20200 table. One for the 'from' checkbook and one for the 'To' checkbook. If you reconcile one checkbook and then move those reconciled transactions to history (CM30200), then the drill-back on this bank transfer from Checkbook Inquiry window is missing information. The drill back works if both sides are either in OPEN or in HIST. But if the transfer is split, where one checkbook has it in OPEN and the other in HISTORY, then the details of the transfer do not display till they are both moved to history
When 2 or more users try to post batches from CBM Batch Entry screen (Transactions>Financial>Bank Management>Batches) at the same time, at least 1 of the batches will fail with the error
"Data entry errors exist in batch #BatchNumber# Use Batch Recovery window to process this batch."
After recovering the batch you can successfully post it.
It appears that the error involves GP trying to drop the TEMP table(represented by the ##) created during the process to move on to the next process during posting. It appears that the other batch had already done that during the posting since it is using the exact same table. In essence, both batch processes are doing the same thing and that procedure takes a bit longer that the others. Since the one batch is slightly ahead in the process it drops the TEMP table while the other batch was still completing the process. When the second batch tries to move forward, the TEMP table is already dropped and the system does not move forward correctly which is causing the issue.