Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Trivial
-
Resolution: Won't Fix
-
Affects Version/s: 4.3.3
-
Fix Version/s: 4.4.0
-
Component/s: CiviContribute
-
Labels:None
Description
The aim is to use the existing batch feature for the sepa dd. We will not use a UI to select the contributions to add to a batch, but automatically do it (initial idea is to create the new monthly contribution and add it directly to the next month batch while we are processing the current batch of contribution for the month)
Sepa needs to have different batches for initial contributions and "normal" recurring ones that already have been processed at least once.
Through various discussions with Joe and testing, it seems we can mostly re-use the batch and create new batch types for our need.
X+
P.S. I've edited the issue after quite a few comments, the initial question was about the UI but drifted until it reached this question as edited
Attachments
Activity
Pradeep, can you point Xavier towards how we are handling searches related to batches? My sense is that he could create his own searches, but I am not sure if there is a good UI for that.
Xavier, it would be about 1.5 days to update core as follows, maybe another day to add webtests:
1) add FinancialExport as a batch type
2) change batch_type to that a) when data entry is done for contributions and memberships and b) when new financial export batches are created
3) refactor our code to include batch_type = FinancialExport everywhere needed
4) create webtests as appropriate for use of batch_type field
@Joe, right now, the two types are contribution and membership, how is this used? are they different export features for instance?
I'll dig into how to create saved searches, might create an api for that, will update when I understood what the UI generates today
as for estimated time to update the core, we don't have the resources right now given the state of the MiH. What I suggest for a v1 is to create new batch types (sepa_initial and sepa_recurrent) and leave the existing ones (contrib and membership) like they are.
The worth thing that can happen is that some sepa contrib end up in normal export, right?
I'll add a big warning on the extension that it's likely not to work in conjonction with the "normal" batch exports. and that is they want to use both they need to fund the 1.5 or do the fixing/testing themselves. Sounds about good?
The contribution and membership batch types are for data entry of batches of contributions received as cheques and deposited in a batch at the bank. These are turned into financial batches ready for export to accounting systems as soon as that data entry workflow is finished. It would make sense to have that happen with SEPA batches as well.
Yes it is possible to make use of the table with that warning, though I would prefer for the solution to supporting batch type field in the financial batch code be submitted to core rather than be a hack on the extension. FWIW, the financial export batch code uses the batch_status field to keep clear about its batches versus those of the data entry code. So using different statuses than those currently defined would be a way to workaround the 1.5 days to let everything work together.
Could you determine what if anything needs to be done on this?
thx
Sepa folks have come up w/ their own solution for batching.
The export was designed to include fields that we expected would be useful for accounting packages. civicrm_batch was originally put together for data entry of contribution and membership batches, then expanded to support financial batch export. We have not provided facilities for customizing the fields.
What fields were you needing, and what is the use case? Maybe update the Issue name with the use case??
If you need to override, the fields for the downloads are defined in CRM/Financial/BAO/ExportFormat/CSV.php and CRM/Financial/BAO/ExportFormat/IIF.php.