Ok MajP, I tried that and it appears that the fields aren't opening until I select another combo below it. For example: I select POA. Nothing happens. I pick another document in the 2nd combobox, and then the POA fields open. I make a selection in the 3rd combo, and the fields enable for the 2nd combo selection
I can see that. The afterupdate event takes place, but that just commits the value to the control buffer. It is not written to the table yet, until you move from that record.
In the after update try adding at the beginning of the code
me.dirty = false
this will save the record first. In other words if you choose 7 or 8 in the combo, 7 or 8 is not added to the table until you move off the record. So currently when the code runs the value is not yet in the table.
Store the relevant information in the CHILD record.
Use a conditional field on the PARENT FORM to display if any of the CHILD records match condition.
This would mean you can add 144 documents. If ONE of them has "Notary Required" selected, you would DISPLAY (NOT SAVE) "Notary required" on the parent FORM but not save it in the parent RECORD.
This way, as child records are updated, you always know what is required.
This also means that if you have child records updated so you no longer need a notary for any of them, you will not see "Notary required" and it won't be saved anywhere.
Would the conditional fields on the parent form be unbound then, and pass the values to the subform's table? Or how does that work?
When I started, I had another table: a table with the account info, a table for all of this info that will appear on the letters (customer name, address, and the fields I was trying to enable/disable), and a junction table for document needed. I have several other fields that are showing and hiding based on account info as well, and I just got overwhelmed with too many subforms and not enough vba knowledge to make everything work together. I also have someone taking screen shots to put in a procedure and doesn't want me to change anything, even though I didn't have everything working yet. I do want it to be set up correctly, but have those limitations to work with unfortunately.
I also have someone taking screen shots to put in a procedure and doesn't want me to change anything, even though I didn't have everything working yet.
First item would be "Don't write the procedure manual before the software is finished". You can do them at the same time, but who ever is doing the documentation would need to understand that these things can and do change.
As to HOW I would implement this?
From the very little I've seen this looks to be a front end for a rental system. I'd not disable fields that could be useful later (such as Alternate Name and County), but I WOULD have a way in the child record to indicate when these are relevant. If this could be multiple conditions, you may even want a grandchild record to hold them, but without a clear idea of how your data is structured I can't really go further into that.
and see if something is returned. Then you set the control as needed based on what is returned.
This would allow you to check all child records (even ones the user doesn't see without scrolling) to let them know of required items. This also means that as you go through child records and deal with any item that is required you can mark the child as "Done" and not worry about it.
From the users perspective, this helps when your customer comes in and says "I'd like X". User prints out what is needed for "X". Customer signs everything. Customer then realizes they want "Y" added, so your user needs to go back in to add "Y". This also helps when customer says they want "X", documents for "X" are printed, then they change their mind and decide on "Y" instead.
If you always look at only at child records that are relevant you needn't update the parent. This also avoids issues of "Child 1 says to do this, Child 2 says its done, but child 3 says its needed still".
First item would be "Don't write the procedure manual before the software is finished". You can do them at the same time, but who ever is doing the documentation would need to understand that these things can and do change.
I agree. I'm working with people who aren't familiar with Access and keep changing requirements on me and give me a short timeline. The PM has her own deadlines for procedures, so she is doing it regardless of if I'm ready or not.
You are close, it's actually related to auto loans, not rentals. It's more of a one time hit in this form. The user will look at another system and see what needs to be done, and produce a letter to the customer and possibly some documentation to go along with it. Then they can either mark it as complete or move it to a pending "queue" to be worked further later.
I appreciate your explanation and will look into making these changes when I can. Thank you!
With loans, do you run into state/county/city requirements that are unique? If so, you may need to create a table with State/County/City specific documents. You would then check each in the PARENT record to see if you need to add CHILD records specific for each.
If this is true, let us know which level(s) you have these at so we can help you design a supporting table as well as how to automatically add them when the appropriate value is selected on the PARENT record.
As to your PM wanting to do procedures first, this is the type of item that pops up where they get annoyed at first, but realize it helps avoid regulatory issues when automatically implemented. Hopefully it will also help address "Changing scope" issues in design. Mostly by allowing you to actually sit down and get a real specification to work from and avoid the changing requirements.
No, this is more of a cleanup project and the only thing dependent on state is if they get a generic POA or a state specific one. If "Notary Required" is selected, I currently have code to open the generic POA if it's not one of the 6 state specific states. If it is, they have to go to a website to get it.
Thank you for your help and taking the time to walk through it!
Without an understanding of your requirements and what your design currently is, I can only guess. My comment is based on the logic of relational databases which is immutable. There is ONE parent record and MULTIPLE child records. How can any one child record control the parent record? If you have to do that then the attributes are in the wrong table.
