Crypt Trials Technology » Dynamics

Oracle To Dynamics Gp Great Plains Integration Notes

admin — Sat, 17 Jul 2010 16:16:52 +0000

If you work for large organization, which has independent subsidiaries and branches, running various ERP and accounting systems: Microsoft Dynamics GP, SAP Business One for example, and in the headquarters you have custom Oracle database application deployed (CRM, Sales Order Processing, EDI, eCommerce web site, Warehouse Management, Quality Control, etc.), then you might be interested in cross platform integration between Dynamics GP and Oracle application. Again, if you have Great Plains Dynamics implemented, it is rather legacy MRP and ERP systems situation, where either Oracle or Great Plains is the legacy, depending on your corporate IT strategy. In this small publication we would like to review Oracle integration options to Great Plains Dynamics GP:

1.       Dynamics GP SDK. We recommend you to review GP eConnect, as the set of libraries for your integration gateway to program bidirectional integration to and from Dynamics GP. You can deploy eConnect in Microsoft Visual Studio .Net C# or VB project, from where you could also call ODBC gateway to Oracle database world. You can either schedule eConnect gateway in batch integration scenario, or call it in real time with parameters of current transaction

2.       Dynamics GP Integration Manager. This scenario is more user friendly , but at the same time less flexible (if you are programmer and seeking for sophisticated custom integration logic). You can also schedule Dynamics GP IM in batch integration mode (look for generic Windows application macro solutions, where you can call EXE application with parameters, or simply purchase IM scheduler from Microsoft Business Solutions Dynamics GP reseller)

3.       Connection to Oracle. Here you may think about several technologies. If you are working for Oracle shop IT department, you should be already familiar with ODBC options at the Oracle end. If you are in Microsoft SQL Server type of circle, consider creating SQL Linked Server (in MS SQL Server 2005 or 2000) to open the door to Oracle databases

4.       Text files as Data interchange, CSV and Tab Delimited. This approach is feasible if your Oracle resides in Unix or upscale Linux (also consider XML data interchange, which is relative to the idea of platform independent text file). Text files, exported from Oracle database should be easy to process either in Dynamics GP Integration Manager or eConnect Add-on. If you have the objective to move your GL transactions from Dynamics GP General Ledger to Oracle Financials, you can easily export new Dynamics GP GL records via SQL view from GL20000 table

Econnect Ecommerce Posting Server for Dynamics Gp

admin — Tue, 13 Jul 2010 10:44:16 +0000

If you are eCommerce .Net c#, VB or SQL developer, you need to know eConnect – Microsoft Dynamics GP Great Plains SDK for e-commerce developers architecture and limitations. eConnect was specially built up for eCommerce programmers, however at the same time it complies to GP Dexterity architecture frameworks, such as GP batches and transactions posting is GP user prerogative. If you as eCommerce designer plan to post Gp transactions or batches automatically from your e-commerce web application, you will nee either Albaspectrum autoposting server or program Great Plains Dexterity source code with your internal programmers or Dex subcontractors. If you expect eCommerce website just to create so-called working orders or invoices in backend ERP Great Plains SOP Sales Order Processing module, then you are fine with eConnect development and deployment only. However if you only expect GP to fulfill invoices with goods delivery, then autoposting might be required. The rest of this article is dedicated to technology highlights:

1. Autoposting as Microsoft Dynamics GP Dexterity source code application. There is the way to command GP engine to post specific batch in any GP module: GL, SOP, POP, AR, AP, Payroll, Inventory control. However if you think this is easy solution, this is not the case, you need at least 5 years of Great Plains Dexterity programming with exposure to source code (DYNAMICS.DIC with all the sanscripts code not stripped out)

2. After Hours Posting in GP user interface. This is natural solution, when you have limited number of orders per day, let’s say 20 or up to 100. In this case if order size is feasible to sustain your business, you can hire Great Plains users, who will manually post your daily or weekly Sales Orders batches and transfer them for fulfillment and shipment to shipping department.

3. eCommerce integration to GP notes. There are several tools for you to consider, each has pluses and minuses as you can expect: eConnect – if you have developers inhouse, consider first eConnect as it is what Microsoft Business Solutions recommends in long run. If you think you are low level orders per day business, consider Great Plains Integration Manager (10-1000 transactions, maybe more if you consider IM automated integration with some custom logic to launch IM)

