Microsoft Dynamics GP’s eConnect is a powerful tool, user-friendly for .NET developers, comprehensive, well-documented, and generally efficient. While it has its occasional quirks, it’s a great system to work with.
However, there’s a common misunderstanding among non-technical users about the effort required for developing a full-fledged eConnect integration. They often assume it’s as straightforward as Integration Manager, where building an integration should only take a few hours at most.
Unfortunately, it’s rarely that simple. To illustrate the complexity, consider a scenario where a GP partner underestimates the time needed to develop an integration involving Purchase Order Processing (POP), Sales Order Processing (SOP), and Project Accounting. When explaining why this integration would take approximately 40 hours to develop, it’s crucial to emphasize that eConnect itself represents only a small part of the overall process.
Think of it this way: eConnect is the easy part, maybe 10% of the work. It’s a standard API with good documentation, a known entity. The remaining 90% involves handling the client’s source data file, creating business logic for processing this data, and managing any exceptions within it. Additionally, factors like testing, debugging, making minor adjustments, installation, and documentation require significant time and effort.
While there are instances where clients have very clean and straightforward data files that seamlessly flow into GP without requiring data transformations, lookups, or complex exception handling, those situations are generally rare. Such simple integrations are often achievable through Integration Manager or even table imports (although table imports aren’t always recommended).
The true power and benefits of custom eConnect integrations shine through in complex scenarios. In these cases, the value lies not solely within eConnect but also in the additional logic incorporated into the custom integration. For instance, importing a customer into GP via eConnect is typically a standard procedure. You define the customer and address objects, populate their properties, and send the data to eConnect.
However, complexities arise when customer data is spread across multiple files, uses different formats, or contains unparsed or incomplete addresses. In these situations, custom .NET code becomes invaluable. This additional code handles data transformation, manages exceptions, and ultimately makes the integration far more robust and valuable than a generic import.
Here’s a relevant example: a client had over 600,000 monthly cash receipts, a number that was quickly growing. They receive a single large payment from an external trading partner, along with a 150MB text file containing payment details for each customer. The task involved entering these cash receipts and applying them to invoices – totaling over 1,000,000 transactions monthly. The client sought to automate this process to eliminate the three full days of manual work. At first glance, this seems relatively straightforward, and eConnect is capable of handling it.
However, when asked if there were any manual exceptions or issues requiring attention before entering or applying a cash receipt, the client initially said, “No, not really.” This seemed unlikely.
Upon further investigation, it was revealed that the customer ID wasn’t included in the data file; only the customer name was provided. Sometimes this name matched the one in GP, sometimes it was similar, and sometimes it was entirely different. The accounting team had to manually look up each customer name in GP. This is a major issue for 600,000 transactions. While it’s possible to map the customer names in the data file to GP customers, this process has nothing to do with eConnect.
Further complexities were revealed, like an additional worksheet containing a different type of cash receipt that required separate handling. This meant dealing with both regular and special cash receipts – another exception to handle before involving eConnect.
As for payment applications, initial inquiries suggested no issues. However, upon examining the first cash receipt in GP, it became clear that it wasn’t applied to an invoice because there wasn’t one available for that customer. This presented another exception. Then came overpayments, underpayments, and requests for automatic debit and credit memo generation, applied to the customer’s balance based on specific thresholds. Anything exceeding that threshold would appear on an exception report for review.
As the requirements and exceptions grew, it became clear that the primary challenge wasn’t eConnect itself. It was managing the massive 150MB data file and the multitude of exceptions the integration needed to address. An efficient way to deal with exceptions and errors was essential. The solution involved creating an exception file, allowing the client to focus on the specific records needing attention instead of wading through the full 600,000-line file.
Finally, reporting was crucial, providing a log of imported cash receipts and their corresponding invoices.
While this was a challenging project, the ability to transform a three-day ordeal into a 15-minute process was incredibly rewarding. However, it’s important to remember that a significant portion of the work, approximately 90%, involved managing and manipulating the source data, while only 10% directly involved eConnect.
_Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified Professional in Los Angeles. He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.