GP2013 – Purchase Invoice Inquiry Zoom Bug (Change)


I received a strange support request today from one of my users that PO number is not shown fully on Purchase Invoice Inquiry Zoom window. Just tried to inquire some purchase invoices myself and I got what she mentioned:

Snip20130807_12

 

If you see above highlighted PO number, it’s not shown fully. This will be the case only if you use GP’s standard PO number sequence or used entire PO length of 17 characters.

When I checked it on Modifier, I found a nice little icon sitting right next to PO number field, but overlapping it by some millimeters.

Snip20130807_11

This icon denotes whether the PO line item is Drop-Ship or not.

And boy, isn’t that icon looks cute? But unintentionally, it is overlapping on PO number field. Not sure how folks at GP dev team skipped this.

Solution to this issue? Modifier. Use modifier to resize the field, till we get this fixed by GP dev team.

VAIDY

Advertisement

GP 2013 Home Page (Re)Design Horrors


Well, I could understand what you might think after reading the title of this post AND if you had read my previous post on GP 2013 Home Page Redesign.

I did admit that the redesign was kind of great for users. Ian Grieve had commented back with an important #FAIL factor of this redesign.

With that #FAIL factor, I just got one more to crib about. So lets list it:

  • You cannot scroll within a frame. You MUST rely on mouse clicks(or a trackpad). You have no other option. (Thanks Ian, for your feedback with this point).

UPDATE (GP2013 SP1): Looks like this one’s fixed. You can indeed scroll within a frame using a standard mouse scroll wheel or a trackpad’s scrolling functionality. It’s a welcome fix.

  • If you ever want to realign the frames of a module (for instance Manufacturing), you can. But wait, that would stay ONLY TILL THAT SESSION IS ACTIVE. Once you log out from GP and log on back, your realignment is gone. Poof!!!

I am sure it is going to be highly irritating for users who rely mostly on GP home page.

And with that above statement, I now reverse my opinion on my first post.

VAIDY

Error when switching back to Microsoft Dynamics GP from Modifier – Fixed in SP3


With the release of Microsoft Dynamics GP 2010 SP3, MSFT GP development team has fixed one of the nagging bugs which got introduced in Microsoft Dynamics GP 2010 R2.

The following posts would explain what exactly that issue is:

Error When Switching Back To Microsoft Dynamics GP From Report Writer (Ian Grieve)

Unhandled script exception: Illegal address for field ‘[Not Found]’ in script ‘Unregister_Triggers’ (Mariano Gomez)

Rest assured that this bug is now fixed with the release of Gp 2010 SP3.

VAIDY

Analytical Accounting Menu Master Table (SY07110) Records Multiplying – Bug & Workaround


This one is another SY07110 (syMenuMstr) table issue.

For the past 1 week, users were complaining about GP slow down as soon as they select a company and click OK. The delay was anywere between 30 seconds to 1 minute, which is quite huge, considering the fact that GP is suppose to get initiated within 3-5 seconds maximum.

We have two different launch files; those users who are not suppose access AA and those who access AA. This delay was reported by only AA users. And that eased my debugging task out.

Troubleshooting started by taking a SQL Profile exactly at the time of selecting a company and clicking on OK. After painfully long time, GP got initiated with all Menu and other startup objects. I stopped SQL Profiler and noticed the following piece of SQL query being executed for as many as 143 times, which in total resulted in 4730 records:

The above query is same except some of the fields. But all these SQL SELECTs where targeting the same product; AA (CmdDictID = 3180).
Quite shockingly, I had 4730 records in SY07110 for Dictionary ID 3180, i.e. AA.
So how to solve this? Simple. I took a backup of this table (just for precaution) and executed the following SQL query:
DELETE DYNAMICS..SY07110
WHERE CmdDictID = 3180
It removed all 4730 records for AA module. I then launched GP. Bingo. It’s getting initiated in as long as 3 seconds.
The story does not end here. For the first time SY07110 table gets inserted with 33 records for AA module. As and when a user launch GP, with AA module, it inserts exactly ONE additional row onto SY07110 table.
Now this certainly looks like a bug.
So what’s the solution? Time being, I have to write a scheduled SQL job which will execute the above DELETE query on a weekly or daily basis.
I am not sure who else is currently facing this issue. If any of you people have this issue, then at least you have a workaround.
I am planning to raise a Support Ticket with MSFT team if no one out there gets back to me with a solution and make sure that this is not a bug as such.
VAIDY