Then why are you still advertising it as a feature of version 3.0 on your homepage? See https://synergration.com/software/opensync/
This is false advertising!
This really is unacceptable. I was told in November of 2017 that this functionality was supposed to be working (See https://synergration.com/forums/topic/identifying-new-id-after-syncing/). We’ve been waiting for over a year and a half to get this feature and you continue to advertise it as a feature of your newest version. This is not only extremely disappointing but also false advertising and terrible customer service.
Have you found a solution to this, as I’ve run into this issue as well. Thanks!
I’ve run into this issue as well, and would love to see a solution if you’ve found one?
Support — PLEASE provide some support on how we can match these more accurately. There must be a simple way to do this.
Synergaration Support — do you have any additional details about how/if/when the TxnID or ListID numbers numbers could be change?
That might work for Vendor, but it wouldn’t work well for a bill or a check. For example, I ran into a problem last night where after my web app inserts a bill record, it then tries to match the bill based on vendor and amount, but there were two bills with the same vendoer and amount, so later, when it tried to push in the billpaymentcheck, it failed because it was trying to apply it to the wrong bill, which had already been paid.
I have been linking things together using the TxnID or the ListID, but if those could potentially change at some point in the future, this is going to cause cascading errors of this sort in the future.
Is this true for only Invoices or for any item? This seems like a huge issue to me. I’m developing a web app, and I need to sync Vendors between the web app and Quickbooks, if Quickbooks could just randomly change the ListID for the vendor, how can I reliably link the Vendor in our web app to the Vendor in Quickbooks so that when we push in new bills or checks, it is going to the correct Vendor? Another huge area of concern would be the Chart of Accounts, how can we ensure we have the accounts linked consistently if it could potentially change?
In another post it was suggested to use “UserData”, however, that doesn’t seem to be implemented consistently yet?
Has there been any update on the best practice for this? I’m running into problems where vendors will have multiple invoices for the same amount, and I can not find a reliable way of relating items in my database to what is in OpenSync once the temporary ID gets changed to the QB Assigned TxnID. I’ve tried using the Memo field as one user suggeted, bt our accounting staff is very particular about the use of the memo field and does not like this option. This seems like a really simple problem and I would imagine someone has a fix.
After I “ADD” a record, how does my application know what the new ID is after the sync?
I’ve started testing and trying to get this to work, however, I’m finding it is not. I set the UserData equal to the random id that I also put into the TxnID. After I sync, the UserData field comes back as NULL (As do the CustomFields, which I had set data to). Is there something special I need to do force Open Sync to leave the UserData in place?
Any other options I can try?
Fantastic, thank you!
Yes, I understand that. So when I “ADD” the item to the database to sync with Quickbooks, I assign a random ID number and put it in the TxnID field for the bills table, and in the IDKEY field on the expense table. After Open Sync syncs with Quickbooks that random number is replaced by an ID number generated by Quickbooks.
I want to know if there is a way I can search, after the sync, for the old random id number I generated to find out what the exact new TxnID is, so I can replace the link in my webapp’s database to make sure that the bill and the transaction in my web app are still linked together.
This did not work either. Here is a list of what I tried after I received your post:
– Installed the latest version of Microsoft XML Core Services 4.0 (which was SP3).
– Didn’t work.
– Installed the Microsoft XML Core Service SP 2
– Didn’t work.
– Uninstalled both Microsoft XML Core Services SP2 and SP3
– Uninstalled all Microsoft SQL and mySQL ODBC drivers
– Uninstalled Open Sync
– Reinstalled only the 32-bit version of mySQL ODBC Driver
– Reinstalled only the SP 2 of the XML Core Services
– Reinstalled Open Sync
– Removed the mySQL database it was syncing to previously.
– Deleted the data that was there from the previous install
– Resetup the database link, the Company File, and the Task
– Tried running the task
– Didn’t work. Same ActiveX component can’t create object:429 error.
– I tried to create a new task that only populated from Quickbooks to mySQL, and that does work.
– I then tried to create a new task to populate from mySQL to Quickbooks, and this also worked. (Didn’t do anything though since I hadn’t changed any data).
– I then ran the FullSync, and it worked fine.
– Then I reset the server, and tried to run Open Sync again, and it worked fine doing the full sync now.
– HOWEVER — I then setup the second mySQL database, and then attached the second Company Files and setup another Task this time to do the bi-direction update and refresh again, but it again got stuck with the ActiveX component error (same 429 error code again).
– Once again, if I went in and manually did first the Populate alone and then the refresh alone, it worked, and then after that the sync worked on both first and second tasks that was full (both populate and refresh)
Consequently, I did go in and remove the one-way-only tasks, and then also went back and ran the initial task and both bi-directional syncs did continue to work.
So there seems to be some issue with the initial sync somehow.
Good Morning –
I dropped the database schema from mySQL, removed the task, company file and database from Open Sync. Set up a new database in OpenSync, reattached the Company file, and created a new “Refresh and Update” task and tried to run it and came up with the same problem.
The ‘account’ table does update, not sure if it completed or not, but none of the others did.