Geoffrey Gerhard

It's pretty simple to push an Estimate from FMP into QB, although there's usually not much benefit to doing so. Any reporting on Estimates can often be done in FMP, and Estimates in QB are non-posting transactions that have no impact on the balance sheet or income statement. I'm unsure if there's any way to "convert" the Estimate into a SalesOrder via the API, and a glance at the OSR ( Onscreen Reference ) does not show any way to create such a link. That said, it's certainly possible to send the same ( or adjusted if the Customer accepts only part of the Estimate/Quote ) transaction from FMP to QB as a SalesOrder record that doesn't point back at the Estimate. Like an Estimate, a SalesOrder is non-posting. This means that the only reason to pass a SalesOrder from FMP to QB is if the Invoicing is only done within the QB UI. If you are doing the Invoicing in FMP, I'd recommend pushing only Invoices to QB and skipping the process of pushing Estimates and SalesOrders unless there's an accounting/business rule ( or reporting requirement ) that cannot be met from the context of the FMP file. HTH! Geoffrey Gerhard Creative Solution sIncorporated 14000 Creekside Drive Matthews, NC 28105 704) 184-6852

I hope you'll let us know what you find--I'm really curious to see what's needed ( and/or must be omitted ) to make it work. I couldn't find any direct reference to what's needed, but my reading of page 388 of the 2013 QBSDK_ProGuide is what led me to think it may be nothing more than an ItemRef for the ItemSubTotal. Are you attempting this using the Desktop version of QB? If so, the documentation is here... https://developer-static.intuit.com/qbSDK-current/Common/newOSR/index.html ...but it doesn't appear to say anything useful for your particular use case. Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

I've never passed an ItemSubTotal in an InvoiceLineAdd node, so I'm not sure what--if any--detail ( other than the ItemRef ) is necessary . Does your InvoiceAddRq creation process sort the FMP InvoiceLineItems by their type ( parts, material, labor ) and then insert an InvoiceLineAdd for the appropriate ItemSubTotal after it processes the last InvoiceLineItem of each relevant type? If an InvoiceAdd that followed the model in your email included eight InvoiceLineAdd nodes in the model's sequence, I think it will work. Is QB returning an error? If so, what does it say? Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

Hey, Christi. It seems likely that there's a typo in your variable name or the variable is null because of an empty field or calc that produces no result. An empty node is acceptable to both the plug-in and the QB API, and if that's the only filter, would create a QueryResponse of all records. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852 Hey, Chris. I'm curious about the format of your function calls. The first line in FMP 16 32-bit looks like this... PCQB_RqNew( "ReceivePaymentQuery" ) ...without any Select or Results:$result parameters. Geoff

Modification will drop all Lines that are not identified by their TxnLineID value. If your ModRq contains only Lines where the TxnLineID values are -1, all the original lines are dropped and the Modified Txn will have only the new Lines. In my experience, it's easier to omit any reference to the original Txn's Lines TxnLineID values and simply pass all the Lines you want to appear on the Modified Txn with a TxnLineID value of -1. That means you don't need to explicitly store the TxnLineID values from AddRs/ModRs if you have no other reasons for doing so. I usually discourage Modifying a transaction in favor of Voiding the original and creating a new Transaction. The Void is really easy to code, and you'd use the AddRq process you've already created to push the corrected Txn. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

Nice write up. A couple quick edits: this... ...should say "18-3" or "the response from the Query shown in Listing 18-2" And in case anyone copy/pastes 18-2 or 18-4, there's a typo in the line... PCQB_RqAddRealtedRecord( “SetCredit” ) ...where "Realted" should read "Related" like this... PCQB_RqAddRelatedRecord( “SetCredit” ) HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

ItemSalesTaxRef is the right attribute to identify either the ItemSalesTax or the ItemSalesTaxGroup you want to apply to all taxable LineItems on the Invoice. The documentation says that you cannot use a SalesTaxGroup as the ItemRef of a LineItem, although I'm not sure if that's still accurate. Perhaps sharing the code you're using would clarify where you're going wrong.... Hope this helps! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852

Just stumbled on this thread and a related post on github.com/filemakerstandards. Having "rolled my own" years ago, it was interesting to discover that most practitioners end up in (more or less) the same place. I'm curious on one point: are there any "truly safe" delimiters? Corn Walker mentioned Char ( 2 ) and Char ( 3 ) at the POE NY as likely candidates (apparently they're teletype characters), and I've been using them ever since. Never seen them in the wild, and substitute them for null in all value parameters. Curious if anyone thinks these (or anything else) cross the threshold from "obscure" to "bulletproof." Is there a case where their deletion could be relevant to the utility of a field's value?