Geoffrey Gerhard

Make sure any FMP scripts that interact with QB do so only for the user/credential on that one computer. Will the user on that computer be working within the QB UI? If so that user should log into QB using a credential with sufficient privileges to perform all of the automated tasks. QB, just like FMP, is a database and will lock a record when a user begins editing. That can lead to an error if one of your scripts attempts to edit a "locked" QB record, so make sure you're sharing error messages with your user. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852

You identified the right fields: Either a ListID or FullName value identifies the Customer/CustomerJob. (You only need one, has you send both QB uses ListID and ignores the FullName value.) When you identify the Customer/Job and identify BillableStatus as True, QuickBooks will ask, when adding an Invoice via the UI, whether to display the list of BillItems not yet Invoiced to the Customer/Job for inclusion on the new Invoice. You can also use it for generating reports in QB. In FMP/QB integrations, there may not be much value to in identifying the Customer/CustomerJob if most of the reporting is done from FMP. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852

Is this really required, PCIPal? The OSR identifies the GUID element as optional in a ItemNonInventoryAddRequest.

What error message is produced? Your screenshot leaves out a lot of detail, not least of which is the line that calls the PCQB_RqNew( "ItemNonInventoryAdd" ; ... ) function. It also shows no reference to either the SalesOrPurchase or the SalesAndPurchase aggregate. If I recall correctly, you must add the elements for one of those aggregates. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852

I do relatively little work in QBO, so grain of salt... The message makes it appear that the math is wrong. Is it? ( I'd look closely at whether there are rounding issues, as sometimes FMP produces a different value than FMP when doing math and rounding decimal places. ) If not: Can you exclude either Amount or UnitPrice? QB desktop allows this, and does the Algebra necessary to solve for x. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852

That's a lot of new pieces at once. Here are a couple things to consider in this situation: Is the problem isolated to a single Invoice among several sent from the same computer in the same FileMaker session? Have you tried voiding a "problem Invoice" in QB and sending it again from FMP? If so, is the subsequent attempt successful? The InvoiceAddRs contains the details of every LineItem on the Invoice. You can parse the Response to determine whether or not they contain the expected detail, and take appropriate action if they do not. For troubleshooting purposes, you could add a step that captures the result of PCQB_SGetXML( "Request" ; "" ) above the step that calls the PCQB_RqExecute for the InvoiceAddRq. This will confirm that FileMaker and the Plug-in have assembled the Invoice details correctly. It's unlikely that the API is handing back a Response that doesn't match the Invoices it created, but you could confirm what the API returned by adding a step that captures the result of PCQB_SGetXML( "Response" ; "" ) below the step that calls the PCQB_RqExecute for the InvoiceAddRq. If I were working on this, I'd set a $variable for each of the SGetXML calls, use xpath filtering to produce a stack of the relevant LineItem Node values, and compare them. If they don't match, I'd send myself an email with the xml Request and Response data. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852

I wondered about the lack of ItemRef, but presumed it was truly optional given Kyle's initial post that said it worked with a single PO LineItem. I also presumed--despite never encountering one in 15+ years of FMP/QB integration projects--that his client has a valid reason for pushing PO records from FMP to QB. I've found that adding Sales and Purchase Orders to QB don't add much (if any) value for the client, and advocate pushing only the Invoices Vendor Bills to QB. Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852

I haven't used the plug-in functions as script steps, but the basic structure appears correct: AddRelatedRecord at the start and CloseRelatedRecord at the end of each iteration. Someone at PCI will have to weigh in on whether the script step parameters look right. Is there an Error number/description returned when there's more than one Purchase Line Item, or do you mean it doesn't work correctly but no indication of why from the plug-in? Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852

Have you confirmed that this now works? It's been awhile and I may have tried this only in the previous version of the API, but IIRC a CustomerAddRq with more than two Contact nodes--and assuming no AdditionalContactRef nodes--would create the Customer record and add the first two Contact iterations only while ignoring additional repetitions.

I believe the API does not allow you to Add/Mod Contacts beyond the primary Contact and AltContact records. In addition, I think a CustomerQuery will only return the first two Contacts, and characterizer them as Contact and AltContact, regardless of how they were entered in the UI. The OSR displays different values on the Request Tab than the XMLOps tab for Contacts: Request shows a "ContactsList" node, while XMLOps shows a "Contacts" node. This inconsistency appears to support my recollection that Intuit never fully implemented the functionality. Please post again if you find anything that contradicts either assertion--would love to implement this so it works as expected in my FMP/QB integration template. Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852

It's strangely coincidental that the value of Quantity is 0.6. Have you checked the Form Editor in QB to be sure that the "% XXX" columns are really custom fields and not just labels? I've never encountered a situation where Custom Fields defined within the QB UI ( or via the plug-in ) have failed to return the DataExt node(s) when OwnerID = 0 and the DataExtValue is not empty. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852

Is it possible that the Custom Fields were defined with a different OwnerID value, perhaps by another integrated application? You're looking at the raw xml using the PCQB_SGetXML( "Response" ; "" ) function, right? Worth noting: they normally appear in the xml response only when they have a value. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852 P.S. I asked about the raw xml because I'm wondering if the "%" symbol is coming back encoded, and therefore isn't matching your PatternCount test.

Not via BillPaymentCheckAdd, as it's only for paying existing QB Bills. Look at CheckAdd as a possible alternative. It has a "ApplyCheckToTxnAdd" node that allows you to specify the Bill TxnID when you have one. Don't recall if you must enter ExpenseLine(s) or ItemLines when there's no ApplyCheckToTxnAdd specified, but I think not. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852

Line 25 should identify the TxnID of the Bill that's being paid by this check. Side note: AppliedToTxnAdd may repeat. Using "AppliedToTxnAdd::xxx" works for 1-1 Check-Bill payments, but won't if you need to pay multiple Bills from a single Vendor on a single Check. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704.814.6852

It isn't an issue for the plug-in to talk to whatever QB Company file has already been opened by a user. If you're looking at a "headless" connection, where the QB Company file is running without an accessible UI and get's opened by FMP, you'll need some way of identifying each branch's path to that branch's QB Company file. Is there any overlap between Customers, Vendors, and/or Items between the two branches? If so, successfully integrating the common elements with separate QB Company files hinges on a number of variables and quickly grows in complexity as it moves from a "kinda fragile" to a "pretty robust" integration. Simple and fragile would have FMP identifying all List records ( Customers, Vendors, Items, Terms, etc. ) using FullName. The problem here is that someone at BranchA changing the FMP Customer Name value will break the ability of BranchB to identify that record in their QB Company file. Complex and robust would have you tracking the ListID values for each branch's copy of QB. The problem here is that you'll have to create separate scripts for each branch's integration with QB, or create some kind of "abstraction" to determine which Branch's QB ListID value to use when assembling a QB Request. A third option would be identifying transaction data separately in QB using an otherwise unused ( or Custom ) QB field. Your QB Transaction Requests ( Invoice, Payment, Bill, ReceivePayment ) could pass a value to the specified field, and that field could be used as a Filter criteria for any Reporting in QB. A fourth option would be to split the FMP files into separate versions for each branch, and use FMP 17's ability to quickly update/deploy the database schema/structure changes. That would mean you have extra work when you do development work. None of these options are "pain free" in the sense that there's extra work involved for someone to make things go smoothly. If it were me, I'd probably lean toward the fourth option. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852