Microsoft Dynamics GP Business Portal Implementation Notes
We certainly understand and respect new technology embracing approach. In order to implement Microsoft Great Plains Business Portal – you should come by implementation guide and understand the architecture of Business Portal and how it integrates with back office – Microsoft Dynamics GP. 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 proportion and how BP utilizes GP eConnect, MS Exchange, Terminal sets; how document is processes in BP and then how it travels down to GP; how to create report sharing BP and GP data, etc.
o 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 buy 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 obtainable to the approver in the hierarchy, based on BP RM security settings) and document goes up by approval hierarchy, finally reaching purchasing clerk. Purchasing officer creates buy 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 buy 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 chosen vendor as official PO. Vendor furnishes requested items typically with vendor invoice; in some situations vendor invoice is sent separate – these two scenarios in GP are handled as buy Receipt and PR with Vendor Invoice
o 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.
o 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” method – 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.
o 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 buy requests (typically all your office employees). Instead you buy BP user licenses (which is below $50 per user/employee)
o 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 in addition in BP. In other words – if you used eXXX series of products – you will need to redeploy or already reimplement them in Business Portal.