Microsoft,Dynamics,Business,Po computer Microsoft Dynamics GP Business Portal Implementation Notes
Gone are those times when the companies and the organisations didn't need a hi-tech system to handle them. Owing to the considerable increase in the business sector and thus, an enormous increase in the complexity of the organisational struc ----------------------------------------------------------Permission is granted for the below article to forward,reprint, distribute, use for ezine, newsletter, website,offer as free bonus or part of a product for sale as longas no changes a
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. Lets 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 InvoiceBP 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, dont 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 dont 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
Microsoft,Dynamics,Business,Po