Jump to content

Geoffrey Gerhard

Members
  • Content count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Geoffrey Gerhard

  • Rank
    newbie

Profile Information

  • Gender
    Not Telling

FileMaker Experience

  • Skill Level
    Expert
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
    X-Platform
  • OS Version
    Recent
  1. Geoffrey Gerhard

    Push Bills

    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
  2. Geoffrey Gerhard

    Push Bills

    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
  3. Geoffrey Gerhard

    Error 3100

    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
  4. Geoffrey Gerhard

    Pulling Linked Txns

    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
  5. Geoffrey Gerhard

    Pulling Linked Txns

    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
  6. Geoffrey Gerhard

    Pulling Linked Txns

    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
  7. Geoffrey Gerhard

    Pulling Linked Txns

    Migrating data from one QB Company File to another is not trivial, with lots of potential traps for those new to QB. Potential pitfalls include: Account Balances, Inventory Counts/Values, Bank Balances, Receivables, Payables, Credit Memos, Bill Credits... The order in which you populate the new file is relevant, and especially so if there's Inventory Items on open Invoices or Bills. Vendors and Items need to exist before you can recreate the Open Bills, Bills need to be created to adjust the Inventory Counts/Values prior to Invoicing, as do Customers ( and Customer:Jobs, if relevant ), and Invoices need to exist before you can add ReceivePayments. And ReceivePayments that apply to multiple Invoices may need to be adjusted to reflect Invoices that were paid in full ( and therefore not on your list of Open Invoices. ) As I said, it's not trivial. If you need help, I've been doing this for years and would be happy to consult. I have experience and a tool for this, and for combining multiple QB Company Files into a single new Company File. Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852
  8. Geoffrey Gerhard

    Pulling Linked Txns

    I'm not entirely clear on what you're trying to accomplish, but my initial reading suggests that you'd use the ReceivePaymentAddRq using the new QB file's Invoice(s) TxnID within each AppliedToTxnAdd node. The ReceivePaymentQueryRs should contain all other values needed to complete each AppliedToTxnAdd node in the ReceivePaymentAddRq, as long as the ReceivePaymentQueryRs includes the IncludeLineItems element with a "true" value. HTH! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852
  9. Geoffrey Gerhard

    Pulling Linked Txns

    In case you revisit this issue, it's worth remembering that the LinkedTxn node is essentially a related record that may have multiple occurrences. You'd use PCQB_RsOpenFirstRelatedRecord ( "LinkedTxn" ) to get the values of TxnID, TxnType, etc. from the first repetition, and then PCQB_RsOpenNextRelatedRecord to get values for each subsequent rep. If a Customer makes multiple payments against the same Invoice, it would show multiple LinkedTxn nodes with a TxnType of "ReceivePayment". Each LinkedTxn node for ReceivePayment and CreditMemo contains what most identify as the most relevant details of that payment: Date, RefNumber, Amount. Note that you will need to go to the ReceivePayment source record if you need to differentiate between the components of the LinkedTxn node's Amount value, which is the sum of PaymentAmount and DiscountAmount. ( If you applied a CreditMemo in that same ReceivePayment, the CreditMemo will be in its own LinkedTxn node. ) Hope this helps! Geoffrey Gerhard Creative Solutions Incorporated 14000 Creekside Drive Matthews, NC 28105 704) 814-6852
  10. Geoffrey Gerhard

    Estimates/Quotes in FM Books Connector

    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
  11. Geoffrey Gerhard

    Subtotals on an Invoice

    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
  12. Geoffrey Gerhard

    Subtotals on an Invoice

    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
  13. Geoffrey Gerhard

    Pulling Received Payments from QuickBooks

    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
  14. Geoffrey Gerhard

    Modifying Transactions

    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
  15. Geoffrey Gerhard

    Handling Receive Payment Transactions

    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
×

Important Information

By using this site, you agree to our Terms of Use.