see below:
template2.zip
see below:no reason why you can't but I have to question why you need to.
If you have 4 accounts, then they should be in the same transactions table - but with an additional field to show the account name - and you would need to modify the queries provided to filter or group by the account name
template2.zip
I've seen - what is the question?
I can`t seem to put an input mask to require a positive amount in the column advance and negative for payment. Ive also change the Data Entry to Yes.
Problem is that when i add the input mask in the payment column, I can`t enter an amount in the advance column...
So what I did is I put in the 0 for default values both in the payment and advance column
and >=0 for the input mask for advance and <=0 for payment. Except when i enter something in either column , it gets copied into the other column.
without seeing what you are actually doing, difficult to advise. Don't understand why you are using an input mask for basic numbers - they are usually used for thing like telephone number, card numbers and the like
This is not a data display problem, it's a data validation problem. An input mask is not the correct solution. You need to use the Before Update event of each Control, and, as an extra measure you may want to use the Before Update event of the Form as well, to do your data validation. Example (air code);
Reverse the logic for the Advance controlCode:Private Sub txtPayment_BeforeUpdate (Cancel As Integer) If Nz(Me.txtPayment, 0)>0 Then MsgBox "Payment amount must be negative" Cancel = True End If End Sub
As an aside about input masks, I personally think they cause more problems than they solve. Better to just let the users enter the data, use the proper Form or Control events to validate the data, then use a Format if you want it displayed a certain way (IMO).
if you are using my example, once a value is entered it is automatically displayed in the correct column depending on its sign - and then the control in the other column is disabled. Users will soon learn that if they enter a negative number it will appear in the left column and a positive in the right. They can still edit the number wherever it is to change the sign if they got it wrong
if you are using my example, once a value is entered it is automatically displayed in the correct column depending on its sign - and then the control in the other column is disabled. Users will soon learn that if they enter a negative number it will appear in the left column and a positive in the right. They can still edit the number wherever it is to change the sign if they got it wrong
I meant to write Validation Rule.
Well it has happened that in even easier interfaces , users would enter an amount in a column and not verify which column it has been entered into
the suggestion by Beetle is a good one and the way I would go
Worked out perfectly. I have added the code in the Before Update event for txtPayment & txtAdvance but I am not sure why I need to add a code for the Form as well.
You may not necessarily need to. Before Update of the Form can be used as a final validation event, before the record gets saved, to verify that all required fields have valid data. Your choice whether or not you want to have that extra level of validation.
Thank you Beetle!
Hi Ajax!
I am in the testing phase and something came out weird... Not sure why this is happening.
I entered an amount with a date value in the past (i.e: On may 29th, i entered a payment for may 10th).
On that same day, another transaction was made. The balance column isnt representing the correct amount per row (see May10th):
2018-05-29 11-38-26.pdf
without knowing the code you are actually using or which transaction you are referring to, difficult to say, but looks like you haven't provided a proper sort on the data to include the ID field, if that is what you have done