I'm looking for advice on how to handle a multi-option input scenario in an Invoice form.
The attached database shows a simplified version of what I'm after.
The db has a table, T_Invoice:
And a form built off it, F_Invoice:
The sample form above is intended to provide a choice of fee payments for the Invoice.
If the user chooses Base, then the entered Base Rate is applied to the fee's base amount.
If the user chooses Multi-Fee, then the entered Base Rate and entered Additional Rate are applied to the fee's base amount and additional amount.
However, I'm using a tab control and have encountered some issues with that approach.
Hence, I'm wondering if anyone has any suggestions for best practice solutions to cover the follow issues.
Potentially Dodgy Practice #1
The multi-option inputs are built from a tab control.
I'm not sure its best practice, because:
(i) The tab control seems to act like a subform.
Eg. if you choose multi-fee, set the two rates, then hit tab, the form gets reset.
This is potentially a deal breaker for this approach.
(ii) I have to hide the tab buttons (ie. set them to 'None')
(iii) Its fiddly to try to align the input boxes and lables
(iv) It seems impossible to left-align the labels with the Input Type label above the tab form
(v) I have to use VBA to show the correct input boxes
I initially wondered instead about using one or more subforms to handle these options.
But the tab control approach seemed more elegant.
However, due to these problems perhaps its not suitable after all.
Potentially Dodgy Practice #2
There are actually several different types of rates, but I have "shoehorned" them into three fields.
1) Rate - this could the Base Rate, or the Compensation Rate, or the Commission Rate.
2) RateAdditional - this is a single field with only one purpose (ie. the additional rate if the invoice Type is a Multi-Fee)
3) Fixed Fee - this is a single field with only one purpose (ie. the fixed fee if the invoice Type is a Fixed Fee)
The resultant calculations would be built off the InvoiceType field, to determine how the Rate is applied in the calculations.
This was a design choice to keep it 'simple'.
If anyone has any advice about my approach here that would be welcome.
The first issue above is the main problem, but very happy to hear of improved solutions for either of those issues.
Many thanks in advance,