Light talks about big data and fully tracking all sales clear out to the state, county, and city level. It is amazing how much the word "tax" or "taxes" play into the mix. Lots and lots of changes.

What if we built the application to help record the sales tax information so that it could be world wide. This would have to be on a per transaction basis. We already do this on stock/units and stamp the current tax rates, taxes, and customer location per stock/unit purchase. We also have some built-in functionality where an invoice could be sold from one location and then flipped to a different location and thus changing the full sales tax pieces.

We also talked about some of the underground and black market pieces that will come from some of these choices and decisions. Huge requirements usually drive certain people to a more hidden and/or underground market. Kinda interesting.

This whole conversation is part of what is going on. We at least need to know and acknowledge that some of these changes are going on.

Eric popped in and we switched to talking about loyalty points. One of his main questions was, are we using a line item to lower the total of the cart (redemption points) or are we using some kind of special payment type for loyalty points? Great questions. Eric came back in later and we spent some time talking about line items vs special payment types. What is a loyalty point? Is it a special account that doesn't really play into the financials or does it? Are the redemption of loyalty points a virtual discount or does it affect an actual liability that is recorded somewhere on the financials? Eric is using cart favorite buttons to help setup some of these systems.

We are seeing that most of the people want a standard value for the loyalty point. Some people have wanted variable point values. One of Eric's main question is dealing with the difference between how to accumulate and redeem the loyalty points. Is it a line item or is it a special account or special payment type. We are seeing special payment types coming more into the mix. Are loyalty points a real liability or are they a phantom liability? What happens if the loyalty points are variable? Does that mean that the phantom costs of that liability can change?

We also talked about special tracking accounts... Are these real, like a gift card or are they virtual or phantom like a loyalty point? They could potentially play slightly different. One of the challenged are wanting loyalty points having variable values based on time (dates and times) and/or what is going on in the cart (certain sales, promotions, or campaigns). The variable changing loyalty points could be a problem in tracking what the phantom liability is.

Maybe we could track all loyalty points and gift card stuff in the special tracking accounts. We then allow for the main account types to be real and/or phantom based. That way we could pull a real asset, liability, and/or equity account or a simulated (fake and/or phantom) asset, liability, or equity account. We really need to track all of the in and out values. Then we need to record what happens as those items are used. There may be a point value and a dollar value. They may even be different based on time. The value of time is going to be playing more into the mix on how these points are going to be used. Interesting, the loyalty points are becoming a form of currency and we need to figure out how to apply that. It goes beyond a simple discount and gets into an additional payment type. In a way, the question is what is the value of the loyalty points? Is it a discount or a payment type? We are seeing that people want to have both and even mix things to make it feel like the deal is even better.

We may need some tools that allow them to set things up and then the system will play by the rules that they setup. We need ways to add/edit loyalty points through a virtual interface. Everything needs to be tracked on the special tracking accounts. We can add (manual or automated) and we could subtract from the virtual account through both manual and automated action.

What if we allowed the users to setup the rules if they are using line items to add and subtract on an invoice or if they are using special payment types and how that affects things. Basically, we build the tools that are very generic and flexible and then help the users setup their own goals, needs, rules, and usage options.

After that, we jumped in and worked with both Steve and Dustin on merging in their code branches.