I have an existing integration with Great Plains importing JE's from a source Enterprise Asset Management system. These journal entries record receiving and inventory transactions.
Since last year, when it went live, I have been using the actual Journal Entry Number from the Source System as the Journal Number in GP, because I liked the idea of having the actual number from the source system as the JE
This works fine, as the JE's from the source system are in the 100000 range and the Journal Numbering in GP is already at 240000 so there is little chance of them stepping on each other year-over-year. There is also a unique ID coming from the source system that is alpha numeric that I place in the Reference field of the Journal Entry, but the actual way to tie back to the entry from the source system is with the imported JE number.
So, everything went fine for a year. The client stores images of backup for the JE's in Image Silo, and using an app provided by the Image Silo vendor, we update metadata on the image silo documents with data from GP.
Some of the metadata in ImageSilo from an older year got stomped on by data from the new year, because the incoming JE numbers for the current year are also in a previous year. This is ok in GP, of course, but my contact at the company did not like it and I could not convince him that if we added a Year key to the query that populated the Image Silo metadata, everything would be fine. I could not get him to understand that GP is built to allow the same JE number in a different year, because the year is part of the key, etc.
So I am testing the switch with SmartConnect to use the GP Rolling Column for JE numbers instead of the incoming JE number, and I don't like losing that key. I feel like that opens me up to more duplicates if there is a hiccup in the system for some reason it could end up importing GJ's over and over and just assign them new JE numbers. The design of the interface is good and this scenario is highly unlikely, but it does not sit well with me. I can check against the other value in the Reference field, but that is editable and if a user deletes or alters that value, the connection is lost.
The other proposed option is to stick a zero on the end of the incoming JE number, so that it will be way larger than the series in GP, but that also has its problems.
Has anyone ever had a General Journal import project and potentially have some advice?
Thanks
*This post is locked for comments