On the morning meeting with Steve. We did some light talks about a concept of "flow state" or "flow status". This concept came from an audio book that a buddy and I were listening to on a road trip over the weekend. I haven't looked up the author, but I believe that the book was titled "The Rise of Superman" dealing with how action sport athletes use this "flow" or "flow state" to do amazing things that some people consider impossible. The book was covering how it works, what they know about it, pros and cons to flow, and what kind of triggers that that these athletes use to enter that flow state. Anyways, it, the audio book, had some interesting concepts and I would love to use some of those things in the adilas world and adilas environment.

Josh joined the meeting and gave us a small report. We should be hearing more from him in the next couple of days. Eric joined and was looking for an update. He was also volunteering if anything needed to be done on different fronts. He just got back from a trip, so he is swamped, but willing to help. Wayne joined and gave us all a small report on the AWS transition stuff. He and I were talking about some of the changes that he is making and where things are going. He showed me some of his custom tags dealing with look and feel and corporation logos and settings. Making progress.

As a fun side note, we can't do all of this stuff on our own. We need a team of highly trained professionals, each in his/her own way. That is awesome.

While the rest of the meeting was going on, I was working on my local environment and getting new programs installed and configured.

Working on my local coding environment. Installing and configuring new code editing programs. While programs were installing and uninstalling, I was doing some reading on adilas core concepts, out in the developers notebook, searching between 1/1/13 and 21/31/13. Lots of work on core concepts during that time period.

https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=core%20concept

Got on a meeting with Bryan. We merged in two code branches and pushed up some files to live servers. One was some custom parts/items report stuff. The other one was dealing with new code for Full Circle (marketing and text messaging stuff). Full Circle has an active window right within the system where the person could be logged into both systems at the same time. Kind of a hybrid type scenario.

More research on core concepts. We need good code to help support our cause. However, the real value lies in the underlying concepts. I'd really like to keep pushing on that part of the puzzle. Our code (actually what the system does) could be one of thousands of possible options. The underlying core concepts are the stable foundation on which to build on or build off of. Good stuff.

Steve, Dustin, Wayne, and I were on the morning meeting. Wayne was working with the guys on some of the changes out in the AWS land stuff. Once I came on this morning, Steve and Dustin jumped off to work on a separate project. Wayne and I talked about some logo and image changes and then some update queries. After that, I did a local database back-up and got ready to uninstall and reinstall some database servers.

Bryan, Molly, and Eric joined the meeting. They were talking a lot about 3rd party solutions and who pays for what. We also talked about some needs for sub inventory. We need API sockets, documentation, more integration models, etc. We even started talking about 3rd party solutions and diverse plug-ins and how to best help that model out. Not all solutions are worthy of spending the time to fully integrate. We want to enjoy working with these other companies.

Molly is looking to expand the searchability and export options for sub inventory. They have done some foot work and worked on a custom export for sub inventory. They would love to bring some of that more into the core process. Currently, a lot of the filtering is done from the parent level down to the subs. We are seeing a need for being able to filter from the subs up to the parents (reverse filtering). We briefly talked about adilas and that we will be doing a new adilas funded round on sub inventory. Currently, we have done 3 full rounds on the sub inventory section. We will be bringing in Alan Williams to help with this project. Before we jump, we are looking for a proposal and/or a plan for going forward.

The conversation started going towards... what is coming up next both with adilas and in general. The landscape keeps changing. What are the priority on the different projects that are coming down the pipeline? Molly was expressing some of her priorities and where the needs are.

Pagination vs grouping - Going back to sub inventory... We need exports and searches on parts, items, sub inventory, parent attributes, sub attributes, etc. To sum it up, we need better reporting on sub inventory and everything that it touches.

Towards the end of the meeting, Steve and Dustin were working on some custom reports and I was working on new install stuff for my local environment.

Eric and I met and talked about exports to MS Excel. We talked about traditional methods and doing custom exports and/or going more fully to the JavaScript Snow Owl data tables (prebuilt exports to Excel). I showed Eric a sample page that deals with showing a snow owl data table with the built-in exports. He will modify his code based on what that page does. We also talked briefly about outside API socket documentation and who takes care of that.

On a side note, both of us were talking about having too many projects on the fire at the same time. We all lose so much traction and end up spinning our wheels in the transition of switching between projects. It helps to have a couple projects and then to focus on those, get them done, and then go open up a new drawer or project.

Working on installing new software on my local environment. Running tons of database updates and scripts to get my copy of code and database stuff up to par.

Bryan and I worked on some new logic for some sub inventory searches and exports. Some of it was some training on complex data sets (arrays of structures, and arrays, with sub arrays, etc.).

Working with Dustin and Steve on some debugging on their cultivation stuff. The bug we ended up finding, after tons of searching, was dealing with text comparisons vs id and settings comparisons. It got pretty deep. 

After Dustin and I got done debugging some comparisons between settings and sub inventory attributes, Wayne and Eric popped into the meeting. Wayne was just checking in and letting Steve know that more progress was being made in the AWS land stuff. Eric then had some questions about a 3rd party API socket project that he was working on for a company called Spring Big.

Basically, if a company turned on this 3rd party solution, it would share and pass both customer data and invoice data over to Spring Big. I'm not sure of all of the details, but it seems that they did some marketing and offered some coupons and/or campaign type offerings (don't quote me on that - just going by impression). Anyways, Eric and I were looking into new custom code and debugging some of the API calls and internal methods. He has a pretty deep wrapper function that have a number of other sub routines and sub API socket calls. We spent over an hour looking and testing things. We found our bug and fixed the issue. Towards the end of our session, he was checking API socket calls, pushing data, updating data, and finalizing transactions. Great progress.

