CRM-12061 Bulk Contribution Entry Issues on Upgraded Site

Stuart - Contribution types should have been converted to Financial Types - so first thing is to check that this happened (Administer > CiviContribute > Financial Types.

The 'old vs new' custom contribution field issue seems separate. Would be good to investigate the properties of a custom data set / custom data field that works vs. one that doesn't (both in the UI and in the DB - civicrm_custom_group / civicrm_custom_field.)

Financial types exist. See new screenshots. I can provide you a DB dump re: the custom field issue. i examined the schema of both custom data sets and they seem to have no discrepacies.

Please work with Pradeep to figure out why Batch Data Entry is failing on the upgraded (4.3) DB. Stoob will be sending you a copy of the pre (4.2.8) and post ( 4.3) DB.

I have shared the db via Dropbox with Deepak's webaccess email. Please let me know if you do not get the invite to the shared folder Deepak.

Stoob thanks i have received the db. I'm looking into it.

Re: Bulk 'contribution type' blank -
Problem is related to profiles that included contribution-type fields. civicrm_uf_field for example, even after upgrade has entries with field_name as 'contribution_type'.

This is making bulk contribution screen unable to populate contribution / financial type.

Re: contribution missing -
Contribution records created with above bulk process with missing contribution-types have financial-type missing in db (for cid=28604). And therefore UI doesn't show this contribution.

Re: older custom contribution custom data don't work
This is a bug in file CRM/Batch/Form/Entry.php
Line ~389 - $value['custom'] = CRM_Core_BAO_CustomField::postProcess($value, CRM_Core_DAO::$_nullObject, $key, 'Contribution');
Should pass NULL instead of $key, since that suppose to be entity_id, and entity-id in case of bulk, is always not going to be present before hand.

Assigning to pradeep for implementing / verifying the fixes.
Pradeep, assign back to me for QA when you done.

Thanks for your help with this so far. i can confirm this bug exists on another 4.2 site with custom contribution data recently test-upgraded to 4.3. if you want a copy of that database as well let me know

Merged changes at #133.

An update: So fixes mentioned by stoob seems to have been fixed.

Just found another error while testing upgrade on stoob's db:

INSERT INTO civicrm_financial_trxn (contribution_id, payment_instrument_id, currency, total_amount, net_amount, fee_amount, trxn_id, status_id, check_number, to_financial_account_id, from_financial_account_id, trxn_date, payment_processor_id, is_fee) SELECT con.id, ft.payment_instrument_id, ft.currency, ft.fee_amount, NULL, NULL, ft.trxn_id, 1 as status_id, ft.check_number, efaFT.financial_account_id as to_financial_account_id, CASE WHEN efaPP.financial_account_id IS NOT NULL THEN efaPP.financial_account_id WHEN tpi.financial_account_id IS NOT NULL THEN tpi.financial_account_id ELSE 15 END as from_financial_account_id, ft.trxn_date, ft.payment_processor_id, 1 as is_fee FROM civicrm_contribution con INNER JOIN civicrm_financial_trxn ft ON (ft.contribution_id = con.id) LEFT JOIN civicrm_entity_financial_account efaFT ON (con.financial_type_id = efaFT.entity_id AND efaFT.entity_table = 'civicrm_financial_type' AND efaFT.account_relationship = 5) LEFT JOIN civicrm_entity_financial_account efaPP ON (ft.payment_processor_id = efaPP.entity_id AND efaPP.entity_table = 'civicrm_payment_processor' AND efaPP.account_relationship = 6) LEFT JOIN civicrm_temp_704fba83983ee623d1d3251e9004607b tpi ON ft.payment_instrument_id = tpi.instrument_id WHERE con.fee_amount IS NOT NULL AND (con.contribution_status_id IN (1, 3) OR (con.contribution_status_id =2 AND con.is_pay_later = 1)) GROUP BY con.id [nativecode=1048 ** Column 'total_amount' cannot be null]

Which is due to total_amount getting inserted as NULL. Pradeep is looking into it.

Looks fine now.

Deepak or Kurund, can you please commit changes to the CRM/Batch/Form/Entry.php file to the 4.2 branch for inclusion in 4.2.9? This issue affects 4.2 also. That simple patch according to my testing fixes the issue for 4.2 also.