Calling on FMBooksConnector Users

[boilnh2o]

I'm starting to dive into integration and have been looking for a users forum. So maybe this can start one....?

Here's my puzzle: Insert invoicing and estimates that are associated with a job. I'm set with inserting one associated with a customer, but the way QB handles jobs (I believe its a self relation with their customers table)doesn't seem to make it possible using the plugin.... or is it? Maybe there's a trick?

Anyone out there?

Thanks

[Colin Keefe]

If I understand your question correctly, it might help to know that all list items in the Customer:Job list are unique and can be referenced by ListID or FullName when pushing message Requests and parsing Responses.

e.g.

ABCMoving

*Transport

*Packing

as they appear in the Customer:Job list, are separate, and can be referenced by FullName as:

ABCMoving

ABCMoving:Transport

ABCMoving:Packing

This is the syntax of the FullName field wherever you see it in any kind of list - the item, prefixed with its ancestors.

If you're asking how to roll these up into a single customer on the FileMaker side, I'd suggest building a relationship structure of your own, with related jobs, and pushing invoices from your Job table. Push a concatenated FullName, then grab the ListID in the Response, so you can make mods to the invoice reliably later.

I say this because to my knowledge there's no foreign key in the Customer:Job pointing to its parent Customer that you can access. It may be there behind the scenes, but all we have exposure to via the QB SDK is ListID and FullName.

[boilnh2o]

Yeah I figured the FullName:JobName thing and tried to recreate that and use it to insert an invoice but QB doesn't like the in the full name field and errors out.

I found a work around by grabbing the listIDs of the customers/jobs and then appending the ListID for the Job and using it to insert an invoice and it goes into the right place. I can add an invoice to a Job and in QB it shows up in both the job and the Customers aggregate. It means that my users are going to have to pay attention and make sure the right job ListID is associated with the data in FM first. But it works and beats hand entering data in QB.

Mark

[Colin Keefe]

That's actually the better way to do it anyway! ListID is guaranteed to be unique.