Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2023-11-23T07:17:29Zhttps://lab.civicrm.org/dev/financial/-/issues/182Possible regression - civicrm_line_item.line_total is incorrectly tax inclusi...2023-11-23T07:17:29ZeileenPossible regression - civicrm_line_item.line_total is incorrectly tax inclusive - potentially 5.39+In 5.39 there was a fix to stop the situation where the contribution.total_amount was recalculated on edit when tax was involved. However this fix had a bug and civicrm_line_item.line_total [stored the tax INCLUSIVE amount](see https://...In 5.39 there was a fix to stop the situation where the contribution.total_amount was recalculated on edit when tax was involved. However this fix had a bug and civicrm_line_item.line_total [stored the tax INCLUSIVE amount](see https://github.com/civicrm/civicrm-core/commit/e967ce8fe2b58b94e2163dde395542e55599da13#diff-4c9d0b1abe07057a4eea2b47bc627eecb95face8ed8d86c1c005312a52cca811L4026-L4035) We [have merged a fix to the rc](https://github.com/civicrm/civicrm-core/pull/21212) but I opened this to try to determine if any released versions are affected. This rose to a bigger issue in the rc because of changes on top of it - which assumed it was right.
The reason this went awol is largely because we had too behaviours - if the contribution bao didn't receive tax_amount it treated total_amount as exclusive and if it did it treated it as inclusive. The former was locked in by tests & not the latter leading to confusion (I'm still confused)
At this stage I'm unsure about real-world issues with this as
1) it didn't affect any core forms that I'm aware of as they pass in 'line_item' or 'skipLineItem'
2) this was the 'correct' behaviour historically for Contribution.create api calls that should have tax_amount passed in, but didn't
3) we have a [deprecation notice](https://github.com/civicrm/civicrm-core/commit/e967ce8fe2b58b94e2163dde395542e55599da13#diff-4c9d0b1abe07057a4eea2b47bc627eecb95face8ed8d86c1c005312a52cca811R193) in the code that would likely have been triggered if line item tax totals did not add up to contribution totals & it's unlikely people would miss wrong contribution totals.
However, my head breaks a bit when I try to think through this
I *think* this would pick up any wrong rows
```
SELECT
SUM(li.line_total + li.tax_amount) as lines_total,
count(li.id) as c,
SUM(c.total_amount) as total_amount
FROM civicrm_contribution c LEFT JOIN civicrm_line_item li ON li.contribution_id = c.id
GROUP BY c.id
HAVING c > 1
AND lines_total <> total_amount
```https://lab.civicrm.org/dev/financial/-/issues/181Update billing details fails when no State/Province entered2022-09-16T21:08:32ZlarsssandergreenUpdate billing details fails when no State/Province enteredUpdate billing details gives "Page could not be loaded" on submit if the user has not entered a State/Province. In some cases, it is valid for a user to not enter a State/Province if they live in a country that does not have states. This...Update billing details gives "Page could not be loaded" on submit if the user has not entered a State/Province. In some cases, it is valid for a user to not enter a State/Province if they live in a country that does not have states. This works as expected on contribution pages, etc, but not on the update billing details page. Tested on 5.35.2.
I will have a look at how this is handled for contribution pages and port the solution to update billing details, at some point.https://lab.civicrm.org/dev/financial/-/issues/179Search kit bugs2021-08-04T22:27:21ZeileenSearch kit bugs@colemanw I hit a couple of things writing up about [how to do a payments search](https://docs.google.com/document/d/1OM8T-HsqFQDVGMB83iXx6CkC4mtRh4dA0hNK0MIX4hc/edit#)
I figured I'd just stick them in one ticket for now
1) The amount...@colemanw I hit a couple of things writing up about [how to do a payments search](https://docs.google.com/document/d/1OM8T-HsqFQDVGMB83iXx6CkC4mtRh4dA0hNK0MIX4hc/edit#)
I figured I'd just stick them in one ticket for now
1) The amount column from the financial_trxn table was not available to add as an afform filter
![image](/uploads/3608db6fc7f5c8289b4f276d40396927/image.png)
2) It 'looked' like I could make check_number 'edit-in-placeable' on the financial_trxn table - but it didn't work - note that check_number IS a field that should be editable as a data entry issue with no financial transaction implications (if we were editing payment method I think we would to be sure that the edit-in-place is calling v3 Payment.create not v4 FinancialTrxn.create - the former is a wrapper for the latter with more logic)
![image](/uploads/67ed36272f37bbc2fe9bdeacbe199c5d/image.png)
![image](/uploads/58fab89fd8ca820dfb2f17a0a4ffa726/image.png)https://lab.civicrm.org/dev/financial/-/issues/177Batch Transactions: Search cannot filter by Soft-Credit2023-07-21T17:13:51ZmhowisonBatch Transactions: Search cannot filter by Soft-CreditI'm trying to create a batch of existing contacts who have all made a contribution via Donor-Advised Fund (DAF).
When I use the Find Contributions search feature, I'm able to produce a list of contacts who gave through Donor-Advised Fun...I'm trying to create a batch of existing contacts who have all made a contribution via Donor-Advised Fund (DAF).
When I use the Find Contributions search feature, I'm able to produce a list of contacts who gave through Donor-Advised Funds in FY21 (Date Received=Previous Fiscal Year, Contributions AND Their Soft Credits, Soft Credit Type=Donor-Advised Fund).
However, when I run this same query through the search feature in the 'add existing transactions to a batch' screen, the results are incorrect. It filters for previous fiscal year contributions, but it returns all contributions rather than just contributions with a soft credit type of DAF.
The Soft Credit Type criteria doesn't seem to be registering. This shows you the 'add existing transactions to a batch' screen I'm referring to: (https://docs.civicrm.org/user/en/latest/contributions/accounting-integration/#create-a-new-batch-from-existing-transactions.)https://lab.civicrm.org/dev/financial/-/issues/176Billing fields aren't hidden even when they can2024-02-19T16:44:11ZcapoBilling fields aren't hidden even when they canThe **assignAddressField** function, implemented in [CRM/Core/BAO/UFField.php#L785](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/UFField.php#L785), is meant to return a boolean that tells if:
> Can the address block ...The **assignAddressField** function, implemented in [CRM/Core/BAO/UFField.php#L785](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/UFField.php#L785), is meant to return a boolean that tells if:
> Can the address block be hidden safe in the knowledge all fields are elsewhere collected (see CRM-15118)
But it only has one return statement when that covers some of the cases in which the fields can't be hidden. In other words, the function never returns true. It can let JavaScript know that all the necessary fields are present but it can't let know other PHP functions.
This issue might be related with #129.https://lab.civicrm.org/dev/financial/-/issues/175Can't remove previously-added currencies2021-07-01T18:10:13Zmegaphonetech-dennisCan't remove previously-added currenciesOverview
----------------------------------------
When I remove previously-added currencies from the list of available currencies under *Language and Currency* and hit the **Save** button, the currencies are still listed among the avail...Overview
----------------------------------------
When I remove previously-added currencies from the list of available currencies under *Language and Currency* and hit the **Save** button, the currencies are still listed among the available currencies when I return to that page.
Reproduction steps
----------------------------------------
1. Go to **Administer** >> **Localization** >> **Languages, Currency, Locations**
1. Next to *Available Currencies* add some currencies. I used CLP and TWD. Click on the **Save** button located at the bottom of the page.
1. Return to **Administer** >> **Localization** >> **Languages, Currency, Locations**
1. Next to *Available Currencies* remove previously-added currencies, and click on the **Save** button located at the bottom of the page.
1. Return to **Administer** >> **Localization** >> **Languages, Currency, Locations** and find those currencies still listed next to *Available Currencies*.
Current behaviour
----------------------------------------
There are no error messages or any indication that something has gone wrong.
Expected behaviour
----------------------------------------
I expected the currencies I removed from this page to no longer be listed as *Available Currencies* when I returned to this page.
Environment information
----------------------------------------
Replicable on the demo server.https://lab.civicrm.org/dev/financial/-/issues/174Partial payment records amount of full contribution disrupting balance2023-06-16T09:36:40Zmagnolia61Partial payment records amount of full contribution disrupting balanceIn https://lab.civicrm.org/dev/financial/-/issues/173 the user dashboard pay now button was enabled for partially paid contributions. When I first tested this it looked fine, as the proper remaining amount was charged for the additional ...In https://lab.civicrm.org/dev/financial/-/issues/173 the user dashboard pay now button was enabled for partially paid contributions. When I first tested this it looked fine, as the proper remaining amount was charged for the additional payment.
On further testing I noticed that it was not recorded properly. Situation was like this:
Contribution Amount = 155
Initial payment = 55
Amount Due = 100
Via the User Dashboard Pay Now button the remaining 100 is paid.
The contribution status is now completed.
But the payment transaction is recorded as being the full 155.
So Civi thinks too much has been paid.
![Screenshot_2021-06-02_Dashboard_-_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen](/uploads/aafe9f5a09dd4a57a4ad39042cf5148d/Screenshot_2021-06-02_Dashboard_-_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen.png)
![Screenshot_2021-06-02_Online_betalen_Stichting_Onvergetelijke_Zomerkampen](/uploads/1905ada9754fb2414871da4197ec45c6/Screenshot_2021-06-02_Online_betalen_Stichting_Onvergetelijke_Zomerkampen.png)
![Screenshot_2021-06-02_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen](/uploads/b5501ee9d40fd6ae41f1a1ae1692bf6c/Screenshot_2021-06-02_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen.png)
The second payment should have been recorded as 100 euro, but is listed as the full contribution amount
![Screenshot_2021-06-02_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen-balance](/uploads/9fbebc447f2cfe1b00dd6d4c9040fc33/Screenshot_2021-06-02_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen-balance.png)https://lab.civicrm.org/dev/financial/-/issues/168Preparing PayPal & 3DS2023-09-15T02:08:57Zjoshjosh@civicrm.orgPreparing PayPal & 3DSIn a recent discussion with PayPal we learned about changes coming to their product line as a result of current 3DS adoption in the UK, EU and expected adoption in the future. This appears to be most relevant to merchants using PayPal Pr...In a recent discussion with PayPal we learned about changes coming to their product line as a result of current 3DS adoption in the UK, EU and expected adoption in the future. This appears to be most relevant to merchants using PayPal Pro.
Currently, merchants in the UK and EU using PayPal Pro will experience an increase in declines as a result of 3DS enforcement. While the absolute number of CiviCRM users in both areas is low to modest, there are several rather large users, so the payment volume is sizable.
PayPal Pro does not support current 3DS parameters (version 1.0) and will not support future versions (version 2.0 arrives in October iirc). In essence, PayPal Pro does not support 3DS. In fact, they are phasing it out in favor of PayPal Commerce (venmo, apple pay, etc.), which is 3DS compliant.
PayPal expects 3DS enforcement to arrive in more countries such as CA and AU next, followed (eventually, ahem) by the US.
PayPal products that do not support direct card payment, i.e. Express and Standard, are not affected.
PayPal is advising partners to notify their merchants of the impending change and is recommending that partners build integrations with PayPal Commerce (or braintree, though they recommend Commerce for nonprofit organizations).https://lab.civicrm.org/dev/financial/-/issues/167Document Support for CiviCRM from payment processors2024-03-07T16:39:04ZJoeMurrayDocument Support for CiviCRM from payment processorsDocument appropriately the support that CiviCRM receives from a variety of payment processors.
- [ ] Payment processing feature page that cites the sponsoring payment processors
- [ ] Individual payment processor pages similar to partn...Document appropriately the support that CiviCRM receives from a variety of payment processors.
- [ ] Payment processing feature page that cites the sponsoring payment processors
- [ ] Individual payment processor pages similar to partner detail pages
- [ ] Update the extension readme.md on extensions in gitlab
- [ ] Update extension pages on c.o (for as long as these will exist)
Josh has started on first two tasks as of Feb 22, 2021.
----
Original description
Document appropriately (after determining what that means ;) ) the support that CiviCRM receives from a variety of payment processors.
This might mean putting something into the info.xml or README.md of each extension, as well as adding something somewhere on c.o.
See https://github.com/agileware/cf-stripe/issues/1
@mattwire any sense of Stripe's compensation arrangements being different in Australia compared to other countries? I like the policy thrust of @justinfreeman 's comment but don't believe it is industry practice.joshjosh@civicrm.orgjoshjosh@civicrm.orghttps://lab.civicrm.org/dev/financial/-/issues/165Specify text for backend recurring receipts, also cc's and bcc's2022-12-19T03:45:27ZJoeMurraySpecify text for backend recurring receipts, also cc's and bcc'sIf a front end recurring donation is made, then the page's receipt text is added to every recurring receipt (from https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contribute/ContributionPage.xml#L326).
If a back end recurr...If a front end recurring donation is made, then the page's receipt text is added to every recurring receipt (from https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contribute/ContributionPage.xml#L326).
If a back end recurring donation is made, then the message template Contributions - Receipt (on-line) doesn't output anything from
```
{if $receipt_text}
<p>{$receipt_text|htmlize}</p>
{/if}
```
I think it it would make sense to have this additional text that is added at the top of the receipt specified for backend recurring contributions in core. It would involve a schema change to add a receipt_text field in civicrm_contributioin_recur after https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contribute/ContributionRecur.xml#L432 , and change the template above to use it.
(Could this be done in an extension, apart from the question of whether it is functionality that completes a feature? The hook at https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_alterMailContent/ allows the text of a template to be altered. But there is no tooling for modifying a specific part of a template similar to how we've come to use js to modify a page's DOM rather than override its tpl. As a result, it's quite difficult to manage changes to the contents of core templates from extensions as I don't think there is a good way to 'modify its DOM' prior to sending. I suppose a regex every time a receipt is sent to insert the desired text is possible if a bit ugly.)
Simiilarly, there is no ability to cc or bcc these receipts for backend recurring contributions like there is for frontend ones. I'd add fields for this into civicrm_contribution_recur similar to those from civicrm_contribution_page.
I don't believe the is_email_receipt field on civicrm_contribution_recur is exposed on the backend contribution form (anymore). I think it could make sense to add it and the new receipt_text field just under the Receipt Date field on https://dmaster.demo.civicrm.org/civicrm/contact/view/contribution?reset=1&action=add&context=standalone&mode=live. A better approach if we are going to expose them, I think, is to hide these fields in a receipt fieldset, perhaps above Additional Details.
It's likely that many folks would prefer to just specify this once for all backend recurring donations, as it will include text similar to that on the manage contribution page settings for all front end recurring donations through that page. An alternative to adding these fields to the schema for civicrm_contribution_recur, and exposing them for each backend contribution, would be to make them into settings that could be set at Administer > CiviContribute > CiviContribute Component Settings.
Thoughts? Upvotes or even downvotes appreciated if you don't have time for a comment.
Cheers.seamusleeseamusleehttps://lab.civicrm.org/dev/financial/-/issues/157Proposal - if payment_processor_type does not define url_site_default then do...2020-12-04T08:47:08ZeileenProposal - if payment_processor_type does not define url_site_default then do not present url_site on Processor formWhen you go to create a new processor there is a field for the site_url (& some other urls) which I generally don't think it's good to have users fill in and would rather suppress. I think it should be suppressed based on payment process...When you go to create a new processor there is a field for the site_url (& some other urls) which I generally don't think it's good to have users fill in and would rather suppress. I think it should be suppressed based on payment processor & while I could make a case for using a supportsUserDefinedUrl method I think we could get away with either
1) don't display the field if payment_processor.site_url_default is empty or
2) don't display the field is payment_processor.site_url_default is 'null' or some other magic value
We aren't currently doing any 'supports' checks on the form & it feels like this is probably something used primarily by older processors so I lean towards 1 being enough
@mattwire @KarinG @adixon @artfulrobot @andrewhunt thoughtshttps://lab.civicrm.org/dev/financial/-/issues/155Incorrect deductible shown in contribution summary report2020-11-09T13:37:51ZMonish DebIncorrect deductible shown in contribution summary reportSteps to replicate:
1. Ensure that there are multiple contributions with non-zero non-deductible amount.
2. Go to Contribution Summary Report
3. Select Non-Deductible amount column + Grouping on Receive Date - Month
Result: Total non-d...Steps to replicate:
1. Ensure that there are multiple contributions with non-zero non-deductible amount.
2. Go to Contribution Summary Report
3. Select Non-Deductible amount column + Grouping on Receive Date - Month
Result: Total non-deductible amount is incorrect against each month
On closer look, group function (- SUM) is not applied on non-deductible amount, thus the report column show random amount.
Here's a screencast that explains the issue, where I added two contributions this month w/o non-deductible amount respectively, but the Contribution summary report shows incorrect value:
![yhv](/uploads/e851d5c3b56e46c1de049d12d1f977ff/yhv.gif)
ping @JoeMurray @eileen @mattwire @EdselopezMonish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/153Orange Paypal Pro button not redirecting properly after reCaptcha on Paypal2020-12-09T00:33:53ZStoobOrange Paypal Pro button not redirecting properly after reCaptcha on Paypal#151 related issue @eileen @seamuslee
The javascript errors are fixed but we have been able to reproduce other errors related to the reCaptcha system at Paypal.com. I am not sure if these can be fixed on CiviCRM's side or not but we sh...#151 related issue @eileen @seamuslee
The javascript errors are fixed but we have been able to reproduce other errors related to the reCaptcha system at Paypal.com. I am not sure if these can be fixed on CiviCRM's side or not but we should be aware of the following experience from user testing.
My guess is the from the Civi side we should confirm we are sending Paypal the proper auto-return URL to ensure that Paypal can find its way back to us after hitting us with the reCaptcha on their end.
In *Chrome and Safari* the Javascript errors are fixed -- when you click the Paypal button, there's no validation error requiring the user to input CC fields.
**But** when I go to Paypal, I'm asked to complete a ReCaptcha at this URL: https://www.paypal.com//cgi-bin/webscr?cmd=_express-checkout&token=EC-2JE64037K02097038. Once I complete the challenge, the page does not reload to the log-in screen. Instead it just sits with the challenge results accepted. If I then reload the page, it redirects me to the Paypal log-in page as it should at this URL: https://www.paypal.com//cgi-bin/webscr?cmd=_express-checkout&token=EC-2JE64037K02097038
In *Firefox*, the Javascript errors are fixed -- when I click the Paypal button, there's no validation error requiring the user to input CC fields. When you go to Paypal, I'm asked to complete a ReCaptcha. Once I complete the challenge, the Paypal experience is different page loads the sad dinosaur error screen "hmm we're having trouble finding that site"https://lab.civicrm.org/dev/financial/-/issues/146alterPaymentProcessorParams hook and propertyBag2020-09-15T15:35:00Zmattwiremjw@mjwconsult.co.ukalterPaymentProcessorParams hook and propertyBagSee https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all t...See https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all the quirks of checking different array keys for one thing.
> - ✔ any setting the hook does in a prop bag ensures forward consistency for the next process in the chain (another hook or the main process)
> - ✖ It's possible that the reason for a hook is something pretty darn weird needs doing; in which case the raw array may be more useful.
>
> 2. pass the original array to the hook
>
> - ✖ hook has to do all work arounds
> - ✖ hook is free to implement bad practise in altering the array
> - ✔ hook can do whatever it likes.
>
> I think (1).
And example from Stripe where we're currently passing an array for compatibility (but this should not be used as a model as Stripe ignores the return values from the hook anyway).
https://lab.civicrm.org/extensions/stripe/-/blob/master/CRM/Core/Payment/Stripe.php#L484-489
// @fixme DO NOT SET ANYTHING ON $propertyBag or $params BELOW THIS LINE (we are reading from both)
$params = $this->getPropertyBagAsArray($propertyBag);
// We don't actually use this hook with Stripe, but useful to trigger so listeners can see raw params
$newParams = [];
CRM_Utils_Hook::alterPaymentProcessorParams($this, $params, $newParams);https://lab.civicrm.org/dev/financial/-/issues/145Adding "standard" params to propertyBag2020-09-16T00:42:12Zmattwiremjw@mjwconsult.co.ukAdding "standard" params to propertyBagThis came out of https://github.com/civicrm/civicrm-core/pull/18425 and https://github.com/civicrm/civicrm-core/pull/17595.
Specifically, adding "standard" parameters to propertyBag when they are already in use by a payment processor th...This came out of https://github.com/civicrm/civicrm-core/pull/18425 and https://github.com/civicrm/civicrm-core/pull/17595.
Specifically, adding "standard" parameters to propertyBag when they are already in use by a payment processor that has been converted to use propertyBag is likely to break existing implementations.
Accessing params that are later added as "standard" params to propertyBag when a payment processor is already converted internally to propertyBag (eg. most of the ones written by me Stripe, authnetecheck, Smartdebit).
Example Issues:
- authnetecheck accesses `$params['credit_card_number']` which disappears once mapped to a propertyBag because only the standardised `cardNumber` field is available.
- If authnetecheck was using `$propertyBag->getCustomProperty('credit_card_number')` it would throw an "InvalidArgumentException" because you are not allowed to use `getCustomProperty` for a "standard" property.
Similar issues will apply to any other properties that are already in use by a payment processor.
@eileen @artfulrobot @seamuslee @tottenhttps://lab.civicrm.org/dev/financial/-/issues/144Figure out if core processors actually work.....2022-05-19T22:31:00ZeileenFigure out if core processors actually work.....The processors we currently ship with core are
| Processor | status|
| ------ | ------ |
| Authorize.net | works/tested |
| Elavon| broken? |
| Eway| works/tested/ converted to an extension |
| FirstData| broken? (Reported as working by...The processors we currently ship with core are
| Processor | status|
| ------ | ------ |
| Authorize.net | works/tested |
| Elavon| broken? |
| Eway| works/tested/ converted to an extension |
| FirstData| broken? (Reported as working by Brian Civi Version not mentioned) |
| PayflowPro| broken? (Reported as working as of 5.19 by Nicholas) (As of 5.38 Migrated to a core extension with unit tests) |
| PaymentExpress| definitely broken / removed|
| PayJunction| broken? |
| Paypal| works/tested |
| Realex| likely works, have seen gitlabs |
I think we should try to find out about the ones that might be broken with a view to either
1) bring them under CI & move to an extension (per Eway) OR
2) remove them from core
Other than pinging people like @lcdweb to see if they use any my other idea is to add a check or preUpgrade message to try to get people to let us know.
@seamusleehttps://lab.civicrm.org/dev/financial/-/issues/143Convert core processors to use Guzzle and bring them under CI2020-09-05T01:27:07ZeileenConvert core processors to use Guzzle and bring them under CISubtask of https://lab.civicrm.org/dev/financial/-/issues/132Subtask of https://lab.civicrm.org/dev/financial/-/issues/132https://lab.civicrm.org/dev/financial/-/issues/142Order api proposal - require less line item parameters2020-12-03T10:37:27ZeileenOrder api proposal - require less line item parametersI'd like to propose that we add sensible defaults for line items when using the order api
1) price_field_id - if NONE of the rows have a price_field_id then use the default pricefield id for all of them (I don't want to open up technica...I'd like to propose that we add sensible defaults for line items when using the order api
1) price_field_id - if NONE of the rows have a price_field_id then use the default pricefield id for all of them (I don't want to open up technical analysis of dealing with multiple price sets, more complex config) - so this is just for that common use case
2) qty - if not set, default to 1
This would make the minimum required params for a 'quick config' (I hate that usage but I think we know what it means) order
```
$this->callAPISuccess('Order', 'create', [
'financial_type_id' => 'Donation',
'contact_id' => $contact1,
'line_items' => [
['line_item' => [
[
'financial_type_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'financial_type_id', 'Donation'),
'line_total' => 40,
],
[
'financial_type_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'financial_type_id', 'Member Dues'),
'line_total' => 50,
],
]],
]
]);
```
Ideally we would also accept
```
'financial_type_id' =>'Donation',
```https://lab.civicrm.org/dev/financial/-/issues/138Broken bookkeeping records: no financial trxn from Accounts Receivable to rev...2020-06-29T04:05:27ZRichBroken bookkeeping records: no financial trxn from Accounts Receivable to revenue account.According to the [docs](https://docs.civicrm.org/dev/en/latest/financial/financialentities/), when a Pending Order is created it's supposed to create a financial trxn transferring the total sum to accounts receivable. I'm not seeing this...According to the [docs](https://docs.civicrm.org/dev/en/latest/financial/financialentities/), when a Pending Order is created it's supposed to create a financial trxn transferring the total sum to accounts receivable. I'm not seeing this happening.
@JoeMurray [pointed out](https://chat.civicrm.org/civicrm/pl/zs556c7xqjdtjciry8qnipw7rc) that *There's a setting in CiviContribute Compnent Settings now which iirc disables this by default.*
And @eileen suggested that the default should be the other way around.
But even with this turned ON, the trxn is not created.
```bash
# Set this to a contact that exists:
CID=202
cv api Order.create financial_type_id=Donation contact_id=$CID contribution_status_id=Pending \
total_amount=30 receive_date=2020-05-29\ 15:30:00
```
At this point we would expect (according to my understanding) to see:
- ✔ 1 contribution record.
- ✔ 1 line item: directly linked to the contribution.
- ✔ 1 financial item, linked to the line item, which specifies the CREDIT financial account (*Donation*) and status 3 (pending).
- ✖ 1 financial trxn:
- `from_account` (the CREDIT): The revenue (income) account for the *Donation* financial type.
- `to_account` (the DEBIT): Accounts Receiveable
- ✖ related entity financial trxn records
Without this we end up with bookkeeping problems:
- all financial trxns come *from* Accounts Recievable, but there's nothing going *to* Accounts Receivable.
- there are no bookkeeping transactions for the revenue accounts.
- So you get info like "some money went into your bank" but not "a donation went into your bank".JoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/financial/-/issues/137Billing Address params on propertyBag2020-09-14T16:45:36Zmattwiremjw@mjwconsult.co.ukBilling Address params on propertyBagWe currently have a set of `billingXxx` fields on propertyBag but they have no mappings to what actually gets passed in.
Because of `CRM_Core_Form::prepareParamsForPaymentProcessor` we can be pretty certain that fields will be available ...We currently have a set of `billingXxx` fields on propertyBag but they have no mappings to what actually gets passed in.
Because of `CRM_Core_Form::prepareParamsForPaymentProcessor` we can be pretty certain that fields will be available in the format without the `billing_` prefix.
But the mapping is still not completely clear:
```
'billingStreetAddress' => TRUE,
'street_address' => 'billingStreetAddress',
'billingSupplementalAddress1' => TRUE,
'billingSupplementalAddress2' => TRUE,
'billingSupplementalAddress3' => TRUE,
'billingCity' => TRUE,
'city' => 'billingCity',
'billingPostalCode' => TRUE,
'postal_code' => 'billingPostalCode',
'billingCounty' => TRUE,
'state_province' => 'billingCounty',
'billingCountry' => TRUE,
'country' => 'billingCountry',
```
In particular:
1) "County" has various meanings and we should probably standardise on `stateProvince` with `County` being the next level down.
2) Should the params be prefixed with `billingXxx` at all in propertyBag? Or `addressXxx` or just `xxx`.
3) Do we need the supplementalAddress params at all - I don't think anything (payments) uses them?
Ping @eileen @artfulrobot @KarinG