Method Community

1.  I created 5 new custom fields with data in QB and it synced to Method fine. 
2.  Next I changed all 5 data in Methods, and only 1 of the 5 changes synced to QB.  Other 4 ended up in Conflict.
     The Conflict message appears to say the Custom Field is not found, but its there. See url link.
3   Also when I repeated steps 1 and 2 to populate the same 5 custom fields for a different QB ITEM, the same results of 1 out of
     5 data synced to QB, and the other 4 ended up in Conflict.  But the earlier 4 conflicts disappeared.

Questions:
1.  Why did only 1 of the 5 custom field data changes made in Method sync to QB?  Why did the other 4 not sync but end up in Conflict?

2.  Why did those 4 Conflict items disappear when I tested the same custom field changes for another QB Item?

3.  Why did 3 of the 5 custom field names get "CustomField" added at the end of the fieldnames when they synced and appeared in Method?  Example:  "Custom Field1" turned into "Custom Field1CustomField" on Method in the ItemInventoryAssembly table.

See url for screen shots -
http://www.infoontheweb.net/methodintegration/attachment-06082010.doc 

Thank you.

 Hi Dave,

I'm looking into this and will update you as soon as I have some info.

Dave,

Any news on this?  This would appear to be a critical bug.

Custom Fields have been a key issue for me in deciding whether I can run my business on QB and/or Method instead of writing custom code.  The support for Custom Fields has always been poor in QB.  For example the original 5 custom fields were not fully supported in QB's reports even though they could be used on Invoices etc.  Without report support, they were useless to me.

In QB Enterprise 10, more custom fields were added but these fields are not fully supported in QB's SDK or ODBC links.

So, I am suspicious of successful synching of QB's custom fields with Method's custom fields due to poor support from QB in their SDK which Method relies on for synching.

But, I think Method offers a good solution to this problem since it is possible and potentially preferrable to keep ALL custom data in Method and only synch the data that is absolutely necessary to maintain the financial register and postable data in QB.

I am very curious to know what others are doing in this regard.  Although technically it appears feasible to synch QB and Method accross most of the data and it would be possible to enter Sales Orders in BOTH systems, I think it might be good practice to try to drive UI customization to only one system or the other, presumable Method.

Please share your experiences.

Cheers,

James

 Hi Amanda,
How are you coming on identifying and fixing this problem?  Others interested in the custom fields capability of Methods is interested to know as well.  

I'm available to chat with you via GoToMeeting and work with Method to solve this problem.    Once we can get this problem fixed, it will take Method to the next level in using the power of custom fields.

Thank you
     Dave

 Hello Dave,

I'm still looking into this, when I tried adding a few custom fields it didn't work properly. Data was syncing for some custom fields and not for others. I need to look into this some more and will update you as soon as I get more information.

 Hi Dave,

We've looked into this and we made some changes to make custom fields more useable. Just to give you a technical bit of insight from the back end side of things:

1. QB does not provide us with a unique identifier for custom fields.  It just gives us a name and a value.  So it is very hard to maintain values in Method if they rename or add custom fields, so there is no static primary field to match up against.
2. QB gives us the custom fields in alphabetical order, so if a custom field was named “ZZZZZ” it would be the last custom field in Method.  But if they rename it to “AAAA” it would be the first custom field and it would adopt all the existing custom field values from the previous first custom field.

We've added some new logic to try and smartly guess which custom field has been changed, to avoid #2 above (most of the time).  It can still be broken if you change more than one custom field at the same time and the changes affect the alphabetical order.  But in normal use, custom fields are now much more reliable.

Thanks for pointing this out. Let me know if it is better now.

Thanks for the update Amanda.  We will test it out this week and will let you know how activities to the 5 custom fields' and sync comes out.