At the end of the work session, Eric left and Steve and I started working on some of his projects. We spent about an hour looking into his (Steve's) and Dustin's cultivation code and the phases tab (changing plant phases section or sub section of the main cultivation homepage). We did some debugging, added some page and query filters, and commented out some older code. We tested both locally and push things up live. We have a client that is pushing the limits of what we can get the system to do without timing out. We also spent some time talking about ways of changing the existing page structure, carving the code and output into smaller pieces, and using more AJAX (asynchronous JavaScript and XML) type technologies for breaking pages into smaller chunks of data. Lots of potential there.

Recording notes, paying bills, and emails

Working with Bryan. We did some checking on some custom ecommerce filtering (by sub inventory attributes). We actually had to log onto the server and run raw database queries to check for certain records.

There were quite a few people on the morning meeting this morning. We had Steve, Dustin, Wayne, Shari O., and myself. We started out and Wayne wanted to get a standard spot to report and handle issues and bugs for the transition to the AWS stuff. We setup an element of time and will be using the sub comments and notes to record any issues and/or bugs.

After that, Steve and Dustin wanted to go over the cannabis cultivation homepage and figure out where we could speed things up. See attached for some notes. The main take away from the meeting was user designed, single pagers, let users control the flow of data based on clicks and events, and use AJAX (asynchronous JavaScript and XML) type interfaces. The conversation turned lightly to aggerated data (pre-summed up data) vs transactional data (individual details). We would really love to keep heading more and more in this direction.

Shari O. was talking about some communication issues between our clients and the reps that support them. We had an issue last night when we had to turn a client's system off. We had contacted the client and they were over 3 months behind on monthly payments. We shut them off (the companies system) and then crap hit the fan. The client was open 24 hours a day. Anyways, we had a rep that got on the phone and was ripping our tech support people a new one. We had some talks about how we need to use the system to be the bad guy. We have a project planned that will show prompts in the page headers and will let them know that they will be shut off if they get past a certain date. We need to get back to that. If we could get this project done, it would save a lot of headaches.

Shari O. was talking about some team work and playing as a team. We have some great people who help and participate and some that don't do much. We have a spectrum of different people all around.

This is both funny and sad, but sometimes we really feel like the little red hen - who wants bread? Me, pick me. Ok, who wants to help me plant it? Not me, not me. Ok, who wants to help me harvest this stuff? Not me, not me. Ok, who wants to help me with (fill in the blank)? Not me, not me. Ok, I guess that I'll just do it my self. Suddenly, we get the bread done, and everybody wants it. There is some truth to that.

Steve was expressing some concerns that he is getting behind on his email stuff. We had some light talks about what needs to happen there and how best to structure our team. At a certain point, you almost give up and/or can't keep up. The mountain keeps growing and doesn't seem to stop.

Back on team building stuff... we are trying to help and train our guys and gals to work as independently as possible. There are constant needs that just keep coming. It gets pretty crazy. Back on the email stuff, maybe we need to use more of a standard like "support@adilas.biz" or "info@adilas.biz" and then let it get filtered out before it hits all of us. Steve really wants us to use technology to play this game. More automation and more ideas and options. Lots of tag team stuff. We are also learning along the way. Lots of new lessons being learned and hopefully applied.

Steve was talking about dependables and who is playing with what and who is doing what. We have a very independent model. That is awesome but does have some challenges as well. Steve would like his sales focus to be more on the white label type arena.

Alan joined the meeting and gave us an update with USAePay and there EMV chip reading and chip processing. We may end up having to integrate with FirstData as a merchant processing account (more gateways). We currently offer some chip reading options, but it still kinda random and small ball of strings. There is a growing need on the merchant processing and gateway stuff (credit card processing and chip reading technology stuff). This is way out there... but maybe at some point adilas will be their own merchant processing gateway (some sort of internal solution). Alan volunteered for this project (just kidding).

Towards the end of the session, Eric jumped on and needed some help with some queries of queries, complex data, and getting some data tables setup for his custom reports. We also scheduled some other time next week to work on sub inventory and API socket documentation stuff.

Paying bills, emails, and reviewing some code standards on W3Schools - how to do certain tasks.

Questions about assigning sub details per items. We considered parent attributes, flex grid, or dynamic web/ecommerce part or item options. We spent some time and talked more about the web part options. This may be the best solution for what he is trying to do. We went over permissions, some part category settings, and how to populate the data.

Eric was also on the meeting and had some questions. His queries are dealing with flex grid queries and some cross corp flex grid queries. All of these guys are really pushing the limits.

Light testing on the AWS stuff. Ran into problems with the main login.

Did some research and worked on a small tutorial dealing with CSS, JavaScript, and a photo slide show. That was kinda fun.

Working with Drea and Dustin on a small bug with the cultivation homepage. We had to log into the remote server and run some check-up queries. All three of us were working together and changing who was running with the presentation. Dustin had his code editor open, I was logged into the remote server, and Drea was logged in as a user in the corp that was having issues. Good team work. We got it fix and did some light checking. 

Another fun day on the adilas farm... We had Steve, Dustin, Eric, Wayne, and I on the morning meeting. Dustin was reporting about some of his new AJAX stuff on his cultivation pages. He is trying to break that page and flow process into smaller bite size pieces. Steve had a few questions on some of his bulk page clean-up tools (bulk close sub inventory packages that had a 0 quantity and were set to show - disabled). We looked at some queries and made a few minor tweaks. He is doing great. Eric had a couple of questions. Steve had some 3rd party API socket settings stuff for Eric and I. There is also a Lots of moving pieces out there. Steve also let us know about a possible project that would be funded by an outside party that deals with an API socket connection between Woo commerce, WordPress, and adilas. Wayne was checking on our AWS transition testing and making some tweaks. Lots of good stuff.

As a side note, there were some small discussions about security and liability of our clients using the adilas API sockets. We also talked about other outside parties using the same API sockets. We have to maintain who authorized what access and who virtually opened the data window/door. I told Steve that I would like to keep the API sockets open and increase the options to use them. He was worried about both security and liablility levels and wanted to know how some of that stuff works and/or is setup. We covered the basics and even went over a few scenarios. We had a brief, but good talk on the subject. As a follow up, we will be doing a mix between a full 3rd party solution and a custom black box for a single client and their mini 3rd party provider (kind of a hybrid of sorts - just for a single corporation). The important thing is, we will be tracking all of their data requests via a custom and special id number (this will help with the audit trail).

Paying bills, recording expenses, and light email research. We are wanting to allow corporations and companies to be more self-reliant with their own custom adilas.biz email accounts. Shari O. and I will be meeting later today to discuss some options.

See the attached email screen shot. This is for a spelling error inside the system. It seems like a quick thing to fix, but it has some teeth. The term verbage/info is used as a system reserved part or item. It would need to be changed in multiple places including tons of back database pieces. It could be a couple of hours or more to make this change.

Shari O. and I met up to go over some email options. We currently have about 3 main email addresses that our clients use to send invoices, quotes, statements, etc. As such, if anyone replies to those emails, they get sent back to my inbox (email mappings). Our goal is to create a number of custom email addresses and then allow the customers, clients, and corporations to have their own email addresses. This should save quite a bit of time and should help the customers have better business transactions because I won't be in the middle (as a pass through account). Anyways, that is the goal.

We went over some proposed changes inside of adilas and how those values will affect the email settings. We then spent most of the time over in the SmarterMail application going over their settings and options for forwarding emails. We made a good plan and will go from there. Mrs. Shari O. helps Steve and I pick up numerous pieces and does a knockout job. One of the giants of the adilas teams (awesome job).

Eric and I met up to talk about a couple of things. Pretty casual and we finished up a little bit early. Back on the new email fields and settings.

Worked on the admin corp-wide settings to help open things up for custom adilas.biz email addresses. Shari O. has instructions on what is needed there to help set those values up. I was only able to get the admin corp-wide settings page to update. The other page (AFB custom email settings) in question needs some database work before it will be able to updated. Sent a note off to Shari O. with an update.

Got a call from Bryan and he wanted to meet for a bit. He got an email from a gun club that uses adilas to file member waivers, sign people in/out, and run their gun club. They are interested in showing community events (calendar and elements of time) to the public on their website. They would also like to do some ecommerce and do some online booking and reservations and being able to sign-up for classes through their website. Great stuff and very possible. Some of those things are already done and some just need a light tweak and we could make it work. Kind of a mix between ecommerce, elements of time, invoicing, quotes, customers, files (media/content), and making it all flow through correctly. Sounds fun.

At the end of the session, I was working on a few small changes to a sales flyer for Pat, Shari O., and Drea. The originals are held here: https://data0.adilas.biz/top_secret/adilas_banners.cfm

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.

Shannon wasn't able to meet today. So, I did some more research on the QTI stuff (transition invoice stuff - QTI - between a quote, transition, and an invoice). Balance sheet research. Verified that some dates were changed as the process completes. Still need to figure out how that affects the numbers on the balance sheet. Getting closer.

Helped Bryan push some code live for a 3rd party API socket. Pretty easy change and uploaded file.

Dustin and Alan came on the meeting at different times. Mostly just to check in and report. I was back on the transitional invoice project and light tweak on the balance sheet dealing with the way we show the transitional invoices (QTI invoices). Towards the end of the meeting, Eric joined the meeting looking for Wayne.

Research and working on the transitional invoice project. Small tweak to the balance sheet and how things are handled. Trying to track down values. I got a call from Eric to ask about tax reports based on counties and zip codes. We talked about some options.

Gathering up some documentation for one of the original 3rd party solutions (back in 2014 ish). They are circling back around and getting some things going again. Small blast from the past.

Logged into the testing corporation on Wayne's AWS (amazon web services) cluster to do some testing. Recorded a number of errors and bugs on element of time # 1430 in the adilas corporation. This is where we are gathering all of the notes for Wayne.

More research and playing with the transitional invoices. I think I need to go deeper in some ways and lighter in other ways. Trying to follow all of the possible options. The tricky part is that the line items switch the dates to the last known date (actual book date or actual invoice date) at the end of the process. That helps us keep things straight, but it also creates a small gap and virtually changes what is really happening. I'm not jumping there yet, but I'm wondering about tracking individual dates based on the line items vs based on the main. This issue has more teeth than not, but may be worth looking into. The other thing that seems to be baring some teeth is the tax liability and when and how to make that show up. Anyways, just rambling.

Mostly just Steve and I on the meeting this morning. Dustin and Eric joined for a bit but today was mostly a work session for Steve and I. Normally, we have Wayne help with all of the data migration projects. He was out travelling today and won't be back in until Monday. Anyways, Steve and I had two new corporations to setup and populate with data from other existing corporations. I spent some time and updated a bulk parts/items copy tool and got Steve using that tool to migrate parts and items from one corporation to another. I then worked on a customer (patient/visitor) upload file that they provided and got it all prepped and ready to do a data migration for the customer records. I migrated close to 7,000 customers from a spreadsheet into two different corporations on the data 7 box. We had to do a little bit of custom stuff and all of the records had about 5 flex grid tie-in fields to go along with the normal records. Once again, mostly a work day today, so far. Time for some lunch.

Eric, Steve, and I were on the GoToMeeting session. Eric and I were working on adding in sub inventory to the getWebGeneralInventory API socket method. We first had to go through things and figure out where to put the new code.

Shannon joined the meeting but I was working with Eric on some sub inventory documentation. I had to cancel with Shannon and we'll reschedule for later. If she has time, she will keep plugging away on adilas user guide content.

Helped Bryan get a few new files merged in and uploaded. We had to fix a couple of merge conflicts, but that process went pretty smooth. We pushed up new files and Bryan did some testing.

Working on the new sub inventory options for the general web API sockets. Currently, the general web API sockets only have parent part number or item information. We are going to tweak it out and add some subs to help things go smoother for outside parties and outside developers. This will make the original calls and responses a little bit bigger, but it should cut down on the number of calls. That's the plan.

Working on a document that Alan needed for getting some new hardware for testing and integrating a new chip reader (merchant processing). After that, we worked on merging in a new code branch from Steve. He had just over 40 files that we merged in and pushed up.

Working with Eric on adding in sub inventory values to the general web API socket called "getWebGeneralInventory". Most of the work this morning was pulling the related info out of the database. At this point, it is all in clumps and/or groups (the data is there but doesn't look very human friendly yet). We will do more formatting and combining later today.

More work on adding sub inventory to the getWebGeneralInventory API socket.

Worked with Dustin to merge in 8 new files from his code branch. Lots of his code was dealing with breaking up a bigger page into smaller asynchronous data calls using AJAX and loader images. Great breakthroughs. Steve and Dustin spent some time testing and making notes on other things that could be sped up. They were excited about these new changes.

Worked on formatting complex data sets to include parent items, sub inventory (child items), and unlimited sub attributes. Most of this session was taking bulk or raw database data and making it presentable and structured so that outside developers may use it and/or follow along. Making progress.

Pretty quiet morning meeting. Dustin, Wayne, and Eric were on a different times. Mostly just checking in. Eric and I were working on finishing up the small project of adding sub inventory to the getWebGeneralInventory method (API socket). We got it working and I pushed the files live and let Eric know.

It may not sound like much, but it combines six different queries into a complex data object. The six different queries are: get the main or parent items, get the sub items (child items or packages), get the sub attribute names and titles, get all of the text based attribute values, get all of the date based attribute values, and get all of the numeric based attribute values. Then you have to loop over the different pieces (conditional nested loops) to construct and make the data reassemble in order to get a readable output. After all of that, you still have to convert it into JSON or XML (web readable formats for the adilas API sockets).

Paying bills, recording notes, and doing email.

Working on documentation for the getWebGeneralInventory API socket. Not that it is that fun to read, but here is the link to the documentation. https://data0.adilas.biz/top_secret/printable_web_api_documentation.cfm?id=234

Bryan Dayton called me and we jumped on a GoToMeeting. We looked into an error that was coming up with sub inventory buffers out in ecommerce. We found that a query was being called and then a sub query was renaming the main query and thus losing some of the original data. The data was still in the actual database, the memory variables were just being overwritten. We made some changes and pushed up some new code. We also did some debugging on a custom label job that Bryan was working on. The issue there was pretty simple and we had to switch from one id to another id and then the custom label was able to run. Small switch between parent and child id numbers.

Adding more documentation to the getWebGeneralInventory method as part of the general web API sockets.

2/26/21: Nixing this project as OK is getting metrc soon.

As of 5/26/2020: Need to assign a new developer.

AS of 3/10/20: Josh is adding more fields to the report after Drea met with client and they advised her of changes/additions.

As of 11/25/19: Report is pretty much finished. Will start testing live data with Drea's customer.

As of 10/7/19: Steve uploaded a bunch of files on all servers. Currently launched and in beta testing. Josh may need another week or so.

Busy Monday morning. We started out with Josh joining us and giving us a small report. He is working on some custom reports and making a few changes to the discount engine and the inventory engine projects. We setup a time to do some code review and sign-off for this coming Wednesday.

Alan gave us an update on automation of USAePay (merchant processing) and reoccurring billing stuff. He has a client wanting similar reoccurring billing options built out for another gateway called Converge and Converge Connect. Alan also gave us an update on the invoice due date project, using internal universe API sockets, refactoring sub inventory, taking corp-wide settings out to a server scope memory cache vs direct database pull every time. That should be a good time saver and be more efficient. He was also talking about some new getters and setters (ways of pushing and pulling the data in smaller direct pieces). Cool stuff and he seems to be making progress.

Dustin and Steve were talking about AJAX (asynchronous connections) and how some of the new changes have really sped things up with one-pager interfaces and loading graphics, and faster more direct database look-ups. Dustin was volunteering to add some of these asynchronous calls to other pages and reports. By way of definition, a normal synchronous (or in-line) call means that you go ask for some data and you wait until you get everything back. Think of one giant clump of data being returned. You then report back to the browser or user and show the page. An asynchronous call (or on-demand as needed) allows you to return basic information and structure very quickly (the user will see something on the page). It then uses asynchronous calls and connections and fills in data as it can and/or as it gets returned. This is great for data that may be a subset of the main data and/or you want a user to click or interact to see additional results. It is a way of breaking up the data and speeding up the loading and display time. Great stuff and Dustin is doing great on some of his sub projects.

After that, it was just Steve and I on the meeting. We talked about a number of different topics. We have been doing more testing out in the AWS (amazon web services) land and getting things ironed out there in AWS land. Wayne is doing great and making awesome progress. Steve and I setup some time for tomorrow to work on balance sheet related project. We are going to be diving in deep and looking at how certain values are being tracked. That small conversation brought up some other topics such as caching, efficiency, moving more towards aggerated (summed up data) type transactions, etc. We are seeing more needs for watchers, feeders, triggers, etc. We even talked briefly about the underlying goal of getting all of the data organized into a 3D calendar of sorts. Fun to bounce back to past ideas and concepts. Good stuff.

Eric called in and was out on the road. He had a couple of questions and gave us some updates on some custom 3rd party solutions and custom reports that he is working on. As an interesting side note, some of the comments between Eric and Steve had an interesting undertone. Nothing negative, but definitely complex and cross-corp oriented. They, both Steve and Eric, are working on custom consolidation reports, cross-corp reports, and even multi-corp syncing. The deeper we get, certain clients are wanting to standardize data across platforms, across systems, and even across servers. It is getting more complex and we are seeing needs where we may have a master corporation and then being able to cascade certain data from a master corporation setup to an unlimited number of sub or slave type corporations. We are seeing both data and reporting needs that need to be synced between multiple corporations. This syncing type need is in an effort to help with collaboration and standardizing data across systems. Almost getting into a data warehousing type need or data warehousing type environment. Kinda interesting.

After Eric, Bryan joined us and had a few questions for both Steve and I. He is working on custom gram tracking (subs of the shopping cart) and taking certain gram tracking settings and helping them cascade all the way over to custom label building. It is interesting to see the levels of customization and the needs that some of these clients are expressing. The scary side to that is... how far are we willing to go and what will that take? Custom is potentially a huge swinging door. Awesome, powerful, but potentially bigger than we would like.

In between these different little meetings. I finished up the documentation to go with the getWebGeneralInventory API socket method call. I was working on that project last week a little bit. I added a small working document (to do list and brainstorming doc) for the small changes and to help with the project scope. Nothing major, just wanted to record it. Busy morning. It must be Monday.

Working on API socket documentation for sub inventory methods out in ecommerce and API land. Working on the method called getSubInventory - https://data0.adilas.biz/top_secret/printable_web_api_documentation.cfm?id=706

Working with Bryan to push up some new white label code for Herbo. Lots of variables and switching out names and contact info. Bryan is doing a great job. I recommended that he go in and change some variable names to help them be more  human readable. Currently, they were things like whiteLabelVariable2, whiteLabelVariable3, etc. vs a real well defined variable like whiteLabelEmailAddress or whiteLabelBusinessName, etc. Good stuff. Progress is being made.

Eric popped in and gave us an update on some things. As an observation, it is amazing how much some of our reps and consultants fill in the gaps between the system and the education and training that is needed. Eric is working lots and lots with some of the 3rd party solutions and outside API sockets.

Next, Dustin and I worked on some reports and showing dates and ages between different phases for his cultivation stuff. We ended up doing different queries to get the dates, then logic to see if they were real or not (had it really happened), and then showing the age calculation in the reports. Kinda fun little challenge.

See attached for a small work document that Steve and I were using for some brainstorming on the QTI (between a quote, transition invoice, and a real invoice) tracking and process. Here are a few of the notes:

- We may need to go to a line item level on the dates (po/invoice line items)… Currently, we try really hard to match the main (PO's and invoices) with the line items. There is some built-in code to help with this process.

- We may need to pull some data... and see what to do with it - For example: you stand in this line, you stand in this line. (analogy between parallel lines and diverging lines and the bubble analgoy - small flex zones or small flex bubbles)

- We would love to see the ice-down date, aggregated data, watchers, feeders, tiggers, 3D calendars, taking things clear out to minutes and seconds vs just 24hour dates (June 1st, June 2nd, etc.).

- Steve and I were talking about "display only" pieces on the balance sheet... The future potential from QTI invoices may be a display piece, not a real book piece. Just like the liabiltlty for loyalty points. Just ideas.

- Small talks about posting (old school accounting and posting to differnet accounts) vs a computer just running logic to figure out where things were at (roll call accounting) - a computer can figure it out and repeat those actions every time so that it just flows through vs having to post and post and repost. Basically, make it show up for roll call vs doing different journal entries every time.

- To make the current QTI process work, we skipped the tax stuff until the very end... We also need to track both lists of invoices that are still in transition and those that are done. This is really true if you are going back in time.

- We briefly talked about using aggregated data to show daily break-downs in the full P&L and balance sheet levels - even to the 3D calendar level
- different categories go down the left side.
- dates go across the top.
- totals show up below (per column per date), they also show up per section (far right per row or per record).
- it would be so cool if we could put all of the known P&L and balance sheets categories on a single report and then pull from special daily totals (aggregated data) to populate thos values.
- see this element of time in the adilas university site for some sketches of a similar idea
https://data0.adilas.biz/top_secret/time_web_gallery.cfm?corp=371&id=1797

- What has been changed and what has been iced down?  - Evaluate those values as we move across time on a report and/or calendar?

- What about using ajax (asynchronous calls to get the data) to figure out the aggregated totals as they show up.

- It would be really cool to see the known issues and be able to drill-down to those values easily... even through the aggregated totals.

Spent some time recording some notes from this morning. The notes came from a session between Steve and Brandon talking about financial reports and advanced balance sheet stuff using aggregated data. I also went back in and reread a few of the ideas and made some light tweaks. I also printed some things off, did some prep work and started brainstorming on what is needed. I also reviewed some existing processes and even read a couple of help files. Trying to get my head around the whole thing.

As a fun side note, we will get there (meaning our end goals), it just may still be some time before we get to that level. Keep the vision alive.

Shannon and I had a great session recording new content for the adilas user guide. We are currently working on the financial report section and talking about old school and new school accounting practices and how they are similar and how they are different. Fun session. 

Meeting with Bryan. We did some merging in of some white label variable changes. That will help as we go forward. We talked about online reservations and possibly splitting a bill/ticket with a client who would like that functionality. I would love to add that to our offerings. We also did some light debugging on some QR codes and stuff for some custom labels. Good session.

First part of the day was pretty quite. I helped answer some API socket questions that Eric had. I then merged in some code for Steve and pushed up a number of new files.

Working on sub inventory documentation for sub inventory API sockets.

https://data0.adilas.biz/top_secret/printable_web_api_documentation.cfm?id=706

This is just a note for the developers. We allow a corporation to use an alias corp key to login for a certain company and/or corporation. Currently, out in the API socket land, we only allow the older corp key value, which is three letters of the corporation name, a dash, and the corporation id number. Example: Pla-0053 or Mor-0003 or Cor-0263.

The aliases are much more human readable. These could be values such as: demo, herbo, adilas, expo, 710Labs, etc.

It would be nice if the API sockets could handle both versions. That shouldn't take too long, but it may really help.

Working on more documentation for sub inventory API sockets. As a side note, I'm seeing that each of the existing API socket calls are going to need some more work so that outside developers won't have to make other calls to get all of the data that they need. I think that our existing calls are going to need a little bit more lovin.

Pushed and merged in some code with Bryan. We did some session clean-up from some temp session variables that were set yesterday. He had some questions about QR codes and we also spent some time going over merchant processing and how and what we do (on our side) to help our clients get setup.

Steve and Eric were having some discussions about the existing data model. We have some companies that are small and totally fit into our existing model (single corp with multiple locations under the same tax or EIN number). We are seeing some crazy stuff between bigger companies that have multiple corporations and virtually want to have sub corporations under that bigger umbrella (consolidated reporting, cross-corp look-ups, master/sub type levels, etc.). Steve and Eric were talking about master corporations and then having sub corporations. It gets into rules, permissions, and the flow of the data.

The topic sort of came back around to getting into aggregated data and being able to pass data back and forth between corporations (internal API sockets). Steve really liked the concept of a "master corporation" to hold high level things like global items lists, global part category list, global customer types, global customer/client lists, loyalty points, certain rules, consolidated reporting, high level financials, etc.

After that, Steve wanted to see some code to do some internal API socket stuff. He has a cross-corp report that needs data from two different servers. As a side note, that complicates things even further. Instead of just saying - I need data from all of these corps... you are virtually saying - I need data from this corp on this server and these corps on this other server and I need to pull it all together into one report. I spent some time looking up some code samples.

Wayne came on was asking some questions about a 3rd party solution that is trying to get super deep and looking into building out both a payment solution and an integrated but external ecommerce solution. It is crazy to see how every conversation keeps turning back to access to the data - basically, how can I plug into an API sockets and get and pass data back and forth. Very interesting.

From Danny - We are trying to bring in parent attributes to a label located on invoice side. I worked with Steve on this last week and he felt it would be best if you had a look at it.

I met with Danny over a Zoom session. He was really close. We got into his code and looked at it and found the problem. We made the fix and he was off to the races again. Good stuff.

Tech support, emails, and research for Steve and setting up a simple API socket for cross crop data (daily sales totals).

On 6/27/19, Brandon and Shannon were working on some content for the adilas user's guide. As part of that, they went over a PDF document that was created back in 2011. See attached for the full document. Below is the basic text from the PDF flyer. This is the virtual road map of what happened and why... fun story!

SUBJECT: Start-Up History of the "adilas.biz" Business Platform Quick Overview

Adilas, LLC was officially created in January of 2008. The original partners were Stephen Berkenkotter, Brandon Moore, and a corporation called Morning Star Automotive, Inc. The Morning Star Corporation has since been dissolved (2010) in order to more fully focus on the adilas platform. The actual project began in 2001 as a custom write-up system for Morning Star. Originally, the application was created for the used vehicle and trailer dealership industry.

In 2006, the application went through some major changes when Stephen (Steve) came up with the concepts for adilas. At that point, it started to change from servicing just the dealership industry into a more general or open business model. By the end of 2008 adilas was servicing a number of new clients (besides dealerships) with the following business types: self storage, modular homes, construction, manufacturing, professional services, and retail. As of 2011, adilas has added other businesses such as: virtual finance companies, real estate companies, transportation, GPS tracking, computer services, alternative healthcare providers, fasteners (nuts and bolts), catering, consulting, personal accounts, home-based businesses, etc.

The application or platform is set up for future growth and is very scaleable. It is currently geared towards small to medium-sized businesses. The application is in a constant state of improvement. This includes adding and upgrading features and tools, building reports, and automating existing functionality. Each new tool and/or feature is developed and tested locally before being deployed to live servers. All new tools and features are assigned to a permission on a per user and per corporation basis. This makes it so that only persons and/or businesses that need the new tools turn them on and use them. All unassigned permissions and features are dynamically hidden until assigned. The existing core of the application has been developed and tested over a number of years and is currently on its seventh full version.

The adilas platform is web-based and set up on a series of commercially hosted environments with state of the art data centers and 24/7 support techs that monitor all servers and databases. The application is completely "cloud" based and only requires a computer or a device that can access the Internet. All application pages and web service calls are done over a secure socket layer (SSL) with many other security features in place. Daily back-ups are done from within the hosted environments. Current adilas clients may export their own data and save local back-up files at any time. Adilas also performs its own weekly back-ups and then securely stores files offsite. For more information about adilas, please visit - www.adilas.biz

Going back to the beginning…

Morning Star Automotive, Inc., one of the original partners in adilas, was founded in 1989 by Stephen Berkenkotter and his brother David Berkenkotter. It was a used vehicle and trailer dealership. Over the years, they did well over $100,000,000+ (hundred million) in sales. By 2001, Steve and David had been in business for about 12 years and had 5-6 locations in Colorado. Things were going well and they were quite successful. They were managing their used vehicle and new trailer inventories on a spreadsheet that Steve had created. All of their accounting was done on a separate software system called Peachtree Accounting. All sales were done on hand written tickets and then given to the accounting office for data entry. The accounting department entered all sales and inventory items into the PeachTree Software after the fact. The outlying store locations would save all paperwork and invoices and then send a weekly batch via FedEx or UPS to the accounting department. Morning Star's primary headquarters and accounting office was located in Salida, a small mountain town in central Colorado.

Brandon Moore, another original adilas partner, had just graduated from Utah State University in Logan, UT, in December of 2000. He moved with his small family to Salida, CO in the summer of 2001. He originally moved to Salida to be a professional raft guide and kayak instructor on the Arkansas River that ran through the Salida area. As the summer progressed, work was slim and Brandon was scrambling to make ends meet and to keep he and his family afloat. He found a job listing in the newspaper doing data entry work for Morning Star in August of 2001. Brandon interviewed with Steve and his head accounting person for the data entry job. They offered him the job and he offered to help build the Morning Star website.

Brandon had graduated with a BA in Business Information Systems with an emphasis in Office System Management. Prior to that, Brandon had created a couple of small websites in college and worked as a computer instructor for a local technical college. The accounting staff began using Brandon to do data entry work for the parts department.

Soon after starting to work in the accounting department, the company website became part of Brandon's main job. He began gathering information on inventory levels and items for sale. With so many locations and inventory items being sold on a constant basis, it became almost impossible to keep up with the changes. To make matters worse, the company was constantly transferring a large floppy disk (100 MB zip disk) from store to store to make sure that each location had updated information. The process took about two weeks to make a full circle and then it would go around again. Each time a store would get the disk; they would update their files, add any new items, and send it via FedEx or UPS to the next location. This was a never ending loop with time being one of the biggest variables. Talk about a money pit and literally chasing your tail…

The first step in changing this process was to create a centralized location for the data. One of the sales managers in the Salida office would keep the inventory file relatively up to date by making phone calls and trying to record the data. Every couple of days, Brandon would post the file online with a date to let the other managers know how current the file was. Having the data centrally located sped up the time frame from a two week cycle to just a day or two and totally cut out the next day FexEx charges. Even with these changes, work and efforts were being duplicated. Different salespersons were selling items without others knowing about it and new web page files were being made for items that had already been sold. It became very frustrating as a salesperson would have a good deal on the table just to find out that the item was already committed and/or sold. Deals also went the other way. A customer would ask for something and according to the spreadsheet, it didn't exist, even if it was physically available at another location. Eventually, the need was great enough to drive both Steve and Brandon to come up with a plan to create a dynamic web driven application to track the main big ticket items called stock/units (vehicles, trailers, and toppers).

Brandon went back to Utah on a family vacation and was able to take a dynamic webpage class from the technical college where he previously worked. After the class, he returned to Salida and began working on his very first database web driven mini-application. Its only functions were to track the stock/units (big ticket items), stock items in/out, and mark them as sold (basic inventory tracking). Once completed, the timeline for doing a transaction went from the two days between updates to each salesperson making real-time connections and totally eliminating the old spreadsheet of inventory items. At that point, a number of concepts that are built into adilas started to form. These concepts are enter once, use many, and empower the users at the point of action.

Once the first mini-application was complete, Brandon terminated his full-time employment with Morning Star and became a sub contractor and independent web developer. He started working from home and started his own web-based business and began seeking new clients. Morning Star was still one of his biggest clients, but he no longer worked full-time for them.

As things progressed, more and more options, tools, and features were added to the system. It wasn't long before the operations side (sales) was walking circles around the accounting department. Communications improved, sales went up, and the sales staff loved their new tools. Meanwhile, the accounting department was getting buried and management was looking to add new locations because of improved sales.

Because of the load and stress, the accounting department began to ask for reports with specific dates, data, and totals. Prior to that point, the accounting department had had nothing to do with the inventory tracking system other than the fact that they could login and look at individual stock/units and their histories. A very distinct line was in place and operations could not touch and/or see any of the accounting pieces or functions. Each department only dealt with or played in their department and minimal crossover took place.

As the accounting department slowly began to ask for more and more reports, new tools and new features, the two departments slowly began to interact better. Communications, procedures, and flow started to develop. The commonality became the system. As a matter of fact, they even made the system be the "bad guy" to help spell out the rules and say "No" when needed. If management didn't like what the sales staff was doing, they had Brandon open and close virtual doors to accommodate the correct flow process. More and more permissions where developed to accommodate needs on both sides of the transaction. Real time problems and solutions were beginning to be addressed as they happened.

The operational interface began to lightly feed the accounting department certain values and date sensitive reports. Managers and operations folks began to see numbers and reporting that they had never seen before. A cause and effect cycle began to emerge. This may not seem very big, but it was the start of a huge paradigm shift for the entire company. Managers began watching expenses and taking pride in running a tight store and location. Inventory levels were being tracked, purchases made accordingly and accounting was getting their numbers. Things were starting to flow more smoothly. The entire development process was as follows: 1. Find a specific need 2. Figure out what pieces came from where 3. Take a step in that direction by releasing a new tool, feature, or report. The natural consequence of the user actions would then present the next logical step and management would be able to see where they wanted to go. In a way, the horse began leading the cart instead of the other way around.

The next phase of growth was changing from one corporation into multiple corporations. As the dealership grew, they took on different businesses and acquired others. Steve went to Brandon and asked for the exact same web application for some of his other companies. Each new system needed to be independent so as not to mix numbers and items between corporations. All that needed to be changed were names, locations, tax settings, colors, logos, permissions, and a few other minor tweaks. After adding a number of independent systems, Brandon told Steve that it was getting too hard to keep up with all of the different systems. A single update or change had to be tested in multiple places in order to make sure that it worked with all systems. Users were getting multiple logins to be able to work in different corporations (no cross over existed between the systems). An additional load was added because certain users needed certain functionality in one corporation but not in the other corporations. The current system permissions and roles began to morph into user-specific custom code and began to split the application. More functionality was added but upkeep and maintenance became much harder.

Brandon proposed that they pull back and try to put everything under one roof and build with growth and expansion in mind. This new system could include: multiple permissions that could be assigned to different users by corporation, any number of different corporations, unlimited locations within a corporation, and each corporation could have their own settings and virtual sandbox to play in. To top that off, a bridge or interface could be built to allow a user to switch or cross over between corporations without having to login under that corporation. The entire system would be built on a one-to-many relationship model. Steve liked these ideas and began to think on a more global scale. All of the existing systems continued with minimal enhancements for a number of months.

At this time, Brandon was very involved in a business he had started to teach people how to do snowboarding freestyle tricks and moves through an interactive CD-ROM. Most of his time was devoted to building his own business. He was spending very little time working for Morning Star other than minor special requests. Brandon was looking to have someone take over the work he had been doing for Morning Star as their web developer.

Morning Star needed help with Brandon heading out the door so they hired a new computer guy. Brandon agreed to stay on long enough to train the new guy until he could take over. This required Brandon to dive back into what was going on at Morning Star. About this same time, Steve was dreaming up the concept of creating a "super system" – a web application that could track all of the data for different businesses. He could see the potential of selling this web application as a service to businesses with a reoccurring revenue stream. Steve grabbed the bull by the horns and set up several meetings with Brandon and the new computer guy to share his dream and vision.

It was Steve's idea to begin pulling the operation side and accounting side together like the cogs of a zipper being zipped up until each piece fit in perfectly with the other pieces. Some of the functionality was already in place in a very loose sort of way. Steve had many business ventures (besides his dealerships) in real estate, transportation, small investments, etc. Steve was also in the process of finishing his degree with a dual major in business management and accounting from the University of Phoenix out of Denver. Because of his business knowledge, his entrepreneurial spirit, and experience, he knew that a large gap existed between operations and accounting.

He could envision a way that as he did his day-to-day tasks (operations) that they would automatically show up for roll call on the accounting side of the application. Data would be entered once and then passed along until all of its activity was complete. He wanted to track every penny from start to finish. He also came up with the theory of entering pieces on the operations side and then slowly having them become more firm values, solid dates, and eventually final numbers. He used the analogy of water droplets forming into ice crystals. The droplets start fairly loose (sales) and slowly become crystals, then slush, and then finally becoming completely frozen or iced down. This final output would end up being the actual accounting for the organization. Basically, this was the start of tracking a transaction from beginning to end through its life-cycle. Each key date or status change was flagged and dated and all prior steps were locked down according to user permissions. This became a running history of the objects and data as they moved over time.

About this time, Brandon had a small business loan or note that required a significant payment and funds were tight between trying to push his own products and make the note payment. He began to supplement his normal income by helping to train the new guy and diving in on Steve's idea of this business accounting and operations system (accopps). Within a year, the new part-time computer guy had some family problems and was unable to continue. By this point, Brandon had caught the vision from Steve and both were working almost full time on the project.

All of the existing online systems for the other corporations continued with minimal new enhancements as Steve and Brandon developed a brand new system from the ground up. The new system required a major rework and was purposely built with growth and expansion in mind. Every single page was built from scratch to incorporate the new fields and settings. Scripting and database platforms were changed, servers were added, and the goal began to move toward an open business model instead of just a dealership industry business model. Each new development step opened the vision even further. Ideas and concepts that weren't even possible began to become a reality as the process continued. Cogs of the zipper were slowly coming together from the bottom up.

It wasn't long and the new "Morning Star System" was created. All existing companies migrated from older standalone web applications and started to use the new system. Additional companies and corporations were added under the "Morning Star System" name. No marketing was done and all of the new companies were referrals from current system users. Brandon and Steve were working hard to come up with the next steps and still trying to figure out how to keep pulling the zipper cogs closer and closer together. There were no road maps for doing this. They were truly pioneering ideas and concepts with only a vision, brainstorming, and trystorming (planned experiments) to guide them. The deeper they got, the more they started to see that other companies had the same problems and frustrations that they had already worked through. New companies were ready to pay even though the entire application was not yet finished. A definite "need" was forming.

Steve and Brandon knew that the new system would need a name and would need to become its own company and entity. Over a lunch meeting in Salida, Steve proposed the name of "adilas" which is actually the name Salida spelled backwards. Up to that point, the entire application had been created there in the small mountain town of Salida, CO. The name stuck and an acronym was developed – "all data is live and searchable". As time went on and as each new development step was added to the system, the more this acronym became a living part of the application.

Adilas, LLC was officially created in January of 2008 with the first paying customers in June of that year. Shortly after that, the first paying international customers were added. All in all, there were close to 20 corporations using adilas before it even became an actual entity. All of these companies, from the various industries, had asked to be a part of the process. They were all using the service free of charge up to that point. Each company helped tremendously by providing feedback and ideas that were incorporated into the development process.

The feedback and suggestions from their clients became one of adilas' biggest assets (and still is today). The size and depth of the live test bed was another huge asset that they harnessed virtually for free. It would be nearly impossible for a small company to pay for a test bed of that magnitude. It would have cost millions in research, development, and staff salaries alone. Similar to the cream rising to the top analogy, the ideas and suggestions began paving the way to new features and functions. Over the years, hundreds and hundreds of people have chimed in and made a contribution in one way or another. When asked, Brandon said that "Even our most adamant critics have helped formulate our direction and plans. We are very grateful to one and all. The more holes they would find and point out, the more we just keep trying to fix the problems. It has been awesome!" People from all different walks of life from CPA's, attorneys, bankers, accountants, owners, managers, salespersons, data entry folks, entrepreneurs, and friends have all added their suggestions, ideas, and feedback. Literally hundreds of thousands of hours and millions of dollars have been put into this project. In a way it has become somewhat of a community effort or project.

In seven short years, from 2001 to 2008, adilas went from a mini custom write-up system to a multilevel business platform that is capable of bridging the gap between operations and accounting. The adilas guys have continued to pioneer the way and haven't stopped building. They are working on a master plan that includes a new way of doing accounting called "roll call accounting". This deals with tracking objects and data over time. Operations lead the way and the system is set up to catch and show cause and effect relationships of what was done and how the pieces are tied together. Along the way, each step is dated, flagged, and recorded. The entire story is being captured, mapped, and laid out for users to see. The "roll call" then happens when the user asks the objects and data where they were at any given point in time. The objects and data then virtually respond or report back to the user.

Clients currently use the system to track inventory, manage customers, showcase their products on the web, sell their items and services in an online point of sale system, run retail store fronts, pay bills, track receivables and payables, do their entire backend accounting processes, do payroll, scan and file documents (paperless office), schedule calendar events, run their business, and much more. New features and tools are released almost weekly and the system is gaining momentum and direction. A future training ground called Adilas University (adilasuniversity.biz) is in the works. This will be a dedicated place for training, video tutorials, step-by-step instruction, newsletters, upcoming events, new feature releases, along with a number of other different topics.

The entire application development process is fully paid for and has been through a number of full working releases. It has had hundreds and hundreds of people from different businesses pushing it to see what and where it will go. The story is still unfolding at an incredible rate. The adilas team is still adding new things every couple of days. With each new release, the vision opens up new doors and more options emerge. When asked, Brandon said, "You should see our tick list of where we want to go with this. I can see better training, faster reports, more automation, new custom settings, user defined preferences, and a more visual-type interface. I'm pretty excited about it!" So, it continues… as long as their users keep asking for the next logical step, they will keep building it better and better! The future looks very bright!

For more information about adilas, please visit - www.adilas.biz - If you would like to learn more about adilas, the system, the tools, the theory, the people, please get a hold of them for a free live demo. They welcome questions and love ideas! Contact them at: sales@adilas.biz or 719.439.1761 and ask for Steve.

--- additional contact info: support@adilas.biz - tech support line: 719.966.7102

--- as a fun side note... this document (text above) was created in 2011. Tons of new chapters have been added since then. Today's date is 6/27/19. And so it continues...

Meeting with Josh and pushing some code for a custom report. Light rework on the report and pushing things up and rechecking.

Super fun session with Shannon. We were working more on new school accounting concepts and trying to get some content for that part of the adilas user guide. We ended up rereading a historical document from back in 2011 (see attached). As we did that, we took a few notes and talked about the process of finding a need, brainstorming a solution, and taking a stab at it. We have done that process, with user input for years and years. If you look at what we are currently doing, it is literally the same thing today as it was in the beginning. The only difference is the problems and issues are deeper and have more teeth (virtually speaking). Good stuff.

Link to the text or historical flyer we were reviewing - https://data0.adilas.biz/top_secret/time_web_gallery.cfm?corp=371&id=4028

Data migration for a client. Pulled about 6,000 customers/patients from one corporation and migrated basic customer data and flex grid fields to two other systems owned by the same company.

Met up with a client over a Zoom session and helped them with some training about credit cad swipers and USB card readers. They are setup with Authorize.net (merchant processing) for credit card stuff. This client training session was not a chip reader thing, just normal and simple card swiping using the card readers.