Microsoft Dynamics GP Business Portal Implementation Notes

You should clearly understand what is GP and what is Business Portal and where they have “shared territory” – which SQL databases they both use and share and how BP utilizes GP eConnect, MS Exchange, Terminal Services; how document is processes in BP and then how it travels down to GP; how to create report sharing BP and GP data, etc.

• GP typical document workflow.  Please, think about such BP module as Requisition Management.  Let’s try to track RM document life cycle.  In Business Portal: employee creates Purchase Request and submits it to the manager for approval.  Manager (from Approval hierarchy) reviews PR, makes required changes (selects vendor, expense account, price, inventory item, site – all or some of these decisions will be available to the approver in the hierarchy, based on BP RM security settings) and document goes up through approval hierarchy, finally reaching purchasing clerk.  Purchasing officer creates Purchase Order (or adds the lines to existing PO for the same vendor) – at this moment the document reaches Great Plains.  In GP it shows up as Purchase Order, which has GP approval (this is typically not as complicated as in BP RM).  When PO is approved in GP – it should be sent to the selected vendor as official PO.  Vendor furnishes requested items typically with vendor invoice; in some cases vendor invoice is sent separate – these two scenarios in GP are handled as Purchase Receipt and PR with Vendor Invoice
• BP is GP extension.  As you can see from the above example – BP Requisition Management module could be considered as an extension to Great Plains.  Similar conclusion could be made for HR and Employee Self Service module – this BP module requires either GP Payroll or GP Human Resources modules (or both) implemented in GP backoffice.
• BP Hosting Databases.  Microsoft Great Plains allows you to add objects: tables, SQL views, stored procedures, triggers to existing GP databases, such as Dynamics (GP system database) and company databases.  “Allows” means – these custom object will not be wiped out with GP version upgrade.  GP tables names are not “human friendly”: IV00101, GL00100 – these are probably coming from UNIX naming traditions; BP tables names, in contrast, are easily recognizable: ReqMgmtDocument and ReqMgmtLines – these names you can probably recognize, don’t you?  BP places it tables in Dynamics and companies databases, so in order to create BP-GP report – you will need to review BP tables and views and research GP tables: Tools->Resource Descriptions->Tables.
• BP licensing.  This is where you get cost efficiency.  You don’t want to pay costly GP user licenses for your employees and people who places purchase requests (typically all your office employees).  Instead you purchase BP user licenses (which is below $50 per user/employee)
• eOrder, eRequisition version upgrade.  Sometimes this is confusing issue.  BP for GP 8.0 and 9.0 is completely rewritten in .Net product and such legacy ASP applications as eOrder, eRequisition, eEmployee, etc. are rewritten as well in BP.  In other words – if you used eXXX series of products – you will need to redeploy or even reimplement them in Business Portal