I recommend everyone to update your environment with this new build to avail it to it’s fullest.
More about this release: Support Debugging Tool Build 15 Released.
VAIDY
I have never written a code like this in my 8 years of experience. That said, I have not met any requirements that challenged me to write such code. With this, David has eased my (our) efforts in finding how it can be done.
Thanks David.
VAIDY
Interestingly, when I was explaining about Quantity Quoted Vs. Quantity To Order Vs. Quantity Cancelled, one user said they had never used Quantity Cancelled at all to record any line item cancellation. That was quite a surprise to me.
Consider this scenario: A customer enquires about couple of products and we prepare a quote and send it to them. Out of two products, they confirm only one and we are to transfer this quote with only product. There are three ways we can adapt:
1. Delete that unwanted product line on the quote and transfer this quote to an order (Bad Approach).
2. Transfer the quote in totality and from Sales Order delete that unwanted product line. (Bad Approach).
Above two approaches do not give us the fair picture on quote conversion. Considering the fact that GP SOP do not maintain a revision history of each document, it’s not advisable to follow above steps.
3. Cancel the quantity, by removing “Quantity To Order” and entering “Quantity Cancelled”. Transferring this quote will not transfer unwanted product to Sales Order.
By doing this you are retaining originally quoted products list and transferring only those which your customer wanted, also for your self-assessment on how you have performed in winning the quotations. Most recommended approach.
Of course, we would be forced to add/remove product lines from Sales Order for some reasons. But at least, quote conversion would give us facts at the time when we won the quote for that particular customer.
UPDATE: Siva has written a post which expands my post into different modules and how we can maintain records for better and painless auditing.
VAIDY
1. Don’t run Check Links process for AA at this time on versions GP10 and GP2010.
2 Apply latest Service Packs or Hotfixes for Microsoft Dynamics GP (versions 10 and 2010) to get AA related latest fixes.
More on this here: Information about Check Links for Analytical Accounting in Microsoft Dynamics GP.
VAIDY
I am talking about *Auto-Assign Serial Numbers* and *Auto-Assign Lot Numbers* options in Sales Order Processing Options Setup window.
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:
Dynamics GP - Learn & Discuss 