(I want to apologize for the delay in responding. I had written about 2/3 of a reply, offline, and misremembered as having posted it already.)
I want to caveat this reply by saying my contribution to this base was the addition of the pricing schedules feature, which allows the user to change item prices without invalidating historical data. I may have spent an hour on it — if I include time spent getting coffee, and if I had at least a couple of cups while working on it.
That said, based on a relatively superficial test consisting of my creating a new order for a pair of end tables and a surprisingly expensive burnt orange sofa, I don’t see anything I would have implemented differently (well, except for something I did implement and would probably change — but more on that later). To my way of thinking, this is single-screen data entry; to flatten it out into truly a single screen would eliminate most of the benefits gained by building the system on top of an RDBMS.
New orders should be processed from the [Client Orders] table. When a call comes in, the CS rep first creates a new client order record by clicking the plus sign below the last number in the left-hand column. (This ensures CREATED_TIME() and the actual time of order are identical.) Next, he or she clicks the plus sign in the {Client} field. This drills through to the [Clients] table and allows either an existing client be selected from the list of known clients or, for a first-time order, new client data to be captured and entered. Once either of those steps has been completed, the user is returned to the [Client Orders] table and view.
Now, what just happened here may vary based on interpretation. To you, this may seem like the rep ‘jumped’ from the [Client Order] table to the [Clients] table and back again; to me, the rep remained in the [Client Order] table the entire time but accessed, when necessary, a related table in order to access data needed fully to populate [Client Order]. Note the rep was never required to navigate from one table to another; instead, when needed he or she passed ‘through’ the current table to an underlying one. Once the necessary data was retrieved from the related table, the rep was returned to the point of departure. This same ‘drill-through’ model pertains to the other linked records you mention — line items, for instance.
Note as well there is no need for the rep to "select the correct order from the client order table.’ Instead, because of the reciprocal nature of linked records, the line items added to the order are automatically related with the appropriate customer order, which in turn is linked to the appropriate customer. (To minimize confusion, though, I would reconfigure the {Belongs to Order} field in the [Order Line Items] table to turn off ‘Allow linking to multiple records.’ While the link from orders to line items should be one-to-many, the reciprocal link should be one-to-one; otherwise, upon adding a line item to an order, the rep will be prompted for a new “belongs to order” link.)
The one thing I don’t like about this base — and that you might wish to modify for your own use — is the handling of the current pricing schedule. As it stands now, {Schedule} is a single-line text field within the [Order Line Items] table in which a two-character code is entered indicating under which schedule the item is to priced. In theory, the currently active schedule can be specified by setting a default value for {Schedule}. Unfortunately, at present Airtable does not honor default values for fields in linked records; that is, when the rep drills through from [Client Order] to [Order Line Items], instead of its configured default value, {Order Line Items::Schedule} displays a blank.
Ultimately, I chose to keep {Schedule} as a line item field, even though doing so means anyone entering orders from the [Client Order] table will need manually to specify the pricing schedule, for a couple of reasons: First, I assume Airtable will correct this oversight in an upcoming release, but second, and more importantly, doing so allows an order to contain items priced according to multiple schedules — for instance, to support a ‘rain check’ on an order placed under an earlier schedule, or to reflect a special offer or group discount. However, should such concerns not apply in your case, you may wish to make the schedule a variable at the [Client Order] level, with one pricing schedule for all items in an order. If so, you’ll want to define {Schedule} as a single-line text field in the [Client Order] table; you’ll also want to change the definition of {Order Line Item::Schedule} to a lookup field using the {Belongs to Order} link to access {Schedule} in the linked record.
Assuming you don’t make such a change, you may want to take a look at the latest version of this base — specifically, the [Order Line Items] table. There I have changed the formulas for {Price} and {Total Cost}, and I’ve added a new field, {Alert}, to make data entry a little more foolproof. (You can find the syntax of the new formulas within the field descriptions; that way, you won’t need to copy the base simply to access field configurations.)
If you have further questions about this base, please ask. :winking_face:
