Despite the fact that Microsoft Dynamics GP is an Enterprise Resource Planning system on its own, our company has very specialized needs requiring us to create a proprietary 'erp/crm' system, but we want to use Dynamics 2010 GP for the accounting functionality.
We have been advised that we need to use eConnect to 'talk' to and from Dynamics GP.
Our Accounting Dept will be working directly within the GP Client, but the others in the company will be working within the 'erp/crm' application, but needing to access GP info about the customers.
And some operations will be occurring automatically within the 'erp/crm' system that will need to automatically post AR transaction info into GP.
If necessary we can do direct SQL Operations to acquire/update/etc. GP data but we are not clear on where that might be appropriate and where using eConnect would be the best approach.
I have Victoria Yudin's EXCELLENT book:
Microsoft Dynamics GP 2010 Implementation.
While I am a long way from getting through the book, it does not seem to handle using eConnect to make things happen within GP from the 'outside' world.
I even have the 2 eConnect documents:
eConnect Installation and Administration Guide
eConnect Programmer's Guide
Those documents have a LOT of information in them - lots of micro operations, but not a clearly explained list of ALL of the aggregate micro operations that need to come together to make a complete and successful transaction occur.
What I am looking for is how to develop a 'road-map' of what eConnect functionality needs to be executed in order to perform certain transactions within the 'erp/crm' application.
I am assuming (accurate or not) that some transaction operations might require multiple eConnect operations.
While there are many operations that we need to support, what I am looking for today is what needs to occur when we want to:
* Create/Modify an Invoice entry from a 'erp/crm' sale into GP
* How to acquire AR (summarized or not) info on a customer that can be brought back to the 'erp/crm' for user display
Maybe I am just inundated with too much info and just haven't yet found the 'Yellow Brick Road' to the answers I am looking for (can't find the needle in the hay stack), but any help/advice you might be able to offer to get me started in the right direction would be greatly appreciated.
Thanks,
JRB-Bldr
We have been advised that we need to use eConnect to 'talk' to and from Dynamics GP.
Our Accounting Dept will be working directly within the GP Client, but the others in the company will be working within the 'erp/crm' application, but needing to access GP info about the customers.
And some operations will be occurring automatically within the 'erp/crm' system that will need to automatically post AR transaction info into GP.
If necessary we can do direct SQL Operations to acquire/update/etc. GP data but we are not clear on where that might be appropriate and where using eConnect would be the best approach.
I have Victoria Yudin's EXCELLENT book:
Microsoft Dynamics GP 2010 Implementation.
While I am a long way from getting through the book, it does not seem to handle using eConnect to make things happen within GP from the 'outside' world.
I even have the 2 eConnect documents:
eConnect Installation and Administration Guide
eConnect Programmer's Guide
Those documents have a LOT of information in them - lots of micro operations, but not a clearly explained list of ALL of the aggregate micro operations that need to come together to make a complete and successful transaction occur.
What I am looking for is how to develop a 'road-map' of what eConnect functionality needs to be executed in order to perform certain transactions within the 'erp/crm' application.
I am assuming (accurate or not) that some transaction operations might require multiple eConnect operations.
While there are many operations that we need to support, what I am looking for today is what needs to occur when we want to:
* Create/Modify an Invoice entry from a 'erp/crm' sale into GP
* How to acquire AR (summarized or not) info on a customer that can be brought back to the 'erp/crm' for user display
Maybe I am just inundated with too much info and just haven't yet found the 'Yellow Brick Road' to the answers I am looking for (can't find the needle in the hay stack), but any help/advice you might be able to offer to get me started in the right direction would be greatly appreciated.
Thanks,
JRB-Bldr
