open for discussion

Improvements suggested in PR #67

User default syntax for sequence (#67 (comment)):

            if values.get('name', '/') == '/':
                seq = self.env['ir.sequence']
                values['name'] = seq.with_context(
                     date=date).next_by_code('donation.tax.receipt') or '/'

necessary try block?
#67 (comment)

compute monetary field:
#67 (comment)

When adding a bank journal for donations in order to reconcile donations from bank statement the journal code is set automatically to BNK… Is there an option to change the journal code to e.g. DON?

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-15.0

Modules to migrate

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

There is a workaround in the donation module

but the number field is a related field to move_id.name

This makes it impossible to identify the donation later on.

My suggestion to fix this, is to use a sequence for donation, like in sale.order or account.invoice:

As a default something like: DON-YYYY-{sequence}

What's your opinion on this?
@OCA/donation-maintainers
@alexis-via
@nikul-serpentcs

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-17.0

Modules to migrate

• donation
• donation_bank_statement_oca
• donation_base
• donation_direct_debit
• donation_recurring

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Cleanup the Travis Linting warnings:

************* Module donation
donation/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.post_install
donation/post_install.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.__manifest__
donation/__manifest__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.wizard.donation_validate
donation/wizard/donation_validate.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.wizard.tax_receipt_option_switch
donation/wizard/tax_receipt_option_switch.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.wizard.__init__
donation/wizard/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.report.donation_report
donation/report/donation_report.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
donation/report/donation_report.py:119: [E8103(sql-injection), DonationReport.init] SQL injection risk. Use parameters if you can. - More info https://github.com/OCA/odoo-community.org/blob/master/website/Contribution/CONTRIBUTING.rst#no-sql-injection
************* Module donation.report.__init__
donation/report/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.models.donation
donation/models/donation.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.models.users
donation/models/users.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.models.partner
donation/models/partner.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.models.account
donation/models/account.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.models.donation_campaign
donation/models/donation_campaign.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.models.__init__
donation/models/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.tests.test_donation
donation/tests/test_donation.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation.tests.__init__
donation/tests/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary

************* Module donation_sale
donation_sale/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_sale.__manifest__
donation_sale/__manifest__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_sale.models.donation_sale
donation_sale/models/donation_sale.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_sale.models.sale
donation_sale/models/sale.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_sale.models.account_invoice
donation_sale/models/account_invoice.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_sale.models.__init__
donation_sale/models/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_sale.tests.test_donation_sale
donation_sale/tests/test_donation_sale.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_sale.tests.__init__
donation_sale/tests/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_base
donation_base/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_base.__manifest__
donation_base/__manifest__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_base.wizard.tax_receipt_print
donation_base/wizard/tax_receipt_print.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_base.wizard.tax_receipt_annual_create
donation_base/wizard/tax_receipt_annual_create.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_base.wizard.__init__
donation_base/wizard/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_base.models.product
donation_base/models/product.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_base.models.partner
donation_base/models/partner.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_base.models.donation_tax_receipt
donation_base/models/donation_tax_receipt.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_base.models.__init__
donation_base/models/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_base.tests.test_donation_tax_receipt
donation_base/tests/test_donation_tax_receipt.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_base.tests.__init__
donation_base/tests/__init__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_recurring.__manifest__
donation_recurring/__manifest__.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_recurring.wizard.donation_recurring_generate
donation_recurring/wizard/donation_recurring_generate.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_recurring.models.donation
donation_recurring/models/donation.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary
************* Module donation_recurring.tests.test_recurring_donations
donation_recurring/tests/test_recurring_donations.py:1: [C8202(unnecessary-utf8-coding-comment), ] UTF-8 coding is not necessary

edit: added some more linting warnings to log

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-12.0

Modules to migrate

• donation - By @nikul-serpentcs - #68
• donation_bank_statement
• donation_base - By @nikul-serpentcs - #67
• donation_direct_debit - By @nikul-serpentcs - #69
• donation_recurring - By @nikul-serpentcs - #71
• donation_sale - By @nikul-serpentcs - #70

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-16.0

Modules to migrate

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-9.0

Modules to migrate

• donation_direct_debit
• donation_tax_receipt
• donation_recurring
• donation_thanks
• donation
• donation_bank_statement
• donation_recurring_tax_receipt

When you have to create a mandate from the donation, you get a mandate form. The first parameter is bank account, when you browse on it you don't get any record, you cannot select an existing bank account, it doesn´t recognize the customer´s bank accounts.

Hello,

the commit f9200f1, which fixes an external id error, is missing in branch 9.0

Regards

add a new configuration page to res.config.settings for donation to keep the configuration central.

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0

Modules to migrate

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

For v9, I'm preparing a big re-organisation of the code of the donation project. Let me explain the idea and what I plan to do.

Main idea

The donation module is based on dedicated objects donation and donation.line ; so a donation is not related to a sale order nor an invoice. There are several advantages for this approach:

• the user can encode both the donation and the related payment in a single form, so it's fast and easy.
• we can generate an accounting entry that go directly from the bank account to the revenue account, without going through a receivable account, which reduces the number of accounting entries and avoids reconciliation.
• the donation module only depends on the account module

In one of my new projects, I need to support:

• online donation paid by credit card
• mix of regular products (T-shirt, with VAT) and donations in the same order ; the whole order is paid by a single credit card transaction

For this, I need to support donations inside a sale.order (for the online shop, the basket is a draft sale.order in Odoo). So it is quite different from the current implementation and it's not easy to have those 2 implementations "compatible".

In fact, I think it is the same kind of problem between the "sale" module that provide the sale.order/sale.order.line objects and the "point_of_sale" module that provide the pos.order/pos.order.line objects. The sale.order and pos.order objects are technically independant but they are both related to the sale of goods to a customer. Why did the point_of_sale module created a dedicated object "pos.order" instead of using the "sale.order" object ? I guess it was for simplicity reasons: they wanted to have an object that could handle sale+payment+delivery at the same time (whereas the sale.order object only handles the sale and doesn't directly handle the payment and delivery).

So I plan to make this project evolve to the same kind of approach:

1. First solution: the donation/donation.line objects will be used when you have donation+payment at the same time (equivalent to the "point_of_sale"), because it is very simple and we can have a journal item that go directly from the bank account to the revenue account (no reconciliation because we don't use a receivable account).
2. Second solution: the sale.order/sale.order.line object will be used when you have a mix of products and donations in the same transaction and/or when you want to have donations in an online shop. In this solution, an invoice is generated so there are 2 journal items: one from the receivable account to the income account and a second one from the bank account to the receivable account and it require a reconciliation in the receivable account.
   You should be able to use only the first solution or only the second solution... or use both ! But, if you use both, you will still have the constraints linked to the fact that donation.line and sale.order.line are different objects. The main difficulty will be to be able to handle annual tax receipts in the scenario where you use the 2 solutions.

Proposed implementation

So here are my plans for the code base of this project for v9:

• create a new module "donation_base" that will have the properties on the product object
• create a new module "donation_sale" that will depend on donation_base
• the "donation" module will depend on "donation_base"

I know that this change will introduce more modules and more complexity and I don't want to make this project too complex, so I propose the following simplification: the handling of tax receipts will not be handled in a separate module any more ; the handling of tax receipts will be made in the base module (the donation.tax.receipt object will be defined in the donation_base module). For associations that receive donations but are not allowed to generate tax receipts, the drawback is that they will have menu entries and object fields that they don't need ; so I plan to create a group "Donation Tax Receipt" and you will have to be in that group to see all tax-receipt related info (just like the group "Analytic Accounting").

Please give your feedback on this new idea NOW, because I'm starting the development on this new implementation tomorrow ! :)

Hi I'm trying to install donation for a test, and found it cant be installed since 'installable' is set as False. Any reason for this?

Hi guys,

@tbaden and I are planning to work on a module to deal with administrative flows for tangible in-kind dontaions. The plan is to build on the existing in-kind feature, allow in-kind donations to be consumable or stockable products and...

Usage:

• Create a new donation under donations. On line basis you can either add a already created in-kind donation with the type consumable or stockable or create a new one.
• Select the desired warehouse for the inbound and confirm the donation. A stock move from the location donor to the selected inbound location will be generated and you will have an receipt in the warehouse.
• In-kind donations arriving at a warehouse without a pre notification can be handled as a usual inbound and the administrative part can be created with a button

Not yet included:

• Routing donation lines of one donation to several warehouses

Any feedback on module name or planned workflow would be well appreciated

@tbaden will create the PR

Thanks in advance!

Ben

Thanks for your work. Planning to install the Odoo. Just a quick question.

Is it possible to send donation receipts by email to donors? Or download them as PDF? Or get a link where the receipt can be viewed?

Please your help to solve this issue.

Regards

Error:
Odoo Server Error

Traceback (most recent call last):
File "/odoo/odoo-server/odoo/http.py", line 650, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/odoo/odoo-server/odoo/http.py", line 310, in _handle_exception
raise pycompat.reraise(type(exception), exception, sys.exc_info()[2])
File "/odoo/odoo-server/odoo/tools/pycompat.py", line 87, in reraise
raise value
File "/odoo/odoo-server/odoo/http.py", line 692, in dispatch
result = self._call_function(**self.params)
File "/odoo/odoo-server/odoo/http.py", line 342, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/odoo/odoo-server/odoo/service/model.py", line 97, in wrapper
return f(dbname, *args, **kwargs)
File "/odoo/odoo-server/odoo/http.py", line 335, in checked_call
result = self.endpoint(*a, **kw)
File "/odoo/odoo-server/odoo/http.py", line 936, in call
return self.method(*args, **kw)
File "/odoo/odoo-server/odoo/http.py", line 515, in response_wrap
response = f(*args, **kw)
File "/odoo/odoo-server/addons/web/controllers/main.py", line 934, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/odoo/odoo-server/addons/web/controllers/main.py", line 926, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/odoo/odoo-server/odoo/api.py", line 687, in call_kw
return call_kw_model(method, model, args, kwargs)
File "/odoo/odoo-server/odoo/api.py", line 672, in call_kw_model
result = method(recs, *args, **kwargs)
File "/odoo/odoo-server/addons/mail/models/mail_thread.py", line 241, in create
thread.message_post(body=('%s created') % doc_name)
File "/odoo/odoo-server/addons/rating/models/mail_thread.py", line 14, in message_post
message = super(MailThread, self).message_post(body=body, subject=subject, message_type=message_type, subtype=subtype, parent_id=parent_id, attachments=attachments, content_subtype=content_subtype, **kwargs)
File "/odoo/odoo-server/addons/mail/models/mail_thread.py", line 1909, in message_post
new_message = MailMessage.create(values)
File "/odoo/odoo-server/addons/mail/models/mail_message.py", line 753, in create
values['record_name'] = self._get_record_name(values)
File "/odoo/odoo-server/addons/mail/models/mail_message.py", line 709, in _get_record_name
return self.env[model].sudo().browse(res_id).name_get()[0][1]
File "/odoo/custom/addons/donation/donation_recurring/models/donation.py", line 68, in name_get
name = _('Draft Donation of %s') % donation.partner_id.name
TypeError: not all arguments converted during string formatting

ATM the date for a donation can not be in the future to reduce the risk for user errors. For the planning of tangible inkind donations and donations in general, it should be possible to set a date in the future for donations in draft mode.
Therfore the check of the date should be moved to the validation action of the donation instead of creation. @tbaden will take care of this

We ruled out of OCA addons depending on other addons not in OCA or in the core.

Please remove the dependency or remove the module from OCA/donation.

When creating a journal for donations, AFAIK the type needs to be bank in order to being able to do reconciliation. Due to the bank type the journal displays a lot of things in the accounting => dashboard which are not needed in a donations journal. These items should be blanked if the journal if allow_donation in the journal is true. List of items which are not needed from my point of view:

• Buttons ('New Statement', 'Import Statement')
• Actions New ('Import Statement', 'Send Money', 'Receive Money')

@benbrich
The goal is to set an analytic account based on active donation campaign:
ToDo:
create new field in donation.campaign for analytic account (rel: account.analytic.account)
and add an end_date.

functionallity

GIVEN donation.donation model
WHEN campaign_id is set or changed AND
    campaign_id.analytic_account_id is set AND
    donation_date greater than campaign_id.start_date AND
    donation_date lower than campaign_id.end_date
THEN set value of campaign_id.analytic_account_id to donation.line.analytic_account_id

GIVEN donation.line model
WHEN onchange on product_id AND
    donation_id.campaign_id is set AND
    donation_id.campaign_id.analytic_account_id is set AND
    donation_id.donation_date greater than donation_id.campaign_id.start_date AND
    donation_id.donation_date smaller than donation_id.campaign_id.end_date
THEN set value of donation_id.campaign_id.analytic_account_id to analytic_account_id

Hi Guys,

Charitable associations are often times eligible to issue tax receipts to their members for their membership fees. For now we are able to manage memberships and donations as well as tax receipts separated from each other.

@tbaden and I would like to add a glue module to the donation repository donation_membership (?) in order to add the functionality of creating tax receipts for membership fees as following:

• Adding tax_receipt_ok field on membership products view as trigger
• Creation of tax.receipts when invoice has been paid, product has tax_receipt_ok = true and partner has tax_receipt_option = each
• Extension of action create annual receipts to check for membership invoices as well

Whats your opinion on this one?

Thanks and all the best

Ben

When I understand things correctly, in the actual state of the modules, the donors are partner wise handled like customers.
Is there a reason why you did not implement a new partner "type/role/?" donor besides supplier and customer?
I think this would be more userfriendly considering eg. the displayed partners in donors view (Donations/Donations/Donors). Additionally most of the NGOs I know would not talk about the donors as their customers. Furthermore in Germany Non-Profits can to some degree offer services or other things, like commercial companies do. In this case they have donors on the one side and customers on the other and things could mix up. Thanks

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0

Modules to migrate

• donation - By @nikul-serpentcs - #46
• donation_bank_statement - By @tbaden - #55
• donation_base - By @nikul-serpentcs - #45
• donation_direct_debit - By @tbaden - #53
• donation_recurring - By @nikul-serpentcs - #48
• donation_sale - By @nikul-serpentcs - #47
• donation_thanks - By @tbaden - #54

We are working on an German localisation for the donation module atm. The Localisation will mainly consist out of a report which is precisely pre-defined by German tax authorities.

In order to implement this in the most usable way for others we needed to add some fields like responsible tax authority, NPO purpose aso, to the res.company model because this info needs to be displayed in the tax report document. We are not really sure where to put those fields. For now they are in the localisation but would fit in the base module as well, if these infos are needed in other countries too. What do you think where should we implement the fields?

Module

donation

Describe the bug

Error when Sending a Donation Tax Receipt

To Reproduce

Affected versions: 16

Steps to reproduce the behavior:
1.Open donation module
2.Select Tax Receipt Menu option
3.Select any record
4. Send By Email
5. SEND

Expected behavior
Send succefully the email

Error:
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/odoo/tools/cache.py", line 85, in lookup
r = d[key]
File "", line 2, in getitem
File "/usr/lib/python3/dist-packages/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/usr/lib/python3/dist-packages/odoo/tools/lru.py", line 34, in getitem
a = self.d[obj]
KeyError: ('ir.ui.view', <function View._get_view_id at 0x7f8b13891e50>, 2, True, 'donation_base.tax_receipt_email_template', (None,))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/odoo/http.py", line 1584, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/usr/lib/python3/dist-packages/odoo/service/model.py", line 133, in retrying
result = func()
File "/usr/lib/python3/dist-packages/odoo/http.py", line 1611, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/usr/lib/python3/dist-packages/odoo/http.py", line 1815, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/usr/lib/python3/dist-packages/odoo/addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "/usr/lib/python3/dist-packages/odoo/http.py", line 697, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/usr/lib/python3/dist-packages/odoo/addons/web/controllers/dataset.py", line 46, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/usr/lib/python3/dist-packages/odoo/addons/web/controllers/dataset.py", line 33, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/usr/lib/python3/dist-packages/odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/usr/lib/python3/dist-packages/odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/usr/lib/python3/dist-packages/odoo/addons/mail/wizard/mail_compose_message.py", line 245, in action_send_mail
self._action_send_mail(auto_commit=False)
File "/usr/lib/python3/dist-packages/odoo/addons/sale/wizard/mail_compose_message.py", line 15, in _action_send_mail
return super(MailComposeMessage, self)._action_send_mail(auto_commit=auto_commit)
File "/usr/lib/python3/dist-packages/odoo/addons/mail/wizard/mail_compose_message.py", line 333, in _action_send_mail
result_messages += ActiveModel.browse(res_id).message_post(**post_params)
File "/usr/lib/python3/dist-packages/odoo/addons/mail/models/mail_thread.py", line 2041, in message_post
self._notify_thread(new_message, msg_values, **notif_kwargs)
File "/usr/lib/python3/dist-packages/odoo/addons/sms/models/mail_thread.py", line 240, in _notify_thread
recipients_data = super(MailThread, self)._notify_thread(message, msg_vals=msg_vals, **kwargs)
File "/usr/lib/python3/dist-packages/odoo/addons/mail/models/mail_thread.py", line 2419, in _notify_thread
self._notify_thread_by_email(message, recipients_data, msg_vals=msg_vals, **kwargs)
File "/usr/lib/python3/dist-packages/odoo/addons/mail/models/mail_thread.py", line 2543, in _notify_thread_by_email
mail_body = self.env['ir.qweb']._render(template_xmlid, render_values, minimal_qcontext=True, raise_if_not_found=False, lang=template_values['lang'])
File "/usr/lib/python3/dist-packages/odoo/tools/profiler.py", line 292, in _tracked_method_render
return method_render(self, template, values, **options)
File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_qweb.py", line 577, in _render
template_functions, def_name = irQweb._compile(template)
File "/usr/lib/python3/dist-packages/odoo/tools/profiler.py", line 300, in _tracked_compile
return method_compile(self, template)
File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_qweb.py", line 640, in _compile
return self._load_values(base_key_cache, generate_functions)
File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_qweb.py", line 2443, in _load_values
return get_value()
File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_qweb.py", line 615, in generate_functions
code, options, def_name = self._generate_code(template)
File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_qweb.py", line 665, in _generate_code
element, document, ref = self._get_template(template)
File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_qweb.py", line 792, in _get_template
doc_or_elem, ref = self._load(ref_alias) or (None, None)
File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_qweb.py", line 829, in _load
view = IrUIView._get(ref)
File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_ui_view.py", line 2023, in _get
return self.browse(self._get_view_id(view_ref))
File "", line 2, in _get_view_id
File "/usr/lib/python3/dist-packages/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/usr/lib/python3/dist-packages/odoo/addons/website/models/ir_ui_view.py", line 367, in _get_view_id
return super(View, self.sudo())._get_view_id(xml_id)
File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_ui_view.py", line 2015, in _get_view_id
assert res_model == self._name, "Call _get_view_id, expected %r, got %r" % (self._name, res_model)
AssertionError: Call _get_view_id, expected 'ir.ui.view', got 'mail.template'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
at makeErrorFromResponse (https://aussiehelperserp.com.au/web/assets/debug/web.assets_backend.js:10360:19) (/web/static/src/core/network/rpc_service.js:34)
at XMLHttpRequest. (https://aussiehelperserp.com.au/web/assets/debug/web.assets_backend.js:10413:27) (/web/static/src/core/network/rpc_service.js:87)

Additional context
Add any other context about the problem here. (e.g. OS, Python version, ...)

When setting up a donation using the SEPA method it returns the following error.

It does not create the journal entry as when done through an invoice.

Surely there is some kind of configuration that I do not know.

I am using the Spanish chart of accounts.

The journal entry Draft Entry (* 17) (PAY0004) reached an invalid state relative to its payment.
To be consistent, the journal entry must always contains:

• one journal item involving the outstanding payment/receipts account.
• one journal item involving a receivable/payable account.
• optional journal items, all sharing the same account.

El asiento de diario Borrador de asiento (* 18) (PAY0003) alcanzó un estado no válido en relación con su pago.
Para ser coherente, la entrada del diario debe contener siempre:

• un apunte de diario que involucre la cuenta de pagos / recibos pendiente.
• un apunte de diario que implique una cuenta por cobrar / por pagar.
• apuntes opcionales del diario, todos compartiendo la misma cuenta.

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-13.0

Modules to migrate

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-10.0

Modules to migrate

• donation - By @alexis-via - #24
• donation_bank_statement - By @alexis-via - #24
• donation_direct_debit - By @alexis-via - #24
• donation_recurring - By @alexis-via - #24
• donation_recurring_tax_receipt - By @alexis-via - #24
• donation_tax_receipt - By @alexis-via - #24
• donation_thanks - By @alexis-via - #24