Data validation on each row.

[Bulzie]

Not sure I follow now what the issue is and on what form. Can't look a the zip file here. But if you are trying to do something with a record on a continuous form, I think you need to use the OnCurrent event so that when you scroll though the records it does what you want and also the AfterUpdate event of the field(s) so that if you change data, it will reflect immediately the other fields on that record. Also if you are using a button in the footer to affect 1 record, I don't think that works as it will take the focus off of that record when you click the button. Again maybe I am not understanding the issue as you were saying above about updating fields on another form and calculated fields, etc. But Rural seems to be working on a solution.

[Homegrownandy]

The button to the right opens a form just to enter the value they want on the invoice. purely to get around this issue. (obviously bringing its own issues). This is why I'm so open to a restructure of this part.

[RuralGuy]

How about if they could just fill in a value on the form? Would that work for you?

[RuralGuy]

Are the fields and information in the header of the form just for debugging? Can we do without them?

[Homegrownandy]

I did want them there but its not a must. It will just let the user know which order they are invoicing against (even if at the moment its displaying rubbish).

the main thing is the remaining quantity value which is a sum of each particular line and the quantity on that line (in the invoices table). This value is then taken away from the quantity of that line on the lines table (the quantity we receive on the order).

This gives us the remaining invoicable quantity. The purpose of this database is to reduce errors in accounts as these errors can eat up weeks of time and money. So starting from a point where its not possible (with correct data to begin with) to invoice against a closed order or for too high a value is a good place to start.

[Homegrownandy]

That form and the record source of it has been remade countless times. I've tried many ways. Ill be back in office first thing. I'm not ignoring you and really appreciate your time.

[RuralGuy]

I know you are in the UK so our timing may be off a bit. I think the record source of that form can be simplified so it is update-able. We'll see.

[RuralGuy]

One thing that's a killer is the aggregate function [Sum]. They will always cause a query to not be update-able. You can use the Domain functions (DSum, DCount...) to obtain the value without using the query. That's what I'll do first.

[Homegrownandy]

If you achieve it ill be very impressed. I have tried using all sorts. Previously on another project I had something similar working where by I used the query as a table and the fields I wanted to update I linked again. (if that makes sense) but with this nothing seems to get me there.

[RuralGuy]

I'm still trying to get my arms around your system. I've been guessing the Invoice Generator form was eventually going to create an Invoice so I was looking at the Invoice form and don't really get the correlation. It also doen not look like the Invoice form is complete as there is an awful lot of white space on the screen. Maybe if you described this part of the system a bit for me it would fall into place.

[Homegrownandy]

The "invoice" form will show anything within the database that hasn't been invoiced in a list. (I have worked on this yesterday but believe in what you have its close to useless) from there Ill hit the button and it creates the report.

The invoice generator form that you are looking at is just for data input. It may be different people, there may be some human validation required but this is the reason for the extra step between input and output.

I suppose invoice generator was a bad choice to name the form. But to the user entering the information, even if there is no output for them, it begins that process for creating/sending the invoice.

[RuralGuy]

So from the Invoice Generator form the actual invoices are printed? What button will you be hitting?

[Homegrownandy]

Its just data input on that form, and a validation check. Then the invoice form will show all entries to the invoice table that do now have a date in the [created] field. Someone can look to check these are okay and create the report from the invoices table.

[RuralGuy]

So it is sort of a manual process after the Invoice Generator form?

[Homegrownandy]

If the data entered in the invoice generator form passes the validation check (or to word it another way.. if that information is saved.). Then that record on the invoice table will exist.

Any record on that table that does not have a date in the [created] field will be in the invoice form for someone to approve. This invoice form will have a button to create the report/invoice.(probably some other features I'm working on).

I'm fairly confident with most of what I'm doing. Maybe ill have a few questions here and there but I'm happy I can reach where I want to get. But this validation is really where my main problem is. Because as you know. To get the remaining value is making it not updatable.