Alex,
These are all very good questions, and it is very hard information to find in a good concise format. Just in case it helps you I'd like to offer my best understanding of the synching.
1. ALL fields in QB whether default or QB Custom fields are synch'd with Method. Method essentially creates an identical copy of the QB data structure in the cloud and then keeps it synchronized. This is actually pretty amazing and in some ways this is a backup of the data.
For every data table in QB, Method maintains a copy of that data table on the Method server and keeps that table synchronized with the QB table. QB will allow you to create up to 15 custom fields in QB. These custom fields actually already exist in the QB data table and therefore are also in the Method data table. If you use these "special" custom fields in your Method Screens, you can also use these fields and their data in QB. (The support for custom fields in QB was rapidly evolving a few years ago so I might be out of date, but Method has always fully supported and 100% replicated any custom field functionality possible in QB.)
So you really have 3 options when using data fields in your custom Method screen development.
1. You can use an existing QB field. These may already be in QB screens or Method screens, or there are some fields existing that are just not used yet.
2. You can create a custom field in QB, and then use that field also in Method. A good idea if you want to add it to the QB screen or keep a local copy of the data in your QB file.
3. You can add a custom field in Method and add it to the existing QB data table in Method. This will not synch down to QB.
Or, 4. You can create an entirely new data table in Method with new fields, which will not synch to QB.
You can operate on almost any QB field or Method field in your customization and Method really does a great job of making sure you can't really make a big mistake, but there are a few things to be aware of.
1. Like any database, there are key fields in the data tables that are very important for data table indexing and relational database functionality. For this reason it is a very good idea to try to be aware of parent child relationships and work from some Method parent screens. Method will prevent you from breaking things, but it's good to know.
2. There are a few fields that QB calculates and you cannot change them. For example the Amount field of an invoice item is always calculated by QTY x Price. You must let QB calculate that.
3. There are a few fields that can be auto indexed by both Method and QB, like Invoice number. You should let QB or Method do this. In general any data field that starts with "ref" should be avoided and let QB or Method deal with it. You can of course change these fields from screens, but don't try to provide logic for these fields.
A really good way to get started in understanding your data is to Export any List from QB to an IIF file. For example the Items table in QB can be exported as a List. If you have data in QB, you can open up the data in Excel and see where certain pieces of information are stored. Then when you look at the table in Method or go to build a screen you will know where important information is stored. You could of course let Method synch to QB then open up a table in Method and do the same thing.
Good Luck! Method's implementation of QB database synching is really awesome. The documentation is not really very well done and I do not believe there is any good document that really describes the data architecture very well, but someone will always help you and everything is done in a very logical way, so you can trust the Method functionality. If you start with the basic Method screens and work from there you can do almost anything you'd want.
Cheers,
James