Check out: BKD GP Team Blog – Dynamics GP Insights.
VAIDY
Check out: BKD GP Team Blog – Dynamics GP Insights.
VAIDY
It was suppose to be a simple task to release this transaction for edit, but due to some reason this transaction got stuck in between. It did not come back to it’s original batch and quite obviously it did not get posted either due to that error.
Following are the steps involved in releasing that transaction:
CHECKS
1. Check whether the transaction is still in RM10301 (RM Sales Work) table.
In my case it was still in RM10301 table.
2. Check the fields BACHNUMB (Batch Number) and BCHSOURC (Batch Source) in RM10301 table for that transaction.
In my case, BACHNUMB contained the USER ID who tried posting the batch; BCHSOURC contained XRM_Sales instead of RM_Sales, since it was in the middle of posting process and got stuck.
3. Check whether a batch with that user’s USER ID is created in SY00500 (Batch Header) table.
In my case, there was indeed a batch with that User ID. Because of which, this user could not open Receivables Transaction Entry window and was receiving the (in)famous error message “A previous transaction level posting… … …”.
CORRECTION STEPS
1. I first created a Receivables batch (I named it as RM-RECOV).
2. Through SQL Server Management Studio, I updated RM10301 table fields BACHNUMB and BCHSOURC as follows:
BACHNUMB = ‘RM-RECOV’
BCHSOURC = ‘RM_Sales’
3. Deleted the batch [USER ID] from SY00500 table, to remove user’s transaction posting session lock.
4. Tried opening that transaction on Receivables Transaction Entry form. Since the batch number RM-RECOV was updated through backend, it did not obviously update batch information. Due to which, I still could not open this transaction.
5. As a final step, I ran Receivables Reconcile Batch Information (Tools => Utilities => Sales => Reconcile). This step updated the amount from that erroneous transaction on to batch RM-RECOV.
After above steps, user was then able to reopen that transaction and edit it.
Bottomline: SQL approach is not always the only option for consultants to clear such issues. We need to perform some crucial application level tasks that would compliment SQL methods.
VAIDY
I am sure this is going to delight people across world who use AA and are dying to see some kind of ways to enhance their AA analysis capabilities.
VAIDY
There won’t be any performance issues obviously as stated by him, but there are some crucial points that we need to think about before enabling it.
Enabling it on live environment is like inviting disaster. I remember I used to do that, but only after all users log off from GP. That particular customer, they don’t work 24/7 which gave me the confidence to enable it on live and disable it back once my troubleshooting was over. I would have been in very deep trouble easily had I not remembered disabling that after my task.
Even a single Dex debug message box would be more than enough to drive a user crazy.
VAIDY
Sales Document Copy feature is a boon for those who deal with sales documents with more than 25 line items (or even 10 that matters) on a daily basis. Below is the Sales Document Copy window:
Our Finance Team and I decided to first do perform YE Close on our test company first before we make it to Live, to anticipate any possible issues and also learn this entire process as this our first YE close in GP2010.
You must by now anticipated what I had done to simulate Live Company. YES, I created a Test Company on same SQL Server (Mark, trust me, your post came after this exercise) and restored live company data on to Test Company.
This we normally do for any transaction level exercise that users would want to perform for their own sake.
The process started and after a good enough time of about 5 hours, it threw an error message, which said roughly Primary Key violation of key PKAAG30000 on table AAG30000.
Upon digging more and keeping a SQL Server profiler, I met this silly yet critical reason: AA was trying to create an entry on table AAG30000 in Live Company database. Why? I have no clue why it would ever happen.
My only guess is that every Journal Entry in GL table will have Live Company Database ID (such as TWO that denotes sample company). AA might have thought that this one is an Intercompany transaction and it requires to create an AA entry in Live Company for that portion of JRN that was processed in Test Company. The only field in AAG30000 that’s considered as Primary Key is aaGLHdrID. My live company would have gone past the next aaGLHdrID which is in Test Company (a back dated restoration) by the time I ran YE close on my Test Company.
I am yet to prove my own theory above, but I strongly doubt so.
Upon suspicion, I decided to create a TEST SERVER (Mark, your post had come exactly at that point of time). I just believe Mark Polino’s Weekly Dynamics article was so timely and I couldn’t agree for more.
After configuring a Test Server environment, I restored DYNAMICS and Company DB, pointed my GP to this test server and ran YE close as if I was running it on my production server.
Good god, YE Close got over without any AA error. I then had no other option than to believe that Test Company with Live Data do not augur well for exercises such as YE close and is in fact quite risky.
Addendum: With GP 12 Multi-Tenant architecture, we don’t have to worry about this, as we can easily setup a TEST SERVER along with LIVE SERVER in the same physical server.
VAIDY
I just wanted to share my thoughts:
Account Segments are simply real. You are going to have separate accounts for specific entity and that means you must be setting these accounts up on several other places in GP other than only Posting Accounts setup. For instance, if you are going to have accounts for each employees of your organization and you track expenses on them, then you got to have each account setup against each employee explicitly and setup GP such that it takes accounts from employee directly instead of Posting Accounts.
Analytical Accounting is purely logical. You don’t really have separate account for each entity that you wish to. Setting up AA dimensions and codes are one time.
Actual complexity lies in assigning AA codes on a particular transaction. Worst case, if you have an apportionment across different AA codes, you have manually apportion it in Analytical Accounting Transaction Entry form. Data Entry is very complex at times with AA. Without proper AA setup, your data will logically scattered and any analysis on this data would be a menace for you to understand.
You can minimize the data entry time by using Analytical Accounting ALIAS, but that again depends on case to case basis. You cannot always depend on AA ALIAS for all kinds of transactions.
Simply speaking, AA considerably reduces your COA but let you toil at times entering apportionment within a transaction. You gain on one side, you have to experience some pain on the other side.
VAIDY
I am not going to discuss this post here. I am just creating a pointer to this article here, since it’s worth to go to Mariano’s site and read it there.
The post, Microsoft Dynamics GP “12” Named System Database Architecture, explains us what this new feature is and how it is going to be designed. Benefits and challenges are discussed as well.
Bottomline: With this new architecture, customers and consultants are going to be delighted. GP 12 is going to be just terrific. There are challenges as pointed out in the last paragraph but will be met with ease by those dependable brains.
Thank you so much Mariano for sharing this first hand information.
VAIDY
The list categorizes reports by module and indicates whether it’s a normal report or KPI based report. This would be the best document to make us aware of and convince our customers that GP does have such expansive list of standard reports and KPIs.
VAIDY
Recently one of my contacts asked me about a GP process and asked my help in getting any KB articles related to that process. I said I would share the KB article number with him but since Microsoft says that it is all *confidential*, I cannot distribute the article directly or publish it directly on my website. I also mentioned that he could instead refer to that KB article number and look it up from Microsoft PartnerSource / CustomerSource. After all, I was under the impression that he’s also a Consultant and is working with a Partner, so ideally he has got access to PartnerSource.
After a week, I was quite shocked to know that he later *downloaded* the same KB article from some other website (I do not want to name this website here, as it is also a known Microsoft Dynamics Partner) as a PDF document. And he criticized me for giving him a lame reason for not sharing the article myself. Worst thing, he even accused me of being selfish in keeping information only with me. OK, that’s quite understandable from his side. What I don’t understand now is the term CONFIDENTIAL on all these KB articles.
Microsoft is keep these articles with a confidentiality tag and has given access ONLY via CustomerSource or PartnerSource. But in reality there are many people out there who clearly violates this *confidentiality* part and has published these articles open.
It’s quite simple. I just don’t want to look dumb in front of people when I say “These KB articles are confidential and are NOT supposedly to be distributed openly”. Well I am frankly serious. You feel like you are the most dumbest guy in this world by saying that. Come on, you have these articles openly sprayed out there on several websites (some of them are genuine Microsoft Dynamics Partners) and all you gotta do is to search and download it.
That brings on my mind several questions for Microsoft:
1. What’s the scope of confidentiality for all these KB articles?
2. On what basis this *confidentiality* is defined and when it is considered violated?
3. What is the real point in keeping these articles as confidential, if I can download these articles from anywhere anytime anyhow?
4. Why don’t you just take that *confidential* tag out and keep it open for all, irrespective of whether they have CustomerSource / PartnerSource access?
VAIDY