0015110: Actual payment field value not synced with payment field value in grid

Notes
(0032622) mirurita (viewer) 2010-11-15 18:26	The behavior is intended: Add Payment in Sales: the user should fill first the actual payment and the amount will be distributed among grid line payments. Add Payment in Purchase: the actual payment is a read only field, so the user should go filling the amount in each grid line. The actual payment will be updated automatically after these events.

(0032624) rgoris (viewer) 2010-11-15 19:54	Mikel, the scenario you describe is correct (this is what we designed indeed). The total amount entered at Actual Payment is nicely distributed. However, if the user enters an amount in the grid field first, then the Actual payment in the top half remains 0. This is not intended. It should update to the sum of all the values in the grid. Also see screenshot. I received only 6 EUR against invoice I09/828 and entered that value in the grid field.

(0032625) rgoris (viewer) 2010-11-15 20:04 edited on: 2010-11-15 20:15	Ok, this might get too complicated. Here is an easy fix: When this window opens, the fields in the grid must be disabled. Now, the user is forced to enter a value in the Actual Payment field and is not tempted to enter it in the grid. See 2nd attached image (of how it should behave). Perhaps even better is to already pre-fill the amount due for the sales invoice from where you launched the Add Payment window. I´ll discuss with RMO.

(0032639) rmorley (viewer) 2010-11-16 17:33	The solutions proposed result in an unacceptable loss of functionality in order to fix what amounts to a cosmetic issue. The both the actual payment field and the grid must remain editable (with the amount being distributed from the actual payment field to the grid. The actual payment field should also be updated if the user chooses to update the grid first. If this is not possible (as it may result in a circular argument) then we should acknowledge this as a known limitation and leave the functionality as it is. However, I am surprised that it appears to be such a big issue to have the UI behave in the way it was specified. It should be possible to control the field logic based on the source of the update, i.e., a manual edit results in a distribution to the grid, but an automated update from the grid doesn't.

(0041055) psarobe (viewer) 2011-09-19 10:18	Finally this is the intended behaviour and it is going to remain like this Thanks

Issue History
Date Modified	Username	Field	Change
2010-11-03 16:51	rgoris	New Issue
2010-11-03 16:51	rgoris	Assigned To	=> mirurita
2010-11-03 16:51	rgoris	OBNetwork customer	=> No
2010-11-15 18:26	mirurita	Note Added: 0032622
2010-11-15 18:26	mirurita	Status	new => closed
2010-11-15 18:26	mirurita	Resolution	open => no change required
2010-11-15 19:54	rgoris	Note Added: 0032624
2010-11-15 19:54	rgoris	Status	closed => new
2010-11-15 19:54	rgoris	Resolution	no change required => open
2010-11-15 19:55	rgoris	File Added: syncAmounts.png
2010-11-15 20:04	rgoris	Note Added: 0032625
2010-11-15 20:04	rgoris	File Added: syncAmounts2.png
2010-11-15 20:04	rgoris	Note Edited: 0032625	View Revisions
2010-11-15 20:15	rgoris	File Added: syncAmounts3.png
2010-11-15 20:15	rgoris	Note Edited: 0032625	View Revisions
2010-11-15 20:16	rgoris	Issue Monitored: rmorley
2010-11-16 17:33	rmorley	Note Added: 0032639
2011-09-19 10:18	psarobe	Note Added: 0041055
2011-09-19 10:18	psarobe	Status	new => closed
2011-09-19 10:18	psarobe	Resolution	open => no change required

Relationships [ Relation Graph ] [ Dependency Graph ]