Where is my Custom Reminder window to add reminders to my GP home page?


I was reported with a very vague issue: user could not create a custom reminder from a smartlist. He received an error message as follows:

Snip20130417_3

Basically, below is the window which user is trying to open:

Snip20130417_5

Ideally, you would think that this window is a part of Microsoft Dynamics GP dictionary. But it is NOT. It is a part of Smartlist dictionary.

But trick here is, you cannot see this window listed on when you try to assign this window a particular Security Task using Security Task Setup window. Then, how? How would I give access to this window?

After around an hour or so, with several script logs and profilers misleading me, I found one interesting statement on SQL Profiler trace, that was executed when the user tried opening that window:

Snip20130417_6

Exactly after this SQL statement, the above error message was thrown at the user. Which means, I must focus my troubleshooting efforts on this table; DYNAMICS..SY10000. This table is simply called User Security.

When user tried to open Custom Reminder window, system checked this table and see whether this user has got access to a window whose resource ID is 1452 in dictionary 0 (which is nothing but product Microsoft Dynamics GP) inside company ID 1 (which is my production GP company).

I was always thinking about something in Smartlist (which is, without any doubt), but system was checking something else in a different dictionary altogether. I wanted to see the window in Microsoft Dynamics GP dictionary which is of resource ID 1452. Opened the DYNAMICS.DIC on Dexterity and checked it, only to realise with disbelief that it was referring to following window:

Snip20130417_7

I did not understand first. Why would it check something totally irrelevant from what user wanted to open? Why would it check access to this window, when opening a window in different dictionary? I have no answer to these questions.

But I just thought I would take a chance. I checked this user’s security task setup and found that Reminders window was not assigned. I assigned that window for this user as shown below:

Snip20130417_8

Tested whether he could open Custom Reminder. To my utter disbelief, IT DID.

So, if somebody is facing same issue and has already lost almost all your hair, here you have, a solution that would bring upon peace.

VAIDY

Cashbook Bank Transfer Error: Date entered is not a current period for checkbook [Checkbook ID]


This was a menace for the past 4 days, to say the least.

I was reported of this issue, where a user when trying to enter a bank transfer for a checkbook, on a date in previous month, he got this error message (in the title of this post) as shown below:

The above message occurred only for one particular checkbook and not for others.

First step was to ensure the fiscal period was not closed. It was not.

Second step was to ensure that they had not run the reconciliation for this checkbook, so genuinely it had closed the period. It was not.

Third step was to run check links for Checkbook Master, to ensure that things are fine with Checkbook ID master record. It was perfect.

Fourth step was to take SQL Profile and see where exactly this message pops up. When I took twice, the results were different. Due to Analytical Accounting. But that I never got to know since, my focus was more on CB tables.

I referred to the ONLY AVAILABLE forum post, Date Entered is not for Current Period for CashBook, which was way back in year 2010. No solution was provided though.

I decided to take the SQL profile again, but this time without Analytical Accounting to avoid extra lines on the trace file. I took the profile twice and both matched line by line.

The last table where the buck stopped was CBINT605 (Reconciled Amounts) on DYNAMICS database. When I queried this table manually, following was the result:

As you see above, there was a record for this checkbook ID, with a date 30-Apr-2012. Due to which, if you enter any date on or before 30-Apr-2012, it fails.

I checked the user again to ensure that he had not run any reconciliation for this checkbook. He assured that he didn’t, but he also mentioned that he was demonstrating this process to a user, but did not complete it. Bad. Demonstrating on a live company is very bad.

I took a backup of this table and then deleted this record.

Now, my checkbook accepts any date for it’s bank transfer entry.

MORAL OF STORY #1: Messages never lie. If there is a message, it will most probably be correct.

MORAL OF STORY #2: Never ever do any R&D on live company. Never ever demonstrate anything on a live company. That’s why test companies are for.

VAIDY

Using Script Debugger in Runtime Mode


David explains us about using Script Debugger in Runtime mode.

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