Add support to account id, payment type etc.

[sunilpawar]

Additional changes:

• Avoid syncing negative total amounts. (QB does not accept itself)
• Avoid syncing line items if qty = 0
• Pass payment method.
• Pass DepositToAccountRef
• Pass trxn_id or check_number as PaymentRefNum

[sunilpawar]

@agileware-justin , @agileware-fj

Can you please take a look?

[agileware-justin]

@sunilpawar we have had a look, thanks.

[agileware-fj]

Please respond to these questions @sunilpawar

[agileware-fj]

I think buildOptions is deprecated, this could be an API call?

[sunilpawar]

is this ok

$paymentInstrument = CRM_Core_OptionGroup::values('payment_instrument', FALSE, FALSE, FALSE, NULL, 'name');

[agileware-fj]

@sunilpawar I'd prefer for this section to convert the code that gets the API payments use use APIv4, and include payment_instrument_id:name in the selected fields. The changes to the loop are minimal.
Are you happy to try adding that in?

[agileware-fj]

My understanding is that on the Quickbooks side, each product or service should have an Income account set, and we should defer where the payments go to this.

Is there a particular reason for having a setting for one particular income account that overrides this behaviour? It doesn't sound like the correct approach

[sunilpawar]

You are correct, each product or service have an Income account set.

When i look at the record in QB, we are setting Account it Deposit To Account.

Also setting DepositToAccountRef is optional on setting page.

---

This is what I got when I did ChatGPT:

There is a key difference between Income Account and DepositToAccountRef in QuickBooks.

When you create a Product or Service, you must assign it an Income Account. This account is used to:

• Categorize the revenue generated when the item is sold.
• Reflect the sale on your Profit and Loss statement.
• Typically points to accounts like: Sales, Consulting Income, Product Revenue, etc.
  Example:
  If you sell a product called "T-Shirt", and its Income Account is set to "Sales of Product Income", then when you create an invoice or sales receipt, the revenue is recorded under that income account.

DepositToAccountRef is used during a payment, such as when recording a SalesReceipt or ReceivePayment in QuickBooks API. It determines where the actual cash goes.

• Usually points to: Undeposited Funds, Checking Account, Bank Account, etc.
• It's a balance sheet account (like assets), not income.

Example:
When you get paid, the money might be deposited to Undeposited Funds or directly to Bank - Checking.

Ensure every line item in your SalesReceipt or Invoice references a valid ItemRef (product/service) that has an Income Account set.

Also, set DepositToAccountRef properly to indicate where the cash is going.

[sunilpawar]

Also, the label needs to be changed to avoid confusion.

[agileware-fj]

OK I see where I missed a distinction there.
I'm still not particularly sold on the idea of using a blanket account reference for all payments, though.

One other thing that occurs to me is that the Payment entity also defines a "to_financial_account_id" parameter, which can be set to any "Asset" financial account on a per payment processor basis to track funds going into different accounts, with a fallback default.

So far we've been ignoring this account since it's rarely attached to financial types; IMO we could use the acctg code field from these as the "DepositToAccountRef" when pushing invoices. What do you think?

[agileware-justin]

Please respond to these questions @sunilpawar

[sunilpawar]

@agileware-justin , I've responded—please review my reply.

[sunilpawar]

@agileware-justin

Can we separate the issue and the DepositToAccountRef feature? I'll submit a new PR — one for the bug fix, and another for the feature, which we can discuss separately later.

only pending thing in the issue : payment instrument id using api4 support.