Software > Software Templates
Software > Software Templates
Embedded Files
The software templates below are available for viewing and copying by those who need functional software for life, as well as those seeking to learn about Sales Systems, Sales Systems Software, Spreadsheets, Cloud Spreadsheets, using spreadsheets for database applications, Javacript Programming, Google Script Programming , commercial education and more...
< expand for more info >
On this page you will find a collection of sales system software templates created to help you learn about sales systems as well as to help you see how they can be customized for personal needs.
Sales System Software customization needs start with 1) header record data field additions and subtractions 2) detail record data field additions and subtractions and 3) the corresponding output of that data on an invoice or statement (on a form). Customization can get far more complex by adding additional relational data tables but start simple.
Header Record Data fields are generally easy to add to the data table and to the form. You can learn to do that in minutes.
Line Item Record Data fields are also easy to add to the data table, but depending on what you are doing, modifying the output form to handle column changes can take a little time and some artistic thinking.
Sales System 1 was created first. as a very simple sales system with the simplest and most generic needs for line items.
To create Sales Systems 2 and 2T, we took Sales System 1 and made the line item data requirements more complex. We did that to get you thinking about how everyone might have varying line item needs and how some of the more common needs might be handled.
To create Sale Systems 3 and 4, we then included reference to a Property two different ways. One way is a simple field addition that is a shortcut for a relational data table. The other uses a relational data table.
It took us 15 to 30 minutes to make each Sales System into a progressively more complex template. It might take you longer in the beginning but eventually it should be a short task that is only done as you need it and for your own needs.
There is a quirky "artistic" or "mcgyver" skill set required to changing the invoice / statement form layouts because we are dealing in grid based spreadsheets. True Artists, creatives, and perfectionists may view the layout changes as the biggest frustration, until they accept that as a trade-off for function, value, privacy, customization abilities, and fun.
These solutions are about function over form, and with expectation flexibility, there are many very functional solutions to be had that will solve the software needs of many small business people for life.
Please see bottom of page for more information about system differences, system benefits and limitations, and the pros and cons of launching this type of cloud spreadsheet software template technology and educational system.
Folder w/ all Templates
view
BRICs Sales System 1
Invoices and Statements - (General Use)
Line Items have:
1) LI # 2) Description 3) Amount / LI total
BRICs Sales System 2
Invoices and Statements - (General Use)
Line Items have:
1) LI # 2) Qty 3) Description 4) Unit Price 5)LI total
BRICs Sales System 2T
Invoices and Statements - (General Use)
Line Items have:
1) LI # 2) Qty 3) Description 4) Unit Price 5) Tax Rate 6) ext amount 7) Tax Amount 8) LI total
BRICs Sales System 3
Invoices and Statements - (Small Utility Co Billing)
Line Items have:
1) LI # 2) Code 3) Description 4) Flat Rate 5) LI totall
BRICs Sales System 4
Invoices and Statements - (Contractor Billing)
Line Items have:
1) LI # 2) Description 3) Flat Rate 4) Hours 5) Hourly Rate 6) Material 7) Mat Tax Rate 8) Ext Amount 9) Tax Amount
Comments
Comments
Google Script Code Updates for Existing Users must be made by the User (no auto updates)
We have no access to file templates once they are copied. Users who see functionality they want in newer templates or other templates will need to manually copy and paste that code into their systems as desired. That can be a remarkably simple process that can happen in 2 to 4 minutes, including script testing.
Alternatively they can make copies of new templates and transfer their data from their existing template to the new template. This is only a decent idea if you ahven't made a lot of customizations to your own template. You would need to make those again if you still wanted them. For simple systems that got little to no user customization upgrading data for one to another might only be a 3 to 5 minute process.
Duplicate Google Script Code in Templates above is a problem to keep up w/ for us, the Publisher
As a publisher, with this type of setup, if we want to change the scripting, we need to make changes in each file template. This could have been addressed with Code Libraries but we chose not to implement those, after initially starting with them. For corporations with full time IT staff, the idea of libraries makes a lot of sense but for sole proprietors and individuals, avoiding them for simplicity, as much as possible, is ideal.
Strategies for Maintaining Scripting Code as it Changes
For a few templates, we'd need to go into each file and make those changes. With three that is annoying but could be managed, but there will likely be many more coming soon.
With dozens or hundreds, it only becomes viable if there is a product specialist for each file or with a few files for their responsibility.
Alternatively, one idea is to maintain the most progressive version of scripts in a single file and simply point to that as the resource for the most advanced scripts.
Alternatively it may actually be better simply to leave them all of these alone and make code upgrades in separate resource they'd have to cut and paste from
This is the inherent draw back with stand alone software that is not connected to publishers for upgrades and this is one reason it's not been done at scale before
Code Library Options that we chose not to implement...
The individual Code Library File Alternative was avoided - One way around that was to have created a code library file that went along with the software template as a separate file. The problem there is related to initial file configuration and setup complexity. That dramatically increases initial stress for novice and intermediate users. Ir also can get more challenging over time if you then have other libraries you are using. We started with the separate library file setup and we were not comfortable with that after having rolled these out in some beta testing.
The group Code Library File Alternative was avoided - The even larger and worse way around it with a library file would have been to have created that separate library file and shared it from our drive.
With that, if our file went down or went corrupt, everyone's files would go down. Not an option. The Cloud Strike Crash was an example of that.
There may or may not be privacy issues. I believe if a user can attach to a third party library as I'm describing, they can view the entire script / code project to confirm there's no code that is storing submitted data, but I would need to re-confirm that. If they don't have access to view that file in entirety to confirm what capabilities it has, then it's a privacy issue as well.
Page updated
Report abuse