all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||||||||
|
|
|
Blue
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Notes:
|
|
We have a thing called a "transition invoice" and it allows for special actions to be taken. To make a long story short, we originally added the new invoice type as just another invoice type (a way to categorize the invoices). We later found out that they, the transitional invoices, could not and should not be included in sales tax reports, revenue sales, cost of goods sold, and receivables. Technically, they are in progress or promised until they are marked as complete. The problem comes in that we have a physical thing that is happening (meaning items or inventory are being applied or held or promised) but we need to have these items play in a special "quasi" state or status until they are fully done. The weird and hard thing to track is that different pieces happen and come in to play at different times. However, a single invoice only has so many dates and key checkpoints. Because it happens at different times, time itself almost becomes the enemy (hard to track and specifically say what is what). However, on the flipside, time is what we are trying to track (what is the story?). The goal is how does this object move over and through time. Anyways, we may need to add some corp-wide settings on how to deal with transitional invoices. This could be checkboxes that say include as part of XYZ (some item or report) or don't include with normal PDQ (some other item or report). This is a key component of the balance sheet as well. Because it is, we may need some specific corp-wide settings on how we let them play and what are they allowed to do. After a phone call with Steve, here are a few more pieces of the puzzle. The balance sheet will need to record inventory, cost of goods, pre-payments, sales tax that will come in to play, and revenue from the sale once it becomes real. Steve and I also talked about having either a sub location or a sub invoice type (dynamic) that could help track different states and status. These would be pre-set and then assigned to invoices with small date windows for when things were at different states and status. As a mater of fact, the current transitional invoice "magic window" is able to be setup as a one to many to a single invoice. However, the dynamic category (either sub invoice type or sub location) is not in place. We would also need a way to make sure that no gaps occurred between the magic windows. It could get pretty deep but it could also add a bunch of functionality. Who knows, maybe we need both a sub invoice type and a sub location. Along with the comments about a dynamic sub invoice type and a sub location, sometimes users want to record a special window (date range) and a status and sometimes they just want to add a category to an invoice (no sub window or dates). We may need to add a thing called an invoice category. This would be a single assignment to a single invoice. This would be optional and would only be set to one specific thing (1-to1 relationship). We also talked about being able to kill (remove or delete) a transitional state or status. Currently, the code requires at least two dates (ideally three). the first required date is when the magic window gets started. The other required date is when the invoice closes. Ideally, the three dates would be start window, end window (one day prior to the real book or finish date), and the real finish date. Another known issue is dealing with the advanced invoice line items search. Currently, there is no way to limit by all invoices except for transitional invoices. It is a simple switch between all invoices or just a specific invoice type. This problem may be increased if we start adding tons of sub windows and sub categories. One of the key elements is the date range that is being searched. If no dates are included, just do the search as is. If a date is included and it is in the past, we need to virtually be able to go back in time and say what is what... If the date is for the current date, we just need to pull things as they are. The tricky piece is being able to virtually be able to tell are we trying to go back in time or are we just looking at the current state and status of items. Anyways, just some notes from our phone conversation on 8/29/12. |