Meeting with Cory and Eric. We started out with a question that Cory had from an email from a client. Eric and Cory were following logic for wholesale carts and a bypass switch and logic for not sending wholesale data to the state compliance tracking system. Cory and Eric spent close to 45 minutes looking around, checking code, following variables, and comparing old and new code. Randomly enough, some of the changes were done by Eric, some by Wayne, and some by Alan. Also, to add to it, we couldn't tell if it was a user error or really a small bug in the code. We went over and talked a bout a number of possible scenarios, including users changing things after the fact.

We then switched over and went over some of the sales tax aggregate code and processes. Cory had a small list of questions and she and Eric were going through things and discussing options, flow, logic, and processes. It got pretty deep. Tons of moving pieces.

These were some of my observations while they were going over things:

- Possible problems with hidden database triggers. Hard to check the code you can't see. We talked about pros and cons for triggers and clean-up routines.

- Code and version control - branches - Possible problems with certain code branches overwriting other branches - who has the last cookie?

- Maybe make our own visual code based triggers, clean-up routines, and scheduled processes. We may even want to record histories of what happens, where, and when. If certain things need to go through a full process. Can we monitor and track it through the different pieces, phases, states, and statuses.

- One nice thing about a database trigger is watches for any change to the database record regardless of where it comes from. If we do our own, more visual and controllable version, we need to make sure and cover the different scenarios such as add, edit, delete, void, bulk updates, API sockets, backend updates (direct database activity), etc. Just make sure we cover all of the possible tweaks and scenarios.

- There seems to be a need for ways of doing a manual override and or a manual update. It may need to be flagged if updated manually or modified in any way, but sometimes the automated processes fail or have issues.

- Real-time vs a delayed type actions - Is the data being pulled in real-time or is there daily or nightly process that aggregates or cleans something up. Some outside schedule or routine. We have a lot of future aggregates that we want to build out for our fracture project. We may need ways of flagging and tagging the data and tracking it through phases and activity paths help us know where things are and what processes that they have gone through. Flags and tags (a flag and date or a checkbox and a date or phase and a date) are huge. they really help us track what is going on and what has already gone on. If the data is correct, let it pass. If not, correct it and then flag it. Once it is good, let it pass. The history part of it is important for what happened, when, how, and by whom. Basically, a roll call - where are you? What is your status? Where have you been? Who were you with? When did you finish? etc., etc.

At the end of the meeting, cory and I briefly went over some budgeting and funding values.