I have forms that have SEVERAL items & options on them. So if a client buys 1 item, the invoice is just this gigantic list of categories (fields) with 1 thing filled out. Can anybody help me figure out how to set it up so it acts like a receipt??
If you bought a pack of gum at the drug store, the receipt has "gum $1.00" -- THAT'S what I'm looking for and desperately need to set up. Not the giant long list of drug store items you COULD'VE bought. Do I need to set up a pipeline to do this, or CAN I at least??
Any help would be life saving, I'm kind of freaking out! I have a deadline in a couple days. :( :( :(
Thank you so much!
------------------------------
Michael Brumfield
------------------------------
Question
How Can I hide invoice fields when blank??
This topic has been closed for replies.
+22Typically in the proper design of an app you will have a parent child relationship. That means that one invoice will have many line items. So that way the users will add the line items that they need as a trial table and those children will display on the parent form.
It is unusual to have a company where there are so few different SKUs sold that you can actually list every possible SKU write on the invoice.
But if you do not want to re-design your app or in your use case it is appropriate to literally list every SKU on the form then the easy solution is to have two different forms.
Do you have more than one form there is a setting that comes up called forms usage and you can send a different form to be used in View and Edit and Add.
The ADSD and Edit form would be your complete form.
But the view form would have dynamic form rules. In fact it would have a bunch of them.
Fortunately when you make a dynamic form or you can copy it.
So Rule 1 will be
When Qty Item 1 equal zero
Action
Hide Item 1
Hide Qty Item 1
Hide Price Item 1
Hide extended price Item 1.
be sure to check the somewhat hidden checkbox at the bottom of he form rule to collase space on hidden fields.
Your rule number one done perfectly then you can copy it and change everything to refer to item 2.
However before you dig the hole deeper reconsider whether it would be better to design your app "properly quote and have the users add child records one by one for the items they need. The problem with your solution is that does not seem scalable as the number of SKUs grows.
Problem with your approach is that sales analysis will be brutally difficult. That is because you do not have a dedicated table of line item so as soon as you turn around and say you want a sales report by item you will be not able to do that at all.
Just point out once again that not having a child table for items is quite unusual and while not necessarily wrong you need to know what you're doing and not just accidentally do it that way only to realize a month from now that you regret that choice and now have to tear apart the app to rebuild it.
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------
It is unusual to have a company where there are so few different SKUs sold that you can actually list every possible SKU write on the invoice.
But if you do not want to re-design your app or in your use case it is appropriate to literally list every SKU on the form then the easy solution is to have two different forms.
Do you have more than one form there is a setting that comes up called forms usage and you can send a different form to be used in View and Edit and Add.
The ADSD and Edit form would be your complete form.
But the view form would have dynamic form rules. In fact it would have a bunch of them.
Fortunately when you make a dynamic form or you can copy it.
So Rule 1 will be
When Qty Item 1 equal zero
Action
Hide Item 1
Hide Qty Item 1
Hide Price Item 1
Hide extended price Item 1.
be sure to check the somewhat hidden checkbox at the bottom of he form rule to collase space on hidden fields.
Your rule number one done perfectly then you can copy it and change everything to refer to item 2.
However before you dig the hole deeper reconsider whether it would be better to design your app "properly quote and have the users add child records one by one for the items they need. The problem with your solution is that does not seem scalable as the number of SKUs grows.
Problem with your approach is that sales analysis will be brutally difficult. That is because you do not have a dedicated table of line item so as soon as you turn around and say you want a sales report by item you will be not able to do that at all.
Just point out once again that not having a child table for items is quite unusual and while not necessarily wrong you need to know what you're doing and not just accidentally do it that way only to realize a month from now that you regret that choice and now have to tear apart the app to rebuild it.
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------
Sign up
Already have an account? Login
Login to the community
Login with Quickbase US – quickbase.com Login with Quickbase EU – quickbase.eu
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.