Closed pedrobaeza closed 3 months ago
@LoisRForgeFlow can you advice about the error on hr_expense_tier_validation
?
Traceback (most recent call last):
File "/__w/hr-expense/hr-expense/hr_expense_tier_validation/tests/test_hr_expense_tier_validation.py", line 84, in test_edit_value_expense
s.name = "New name"
File "/opt/odoo/odoo/tests/common.py", line 2278, in __setattr__
assert not self._get_modifier(field, 'readonly'), \
AssertionError: can't write on readonly field name
Checked that the failure is also in main branch: https://github.com/OCA/hr-expense/pull/235
Added the management of payment state and amount residual for expenses paid by employee linked to an invoice with the new transfer entry.
Rebased after the fix in the other module and everything green.
@LoisRForgeFlow can you advice about the error on
hr_expense_tier_validation
?Traceback (most recent call last): File "/__w/hr-expense/hr-expense/hr_expense_tier_validation/tests/test_hr_expense_tier_validation.py", line 84, in test_edit_value_expense s.name = "New name" File "/opt/odoo/odoo/tests/common.py", line 2278, in __setattr__ assert not self._get_modifier(field, 'readonly'), \ AssertionError: can't write on readonly field name
Hi @pedrobaeza
It seems something specific of the expense tier validation integration, maybe Ecosoft as the authors have a better insight?
Yes, thanks, it has already been fixed in #236. Sorry for not updating here (I just rebased).
Yes, thanks, it has already been fixed in #236. Sorry for not updating here (I just rebased).
No worries. That was quick :rocket:
Thanks
/ocabot merge major
Hey, thanks for contributing! Proceeding to merge this for you. Prepared branch 16.0-ocabot-merge-pr-234-by-pedrobaeza-bump-major, awaiting test results.
Congratulations, your PR was merged at 40c569492140674ae560838cf323a0c4476a1930. Thanks a lot for contributing to OCA. ❤️
It's not OK this merge. Now, if this case occurs:
The accounting entries are wrong:
Before this merge, It was against a payable account (410), that would be the right thing to avoid having duplicate expenses.
Also, it's wrong in this other case:
If I "Cancel all related operations", the payment made to the invoice will not be canceled. And i have another button ("Register Payment") that right now it's of no use.
Can you review it please? @pedrobaeza Thanks in advance,
Please open an issue, but that was not the behavior got, as you can check in the tests. Please do the tests on a runboat and report back in an issue.
Hi @pedrobaeza , we're having some problems using this module after this specific change.
I'm attaching a video (00:59 seconds) from runboat without any change in the configuration just so you understand the flow I'm trying to follow and the problem I'm having
https://drive.google.com/file/d/1celILhfky3xYFZw1WsYM3f0isrMIm1iu/view
The flow we were doing before this change was:
I think with the change, the flow should be the same because we are generating the AP through the entry in the general journal, but for some reason I can not register the payment. I get "You can't register a payment because there is nothing left to pay on the selected journal items." like there is no debt related.
Can you help me?
Thanks in advance.
@gonzalolenzi please check #249. There's still a couple of things left that I have to complete though.
The resulting entries after posting were not correct. Now, this is handled this way:
When an invoice is selected in the expense, the interface was not properly adapted, avoiding to change certain data, and the corresponding were not filled as well. Now both things are performed.
Removed the non-sense register payment constraint.
Added smart-button to navigate from invoice to expense, as there's no visible link in that direction.
Avoid the need of the field
with_invoice_id
, as it was simply a question of putting properly the other field as invisible and without groups (apart from the already existing one with groups).Tests cleanup, adapted (they were manipulated in some cases to match the weird previous result, like in payment states) and redundancies were removed.
@Tecnativa TT49143