Microsoft Dynamics GP 2013 Web Client – Tidbit

Posted on March 21, 2012 by Vaidhy Mohan

Well, this one is surely a delight for me personally, because I am a die hard Dexterity Developer and I always had and will recommend any customization to be on Dexterity.

I am currently watching Convergence 2012 virtual session named “The Road to Microsoft Dynamics GP ’12′”and got this snapshot which is self-explanatory:

I took this snapshot as is from the virtual session.

Recently I converted all our existing VBA customizations (critical ones) to Dexterity and now this news. Those who were preaching against Dexterity and predicted it’s doomsday, please change your mindset at least from now.

VAIDY

Auto Assign Serial / Lot Numbers on SOP Document

Posted on June 19, 2011 by Vaidhy Mohan

When do we select this option in SOP Setup? Is there any valid requirement that would arise so we setup SOP that on a Sales Document, Serial/Lot numbers automatically get assigned?

I am talking about *Auto-Assign Serial Numbers* and *Auto-Assign Lot Numbers* options in Sales Order Processing Options Setup window.

As a normal practice, I would always keep it unselected. I would like to make sure that I handpick items with specific serial numbers so I won’t let the system pick recent ones first and retain old ones.

Simply speaking, I would always want to sell old items first to make sure that I don’t leave it in my stock as unsold. Like a FIFO.

There are prominently two queries that arise on my mind:

1. How GP automatically takes Serial/Lot numbers for a particular item, if we select the above options? Does it follow FIFO approach or does it randomly pick some serial/lot number?

2. Is there a practical scenario where we require these options selected?

I would be grateful to receive your inputs as comments.

Thanks in advance.

VAIDY

CRM 4.0 Outlook Client Error Message – There was an error while executing action for this menu item/button.

Posted on December 6, 2010 by Vaidhy Mohan

It’s CRM Implementation again and this time quite good amount of time is involved in configuring CRM & GP to Business Requirements.

I faced an error message in CRM Outlook Client and thought I would share the fix to that error. I haven’t found one single answer on all available forums leading people in the right direction.

We have a new CRM Outlook Toolbar which is small yet powerfully packed with all relevant CRM activities that can be performed from within Outlook. The toolbar is shown below:

Using the “New Record” option shown above, we can create a new Lead/Contact/Account/Opportunity/etc/. This will open an IE browser window with relevant Creation form. Excellent, isn’t it? You don’t require to access CRM Web Client at all.

ISSUE: This issue that I faced would occur on following environment: Windows 7 / Vista, CRM 4.0 Outlook Client with Rollup 14 (latest), Outlook 2007 / 2010.

When you try to create a new item (Lead, Account, etc), you get an error message as shown below:

The above error message will then trigger the following IE behavior:

REASON: After some troubleshooting and surfing, some of the forum posts directed me to one single point: User Account Control (UAC).

Invariably all those forum posts asked me to disable UAC for this CRM Outlook Toolbar functionalities to work, which is quite risky. I don’t want to compromise with that. So what else would be the solution? “Run as Administrator” of course.

SOLUTION: NEVER DISABLE UAC in Windows 7 / Vista. It’s not safe. But you can always set any Application Compatibility to “Run as Administrator“. Below is how you enable it for Outlook Application:

So that’s it. I closed Outlook and reopened it. CRM works merrily now from Outlook.

VAIDY

Cashbook Bank Management & Accounts Receivables – Critical Audit Trail Code Link

Posted on August 28, 2010 by Vaidhy Mohan

I recently worked on an issue reported by one of my Finance Colleagues, whose team takes care of Cashbook Bank Management (CBM) Transactions as process owners.

They post Receipts from CBM and that in turn creates an AR Receipt. They post these AR transactions either by posting the AR Batch having that CBM originated receipt OR sometimes by directly posting that AR Receipt by deleting the Batch Number from that transaction.

A week earlier, they reported an issue:

Couple of receipts were voided in AR after posting it in AR, but it is not showing up in CBM Transaction Enquiry/Void process, for them to apply that void entry in their Bank Book. That means, voiding specific CBM originated AR Cash Receipts is not automatically creating a void link in CBM.

Quite serious and I had no clue whatsoever. I asked them for some samples of those which were voided in AR and getting reflected in CBM as well. Idea is to find THAT difference which prevents the couple of AR Voids not getting shown up.

The major and critical difference that I found is as shown below:

The first payment #2445 was voided in AR and it created a void link entry in CBM, whereas the second payment #2446 was voided in AR and it DID NOT created a void link entry in CBM. The difference, after seeing the above screenshot, is quite telling.

