fix(asset): cannot create asset if cwip disabled and account not set #23580
+145
−102
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I am submitting this PR as encouraged to do so in issue #23462. The problem is that ERPNext is requiring the specification of a Capital Work in Progress account in order to Submit an Asset, even if the Asset Category does not have Capital Work In Progress accounting enabled.
The rationale for this change is that in the file erpnext/doctype/asset/asset.py, currently the method make_gl_entries() only ever creates entries that credit a Capital Work in Progress account. Hence, it seems to stand to reason that if Capital Work in Progress is not enabled for a given Asset (because of its Asset Category), make_gl_entries() should never be called. From that, it seems logical that validate_make_gl_entry(), which controls whether make_gl_entries() is called, should always return false if CWIP is not enabled. So that's exactly what this PR does, is enforce this last principle.
However, I should point out that this modification doesn't really make complete sense, in that there currently are explicitly coded logic paths in validate_make_gl_entry() that return True when CWIP is not enabled. So with this change, those code paths could never possibly be used, defeating whatever their purpose is. Since I cannot understand their purpose (since after all, they would, if anything, result in a GL entry that involves the Current Work in Progress even though current work in progress accounting is disabled), I am not able to suggest an improvement to this PR. But my guess is that it will need some modification to make it appropriate to merge. I expressed these concerns in the discussion to #23462, but was nevertheless encouraged to submit a PR. So here it is. If this PR is accepted, it would have the effect that it:
Closes #23462