Geoffrey Gerhard

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

The process can appear "frozen" when the TxnID is empty and the QB Company file has a lot of Invoices. No clue why it would freeze and crash if the elements and their values are valid ( and not empty. ) Something like this... Set Variable [ $$Result; Value:PCQB_RqNew( "InvoiceQuery" ) ] Set Variable [ $$Result; Value:PCQB_RqAddFieldWithValue( "TxnID"; INVOICES::_ID_QBTxnID)] Set Variable [ $$Result; Value:PCQB_RqAddFieldWithValue( "IncludeLinkedTxns" ; "true" )] Set Variable [ $$Result; Value: PCQB_RqExecute ] ...should produce an almost instantaneous result. BTW: In the early phases of writing and testing any QueryRq, you can save yourself a lot of wait time from a badly formed Request by applying one or more IncludeRetElement filters. They dramatically reduce the amount of data returned, and in the event that your Request is returning every record ( as happens when you're querying a transaction table and TxnID is empty/unspecified ) the difference in speed can be staggering. For your purposes, I recommend this... Set Variable [ $$Result; Value:PCQB_RqNew( "InvoiceQuery" ) ] Set Variable [ $$Result; Value:PCQB_RqAddFieldWithValue( "TxnID"; INVOICES::_ID_QBTxnID)] Set Variable [ $$Result; Value:PCQB_RqAddFieldWithValue( "IncludeLinkedTxns" ; "true" )] Set Variable [ $$Result; Value:PCQB_RqAddFieldWithValue( "IncludeRetElement" ; "LinkedTxn" )] Set Variable [ $$Result; Value: PCQB_RqExecute ] ...to winnow the data QB gathers and returns to just the LinkedTxn data for the target Invoice. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

In your scenario, is the manually entered QB payment applied to the Invoice? If so, you can do an InvoiceQueryRq for the TxnID and IncludeLinkedTxns = true. The Response will include all ReceivePayment records applied to the Invoice. The LinkedTxn node includes the Type, Date, RefNumber, and Amount values, which may be sufficient to identify the manually entered ReceivePayment. You could also parse out any/all TxnID values for linked ReceivePayment records, and--assuming you're storing the ReceivePayment TxnID in FMP, perform a find for each. NOTE: I don't recall offhand if the LInkedTxn node's Amount value is for the ReceivePayment TotalAmount, or the Amount Applied to the Invoice, but I think it's the latter. If the ReceivePayment is not applied when recorded manually in QB, a combination of ( ModifiedDateRangeFilter or TxnDateRangeFilter ) and EntityFilter::ListID might help if you're looking for a ReceivePayment for a particular Customer. And if you're just looking to find any manually entered ReceivePayment records within a date range, use the ModifiedDateRangeFilter. While it may include some older ReceivePayment records, it will definitely include all those added within the specified range. As suggested above, as long as you're storing the TxnID in your FMP Payments table you can run FMP finds to identify any TxnID that is not a Payment::TxnID field value, and query for/use the ReceivePayment TotalAmount value to find the match among FMP with an empty Payment::TxnID field. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

I can't find a current reference to support my recollection that "Code: -1000" is a generic error that covers a wide spectrum of possible errors. I also can't recall seeing "Message: No Response Saved" regardless of the Code value. I notice that "VendorRef::ListID" is now "VendorRef::FullName" that gets its value from a field named "xx::List_ID" and wonder whether that's the mismatch it seems to be? I also wonder whether the script is running from the correct context, given that it appears to be referencing Invoice fields as values in a Vendor Bill. Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

The screenshot shows steps that reference FMP Invoices and--seemingly--a ListIDCustomer value. A QB Bill expects a ListID for a Vendor. If you have one FMP record for a company that's both a Customer AND a Vendor, they are separate entities in QB and require a distinct ListID value for each role. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

It's likely that the Customer record exists in QB, but is Inactive. The default view of the Customer List in QB is Active Only, as is the CustomerQueryRq. Update your CustomerQuery script to include "ActiveStatus" with a value of "All" to be certain that the proposed CustomerName is unique. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

Not quite clear on what you're looking for. You could do a CreditMemoQueryRq that limits the Response to TxnID nodes using the IncludeRetElement, and then apply the FMP PatternCount function to the result. The pattern count of "<TxnID" occurrences will tell you how many total CreditMemos are in QB. Is your goal to pull all CreditMemos, to pull all CreditMemos applied to one or more Invoices, or something else? Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

The error likely speaks for itself. Consider these steps to track down the problem: 1) Confirm that the related Invoices::TXNID_New_File record has a value is in the field. 2) Make sure there's only one value, and that it's an Invoice TxnID. 3) Confirm there's a corresponding Invoice in QB. 4) Try doing an InvoiceQueryRq using the RefNumber displayed in QB, and see whether the TxnID in the Response matches the stored value in the FMP record. You also mentioned Credit Memos. In my experience, they're usually applied within the framework of a ReceivePayment. Your script does not show any steps that apply a Credit Memo's values to an Invoice. As noted in an earlier reply, moving data from one file to another can be pretty complicated. Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

The AppliedToTxnAdd steps cited above look right, as long as there's no CreditMemo AppliedAmount or DiscountAmount applied to the targeted Invoice. And any ReceivePayment record that applies to more than one Invoice will need to Loop through those steps.... Good luck! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852