Payment #2445 contains an Audit Trail code which starts with CBREC (denotes a CBM Receipt) and Payment #2446 contains an Audit Trail code which starts with RMCSH (denotes an AR Receipt). Quite ridiculous, we may think, since both are created from CBM. But on a specific occasion, system does warn us as shown below:

The above warning is shown, when we delete the Batch Number from the CBM originated AR Cash Receipt. If you ignore / confirm this warning message by clicking YES, then the Audit Trail link between CBM & AR Receipts is broken, thereby any future actions on these transactions would never get automatically reflected.

Process Explanation: When we post a CBM Receipt, it creates an AR Cash Receipt in a Batch with Batch Number as the CBM Transaction’s Audit Trail Code, such as CBREC00000677. When you post this AR Batch as it is from AR, this Audit Trail Code link will be established completely on both CBM and AR Tables. When you either void or reverse this AR Cash Receipt in AR, based on the Audit Trail Link, it automatically creates a Void / Reverse entry in CBM.

Normally, for one Cash Receipt in CBM, one AR Batch with CBM Audit Trail Code as Batch Number will be created. But at times, CBM maintains one Audit Trail code for several CBM Receipts (typically this happens when you want to run the CBM Receipt Posting Journals for all receipts at a time, and for that, you do not close the receipt window each time you post an CBM Receipt). In such cases, if the User wants to post only one AR Receipt in a Batch, he/she opens the transaction directly from AR Cash Receipt, REMOVE the batch number from that transaction and post it.

This Batch Removal action triggers the above warning message to the users to confirm whether they are aware of this Audit Trail Link breakage and that they are willingly do it. If the user say YES, it’s broken. You would never be able to reverse this action, at any point of time later.

For those who use CBM for their business processes, GIVE HEED TO THIS WARNING MESSAGE. This warning message is not just a typical GP Warning Message and it does have some serious implication towards how later this particular transaction is going to be treated in GP.

Addendum: Not all warning messages are junk in GP. This particular mindset among users is quite common, as sometimes they really do see some junk messages (Exceptions, DBMS Errors, etc) and they don’t seem to pay attention to Messages at all over a period of time; Partly due to the unwillingness to understand about the Product, Partly due to the misunderstanding from a particular warning message and Partly due to Addons’ / Customizations’ messages created by ISVs, Developers, etc. Once user get a feeling that such messages are a waste to read OR possess least significance, they start avoiding ALL messages. This may result in serious impacts.

My humble advise to all out there: Pay Attention to GP Warning Messages. If you feel like it’s wrongly thrown, contact your Support Consultant / Partner / Report to Microsoft.

BUT DO NOT EVER IGNORE Warning Messages.

VAIDY

Are you importing VBA Customizations from 64 Bit to 32 Bit? Beware

Posted on August 23, 2010 by Vaidhy Mohan

This one’s quite baffling. The scenario is this:

1. I have my VBA Customizations on a 64 Bit Live Environment.
2. I wanted to setup a Dev Environment so that I can work on Enhancements and Additions. The Dev Environment is nothing but my laptop and it’s quite obviously 32 Bit.
3. I had DBs restored from Live and GP installed with necessary addons on my laptop.
4. Imported Modifier/VBA Customizations from Live to my laptop. There we go with an error message, which I am yet to solve:

And it took me to the VBA Editor. Since it said “VBA6.DLL is not found”, I wanted to check whether all References are proper. And below is what I found:

See the highlighted path and filename. It’s completely different from what it has to be “VBA6.DLL”.

Excellent and a pat on my back. Now why this is happening. I found the reason when I cross checked Live Environment VBA References:

Alright, the issue is this:

1. On a 64 Bit Server, GP and VBA Files are installed on Program Files (x86) folder.
2. Whereas on a 32 Bit machine, GP and VBA Files are installed directly on Program Files folder.

That’s the difference. Once you import and start GP it does work for the first time. Once you close GP and reopen it, it refers to (x86) folder. Since it’s not found, it starts throwing this message.

The sad parts: Firstly, I won’t be able to change the path back to Program Files folder manually by clicking on BROWSE in the References window. Secondly, I won’t be able to remove the reference by unselecting it and then reattach the VBA6.DLL reference. It will always throw me an error message like this:

I am in a fix now. We may have some other ways to handle this. I am working on that. There may be a followup post which will explain the methods that can be used to fix this issue.

Meanwhile, if anyone has faced this issue, do share your ideas and how you fixed it. It would save me some time.

UPDATE – 1: The reason explained above is substantiated, when I did another test. I imported 64 Bit Server VBA Customizations onto another 64 Bit Environment, it works. I imported a 32 Bit Server VBA Customization onto another 32 Bit Environment, and it works.

UPDATE – 2: The reason that I had explained in this article, is only partial. There are more to this issue. My next article explains the solution and also contains a link to Dynamics GP Partner Forum post, which led to a fix. Read it here: Solution to “File Not Found: VZBA6.DLL” Error Message.

