all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||
|
|
|
Yellow
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Uploaded Media/Content & Other Files
(3)
|
||||
| Media Name | File Type | Date | Description | |
| a_bigger_vision_of_watcher_and_feeders.jpg | Image/JPEG | 6/8/2017 |
After we had the first discussion about the concept of watchers and feeders... We did a little bit of an expanded discussion about what and where these watchers and feeders and standalone declarations could take us. We have been toying with this ideas since 2010. It is fun to see if starting to come into play. The graphic has some of the main system categories listed out. They are things like: revenue, cost of goods sold, gross profit, expenses, net profit, assets, liabilities, and equity. What if we could hold, store, and calculate all of those values on a daily basis. Think of calculations and logic per day, per location, and per main system category. That would be awesome. We talked about how all of this could feed into a virtual 3D calendar. We could then take that data and either show it in reports or even stream it through a video that showed the activity. We could show growth, usage, problems, etc. As needed, we could show possible problems and then allows the person to see where things ran off the tracks... Imagine a report or video that showed the big picture events. If you had a question, you could stop the show and do a drill-down to real details. Once things got fixed... you could resume as needed. Currently, we do run a P&L (profit and loss or income statement) and a balance sheet report. Those reports have to visit 200+ tables and do a virtual roll call on those transactions and tables. What if we could pull all of the data from these internal elements of time, watchers, feeders, and standalone declarations. That would be so fast and awesome. The standalone declarations would be manual entries that were recorded in the per day, per location, and per category section. Basically, you would have automatic ones (system-maintained) and manual ones (user-maintained) declarations. When you pull it all together, you get the overall picture of what is going on. That would be super cool. If a user-maintained entry or standalone declaration was created, you could provide notes on why or what happened to make that entry. That piece would be then in a standalone level or unsupported by auto fed data and transactions. It is still very important, but it would be flagged and visible that it was a standalone entry. Anyways, these are just some ideas that have been cooking and simmering since mid to late 2010. It is super fun to see them starting to come back out again. Good stuff. |
|
| the_concept_of_a_watcher_and_feeder.jpg | Image/JPEG | 6/8/2017 |
This is a small graphic of how the watchers and feeders could work for taxes. We originally talked about the invoices holding multiple new buckets. We then moved into a daily collection of what we caught (real transaction details), what we show as revenue (the calculations are based off of), what it should be (outside math based off of totals vs. line item details), and then the differences (the adjustments and virtual dust pan or catch-all bucket). We also talked about ways of doing things and running things along the analogy of water, slush, snow, and ice. Helping things to solidify and stabilize over time. If needs be, we could even lock things down or use what we are calling the "ice-down date". We talked about the number of transactions that we are catching and how that would relate to the number of sums or daily watchers and feeder records we would be making. There is no comparison, and we gain so much by being able to get things out to that level. |
|
| talking_with_steve_and_shari_on_tax_calcs.jpg | Image/JPEG | 6/8/2017 |
This is a screen shot of a possible disconnect between tax calcs based on line items vs. grand totals. The graphic was saying let's make everything good to go based off of invoice line items. We hold all of the details on the line items. We then show what we collected. We then show what needs to be adjusted on totals vs. the line item details. We were running scenarios and talking about the need to run the taxes bases off of the line items. We were talking about labor, non taxable items, full taxable items, with tax included, certain things that get taxed differently, etc. |
|
|
Notes:
|
|
On the morning GoToMeeting with Steve and Shari O. We started out the day looking at the sales tax differences. We talked about a virtual dust pan for catching any rounding errors on tax calcs. Our options might be: - We extend the original percentage spot - where the percentage is held (on the locations). We could go with say a 5 decimal level of accuracy. - We could use a small bucket or dust pan for tax calcs. This could be called the rounding error for the tax calcs. - We could rework the math on the tax calc function (this is the main function that is used over and over again to calc the taxes). Check for possible bad rounding errors. - We could show a flag on the invoice line items reports where a tax is off (say a color or an icon or something - say red...) - We could show the full extended math on the edit invoice line items page... this could include the extended price * the tax % - no rounding - and then the rounded value. - The biggest complaints are on the grand totals per tax category... This is just a sum of the details. We can't really adjust that number... it is just math. We can however get tighter on the individual sums or individual line items. - Drew some graphics on possible disconnects between calculating the taxes based on line items vs. invoice totals. We were talking about the disconnects on line items vs. grand totals. We came up with a number of possible options... - What if we calculated and stored the line item calculations at 5 decimals. We hold what it really is... - On the main invoices - we could add a number of new buckets to the main invoices... the only problem here is how much of a load this is... The ideas is: new buckets like: sub total, taxable total, tax total, all taxes (state, county, city, other 1-5, out of area), and a new one to help with tax calc diffs (rounding error or catch all bucket). - What if we ran things in a paired type solution where we have a total per tax section and the total taxes collected for that total. That way we could show a total and the calculation based off of that. - We will want to run each major report off of these new totals. *** new idea - this could be super cool *** what if... we did this summing and virtual bucket stuff on a daily basis... that would save tons of storage space. This is what we are hoping to call watchers, feeders, and even standalone declarations. We have been looking at things like this clear since 2010. - As a side note, we could propose a solution that taxed and calculated out to 5 decimals. Then at the very very end we could round it to real numbers. Steve would really like to take this proposal back to the state sales office to show them the problems and possible solution options. - We spent quite a bit of time talking about watchers, feeders, and standalone declarations. We made a number of small drawings and had a great meeting dealing with the vision of these concepts. See attached for some of the drawings. We talked about the 3D calendar and how things could play in if we caught things per day, per location, and per category (these are revenue, cost of goods sold, expenses, assets, liabilities, and equity). We also talked about possible options and how that could even be fed into a virtual video or play-by-play on the full financials of the company and how that plays out over time. Pretty cool futuristic ideas and concepts. - There is more information on these graphics in the media/content section. Additional explanations on watchers, feeders, standalone declarations, and 3D calendars. See attached and the descriptions for more details. |