Dynamics Blogger

The title of the post “The selected position is default and cannot be deleted” is actually an error message that is encountered in Microsoft Dynamics GP Business Portal Requisition Management module. This message will pop up when we try to delete a user in Approval hierarchy who is appearing multiple times in the hierarchy and is assigned the default status. When the settings are such that users can be added multiple times in the hierarchy, the approval hierarchy of the requisition management allows the user to be added multiple times. For example, User A Assigned under User B and the same User A assigned under User C. The question is which level this user will be assigned default status? Default User status is assigned when the user is first defined in the approval hierarchy. Typically, it is called the first level. In the above example, User A is assigned under User B and then to User C. In this case, User A assigned to User B will be assigned default status. Assume a scenario, ...

I’d say this is a million dollar question when some one asks me when Requisition Management module for Dynamics GP gets a feature pack. Unlike Dynamics GP which gets frequent upgrades through various feature and service packs, this specific module within Business Portal looks to be completely kept in the dark. Microsoft is also tight lipped when I queried on the same in several forums on various feature requirements in this one module. In one of his articles, Mariano presented a nice graphic of Dynamics GP roadmap, if my memory is good enough. I tried my level best searching one for Requisition Management or Business portal, I had a hard luck in getting it. Probably it doesn’t exist either or not available on the public internet. So, What is this module lacking in terms of features? I highlighted certain requirements in my earlier post titled Requisition Management – Enhancements When? . Adding to these requirements, there comes several other requests from various clients lined up...

Consider this scenario of your development environment for Dynamics GP Requisition Management in Business Portal before deploying the production environment. What if you would want to remove all requisitions? Here is one easy method to accomplish the same. Deleting data from tables is not always the wise choice though. Requisition Management tables are stored in DYNAMICS database. Here are the tables where it holds requisition transactional data. Keep a backup of DYNAMICS Database first and then run a DELETE statement on these tables below to delete the complete data. ReqMgmtDocument – This holds the Requisition header data ReqMgmtLines- This holds the Requisition line items detail ReqMgmtOpenTasks- This holds list of requisitions waiting on for approval ReqMgmtAuditHistoryDocument-This holds complete history of the requisitions Header ReqMgmtAuditHistoryLines- This holds requisitions line item history After this, We can reset the Next Requisition number in Company setti...

I was thinking of much apt title for this post, I couldn’t get one. This post is about some of the pain areas in Requisition Management module for Dynamics GP (BP 3.0 or 4.0 or 5.0 whatever version we are). Because I feel we continue to see the same functionality since the old Business Portal 3.0 for Dynamics GP 9.0, Business Portal 4.0 for Dynamics GP 10.0 or Business Portal 5.0 for Dynamics GP 2010 with few exceptions. Having said that, We also understand there’s a lot of feature enhancements for BP as a whole, Workflows, Web services and Dynamics GP itself that is helping Dynamics GP to withstand as a favorite product to many in terms of choice. I have implemented Requisition Management module in several places and I must say the product is flexible to implement and a robust functionality than what we could expect from. Yet, I opine that It has certain limitations which has to be addressed at least in the upcoming versions (Though not certain about when it would actually happen). ...

Recently I responded to a thread on Dynamics GP Community forum pertaining to the subject in the title of this post. I thought I place the Q&A in this post since it might be helpful for others when they come across the same questions. Q. Do we need to have Business Portal installed to integrate Requisition Management with MOSS 2007? A. Requisition Management is part of Business Portal and not exactly part of MOSS 2007 or no integration for that matter. Business Portal itself requires either MOSS or WSS. Q. Does Business Portal must be installed for us to use the Requisition Management module? A. Yes. Because Requisition Management is a module that is part of Business Portal and not a stand alone product by itself Q. When BP is installed, I assume it asks for the URL/ Server where our MOSS environment lives, does it then create a site within our MOSS site collection, so it appears seamless to the end user? A. Basically If you have MOSS installed, First you need to instal...

For most of us who would like to understand the prime differences between PO Commitments and Encumbrance Management functionality, Here comes a great information from Dynamics GP partner Forums as was provided by C J Joven of Microsoft.  Differences 1. Encumbrance tracks history in Great Plains while PO Commitments does not. 2. Encumbrance doesn’t integrate with Requisition Management only PO Commitments. You can still use Encumbrance instead of Commitments, but you can’t track against a budget within Business Portal Requisition Management until you create a PO in Great Plains. 3. Encumbrance requires all budgets to be entered for all open fiscal years but PO Commitment's budgets can be entered for any years you want to. Similarities 1.They are initiated in the Purchase Order Entry window. 2. Budgets are for Purchase Orders only. 3. Can do multiple purchases simultaneously (mass). 4. Inquiries on current view. 5. No MC functionality. ...