Microsoft Dexterity: Upgrading Custom Logic for Dynamics Gp

admin — Mon, 12 Jul 2010 05:34:21 +0000

Great Plains Software Dexterity platform was designed in earlier 1990th to be a foundation for Great Plains Dynamics and Dynamics S/C+. Dex was built on the principles of operating system “independence” (C programming language was in time believed to provide shell recompilation, including graphical components) and database platform independence (nobody could say which DB platform will win: MS SQL Server, Sybase, Btrieve, Oracle, IBM DB2). When Microsoft acquired Great Plains Software and formed ERP subdivision, Microsoft Business Solutions, these principles lost their initial focus, as you can suppose, Microsoft turned Great Plains to get advantages of Microsoft Windows OS source code and MS SQL Server as Microsoft database. Every action or decision obviously has pluses and minuses. Dex lost platform independence, but it gained the potential to increase its performance. Let’s take a look at these potentials closer:

1. SQL Aggregation as performance boost. In Dexterity we see Dex native cursors, these constructions allow you to abstract Dexterity sanscript code from low level DB query, but we know that cursors are similar to for statement in procedural programming languages (C, C++, C#, VB, Fortran, etc.). When the fate of GP database was determined, and Microsoft SQL Server was chosen to be the platform for the future, Dexterity programmers were encouraged to use select statement and call SQL stored procedures from Dexterity code. You can argue, that this option was available in the past, however if you think about GP ISV partners, they had to balance SQL and non-SQL Server platforms, such as Pervasive SQL and Ctree and supporting multiple platforms were easier in native Dexterity cursors. If you are Dexterity developer and you work for the company, deploying Great Plains as ERP, please feel free to review your Dex modifications and switch Dex cursors to SQL stored procedures

2. eConnect horizons. eConnect was specially designed for e-commerce application developers, allowing them to create, delete and modify GP master records and work transactions. Initially these options were only available to Dexterity programmer, and with eConnect MS Visual Studio.Net developers got some control over GP logic. If you have legacy Dexterity custom dictionary, please think about eConnect first as an option to upgrade your custom logic and port it into eConnect application. Dex has advantages of being seamlessly integrated with GP user interface and security model, however eConnect enables web applications to have some GP business logic

3. COM Objects and Web Services. In 1990th Dynamics had just a few compromises from OS independence principle – VBA would be one of theses. With acquisition by Microsoft, Dexterity gained new MS and Windows features: COM objects support, for example (Great Plains Dexterity 7.0 and later versions)

Great Plains Partner Newsflash: Dynamics GP Large Scale Ongoing Integration

admin — Thu, 08 Jul 2010 23:40:55 +0000

Microsoft Dynamics GP or former Great Plains Dynamics and eEnterprise should be a good fit for large organization, where you may need in high volume EDI integration to Great Plains from your Electronic Document Interchange order placement channel. If you have very strong internal IT team with Microsoft Visual Studio .Net C# or VB programmers with good SQL scripting background, you can decide to program integration in Dynamics GP eConnect SDK. In this small publication we are describing bullet proof method of deploying Dynamics GP Integration Manager module:1. Integration Source. In simple ad-hoc integrations you typically work with tab or comma delimited text files. In the case of large volume integration you typically have to deploy more advanced ODBC compliant connection. In Dynamics GP Integration Manager this is Advanced ODBC. Please, follow these steps: create new integration, name it and right click on Sources, add source, select Advanced ODBC and Define New Advanced ODBC, select ODBC Data Source (this is what you have already defined in your computer registry, Oracle Sales for example to get connected to your Oracle Custom Sales Order Processing database and application), in the SQL Statement edit area type in something like this: Select * from SalesOrders. In this case we assume that SalesOrders is either Oracle table or Oracle View. With Advanced ODBC Dynamics GP data source you can do pretty much what SQL is about: union, group by, sum, where, join, you name it. We recommend you to create SQL linked server construction in your Microsoft SQL Server 2005 or 2000, where you create heterogeneous query to Oracle, mySQL, Ingress, DB2 database, and enjoy the flexibility of Microsoft SQL Server Stored Procedure2. Integration Destination. Here for Dynamics GP 10.0 you have two options: Microsoft Dynamics GP and Microsoft Dynamics GP eConnnect. There is the difference between the two. Microsoft Dynamics GP is built upon OLE Server and as such it deploys your Great Plains user workstation to push data into Dynamics GP. As you can imagine OLE server is ancient technology and it is deploying the whole stack of layers to get final call (on Great Plains Dexterity level). eConnect is new and cool thing (based on direct encrypted SQL stored procedures). When you select either one of the destination adapters, then you are in normal realm of Dynamics GP modules: SOP (typically targeted in eCommerce applications), POP, GL, Payroll, etc. Please, be aware that eConnect adapter requires company database name (in comparison to OLE adapter, where company name is taken from your user login context)3. Destination Mapping. Here you can further customize integration logic by applying VBA scripts and translations. Follow this methodic: for the chosen field, change rule to Use Script, then on the left side click on the expansion button to the script value (default No) and in Script Editor demonstrate your VBA scripting skills. For Dynamics GP VBA scripting instructions, please open Great Plains Integration Manager Guide. In IM help -> Index, the using scripts or VBScripts objects. Another good advise: C:Program Files (x86)Microsoft DynamicsIntegration Manager 10helpdocumentation and open IMUserGuide.pdf book. Here you will have a lot of fun on practicing VBA scripts for Dynamics GP objects as well as doing Translation for object names in IM

Microsoft Dynamics GP Customization Support and Recovery Service

admin — Tue, 06 Jul 2010 01:58:28 +0000

If you have current or old version of Great Plains Dexterity custom add-on module, or another modification type, such as Modifier with VBA scripts or eConnect application (including the case when it is Microsoft Visual Studio .Net C# or VB ecommerce integration project), GP Integration Manager advanced customization with VBA events handling scripts, simple or Advanced ODBC data sources, Great Plains Macros (including such cases, when you are moving ongoing transactions and master records into such modules as Fixed Assets), complex reporting (FRx, SSRS, Crystal Reports, Report Writer), this small publication should give you initial highlights on what to do next and how to get further help:

1. Dexterity customization recovery. Great Plains Dexterity custom programming was very popular in earlier 2000th and we see large number of Microsoft Dynamics GP customers with Dexterity custom add-ons. If this is your case, please review your Dynamics.set file to locate custom module there (usually it has you company name listed in the name of the module), then find your Dexterity customization source code somewhere on your file server (or request it from your initial Dexterity programmer) – usually Dynamics.dic or Extract.dic with Dexterity Sanscript codes not stripped out (when you integrate Dexterity chunk – source codes are automatically stripped out and there is no way to recover them). If you are not comfortable and need help in reviewing your Microsoft Dexterity customization, please feel free to call our office, see phone and email below

2. Modifier with VBA modification recovery. In order to analyze your GP system and find out if it has Modifier modifications, please review your Dynamics.set file and see if you have modified forms dictionary (Forms.dic for main product) and if you have files with VBA extension in GP directory (these files would contain VBA scripts). In our statistical observations, VBA and Modifier are less popular, comparing to Dexterity customizations, however Modifier customizations could be extremely complex, especially when your former VBA developers used elements of Continuum (including Dexterity Sanscript codes into VBA scripts and switching GP modules contexts, from Dynamics to Intellisol for example). if you got one of these complex Modifier scripting examples, we recommend you to re-haul your Great Plains user workstation to port custom logic to newer tools: eConnect, Dexterity, Extender

3. Integration Manager historical integration recovery and upgrade. IM for earlier versions of GP was based on Great Plains workstation as OLE Server (before introduction of eConnect). You may expect light or heavy VBA event handling scripts in Integration Manager integrations, which could be dependent on unique UNC Path parameters and hardcoded User ID and Password. If you have eConnect connector based integration, attempt to port it to new computer should be combined with eConnect installation on that new hardware (please read eConnect documentation, especially related to Control Panel Component Services). Integration Manager could be perfect tool for Quasi Real time ecommerce integration to Dynamics GP, where you base your Source on Advanced ODBC Query (SQL Server View, including heterogeneous, where data is pulled from MS SQL Server and Oracle)

4. Dynamics GP Reporting. For older versions of Great Plains Dynamics (8.0, 7.5, 7.0, 6.0, 5.5, 4.0, 3.2, including Great Plains on Pervasive SQL / Btrieve or Ctree/Faircom) reports were traditionally designed on Great Plains Report Writer (GP module programmed in Dexterity). Newer versions of Dynamics GP (9.0, 10.0 and 11.0 – expected release in May 2010) has more options for Microsoft SQL Server Reporting Services (SSRS) and more traditional reporting tools, such as Crystal Reports, Microsoft Access Reporting and MS Excel. All the versions of Great Plains and Microsoft Dynamics GP deploy FRx Financial Reporting for such reports as Balance Sheet, Profit and Loss , Statement of Cash Flow and plus consolidated versions of these reports. FRx also allows you to base report on so called Reporting Tree (consolidation by company or by account segment or account wild card or segment mask). If you have to consolidate foreign subsidiary, which is on different Corporate ERP platform, such as SAP Business One or 1S bukhgalteria, you can export foreign branch financial statements or GL trial balance to Excel and consolidate Excel worksheet with Headquarters P&L or BS in FRx

5. eConnect SDK for Microsoft Dynamics GP. Initially this tool was introduced for Great Plains eCommerce programmers to open up back office Dynamics GP accounting for ecommerce shopping cart integration. Since then (2003) eConnect went through the gradual evolution and in our opinion it came to its maturity in Dynamics GP version 9.0 (better to deploy eConnect for Microsoft Dynamics GP 10.0 as this is current version as we write these lines in December 2009, new version of GP 11.0 will or should be released in May 2010)

6. Great Plains Customizations in International Environment. Before being purchased by Microsoft, Great Plains Software made substantial efforts to expand in Europe: France, Germany, UK, Ireland, Spain, Poland, Austria, Russia. However, since the time when Microsoft Business Solutions acquired Great Plains Software and its satellites: Navision and Axapta, MBS strategy changed. And this change is not a surprise – Navision was one of the leaders in Europe in late 1990th and as you could guess there is no sense to compete with Navision on European ground. Axapta, being initially developed and introduced by Damgaard Software in Denmark (perfect cluster of Corporate ERP and accounting application firms: Navision, Mac Hansa, Maconomy, Axapta). Currently Axapta is sort of rising star for Microsoft Business Solutions Worldwide and Navision has good positions in Europe and Dynamics GP is trenched in USA, Canada and English speaking World

7. SAP Business One Rising Star. This small and mid size business Corporate ERP application with elements of CRM, Service Management, Manufacturing and Discrete Production, eCommerce. SB1 is localized and certified with Russian, Chinese, Japanese, Korean, Brazilian tax agencies, plus you can switch languages from English to Russian or Chinese or Brazilian Portuguese

Microsoft Dynamics Gp Ecommerce Partner In Los Angeles Notes

admin — Mon, 05 Jul 2010 11:33:41 +0000

There are several approaches to eCommerce implementation for mid-market Corporate ERP applications, such as Microsoft Dynamics GP or SAP Business One. The first one is to redeploy ecommerce on new product or ecommerce add-on – here you have to sacrifice former investment into custom ecommerce web application and make new ecommerce implementation. Second approach is to capitalize on the old investment into legacy custom ecommerce application and integrate it with Dynamics GP via custom connectors. We are favoring the second approach and this small publication should give you initial highlights on ecommerce integration programming:

1. Integration Manager – batch mode ecommerce integration. If you do not need real time (or quasi real time – say every half an hour) ecommerce transactions integration and you can simply export ecommerce transactions into text file or expose ecommerce SQL tables via ODBC DSN – then you may decide to use Dynamics GP Integration Manager module, where you setup Sales Order Processing documents integration and call it on demand (maybe every morning or every night). Yes, it might be that simple and you can reduce your proposed ecommerce integration budget to just purchasing GP Integration Manager and if required ask for Dynamics GP consultant help in setting up the integration

2. eConnect. This is Software Development Kit with code samples in C# and VB. If you consider yourself as experienced or even moderate Microsoft Visual Studio .Net programmer with some SQL and XML expertise – you can explore eConnect and make self discovery. Programmatically you can create SOP transaction (such as ecommerce Invoice, Sales Order or Quote) and place it into the Work batch for future approval in Great Plains and posting by the GP user. eConnect can do real time integration as single transaction integration could be event driven (when ecommerce customer places the order). If you are about to decide to take eConnect route – we recommend you to upgrade Dynamics GP to current version 11.0, or at least 10.0 (9.0 at minimum), as we believe that eConnect came to its maturity for GP 10.0

3. eConnect automatic batch posting. In order to post batches directly from your ecommerce web application you need Alba Spectrum Posting Server. This add-on is programmed in Great Plains Dexterity with the references to Dynamics GP Source Code (original Dexterity Sanscript codes in Dynamics.dic, available to Source Code Partners)

4. eCommerce Order Connector. This add-on is written in SQL stored procedures with simplified logic, which should potentially be very time efficient. Plus Order Connector should be compatible with legacy versions of Great Plains: 9.0, 8.0, 7.5, 7.0 (assuming that you are on MS SQL Server DB platform)

5. Great Plains eCommerce and version consideration. If you are on older version of Great Plains Dynamics or eEnteprise – consider Integration Manager as reasonable approach, as IM is available with most of the versions down to version 4.0 (5.0, 5.5, 6.0 and up)

6. Local Dynamics GP eCommerce support in Los Angeles, Orange County and San Diego. We have two offices in Los Angeles and Carlsbad to cover Southern California metro area. Our consultants speak Spanish (Mexican and South American connection), Chinese (Asian connection and Port of LA), Portuguese (Brazilian connection, where we recommend SAP Business One for your Brazilian subsidiary), Russian (connection with Russia, where we recommend SAP B1 and 1S Bukhgalteria as well as Microsoft CRM for locations in Moscow)

7. Give us a call: 1-866-528-0577. Or email us: help@albaspectrum.com

Microsoft CRM 4.0 Integration notes: SAP Business One, Dynamics GP, Lotus, EDI

admin — Sat, 03 Jul 2010 10:16:10 +0000

As Microsoft Dynamics Technology partner, we would like to revisit popular Microsoft Dynamics CRM integration scenarios and technologies. This publication is intended to IT professionals and Microsoft Dynamics technical support people. Upfront we have to admit, that we are not reviewing any third party tools and Microsoft CRM Add-ons, we are considering integration tools, available out of the box for Microsoft CRM customer. Microsoft CRM versions: current 4.0, also historical 3.0, 1.2, 1.1

1.       Microsoft CRM SDK. If you are Microsoft Visual Studio .Net C#, VB or SQL programmer and developer, you may decide to dedicate some of your software development training time to familiarize yourself with SDK objects and methods: Lead, Account, Address, Contact, Quote, Order, Contract, Case, Task, etc. Microsoft CRM is pretty complex in its technology layers, and it is not recommended to populate MS CRM tables directly via SQL scripting – recommended way is to abstract your programming through MS CRM SDK layer

2.       Dynamics GP Great Plains integration programming. Here you have to consider Dynamics GP eConnect, this Software Development Kit opens Microsoft Dynamics GP objects, such as customer, vendor, GL account, employee, Sales Invoice, Purchase Order, etc. eConnect is also MS Visual Studio programmer friendly, so you could enjoy eConnect self discovery. We recommend you to consider web integration project, where you combine Microsoft CRM SDK and Great Plains eConnect libraries

3.       SAP Business One integration coding. In SB1 you should think about combining SAP Business One SDK libraries with Microsoft CRM SDK modules. SAP B1 and GP are both ERP and MRP applications and Microsoft CRM integration methodic is similar on technology layer

4.       Lotus Notes Domino integration. Here you have various layers. Try to review ODBC integration if you are doing discovery. ODBC expects you to have repetitive structures in Lotus Notes, which is pretty common if you are dealing with custom Lotus Notes database

5.       Microsoft CRM EDI programming. Electronic Document Interchange is typically associated with Vendor purchasing and order placement channel. If you have merchandise ordering logic from your Microsoft CRM Sales Orders, then consider formatted SQL Select statement from CRM tables

Dynamics GP ecommerce integrations: eConnect, Posting Server notes

admin — Fri, 02 Jul 2010 06:01:28 +0000

It is often good idea to start ecommerce from scratch, however for some of us it doesn’t work as we work for established ecommerce retailers and wholesalers, where ecommerce application might be custom developed and hosted on Linux/PHP/MySQL, Oracle or another non Microsoft solution. In this situation you would rather consider custom integration with existing ecommerce web site and we would like to share with your some highlights. We are trying to write this small publication for programmers and IT people as a review:

1. eConnect SDK. If you are comfortable with Microsoft Visual Studio C#, VB or another .Net language programming, plus you are fluent with XML and have good SQL querying background, you should take a class or try self study on eConnect. With this Software Development Kit you can program virtually all core modules Great Plains objects: GL Accounts, Customers, Vendors, Employees, Addresses. SOP Invoices, Purchase Orders, etc. eConnect might seem a bit complex, especially when you are very brave and would like to try coding custom SQL Stored Procedures, in this case, please consider the following fact – eConnect is written in SQL Stored procs (that are encrypted) and you probably do not want to do it second time, especially taking into consideration the fact, that in Microsoft Business Solutions programmers have access to all the Dynamics GP Dexterity source codes and got appropriate training

2. eConnect Posting restriction. eConnect doesn’t post Dynamics GP batches, as this is how Great Plains architecture was built. Batch posting is prerogative for GP user, who supposed to review the batch (print batch edit list report), get sufficient evidence that all the transactions are correct and ready for posting and then post the batch from Great Plains user interface. If you really think that you need to post GP batch from ecommerce application directly, please read the next paragraph about Dynamics GP Posting Server, or Autopost

3. Great Plains Posting Server. We developed this Add-On in Dynamics GP Dexterity, it deploys native Dex posting routines and by doing so eliminates the problems with Software QA, as it is not exposed to programming bugs. Posting Server or Autopost is for Software Developer and it allows programmers to flag Dynamics GP work transactions batch for posting. Batch posting checker is running every few minutes and it looks at batch ready for posting table and if batch is there, it triggers Dynamics GP regular batch posting routine

4. SQL Scripts in ecommerce integrations. We have several scripts collections, one of them is Order Connector, which allows you to deploy scripts to move ecommerce orders or invoices to Dynamics GP SOP Orders and Invoices accordingly. Order connector runs faster in our opinion that eConnect methods, as we are not validating all Dynamics GP business logic and instead give you green light with simple Orders and Invoices

5. If you have concerns, or would like to get more info, see presentation, feel free to call us: 1-866-528-0577, help@albaspectrum.com

Dynamics GP Barcoding Integrations Notes

admin — Thu, 01 Jul 2010 04:06:29 +0000

Microsoft Dynamics GP, formerly known as Great Plains Dynamics and eEnteprise, has reasonable selection of Dynamics GP ISV products and add-ons, including custom modules with Barcode scanning support. However, Great Plains interface potentially opens Barcode data integration ports in every application screen, where you can enter new data or update existing records. This is why you can always design new requirements for Barcoding integration in GP. Let’s review barcode scanning and integration options:

1. Barcoding process. Scanner could potentially replace computer keyboard and instead of keying in characters and digits, you can read them directly from scanner or barcode server (real time mode) or its memory (batch mode). When you do real time integration, you often do not need any customization, as data goes directly to GP form edit fields. However when you do batch mode scanned data upload to Dynamics GP – you typically need batch processing custom logic

2. Barcoding automation custom programming. If you need integration form be integrated with Dynamics GP GUI, then you may consider GP Dexterity as Development Environment. If you are comfortable in having integration interface be web form, or .Net application, you should consider coding this add-on in eConnect. Dex is semi proprietary programming environment with Sanscript programming language, it is not easy to become Dexterity programmer, and if you do not expect to do tons of Dynamics GP modifications in the future, you should consider subcontracting Dex customizations to Dynamics GP ISV Partner with Dexterity Software Development Factory. eConnect is pretty open for generic Microsoft Visual Studio C#, VB, SQL programmers, who are also familiar with XML

3. Barcode Labels Printing. You can deploy generic reporting tools: Crystal Reports, SSRS, or you can create label printing report in Dynamics GP ReportWriter. For calling Crystal Report with parameters, consider Modifier with VBA in GP directly or purchase third party add-ons (Rockton, for example)

4. Barcoding in Purchase Receipts, Inventory Cycle Count, Inventory Transfers, Picking and Packing. The most popular and successful barcode integration could be expected in Transportation and Logistics, Wholesale and Retail, Consignment, Freight Forwarding, International Custom Clearance, Cargo Tracking, and other industries

5. How to get help? Please call us: 1-866-528-0577, help@albaspectrum.com

Scm Custom Extensions For Microsoft Dynamics Gp Great Plains

admin — Wed, 30 Jun 2010 00:44:48 +0000

Supply Chain Management often is Barcode driven and includes inventory replenishment, and also Sales order execution with high level of processes automation. If you are mid-size organization, engaged in Warehouse Management, Merchandise Automatic Replenishment, advanced Barcode automated Order Execution (Order Assembly, Picking and Packing, Finished Goods Returns and Disassembly), you may expect certain level of custom programming in implementing Supply Chain Management Solution for Microsoft Dynamics GP. We already described in several publications specifics of Great Plains Warehouse Management, Barcoding, Consignment, integration with Retail Application, Inventory Cycle count. In this paper we will try to give you generic SCM approaches and options, especially when you came to the conclusion, that existing out-of-the-box Dynamics GP SCM packages do not provide required functionality:

1. External Application integration with Dynamics GP versus extending Great Plains screen in Supply Chain Management application. This is probably one of the first questions or topics for your homework. There are great SCM self sufficient systems out there on the Corporate ERP software market and if you think that reasonable integration to Dynamics GP is OK, you can decide to take that route. In Dynamics GP there are several integration tools to consider. In the simplest and probably the most recommended scenario, consider GP Integration Manager module, where you can integrate CSV or tab delimited text files as well as via Advanced ODBC query – whatever could be exposed via ODBC bridge (including cross platform DB queries: Oracle, DBII, PHP/MySQL/Linux, Pervasive SQL). You can also explore Dynamics GP eConnect to move records from SCM system to GP. In the case of eConnect you have more control, including real time transaction integration triggering options (eConnect libraries could be included into your MS Visual Studio C#, VB application, where you program your custom integration)

2. Extending native Dynamics GP Screens and business logic to achieve Supply Chain Management goals. Microsoft Dynamics GP itself has very rich business logic, especially in such modules as Inventory Control (items transfer between the sites, cycle count, cost and price control), Bill of Materials (for light discrete manufacturing, including production on demand or order execution), Purchase Order Processing (especially with Purchasing Configurator – this module might be the core of your SCM Inventory Replenishment), Sales Order Processing (where you can capitalize on order execution steps, including order or invoice line allocation/fulfillment, backorders) – to give you several reasons to consider. You may pose the question for your management team – we already bought Dynamics GP Business Ready licenses, where a lot of our SCM required logic is already included – we just need to enable Barcode automation to make Great Plains friendly for your Warehouse workers. If you decide to take Dynamics GP existing business logic extension route, here are the tools for you to consider: Microsoft Dexterity (this is Great Plains architecture with its own scripting language Sanscript and Integrated Development Environment, you have no limits with Dexterity, except probably the fact that Dex requires experienced programmers, who are preferably familiar with Dynamics GP Source Code). Second tools could be Modifier with VBA – it is not .Net compliant but still does wonderful job or extending Dynamics GP screens with new editable fields, push buttons, etc., where you would need to animate these new objects with VBA scripts. VBA allows you to push data to Dynamics GP tables via ADO technology

3. Barcoding Focus. In Dynamics GP every screen where you have editable fields could be subject for Barcode integration (or where you would like to upload barcode scanner batch). The reason to consider custom add-on programming here is simple – each Corporate ERP application screen has several types of editable fields: Drop Down List, Check Box, Radio Group, Edit Field and plus these fields should be filled in determined sequence. Barcode scanner is capable to fill scanned code into Edit Field, and it requires custom logic to automate the rest of the Screen business logic

4. International SCM focus. Microsoft Dynamics GP is localized in most of English speaking countries: USA, Canada, UK, Australia, New Zealand, Oceania, South Africa, plus it is localized to some extent in Spanish speaking South and Central America and Caribbean basin, It is also available in French in Quebec/Montreal. Dynamics GP is also translated to Arabic. In the countries and regions where GP is not localized: Brazil, China, Russia, Japan, Continental Europe, Korea – we recommend SAP Business One

5. How to get further help? Please call us 1-866-528-0577, 1-630-961-5918 or email us help@albaspectrum.com