Here is the purchase invoice I am trying to submit (I removed Freight)
I get the below error
If I remove the first line item, I can submit.
Thanks for your feedback!
Hi @gmeunier
It seems Debit Amount in Account Currency child table field contributes with a high precision and on both child table and header fields have different precision set for currency and float fields.
If not particular, you can set precision uniformly from system setting page for both types of fields and it may help solve the issue.
Thanks a lot.
Unfortunately in system settings I do have the same precision.
I turned around the issue by creating 2 invoices.
However, now that I am closing the books I face the same issue…
I tried to get to the Log, but can’t find it.
Dears
The particular field has to be set for length by going into customize form as below;
This looks like the field capacity to store amount of data has to be defined and generally it can be set from 1 to 1000 in highlighted length field.
Hi,
Thanks to everyone.
I am in production mode, I guess I am not supposed to touch any of these stuff, everything should work smoothly.
On top here I do not get the issue on a form but on the closing voucher.
I have no figure with more than 2 decimals and it ends up finding a 9 digit value from a 2 digit value.
There is definitely an issue with decimals somewhere with float values instead of decimal values.
I will do a dump of the database tonight see if I can find an issue linked to a field or a value.
ok, did the dump.
No float figures in the database.
All decimals set to 2 in the settings, a calculation tries to replace a decimal figure with a float figure.
The 4630.27 it tries to replace just does not exist in the database.
Or effectively it tries to update something that is locked.
I am definetly stuck.
Here is below the trace
File "apps/erpnext/erpnext/accounts/doctype/period_closing_voucher/period_closing_voucher.py", line 443, in process_gl_and_closing_entries
make_gl_entries(gl_entries, merge_entries=False)
File "apps/erpnext/erpnext/accounts/general_ledger.py", line 48, in make_gl_entries
save_entries(gl_map, adv_adj, update_outstanding, from_repost)
File "apps/erpnext/erpnext/accounts/general_ledger.py", line 386, in save_entries
make_entry(entry, adv_adj, update_outstanding, from_repost)
File "apps/erpnext/erpnext/accounts/general_ledger.py", line 397, in make_entry
gle.submit()
File "apps/frappe/frappe/utils/typing_validations.py", line 31, in wrapper
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "apps/frappe/frappe/model/document.py", line 1093, in submit
return self._submit()
^^^^^^^^^^^^^^
File "apps/frappe/frappe/model/document.py", line 1076, in _submit
return self.save()
^^^^^^^^^^^
File "apps/frappe/frappe/model/document.py", line 378, in save
return self._save(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "apps/frappe/frappe/model/document.py", line 400, in _save
return self.insert()
^^^^^^^^^^^^^
File "apps/frappe/frappe/model/document.py", line 334, in insert
self.run_post_save_methods()
File "apps/frappe/frappe/model/document.py", line 1176, in run_post_save_methods
self.run_method("on_submit")
File "apps/frappe/frappe/model/document.py", line 1007, in run_method
out = Document.hook(fn)(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "apps/frappe/frappe/model/document.py", line 1367, in composer
return composed(self, method, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "apps/frappe/frappe/model/document.py", line 1351, in runner
add_to_return_value(self, f(self, method, *args, **kwargs))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "apps/erpnext_france/erpnext_france/utils/accounting_entry_number.py", line 38, in add_accounting_entry_number
gl_entry.save()
File "apps/frappe/frappe/model/document.py", line 378, in save
return self._save(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "apps/frappe/frappe/model/document.py", line 420, in _save
self.validate_update_after_submit()
File "apps/frappe/frappe/model/document.py", line 929, in validate_update_after_submit
self._validate_update_after_submit()
File "apps/frappe/frappe/model/base_document.py", line 1070, in _validate_update_after_submit
frappe.throw(
File "apps/frappe/frappe/__init__.py", line 606, in throw
msgprint(
File "apps/frappe/frappe/__init__.py", line 571, in msgprint
_raise_exception()
File "apps/frappe/frappe/__init__.py", line 522, in _raise_exception
raise exc
frappe.exceptions.UpdateAfterSubmitError: Not allowed to change <strong>Credit Amount in Account Currency</strong> after submission from <strong>4630.27</strong> to <strong>4630.2699999999995</strong>
The GL Entry doctype is a core system document heavily tied into accounting logic. Making changes here using a property setter can have major side effects:
1. Breaks Compatibility with Core Logic
ERPNext’s internal logic, including validations and accounting routines, assumes the GL Entry fields behave a certain way. If you change a property like:
- “Allow on Submit”
- “Read-only”
- “Hidden”
- “Mandatory”
You could:
- Prevent proper posting of accounting entries.
- Cause entries to be skipped or incorrectly formed.
- Trigger validation errors in future updates or during posting.
2. Upgrades & Migration Risks
Property setters are stored in the database. When upgrading ERPNext:
- You might face unexpected behavior if the core Doctype is changed upstream.
- Field definitions might conflict with your custom property setters.
- Upgrades might silently fail or misbehave until the conflict is resolved.
3. Audit and Compliance Issues
If you’re running ERPNext in a regulated or audited environment, modifying GL Entry properties can:
- Create discrepancies between system behaviors and expected accounting standards.
- Invalidate audit trails or compliance requirements (e.g., read-only on submitted entries).
The Solution is to set precision of those aforesaid fields by customizing GL entry docytpe. The property setter has just ignored the core validation and moved forward and may bring a surprise later in the future.