all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||
|
|
|
Blue
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Notes:
|
|
Bryan joined the GoToMeeting session. He and Steve were talking about some custom payment solution options and flow. The deeper we get into some of these payment things, the more, we tend to have left overs - meaning balance sheet stuff (liabilities and non-revenue stuff). Basically, I owe you, you owe me, and we owe x vendor such and such. It gets out into balance sheet entries. Steve is seeing 3 different steps or types for different payment types... 1. Basic. We add a new payment type to the system and we treat it just like a normal payment type. We can then check for an authorization number and let it flow through just like normal. 2. If they take it further... they end up saying, It sure would be nice if we could load the payment card at the point of transaction. This gets a little bit deeper. All of the sudden, we are taking and starting to account for additional monies coming into the system and/or being owed to x vendor. If we just have a 3rd party solution do the loading, we provide a page to let them do it. We don't really track anything other than making a note on the invoice (just a note - no physical tracking of the funds). If we have to account for things, we need to know what to do. 3. If they want us to fully track things (load, unload, and balance remaining) - we need to track the entire thing. This goes clear out to liabilities, balance sheet stuff, how to deposit things, how to payout things, and who potentially owes what to who. This is a mini virtual bank account per client and/or per card. It gets deeper and deeper and we need to account for things. If it gets this deep, we really need to automate things so that our users don't have to do the old Texas 2-step or even the Texas 3-step (multi steps). We are seeing more and more, a need for special payment types. This could also flow in and out just like loyalty points, in-store credit, gift cards, etc. We need the special tracking accounts that Eric and Brandon were working on. Some of our clients almost want a full on ATM (automatic teller machine) vs just a simple card payment type solution. We are seeing lots of feature creep and things being pushed further and further. We need to define how far we are going and/or what kind of mash-up type system we are creating. As a side note, we are also seeing that we could use flex grid (current simple solution), but that has limits. Basically, flex grid doesn't go clear out to the balance sheet. We are starting to get out past the limitations of the flex grid. Steve was mentioning that if we allow other people to make tons of manual entries... it could be a liability on our side, meaning the full sub tracking of these special accounts does not track all the way to the balance sheet. We need to make sure that we can account for what is going on. Steve was talking about doing some sketches and mapping things out... what are the physical happenings? How do we track all of the key pieces? How do we then show the correct processes and make sure that everything gets accounted for? What else is going on and/or possible scenarios that could play out? We may need to create a new special line item that could be tracked to the balance sheet. This is similar to how we can map part number "Other" or part number "Verbage" and point them to the black hole (aka the balance sheet). The special line items have the option of being pointed to normal revenue, COGS, expenses, or the black hole. As a side note to this... We may need to change the verbage from black hole to the balance sheet. It still needs some work. What about part number "Collected"? It currently skips the P&L and just sits on the side - basically, monies collected for an outside party. Maybe something like that would work. We also talked about going clear out to the whiteboard level and really making a true plan. We are currently just adding duct tape on top of duct tape. Eventually, we want a real live solution that can play out to the full level. Other questions... If it is just recorded on the flex grid, how do you know that is real and has been recorded? The only way to really check that is a report. Another question deals with how much training and education is needed to teach the next client to know how to do this? This is a side note question, who ends up paying for this brainstorming time? I know that Adilas is paying for my time, but what about Bryan's time or any other developer who is playing along. Currently, we don't even have a paying client on the line that is wanting this but it still takes time to plan things out. We will have to figure this out. |