We had a few of the guys on the morning meeting this morning. We had Steve, Dustin, Wayne, and Alan. We started out and Steve and Dustin were going over some of their new cultivation code. Dustin is already breaking up the page and adding in some AJAX (asynchronous or non-linear database calls) stuff. This will really speed up that page and alter the flow. Steve and Dustin were sharing some code back and forth and getting certain pages updated.

After that, Wayne had a few questions about some legacy look and feel pieces. Most of it was how we managed the corporation id number switches and why we did what we did. Some of the older code would change look and feel based on who was logged in, whether or not they were logged in, and what corporation was asking for what page. We are looking to get rid of some of that older code and make it more standard.

Alan had some updates on his merchant processing stuff. He is heading into the refund and refunding realm. I tried to let him know about a few of the pit falls and crazy scenarios that could happen out there. As a take away, we ended up talking about time lines, cause and effect, life cycles, and digital storytelling (tracking what physically happens and how we track that digitally). I really wanted Alan to automate what he can easily and then leave some of the crazy things to human intervention (manual transactions and manual processes). We don't want to speed up the flow of monies going out too much. That could be abused, misused, etc. Lots of drawing and small models and scenarios.

The next topic of the morning was the invoice due date project, that Russell and I started back in December of 2017. Alan and I talked ideas, concepts, theory, and how all of those pieces tie in. This project would really help out our own internal people that have to collect monies and do accounts receivables stuff. The overarching goal is be able to set an invoice due date and then monitor aging according to that date. Once an invoice gets to a certain date, we could virtually let a client know (say through a header feed or something like that) some kind of action was needed (payment needed). If we use the warning system correctly, we could also have standards for all kinds of processes and/or procedures. This includes when we turn systems off, for not paying, or warn when invoices are certain days old, etc. Basically a notification process based on invoice aging and monies due. That project has had a lot of work done on it, but it currently is sitting in code branches in the code repository (aka code sitting on the shelf).

Steve and I looked into an AJAX feeder that Steve is using on one of his pages. The page was working one way but not another. After some testing, we found that the way it wasn't working was because of a miss spelling. No error handling was being done and the error was going undetected. Once we fixed the spelling error, it allowed us to get at the new data we were trying to harness and get to. Crazy how sometimes it could be as simple as a missing letter or a 1 switched with a 0 and things may or may not work. Lots of detail work.