Hi All,

An update to the previous post. My blog is now available and can be accessed without any issues on this new address: www.vaidy-dyngp.com. Sorry for the inconvenience (if any) for the past 3 days.

Hoping to see you all visiting my blog in future as well, learn and discuss GP.

Thanks
Vaidy

Hi All,

It’s a phase of CHANGE on all parts of the globe. Some are for good and some otherwise.

Hey wait a second… This has got nothing to do with my blog address being changed from http://vmdyngp.blogspot.com to http://www.vaidy-dyngp.com.

My blog is currently on a Domain Transition and will soon be available on the new address. Apologies for the inconvenience for those who follow my blog and for the new readers.

Till then you can access all the articles by replacing the address www.vaidy-dyngp.com by vmdyngp.blogspot.com. For instance the page address of the article GP to the Max is http://www.vaidy-dyngp.com/2008/12/gp-to-max.html, which can be accessed without any issues by replacing the www.vaidy-dyngp.com by vmdyngp.blogspot.com; so the temporary address will be http://vmdyngp.blogspot.com/2008/12/gp-to-max.html.

Thank you all for your time and interest on my blog. Please do continue visiting and contributing.

Vaidy

It’s been more than 45 days since I had given this solution to a Consultant who had asked me about using VBA & Macro. Initially I redirected him to some of David’s articles. But eventually I thought of doing it myself to know how that work. Below is the gist of what I did with relevant screenshots:

1. Open notepad and type the statements shown in the below screenshot:

2. Save the file as [your_file_name].mac and copy it to the GP Application Folder. In my case, the file name is: SetSOPAddItemMenu.mac
3. Make sure to have the Modifier license.
4. Launch GP and open Sales Transaction Entry.
5. Add Sales Transaction Entry to Visual Basic Editor. Never mind if you see a message, that the window is already been added.
6. Open Visual Basic Editor and select “SalesTransactionEntry”. Right click on it and select “View Code”. Write the piece of code which is shown in the below screenshot:

8. Make sure that, you replace the macro file name (which is shown above as SetSOPAddItemMenu.mac) with the name that you had given.
9. Save this code and compile for any errors.
10. This will do the trick of selecting “Add Item” by default whenever you open the Sales Transaction Entry form.

There are so many ways to achieve this. I was quite excited with this method, as this is a plain VBA stuff and no Dex involved. The effort required to achieve this is not more than 10mins. And finally, it will work with much assurance.

You can find the package to import and use this little customization from the link: SetSOPAddItemMenu.zip.

I have attached an “Installation Readme” for a quick usage reference.

Your comments / feedbacks are most welcome.

Vaidy

Another very important article in the SQL Series: Identifying Duplicate Transactions.

This is very much important and much needed one for all those developers/consultants. The basic idea is to identify unwanted, duplicate records on any transaction tables.

While David has mentioned the need of this, I would like to add one more point to stress the importance of having this script: Most of the customizations written across the world create records directly on the transaction tables (any module that matters). Even if we think that this is going to be perfect on most of the times, there is still a probability of a record getting inserted on any of the table without any relevance.

I would also like to derive a script, which can list the orphaned records as well as the craps. Well, that’s not so easy, I understand. But would be a great script.

Vaidy

Frank Hamelly, has started a blog finally. http://gp2themax.blogspot.com/

This is very much needed, atleast for all of us if not for Frank, to get most valuable information from under one roof.

Frank, welcome to GP Blogosphere. I have already read your first blog and it is precious as usual. Well, forget about the cool stuff, the article spoke your experience and what we can expect in future on your blog.

Thank you Mariano, for pulling Frank in.

Vaidy

While the GP Application Level Security left us with immense information to learn, here comes another series which is going to enlighten us.

First topic is already out (spSearchOnAllDB: SQL Stored Procedure to Search an Entire Database) and available for our reading, couple more are in the queue.

Start with this link: Useful SQL Scripts Series. The most important thing is to contribute some SQL Scripts, which one think would be very useful and is not available out in the common. It can be anything related to GP.

I wish more and more to come on this series.

Vaidy

After the series of GP Application Level Security topics from David, I thought of just substantiating one point which is also recommended by David.

While upgrading GP from lower versions to v10.0, it is recommended to redesign our User Security Access list instead of carrying forward from the lower versions. For those who ask “Why should I redesign when my Security Access details are already on place in the earlier version and it just needs to be transferred from lower version to current version?”, the reasons are listed below:

1. The security model approach in GP 10.0 is Pessimistic as opposed to the lower versions which are Optimistic.
2. It’s a perfect oppurtunity (as precisely mentioned by David on one of his articles: Information about using v10.0 Security Conversion Tool) to redesign our User Security Access using the new Security Roles and Tasks. While the conversion tool does transfer the existing details, it does not however convert the details to the exact Roles & Tasks. It just do a “Near-Role & Task” conversion, as explained on this article.
3. The new Security System provides us with a set of default Roles & Tasks, which are best suited and completely covers the entire system and its operations. In any case, we still need to re-define the Security Access rights to the 3rd Party features, so that is not considered in this discussion at all. We can leverage our Security Details to the best extent by making use of the new set of Roles & Tasks.
4. Technically, the tasks are CREATED instead of CONVERTED. Means, the old Security Details are recreated on the System tables, which means, unwanted load of Security Data. Which means, we may load our system with too many records which are not exact, but near to what is exact.

There may be a lot of other reasons, but the above is what I could think of at this very moment. I sincerely welcome more points supporting / opposing this.

Vaidy

For all Developers,

I just thought of sharing this very simple (some, with their experience, may even think that this is silly) piece of advise.

Recently I was working on a Customization (debugging an issue reported). An Inventory Variance Transaction was not getting posted. Trx Lines were perfect, the lots were properly assigned and everything looked perfect. This Variance Trx was created at runtime based on the Customization. Still, this batch was not getting posted. The client had suppressed the Edit List functionality on the Trx Entry and the Posting Journal Report on the Batch Entry screen. Ideally, there is no other way to get informed on what went wrong.

I first enabled the Edit List report on Batch Entry and ran the Edit List. Which displayed this error message: Lot number does exist for this item and site in Lot Number file.

I checked the IV Lot Master table and IV TRX Serial Lot Work table. Records were properly linked. After hours of troubleshooting, I finally found one difference.

The Date Seq Number in Lot Master table and IV Trx Serial Lot Work table did not match for the erroneous record. The value of DTSEQNUM in IV00300 table was 32768 and the value in IV10002 was 32767. I got the source code of that Customization and checked the place where this Trx is created. This developer had declared an “integer” variable and had passed it to the script INVEN_LotNumberAutoAssign script, which returns a “long” value for this parameter. Ideally this should have been 32768 and since the “integer” does not hold more than 32767, wherever the value was 32768, it had stored as 32767.

Well, the moral of this frustrating story: Please be very alert in declaring variables and always keep it to relevant Data Type, as this may take your (worse someone else’ life) life sometime down the lane.

Vaidy

Those who still love and live with Dexterity, David has given us (yeah I am also a die-hard Dexterity Developer) a great news.

Go thru’ his article: Statement of Direction for Microsoft Dynamics GP

I will be back with some more points on his other articles.

Until then…

Vaidy