Hi,
I have the following issue/question
I would like to be able to submit an order which would have
********************************
1 sales person (lookup from table)
******************************
1 client (lookup from table)
**************************
which would allow me to then
***********************************************
add (product1) - (quantity) - calculate price
Add (product2) - (quantity) - calculate price
Add... as many products as required to fulfil any given order
The part which I'm not able to find a path for is the adding many products one
Do you have any advice in regards how to get around this?
Thanks,
Purchasing many items project
-
grimblefritz
- AppGini Super Hero
- Posts: 336
- Joined: 2015-12-23 16:52
Re: Purchasing many items project
Download the invoicing app from http://bigprof.com/appgini/free-open-so ... plications
It should give you an idea on how to create an invoice (or an order, in your scenario) and add line items.
The task is literally done in that order. Create the parent (invoice or order) record and save it, then add child (line item) records linked to the parent record.
The following may help (if not you, then perhaps others new to or contemplating AppGini):
Some people have the mindset "I have these items, now make an order or invoice using them." That's how humans think about the problem, but not how relational databases deal with the data.
If coding an application from scratch, then you can do all manner of "raise the roof before the walls" things. You can select all the line items before creating the parent data. You can create behind the scenes data lookups and calculations and movements and transforms. Etc.
With an app generator such as AppGini, which is primarily a table editor with additional capabilities to make it more than a simple CRUD tool, the interaction with the data is much more structural (follows the conventions of relational database design) rather than procedural (follows a human conceptualization of a workflow.) You either have to live with that restriction, which is often okay for smaller apps, or you have to be ready to layer custom code on top of the generated code (in AppGini, that would preferably be via hooks, or else direct modification to AppGini's php output.)
I frequently just use AppGini's (or a similar tool's) native capabilities and interface and call it an application. When I need to add a table or field, or insert a custom link or button, I go back to AppGini to do that. These are simple apps of just a few tables and it works fine. However, in other cases I have used AppGini only to establish a starting point - getting the data structure and relationships right, handling deletes, etc - and then completed the application - menu system, input forms, detailed data handling and automation, reports, dashboards, etc. - with custom code around the AppGini-generated core. In such cases I cannot go back to AppGini when things change. I prefer as much as possible to go the first route, but there's more money in the latter!
It should give you an idea on how to create an invoice (or an order, in your scenario) and add line items.
The task is literally done in that order. Create the parent (invoice or order) record and save it, then add child (line item) records linked to the parent record.
The following may help (if not you, then perhaps others new to or contemplating AppGini):
Some people have the mindset "I have these items, now make an order or invoice using them." That's how humans think about the problem, but not how relational databases deal with the data.
If coding an application from scratch, then you can do all manner of "raise the roof before the walls" things. You can select all the line items before creating the parent data. You can create behind the scenes data lookups and calculations and movements and transforms. Etc.
With an app generator such as AppGini, which is primarily a table editor with additional capabilities to make it more than a simple CRUD tool, the interaction with the data is much more structural (follows the conventions of relational database design) rather than procedural (follows a human conceptualization of a workflow.) You either have to live with that restriction, which is often okay for smaller apps, or you have to be ready to layer custom code on top of the generated code (in AppGini, that would preferably be via hooks, or else direct modification to AppGini's php output.)
I frequently just use AppGini's (or a similar tool's) native capabilities and interface and call it an application. When I need to add a table or field, or insert a custom link or button, I go back to AppGini to do that. These are simple apps of just a few tables and it works fine. However, in other cases I have used AppGini only to establish a starting point - getting the data structure and relationships right, handling deletes, etc - and then completed the application - menu system, input forms, detailed data handling and automation, reports, dashboards, etc. - with custom code around the AppGini-generated core. In such cases I cannot go back to AppGini when things change. I prefer as much as possible to go the first route, but there's more money in the latter!