Throughout the previous years of implementing and supporting Dynamics GP, I have worked in several complex environments with quite complicated business needs, although, Dynamics GP has always proved how strong and powerful business solution it can be for small and medium sized companies.
Dynamics GP has a long history not only as a financial but also as a management solution to automate and streamline business processes from supply chain, manufacturing, Human Resources and project management.
The business environment nowadays is changing so fast, which imposes great pressures on companies to respond to the continuously changing market demands, in this essence, existing Dynamics GP clients might be challenged by such demands as the system might be perceived as traditional accounting system.
Although, it is simply not correct. Dynamics GP can be extended and utilized as a powerful platform to support the complex business environment needs, they key to that is simply "Enhancements".
If you are an existing Dynamics GP client who's struggling with certain limitations in the system that can not fulfill your business demands, reach out to me through SIROCo; a Microsoft Partner located in the US with multiple regional offices. I will make sure to provide easy answers and fixes to complex dilemmas .
We would be more than happy to provide free analysis and assessment to your Dynamics GP environment, propose possible enhancements and put your back on the right track to get your return on investment.
This has always been a mystery to some clients, and a problem to multiple other clients, the fact that Dynamics GP prevents transaction level posting from posting "Through" general ledger is no longer true.
With t the release of Dynamics GP 2018 R2, the system now allows end users to post transactions without a batch, although, it will post through GL rather than the need to post these transactions again from the general ledger level.
In order to allow transaction level posting with "Post Through" option, open the posting setup window from Microsoft Dynamics GP > Tools > Setup > Posting > Posting
A new option is added under "Allow Transaction Posting", which is: "Post Through General Ledger Files"
Here is the screen shot from the Posting Setup window:
Posting Setup Window - Post Through General Ledger Files
Below is a list of windows which have an option to "Allow Post Through with Transaction Level Posting"
With the release of Dynamics GP 2018 R2, several new features were introduced to the core functionality in the system. In this post, we will shed a light on an interesting feature provided for the inventory module in regards of the Historical Inventory Trial Balance.
In previous posts, it has been thoroughly discussed that HITB usually encounters issues represented with zero quantity and negative/positive cost. The source of the problem is represented with mismatching issues between inventory cost layers ( IV10200, IV10201) from one side and (SEE30303) from the other side.
Here is a brief on the issue:
Inventory Cost Layers versus HITB (SEE30303)
I have seen such case with multiple clients, resolving this case requires internal matching or rebuilding of the HITB inventory source in order to recalculate quantity and value records and ensure that historical and current inventory balances are matching.
In the same context, the recent release of Dynamics GP 2018 R2 has introduced an interesting feature for the HITB report represented with the ability to either include or exclude either items with "Zero Quantity" or "Zero Value", this will ensure that HITB report is being filter properly for all the zero quantity or value records.
In order to print the Historical Inventory Trial Balance report, follow the path below:
Reports > Inventory > Activity > Historical IV Trial Balance,
While applying a payment to a posted invoice in the payable module, an error pops up indicating that " You can't choose this document because it is part of a recovered batch or is still in the process of posting" as illustrated in the screen shot below.
Nothing exists in the batch recover, don't waste time looking for any corrupted records there
This issue occurs due to having the same record ( mostly an invoice ) in both work and open tables (Unposted and Posted table) . As the apply function checks for any open transaction, duplicated records are found across PM10000 and PM20000, which results with this issue.
In order to resolve the issue, you basically need to delete the record from the PM10000 which already exists in the PM20000. Then, try again and the apply payable document will work perfectly as designed.
DELETE FROM PM10000 WHERE VCHNUMWK = 'XXXXXXX'
Run the script as you replace the XXXXXXX with the specific voucher number which already exists in PM20000.
If you are performing the year end closing procedure and encountering the error " Query Timeout Expired" specifically at step 3 out 7, then an error message popped up " The stored procedure glYearEndCloseMain returned the following results DBMS ... ", you need to know that the GL year end closing procedure has failed as it partially closed the year.
Issue Diagnosis :
When closing the year, Dynamics GP goes through seven steps precisely in order to reconcile GL balances, check returned accounts, account types ... etc and close the year.
Step 3 calls stored procedure "glYearEndCloseMain" which primarily moves records from GL20000 to GL30000, create BBF records. Here is the SQL statement which is causing the system to hang:
Resolution The very initial step to ensure that you restore Dynamics GP databases since in such case the GL tables would be partially corrupted due to having "partial year end closing"
The next step is to check the "Auto Growth - Maximum Size " property on the database server for the GP database. The case occurred due to having insufficient database size restricted by the maximum size.
When migrating reports from one management reporter server to another, the easiest way is to export the management reporter building blocks from the original management reporter server and import them into the new server.
It is a straight forward method and it doesn't seem to encounter much efforts theoretically. Although, when you have the management report crashes all of a sudden while doing the export or import, things get too complicated.
Case Reported - Management Reporter Crashes during Import Export of Building Blocks :
As clearly illustrated in the screen shot below, on the import export wizard of the building blocks, you highlight the specific reports you want to import and click on "Import Function". At certain import it works and at other chances it fails and MR crashes and close.
Import Export of Building Blocks - Wizard
MR Crashes - MR Dynamics ERP has stopped Working
MR Crash Cause
The root cause of the problem above is that if the "mouse cursor" passes over the "report name" column, management reporter client pops up an info message, this functionality is not supported by a certain window update.
Resolution In order to ensure that the MR client will not crash while doing the import export for the building blocks, you simply need not to move the mouse cursor over the "report name" column. Eventually, the building blocks will be imported and exported smoothly without any encountered issues.
As promised, It has been recently announced that Microsoft Dynamics GP 2018 R2 is released with lots of new features. The GP team at Microsoft assured that Dynamics GP continues to deliver great added value to companies including existing and new customers
Microsoft Dynamics GP 2018 R2 improves the core functionality of the system and introduces new enhancements to the system covering the following
Microsoft is releasing Dynamics GP 2018 R2 in October, 1 2018. As usual, this release is providing further enhancements to the core functionality of the system with top features requested by the clients. Microsoft as recently provided a road map for Dynamics GP up until 2020 .
With every release of Dynamics GP, Microsoft team starts a feature series addressing the features to be introduced in the next release and sheds a light on the functionality enhancement. Below is a brief list of the promised features:
Exclude items from the HITB with zero quantities ( Historical Inventory Trial Balance)
Transaction level posting - post through to GL
Monthly and Bimonthly recurring batches
The ability to display or not the inactive checkbooks in Look-ups
Don’t allow duplicate check numbers for Bank transaction entry, miscellaneous checks
Adding vendor document number to purchasing All in One inquiry
Mass update inactive from Navigation List, Inactivate Reactivate Temporary
Check book ID defaults on computer checks batch
Allow partial purchase on a purchase requisition from a PO
Display vendor Hold status
Sales Transaction Workflow
Print invoice in functional currency from SOP Navigation list
New Smart list for deposits on un-posted sales transactions
Print and Email SOP documents at the same time
Customer combiner utility , retain ship to address
Additional sort options on SOP Item Inquiry
Email Customer statements
Additional Top Features
Hide business analyzer for all users
Increase Dynamics GP password maximum length to 21 characters
Password expiry notifications
Smart list designer favorites display in navigation list
When reconciling inventory module with the general ledger in Dynamics GP, the historical inventory trial balance represents the most powerful tool which is used primarily by GP end users. several previous posts were introduced on Dynamics GP Essentials as part of the Essentials Series . In this post, we are shedding a light on a specific support case related to missing records in the HITB report.
HITB report and Inventory Reconcile to GL retrieves data primarily from the SEE30303 table. In this essence, the following should perfectly match without any issue.
One additional customized report for the HITB that was previously provided on this link retrieves the inventory cumulative balances as of a specific period. Here is the report details:
Inventory Balances - HITB Cumulative
Logically speaking, the following three parts should match perfectly since they all retrieve data from the HITB table - SEE30303.
In once of the recent support cases, the client reported that there are missing transactions from the HITB, when they print both; reconcile to GL and HITB, these transactions don't appear as part of the details. The result is that the Inventory and the GL are not reconcile.
The variance was represented with these missing records, which total value closes the variance and results in zero difference between the GL and the Inventory module
When checking the SEE30303 table, these transactions were available, although, they were not printing out on the HITB report since the following two columns were populated as 0
The resolution was to simply update the following fields in order to retrieve the correct inventory account as derived from the item card.
The following SQL Script retrieves these records which have incorrect inventory and inventory offset account index:
WHERE IVIVINDX = 0
AND IVIVOFIX = 0;
Important Note !
If the SQL Query above retrieved any records at all, you will have to update the inventory and inventory offset index columns and then run the HITB or the IV reconcile to GL again.