tag:blogger.com,1999:blog-6691994129222744759.post3721225786972613191..comments2024-03-18T02:11:32.263-07:00Comments on Dynamics GP Land: One Very Hairy Dynamics GP IntegrationChristina Phillipshttp://www.blogger.com/profile/03332221198245457747noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-6691994129222744759.post-153551045842429702011-07-06T12:39:39.908-07:002011-07-06T12:39:39.908-07:00I am doing an internship right now. I have to do s...I am doing an internship right now. I have to do something "kind of" similar to what I am reading. I know this is really not a comment on the article in general but more of a question(as I cannot seem to find where to start researching this).<br /><br />We use GP2010 and Wennsoft service manager(an integrated add-on). Sales will generate a "request for service" which will contain customer information and service information for a job/services just sold.<br /><br />This data is in excel format and is currently reentered by the service department for every single service ticket requested. This seems redundant as most of the information required for a service call(other than technicians being assigned and ticket number etc) already exist in electronic(excel) format in this "request for service". <br /><br />I would like to find a way to have this information create a service call in GP so that a service person can recall the service call created and simply fill in the remainder of the ticket.<br /><br />Is something like this possible...or where is a good source for researching how to accomplish such a task?Opinionatedhttps://www.blogger.com/profile/04390640986196032429noreply@blogger.comtag:blogger.com,1999:blog-6691994129222744759.post-73861403148004818612011-05-18T15:02:07.911-07:002011-05-18T15:02:07.911-07:00Thanks for the comment TechnologyGuy.
You are cor...Thanks for the comment TechnologyGuy.<br /><br />You are correct, the issues exist well before the receipt is imported, but very little is simple or clean cut with this client's environment. My post wasn't an attempt to provide the entire context of the client's environment, but just to highlight how seemingly simple transactions or processes can become very complex in the real world.<br /><br />In this case, all of the data in GP is coming from multiple external systems. Items come from one system, Purchase Orders come from another system, and receipts come from multiple external partners, which are 3PL warehouses.<br /><br />Hence the funky Excel report that I have to use for the receipts--it's what the 3PL warehouse is able to provide.<br /><br />Overall, we're talking about millions of transactions a year that are being integrated into GP, so even if there is a small exception rate, that can mean thousands of transactions--which must be handled in an automated manner if at all possible, since the exception volume is too great to handle manually.<br /><br />Unfortunately, it's not as simple as any single system or any single set of controls--it's multiple internal divisions, departments, and systems, along with multiple external trading partners. There are "explanations" for many of the issues I highlighted, but in the end, we still need to get the data into GP.<br /><br />To have Dynamics GP integration requirements dictate how a massive company operates is, to use the trite analogy, like "the tail wagging the dog".<br /><br />Like most companies, the accounting department does not drive the business. Sales, operations, and fulfillment take precedence, and accounting is left to assemble what is given to them.<br /><br />In an ideal world, yes, things would be neat and clean, but when it comes to high volume inventory for a global corporation, things are rarely perfect.<br /><br />Fortunately, between .NET and eConnect, I was able to get the job done--it just took a lot longer to address all of the details.Steve Endowhttps://www.blogger.com/profile/03950475674093020502noreply@blogger.comtag:blogger.com,1999:blog-6691994129222744759.post-69128208483764468432011-05-18T11:45:53.731-07:002011-05-18T11:45:53.731-07:00This is certainly a nightmare, and I'm sure yo...This is certainly a nightmare, and I'm sure you're going to spend some nights dreaming about coding your integration!<br /><br />It seems to me that this isn't a technological problem you're fighting - it's a business process and control problem. A huge one!<br /><br />Firstly, you haven't mentioned what kind of system are you integrating from or what its whole purpose is in the grand scheme of things. Is this some receivings spreadsheets that the shop guys use? Is it an external requisitioning system? Are you having to deal with inventory, or is it just services?<br /><br />Your first problem is that the system you're integrating from doesn't have any controls in place (from the sounds of it, ANY controls). Have you asked yourself or your client why you want to circumvent the controls in the PO system to fit their external system? Have you asked why they want this information integrated into Purchase Orders instead of, say, Inventory and Payables separately (if inventory is affected) or just Payables? <br /><br />Maybe the bigger problem is that they have the wrong system in place to begin with. There are requisitioning systems, for example, that already integrate directly with GP, have all the required controls in place, allow easy web-based entery for staff, and integrate into other, sophisticated systems. <br /><br />Where is the data coming from that it is this unstructured? Do staff enter this information somewhere? Are the spreadsheets really what drives the whole process? If so, instead of fighting with programatically handling every exception they can throw at you, maybe you need to discuss some process and policies for employees to follow when creating the data in the first place.<br /><br />I agree with the 90/10 rule, but I think it needs a bit of tweaking:<br /><br />90% Process, 10% System.Technology Guyhttps://www.blogger.com/profile/09364436635403356984noreply@blogger.com