VAIDY

How to tackle Chunk Upgrade with Modified Forms/Reports?

Posted on June 18, 2010 by Vaidhy Mohan

This post an extension of Sivakumar’s post on How to Deploy Chunk Files.

Let’s consider, we have a Custom Product chunk file which has been deployed already on a Customer’s site. And we are suppose to deploy an update to that product. Now this particular Custom Product has been modified either the Forms or Reports or Both.

I am going to talk about two scenarios:

1. The developer who has developed this customization, maintains a version to each release.

2. The developer do not maintain the version for releases.

Let’s first take the #2 scenario: The developer do not maintain a versioning for releases. Which is very difficult and time consuming when we deploy. How to deploy this chunk without harming the Forms AND / OR Reports Modifications? David just explained it to Siva, which is clearly explained in Siva’s post.

Let’s first take the #1 scenario: The developer maintains a versioning for each release. I would salute such developers. It’s very rare to see developers maintaining a version for small customizations. If it’s a Dex Customization, it MUST have a version, a proper version. Versioning Dex Customizations have got so many advantages. One such advantage is the one which I am going to explain below.

If we have a version for a chunk and we are trying to deploy an update (which will logically have a higher version than the one which was deployed earlier), then GP Utilities will take care of deploying this chunk and upgrading the Forms & Reports Modifications.

Steps are as follows:

1. Install the chunk on GP Site (copy the chunk on to GP Application Folder and launch GP). You won’t be able to log on, if there is a Modified Form(s) for this product.
2. Close GP.
3. Launch GP Utilities.
4. Verify GP Dynamics Version and Company Databases Versions.
5. Then select the option “Update modified forms and reports” when this window is shown up:

6. Just make sure that you have backed up Dynamics.set file and Modified Forms Dictionary for that Customization chunk.

Important Note: You must copy the Previous version Modified Forms dictionary to another folder (remember, COPY and NOT Move). And follow the instructions shown in the subsequent wizard steps.

For more details, just refer to GP Utilities Help File (Click on that BLUE ? Button shown in the above screenshot and read the instructions).

Hope this helps.

Thanks so much, Sivakumar & David, for giving me a topic to share with our community.

Sivakumar’s Article on How to Deploy Chunk Files – A Note To Remember.

VAIDY

Niraj’s First Birth Anniversary…!

Posted on June 5, 2010 by Vaidhy Mohan

KINDLY NOTE: This post is PERSONAL and nothing to do with Dynamics GP…

Time moves on… Moves on very fast…

Our beloved NIRAJ, Son of Shan & Uma, completes his first year in this world. 🙂 Yup tomorrow is his first Birth Anniversary…

Let’s all join to wish him a Happy Birthday & Blissful Life…!!!

VAIDY

SOP – "This document has been posted." Error & Resolution

Posted on December 15, 2009 by Vaidhy Mohan

This one was a real menace for me, to say the least.

One of the Users reported the error message “This document has been posted.” for a particular SOP Document.

The following were the observations:
1. This document was never saved in a batch.
2. GP hung at the time of entering this document.
3. The User killed GP session in order to come out of the Hung Session.
4. User confirmed that he did not enter any Batch while creating this Document.
5. Once restarting GP (after the KILL), he entered the SOP Number (which he had noted down) and received this Error Message.

Following this, I first resorted in clearing all the Activity Records (ACTIVITY, SY00800, DEX_LOCK & DEX_SESSION). There is a KB article, KB#857082, explaining this issue and the resolution. BUT this did not solve the issue at all. I was still getting the same error message again.

I checked the SOP10100 table for the record and found that document residing there. Also in SOP10102 and SOP10200 tables. Now, I did the following:

1. Created an SOP Batch in GP.
2. Updated the SOP10100 record for that document with the Batch Number that I created in GP.
3. Tried opening the document, but in vain. Still the same error.
4. Checked several updates but to no avail.

After quite an amount of frustrating time, SQL Profiler and Dex Script Log, I found the following:

Batch Source (BCHSOURC) field of table SOP Header Work (SOP10100) MUST NOT BE EMPTY. It has to be “Sales Entry” (Note the Cases; It has to be exactly “Sales Entry“). If the Batch Source field is empty, GP understands that this document is a Real Time document and that it should not be residing in SOP Header Work table at all.

Alright, after I updated this field, I am good to go to open that stuck SOP Document.

NOTE: Always in scenarios like this, delete the SOP Document and recreate it. It’s not advisable to amend anything to this released SOP Document. We never know what else would be wrong with such documents.

Happy Debugging; What else could I say !?!?! :-).

VAIDY