Getting back into the partial PO project. Here is a small list of things that still need to be done for that project.

- Open up the external_alternate_id field for all of the 12 main player groups. They, the database tables, already have that field, it is just hidden and not being used right now.

- In-store credits (customers and invoices) - new special account option

- Vendor specific or category specific PO line searches - add lines in bulk - somewhat of the reverse shopping cart for PO's - the normal shopping cart is for invoices and quotes.

- Full visibility - track total request quantities, total live quantities, and total still on backorder quantities.

After doing some review, I spent some time looking at what it might take to help add bulk po line items. Created a new branch to work on some of the new functionality. Started working on a new page for bulk adding PO line items. Took the original code from the parts homepage and then worked on tweaking it out a bit. The page will allow for filtering parts and items by vendor, by category, by item, by description, by location, etc. That should really help speed things up.

Meeting with Bryan to look at and push up some code changes. Still chasing down some issues between adilas data and the QuickBooks API for invoices on account (in-store credit). We will get back together after Christmas to do another push.

Phone call with Alan, recording notes, and doing some follow ups. Sent an email to Alan with a small list of MVP projects. Here is what I sent in my email.

-------

Here is a small list of projects that I feel need to be done to help with an MVP. There will always be more, but here is a good start.

- In-store credits
- Coupons
- Tips and being able to split tips
- Adilas label builder - version 3
- Stable and standardized chip reading and merchant processing - retail and ecommerce
- Revamp of the shopping cart (mostly done)
- Time and scheduling - vertical time view - scheduling from out in ecommerce land
- Discount engine (rework)
- Smart cart engine and logic (overarching cart logic to handle discounts, coupons, and tiered pricing)
- Rework sub inventory
- Consistent look and feel
- Text messaging and push notifications and reminders
- Database changes - allow for either clustering and/or being able to move corps around at the db level
- Customizable homepage or build your own interface (not really required but I think that it would really help)

Anyways, that's a quick list of some of the things that I think would really be helpful. We are getting closer and closer. I know that people can use it right now and have for years, but these are some of the things that have been asking for. I hope that helps.

Looking into a short MVP list for ship A. See element of time # 9934 in the shop for more details and a smaller list. Here is an abbreviated version...

- in-store credits - $10K

- coupons - internal and ecommerce - $15K

- adilas label builder - round 2 - $40K

- standardize merchant processing - $20K (in progress)

- revamp shopping cart - $40K (in progress)

- time and scheduling - vertical time view - internal and ecommerce ready - $40K

- discount engine - $20K (in progress)

- smart cart engine & logic - $30K

- rework sub inventory - $40K

- planning & flex - $30K

Suzi and I jumped on a demo meeting with the Puppy Pals folks (potential client). Suzi was doing the demo. They, the Puppy Pals folks, need real time texting (push notification). Suzi was demoing the messaging stuff that we have out in ecommerce. Their clients need a quick way to get logged in, communicate, and even get automated responses. They really need notifications.

We switched to flex grid and showing limited flex grid options (for entering pets and one-to-many relations between clients and pets). Talking about dashboards. We went back to messaging for a bit - they really want real time text messaging. Deeper talks about wanting automatic messaging and responses. Two-way communications are needed (big time). Even batch messages.

Suzi handed over the demo to me and I helped with some scheduling stuff. Lite show and tell. They like the time down the side and people across the top for their horizontal time views. Lots of other notes and requests. Basically, they have a complex scheduling need. Almost a 3D model. They have time, rooms, and attendants. They have to matchup all of the pieces.

Partway through the demo, I started writing things down... this is kinda rough (my notes) but here is what I recorded in a quick notepad doc...

- Booking and re-booking

- Moving appointments around

- 5-6 clients coming in at a time

- 100 appointments a day

- Logistics of what happens each day

- Need a quick overview

- Docking and sliding appointments into the slot - temp copy and paste to move things around - move all of the pieces - all of the extras - maintain relationships

- Complex appointments - and then rebooking those appointments

- KISS (keep it simple silly) - visually formatting things to work with the team

- Be able to move the data around

- POS integration

- Be able to divide the tips

- Be able to take a deposit on upcoming services - pre-pay

- They have both taxable and non-taxable items and services

- Bill for no show

- Payoff accounts

- Customer credits - in-store credit

- Notes for customers, notes for pets, notes for appointments - two or three years of notes

- Calendar and time-slot issues and needs

- Per appointment - show dog name - show client name - breed - color code(s) - size, appointment type, assistance level

- Conflicts and rules - max out levels - how many rooms may be booked at once

- Conflict notices

- Each location is different - they are trying to grow from two locations to 10+

- Biggest challenges - complexity of the appointments and be able to move things around

- Be able to manage things and move things around

- Everything happens within 15 minutes... they come in, they get serviced, and they get checked out (payment), and maybe get re-booked

- Future dashboard options - financials, scheduling, inventory, etc.

- We want to help you further that (what you are doing)

- These are "dog" (pet) people

- Pare it down... make it look easy... (frontend)

A lot of that we already have. I was just writing down what they were saying so that I had a record of it. One of the ladies on the call was very sharp. Her name was Jen. You could tell that she had some software and development level background. Great questions, responses, and just knew her stuff. I was impressed.

Merging and pushing up code with Eric. After the initial work, we spent some time talking about data modeling. Here are some of my notes.

- Eric would love to do some more data modeling and taking things into consideration and making a plan. He used to do this for other companies that he has worked with and for. Great resource. We could really use his help with adilas lite or fracture. This was like a mini database and data modeling lesson of sorts. I was loving it and scribbling down notes as quickly as I could. Fun stuff.

- We talked about flex grid tie-ins, flex attributes, and parent attributes. Basically, things that he sees that we do that might be built out into more efficient tools and features. Maybe rework some of this and/or combine some of the features.

- What really connects to other things (natural relationships) or what things are forced together (forced or special relationships)? We may want to look at use cases and try to pull out the natural relationships. Then build your application according to those natural relationships. You may still need to allow the forced or special relationships, but those become the edge cases vs the norm.

- If something happens over and over again, this should be part of the core system. Currently, we do use a lot of flex grid tie-ins to help with some of these special cases. As a side note, some of these one-off features are becoming more normal and should have their own logic and tables vs putting everything into the flex grid tie-ins. Great tool for getting things started but eventually, you may need to build out specific tables, logic, and pages. Make it more normalized and more efficient.

- As a note, what does the flex grid do? It allows for one-to-one connections, one-to-many connections, add log notes to anything, tying things together (main id's to sub id's or main id's to other main id's), and it also allows for up to 30 custom fields. Once again, it can be on a one-to-one basis or used and setup as a one-to-many relationship. Here is a help file that has more info on the flex grid tie-ins.

- As a note, the flex grid tie-ins have been the big brother to the things we are trying to build called flex attributes or real in-line database extensions or real in-line extensions for short. Here is a small, older graphic link, of what we are trying to do.

- We talked about the bus to motorcycle project (datasource project or world building project). We are headed to a new model where the corportion id numbers (corp_id) will be left out per database. Each company will have its own database and thus may not need the corp id number. This deals with table names, joins, and data that gets stored in the database.

- Back to the flex attributes and a possible option to build them right into the main entities or high level tables (for the 12 main players or wherever we see fit to put them). This option has some pros and cons. We'll have to work this out. Currently, I'm really leaning towards something similar to what we did for the current flex attributes or parent attributes. Let them build and setup any custom fields that they need. Dynamic relational model. Just for fun, here is the progression - flex grid tie-ins (2009), sub inventory attributes (2015), parent attributes (2016/2017), flex attributes (2020).

- Lots of talk about data modeling and being able to take off the corp_id. Including on the end of corp-specific tables - for example: invoices_53, invoice_payments_53, time_sub_inventory_53, and a slew of others.

- Maybe break the pili or po invoice line items into two different pieces. It was joined together to help with inventory counts over time and across multiple locations. Anyways, we may look at separating those tables into multiple pieces. Super important, make sure to remember and include locations. If just a single location, we could do the architecture differently. However, with multiple locations, it gets a little bit more complicated or tricky. There are tons of other possible options.

- The payee table should be broken up as well. Currently, if a person or entitiy is tied to an expense/receipt, a PO, an inventory item, it lives in the payee table. Payees consist of users, employees, vendors, and special customers that had to get paid out of the system (a copy and convert process). Anyways, we may want to break that table up into users, vendors, and special customers (something like that).

- We talked about a concept called "attribution" and data normalization levels. There are two main types of data models. You have the logical data model and the physical data model. Entities and entities have attributes. Eventually, those entities and attributes get translated into tables, columns, and fields in a database. Often, most attributes become their own database column or field.

- Attributes are different than types.

- We talked about fields like "flag_for_1099", "password", etc. Those are attributes for certain entities. However, does a vendor need a password field, most likely not. Each field or attribute needs to go with the entity that it belongs with. We, at adilas, tend to mix and blend some of the attributes between different entities. In some ways that is fine, but it requires explanations, instructions, and training. It's not as easy to follow without someone to guide you along. Anyways, some good conversations about data normalization stuff. What goes with what and why does it fit like that?

- Make the names readable and logical where possible. We do a pretty good job on that, but there is some randomness in there as well. Along with that, we jumped into talking about a section called special accounts. We are planning on using that for gift cards, loyalty points, in-store credit, vendor credits, punch cards, and other special account transactions where we almost need a bank account style with a rolling number and being able to add/subtract using individual transactions or actions. Anyways, we have a few fields in there called dev_flag_1, dev_flag_2, and dev_flag_3. We use those flexible fields to help with certain parts of the process. In a way, we didn't know what we were going to need, so we added in some flex fields. Well, now, those flex fields have rules and hold certain data that could be its own column or field. However, because we didn't know what would be needed, the fields are somewhat mixed, depending on what is stored there and what kind or type of transaction record is being stored (loyalty points vs gift cards or whatever).

- The conversion trickled over into human reference fields vs computer identifiers, ids, or computer reference fields. They are different and play different roles.

- As you think things out, eventually you have to transform or go through a transformation from logical models to physical models. Eric kept saying that we should be shooting for the third normal form (data modeling and database modeling). Figure out the whole business world (plan it out as best you can) and then build out what you need, based on what you see and/or know.

- We talked about aggregates and data warehousing. I mentioned that I would like to build out tables for yearly per location, quarterly per location, monthly per location, weekly per location, and daily per location. We would also have the underlying transactions or transactional database tables (raw data that holds all of the data). The other tables would be what we transform the transactions into (a form of aggregates or business intelligence).

- Along with aggregates, Eric was saying that sometimes you can watch the database and see what tables, queries, and reports cost the most (data, traffic, or processing time/energy/frequency). You then build out aggregates based on those findings and/or known needs. For us, we've been doing this for long enough, we know a few places that could really help with speed, server load, and provide great BI or business intelligence levels.

- Our system has to go clear out to the full accounting level. That changes how we do certain things. That is awesome! Our sort of end goal is perfect accounting, aggregates, per day, per location, and per category. Some of those (category levels) vary but they have mostly been defined in the current system. That is huge. We have a plan, we have a path. We just want to refine it. Eventually year over year reporting, monthly by month comparisons, real-time data - all data is live and searchable (adilas).

- Snapshots, aggregates, different preset and controlled data levels. We may need current data (tables without any dates - assumption of current counts, values, sums, totals, averages, maxes, mins, etc.) as well as dated or historical data (tables with dates to allow previous or prior lookups and date driven lookbacks).

- What about enterprise mappings and cross-corp stuff? We need to plan that out as well.

- We also need to consider servers, speed, reliability, backups, redundancies, and how deep we going?

- Lastly, Eric could help with a ground up data model. We could pick a topic, break it down, and do a number of smaller sessions vs a big push. That would be too much. Anyways, great meeting and Eric could be a great resource for planning, checking out our decisions, and planning out the best course of action. Good stuff!

Recording notes and working on a list of known issues. See top_secret/secure/known_issues.cfm for more information.

For fun, here is a list of some of the items listed on that page. This list originally was started in 2009. Small list of what are known problems. Some of these things are real problems and some are just warnings. Lots of things have changed since then. It may need to be updated, added to, and some of the items removed, that have been patched, fixed, and/or finished.

1. Invoice pmts on account with something different than 0.00 value.


2. Receipt pmts on account with something different than 0.00 value.


3. Reimbursements (rei's) with a bank assigned on the receipt pmt.


4. Invoices with mismatch between main and line items.


5. Deposits with mismatch between main and line items.


6. Receipts with mismatch between main and line items.


7. PO's with mismatch between main and line items.


8. Non verified payments (outstanding deposits and checks).


9. Duplicates ???


10. Dates prior to the corp start date or prior to the bank start date. See bank_balance_helper.cfm page.


11. Dates in the future. see bank_balance_helper.cfm page.


12. Internal invoices that are not marked as paid.


13. Receipt payments that are verified but the main is not verified.


14. Difference between invoices and stock numbers. Created a number of flags to show disconnect.


15. When paying back splits and rei's - what about both (main and subs) being assigned to income statement expense types? This could double things up on the income statement. Defaulted special multi build (rei and splits) to b.s. items for expense types. Still possible problem on original e/r that may get assigned to the balance sheet.


16. Update PO's not tied to a balance sheet item (say a loss account or something).


17. Lien payoff line items on invoice with a 0 cost. The cost and the price should be the same otherwise it puffs up the profit. Did run a report at one time to fix this. Also added code to the cart to match cost and price for lien payoff stuff.


18. PO payments that have the wrong date and thus the po_paid date is wrong. The system was using the current date as the payment date even if the payment was actually made in the past. Small disconnect between actual payment date (e/r payment date and PO paid date).


19. Check auto dates that are actually used in I.S. reports or B.S. reports. Need a way to manually change the auto dates if really being used. Check the unit payments, PO payments, other system made payments. The system seems to be ok, the problem is with dates and being able to either set the date when using or edit the date if defaulted to today's date.


20. Blank expense/receipts (payee_id = 1).


21. Voided items but part of it is still in play or not fully voided. Need to get to a voided list quickly.


22. Denied check requests on payables page.


23. Sales tax problem with work in progress invoices. They don't show up on sales tax reports until they get flipped back to a customer invoice. The problem is that the date (main invoice date - if not moved forward) will not show up on the next month’s tax reports. If this happens, the invoice will fall through the cracks and not be counted for sales tax. Possible option for sales tax, Steve thought that it might be cool to have a point and click interface that we physically pay taxes on certain invoices. That way, they never fall through the cracks and we only pay taxes once we collect the monies. This would also help with a system-maintained b.s. item for accrued sales tax. As an update, Eric was working on a sales tax aggregate project to automate this.


24. Along with sales tax problems, how do we show this on the balance sheet? We need to show collected, paid, and owed values. Once again, Eric has been working on this in his sales tax aggerate project.


25. Payroll has similar problems with regards to what has been paid on, what is still needed, and how do we show this info on the financials.


26. See idea in note book about showing all daily transactions. This is different than a history transaction record. This is what really hit in and out on this day in time according to the system. This is not a known issue but may help with finding issues. Daily monitoring of each account per location, per day, per account or category. This would be awesome.


27. Check for master/slave relationships between date changes. For instance main invoice date compared with invoice line items dates. PO main date with PO line items date.


28. Known issue with PO dates. Do we run off the main PO date or the PO received date? Need to standardize. Leaning towards PO received date.


29. Known issue with location based payables. Both expense/receipts and deposits have the location on the line items not the main. This means that monies could potentially get split between stores which would alter bank balances if only part of the money went in/out of the bank. Known problem here. Solution might be that banks are what they are (full monies in/out) and all sub lines and types are location specific. This could give a false indication as to how much money was available for each location.


30. What about transition invoices that have the main invoice date overlapping the transition (wip/qti) invoice date range. They don't show up anywhere other than on the main invoice homepage which doesn't tie to anything. Added a small fix on view_transition_dates.cfm page. Still need to check for possible mismatches.


31. Disconnect between sold date on units and invoice date. This is a disconnect that is unmonitored and will only show up if pulling a sold report (units) and an invoice report for the same time frame.


32. When backing up the main bank start date, there is a problem with expense payments and deposits that have a date before the main start date and a verified date after the main date. The payment or deposit date is not counted but the verified date is. I had the same problem with Leanna in Poncha and with Drew Middlemiss doing his first bank statement. What a pain. See the bank_balance_helper.cfm report (5/16/09) for small fix. Still a known problem with a starting bank balance not being 0.00.


33. Advanced pmt on invoices (pre-paid). They hit the bank because they were deposited but they also need to show up as a liability to offset the deposit or cash going up. This should be a system maintained item.


34. What about deposit types of other income that are assigned to invoices (double counted)? The default is an invoice hits the p&l and only deposit line items that are under other income and revenue adjustments hit or the p&l.


35. What about bad debt? Do we want to create a system maintained items for this?


36. What about deposits that are made before pmts are posted to invoices. This is not backward compatible.


37. Know disconnect between PO dates. The main PO date is currently used as the main search date. The PO received date is the main b.s. date. We are thinking that the main date may become somewhat of a request date or a age player only. The main date will become the received date with the received flag.


38. If a check request gets approved and assigned to a bank but never written out (bank never sees it), there seems to be a problem. There is also a problem with older check requests and the dates that are set in the background. They are uneditable once the request changes into a normal e/r.


39. Known issue with i.s. (income statement) deposit types. If used, without an invoice, they don't show up on the income statement. They may also be double booked if on an invoice and also recorded as other income or revenue adjustment.


40. What about payments made on a PO before it was received. This could happen with a request PO or a basic PO that has not yet been received.


41. What about inactive (status) on parts and subs. If we have details (activity) but something is inactive, that could cause problems.


42. Levels of inventory - this could deal with parents, subs, and usage details. We may need to check costs, quantities, dates, etc. Sub inventory was added way after 2009 (original date of this report). We may want to spend a whole session just going over sub inventory levels and possible pit falls.


43. Steve, Kelly, Molly, and others have lists of balance sheet challenges and other known issues. Check with them and get their lists.


44. Ecommerce and what plays into the real mix from there - invoices, taxes, costs, prices, discounts, payments, quantities, elements of time, etc. Good questions? Some of this is already figured out, it just needs a little bit of loving.


45. What about aggregates (somewhat new for us and just barely getting rolled out) and making sure things match up. Category (could be whatever), by day, by location - are there update processes that may be ran to keep things up to date. Manual updates, API sockets, watchers and feeders.


46. What about backorders? Steve did a whole section on backorders but I'm not sure if we tied in everything to the balance sheet and P&L. Anyways, may need to circle back around.


47. What about banks that get turned on/off (active/inactive). If we go back in time, we need to know if they were playing.


48. Same is turn with location. If they get turned on/off (active/inactive), we need to know when they were playing. We may need a start and end date and then be able to pull things accordingly, even if the current state or status is inactive.


49. What about cost of goods sold on unlimited or special line items? They should be a $0.00 cost because they are unlimited (like a labor or a service). If a cost is needed, it needs to be allocated through an expense to the COGS section or distributed in a thing called SG&A costs. SG&A (selling, general and administrative expenses - aka accounting for general costs by attributing them to a single unit and thus incorporating the true costs into an item). Basically, you take a normal expense like the electric bill or rent and build it into the individual cost of each unit by unitizing the expenses and virtually spreading a bigger general cost to smaller pieces. Sometimes that type of process (SG&A) is required for certain manufacturing and/or production type products. Basically, they (the IRS) don't allow you to expense off the whole expense (rent, insurance, waste, electric, etc.) as a bulk item. It has to be distributed to each smaller piece. If you do real SG&A, it helps assimilate those costs in smaller percentages and thus passing on a truer look at real costs of goods sold.


50. Anything that is currently marked inactive but may have played a role at some point. This could be locations, banks, part categories, items, vendors, customers, etc. Often, if we make them inactive, they don't get pulled (but maybe we need them at some time in the past).


51. Other special account options such as in-store credits, vendor credits, punch cards, etc. We already have loyalty points and gift cards that use special accounts. Maybe expand on this and allow for custom options or other digital payment accounts or payment solutions.


52. I'd love to map out all of the existing balance sheet and P&L values. Make it more widely known and really put it out there. Right now, it all happens behind the scenes and is kinda like a magic box. I'd love to get it all mapped out and presented to the public. We'll get feedback, refinement, and maybe even some other really good ideas. That's my vote, let's get it all out there in the public eye and public realm.

Sean, Shari O., Michael, John, and I were on the morning meeting. We all checked in and said what we were working on. After that, we all either left or went on mute and worked in the background. Shari O. had to take a tech support call and Sean was waiting to chat with her once she was finished. John had some flex grid tie-in questions. I was doing some research on MVP's and past data that we had recorded for what we wanted in some of our MVP (minimal viable product) stuff.

Here is a short MVP list that I'm thinking about - for the record, we already have some of this, we just need to refine it and make it watertight:

- Special accounts and in-store credit - We already have loyalty points, and round 1 for gift cards. Eventually, we would like to do in-store credit, vendor credits, punch cards, and other ones. The next biggest need is for the in-store credit stuff (in my opinion).

- Round 2 on gift cards - We've been gathering ideas and wants and needs

- Coupons and promotion codes - clear out and through ecommerce and internal shopping carts

- Take Calvin's adilas label builder to the next level - we've already done some planning and prep work there

- Standardize the merchant processing options - We have like 9 different integrations. Here's my next goal, pick one, make sure it flows from start to finish and is super simple. I want to do normal sales, pre-auths, captures, tips, refunds, voids, and reoccurring payments, etc. We have to be able to do manual key (like ecommerce mode), swipe, chip/EMV, and tap to pay hardware integrations. I want to do and offer all of the merchant processing functions. I was thinking that we could do a big push and try to get all hooked up with Datacap and then let them handle all of the different hardware pieces and different merchant gateways. That's my thoughts right now.

- Revamp the internal shopping cart, my cart favorite buttons, and general look and feel. I would love to head towards the fracture project - we have a bunch of R&D on where we want to go with that.

There are tons of other things on my list, but that is my quick MVP list for right now.

Talking with Sean about making a tighter game plan for credit card payments and which merchant account types we will allow and support. Currently, we are super open which is nice, but it also introduces too many variables. We have done integrations with a number of different companies and vendors, but not all. It gets really tricky when new hardware is introduced and chip or EMV requirements are needed. Anyways, we'll work on refining our options and how we approach custom solutions.

Eric joined the meeting and had a few questions. He let me know that there was a problem with the Herbo server (most likely a test branch of code). We also chatted briefly about some other MVP special account options that we would like to get to. We talked about in-store credit, round two on gift cards, coupons, and promotion codes. We also mentioned that we may need to do a full review of what we call our standard merchant processing setup and credit card payment options.

Emails, reviewing some videos on a time formatting bug/complaint on employee timecards. We used to leave it very open and allowed users to enter times as they see fit (for example: 5 pm, 5:30 pm, or 5:30:00 pm). The new time pickers require a certain format and some of our clients have been complaining about the requirements. We had time-pickers for hours and minutes, as well as one that required hours, minutes, and seconds. Basically, they want it back open where they can just quickly slam in a time vs having to comply with specific formats.

Just Steve and Sean were on the meeting with me this morning. By 9:30 am, both had bailed out to do different things. We were doing some quick updates and going over things before they bailed out. Here are some of my quick scribbles (notes):

- Gathering ideas from different people. Including new people who are already influenced by existing adilas theory and designs.

- The value of education

- Talking about options for selling shares, percentages, and maybe going public with adilas in order to raise funds for projects that we want to do and pursue. It's all about the connections.

- Steve was talking about the drive to make more money that is shared by most business owners and entrepreneurs.

- Selling adilas to fill in small parts of the business as fill-in pieces. Not piecemeal but selling certain tools and features to help round out other businesses, models, or software packages. For example: Say someone just needs ecommerce, online ordering, scheduling, timecards, or even things like gift cards. We pitch it, get them going on what they need and hopefully they like it and want to expand to other parts and pieces. This is an older saying from Russell Moore back in 4/13/16, "Adilas is a great companion software package for any business!".

- We are still seeing a future need for in-store credit and being able to apply those liabilities to outstanding invoices. You can do it right now, but you have to do everything manually. We would really like to automate that whole process and make it super easy and smooth. This will end up being another one of the special accounts type functions. Not everybody gets it, only certain people or customers need it, and it is basically a reverse account where you overpay and then get to use that value to pay for other things. Very similar to gift cards. As a matter of fact, you could issue a gift card for the overage and then let them use it at will as a payment. Once again, in-store credits will play along with other special accounts such as gift cards, gift certificates, loyalty points, punch cards, lunch cards, vendor credits, and other special account options.

- We got into some talks about deployment as a bottleneck and how training and education could help solve some of that pressure and bottlenecks. There is also a huge need to keep educating and providing learning for new functionality that keeps getting developed. That's an ongoing process.

- Small discussions about keeping up some of the demo sites and making them nice and clean. There is a huge value in nice, clean, data.

After Steve and Sean left, I sent the rest of the time looking over emails and looking into a possible bug on invoices and the new bigger alternate logos for PDF invoices (some new invoice settings).

Steve and Sean were touching base on sales. Steve had a few code questions for me dealing with queries and flow. John joined the called and was asking Steve and Sean about prices and options for clients (pricing structure stuff). Eric joined and was asking questions about gift cards and going over different ideas.

This may or may not help, but I went in and found a bunch of older files that we were had started and worked on dealing with special accounts, loyalty points, gift cards, customer in-store credit, vendor discounts, and other special account stuff. See attached.

Meeting with Steve and Cory to go over projects. We talked about a couple of projects for Eric. We talked about gift cards, other special account projects (in-store credit, vendor credits, punch cards, coupons, and gift certificates or gift cards). Another one is the mini aggregate project to handle inventory quantities per location. The other possible project for Eric is getting back to the enterprise item catalog project. All of those have value and would be great add-on's.

The next major subject was projects that Alan is either working on and could work on. He is one of our top developers and is in demand, because he can do so many things. One of the projects that Cory really wants him to work on is the transition invoices out in ecommerce land. They already exits out there, they just need a little bit of loving. He could also help Steve out with some BioTrack production stuff.

Lots of talk about other developers and what they are working on. It is a challenge to coordinate projects and developers. Lots of moving pieces. We also talked briefly about some projects for Bryan. We are still trying to help our clients transition from billing in the old independent way to dealing with Adilas as a team or an entity.

Another subject that came up was the number of hours spent in a training and tech support with our clients. It takes a lot of time and effort. One of the benefits is that we learn a lot along the way. The more we help our clients, the more we learn, and can adapt the tools and features that we have to get the desired outcome. Along those lines, sometimes we (internally) need to be reminded of certain processes and tools that exist that we may not remember or are new to us. For example, all of Steve's new backorder stuff that he developed and managing quotes, orders, PO's, and backorders.

Cory was kinda putting her virtual foot down on certain projects. We are trying to retain our clients but sometimes they get out of line. We talked about preventative maintenance type stuff with our existing clients and helping them along the way. We, as a company, are offering more and more internal service offerings. We used to sub it all out to outside independent sub-contractors. We are trying to make those same offerings, but do it all internally now and helping out in new ways. It makes for a better product and better retention.

Cory and I going over a list of questions. About halfway through, Steve and Chuck joined us. I think that they were going to meet and work on some look and feel, but Cory and I were on the meeting. Anyways, the question got brought up about doing down payments on stock/units and how to book that and keep everything straight. The real answer is using transitional invoices. Having said that, we went round and round talking about possible options. Towards the end, Chuck was saying that when we redo our fracture stuff, we may need to make it part of the system that a prepaid invoice, deposit on merchandise, in-store credit, and other things be put in place and education and training made available.

For the record, here is how you would do it right now... using a transitional invoice.

1. Stock in the item, even if you don't have it in stock. If it is in stock, use that item. Anything that is unknown, just make a note of that. For example: a serial number or VIN number - maybe use the customer's phone number or email address.
2. Go to the stock/unit and go through the invoice/sale process. Make sure and set it to a transitional invoice (that wording is dynamic - layaway, prepaid, etc.).
3. Do the sale for the full amount and then take the amount that is either pre-paid or deposited. That will start the journey of the stock/unit and the payments received. All of these transactions will auto flow over to the balance sheet (already built-in) if using a transitional invoice.
4. Keep the invoice in the transitional state until it comes in, gets delivered, or whatever. If needed, additional payments (deposits on merchandise) may be made along the journey.
5. When ready, flip the transition invoice over to a real customer invoice and finish out the rest of the info. Once flipped, it will show up for sales taxes, on the P&L, accounts receivable (if money is still owed), and will count against inventory values. Prior to that, the whole thing is held on the balance sheet as the work in progress, pre-paid invoice, layaway, deposit on merchandise, etc. (dynamic naming).

Anyways, the takeaway is for fracture, we really want to have a way to show our people how to do certain tasks (searchable education mode). We also want to have some of the special account stuff like in-store credit, vendor credits, gift certificates, coupons, punch cards, etc. all done and part of the system. Those features may be built-in prior but need to be there. As a note, a lot of those will be sub sections of what we call special accounts, just like the current loyalty points stuff.

Cory, Steve, and I were talking about different projects. We decided to scrap one of them and wait for some other changes to roll into place. I was pitching an MVP (minimal viable product) on some payroll stuff. We chatted about needs there and where it could go. We talked about bulk payroll, special time card aggregates for some of the math, multi-department based timecards, new fields and settings for special programs, and other fields and values that are needed.

As a fun side note, we even talked about mixing payroll functions with special accounts (accrued hours and virtual time based loyalty points for employees and special laws dealing with additional funding and special programs). Special accounts are for things like loyalty point for customers, gift cards, in-store credit, vendor credits, etc. In this situation, we would be using special accounts to accrue or add up additional hours that are earned over time. Then, the employee/users could redeem those extra hours or bonuses, when they wanted. We would have to keep track of values being added to their account, as well as values being paid out or virtually redeemed. This gets into liabilities, and who owes who and the timing that goes along with that. Interesting twist.

Shannon and I were working on the presentation gallery outline. Our topic for the day was accounting. We got to a certain point and basically said "plus, plus, plus" meaning and it just keeps going. I was ready to stop and Shannon kept asking some great questions. Before long, we had more than double what we started with and were still going. I'm really glad that she kept asking questions and having us talk about things.

As a fun takeaway from our meeting, we talked about making conscience decisions and then sticking to those decisions. For example, we often say to people, sorry, but we do it this way vs that way (fill in the blanks). As Shannon and I were talking, we decided that we are not doing this because we have to or we got forced into something. This, what we do and why we do it, is a conscience decision and that's what makes us who we are.

See attached for our brainstorming document. You may have to scroll down to page 18-19 to get to the new brainstorming stuff on the business function of accounting. Just for fun, here are some of the ideas...

- We started out with basic stuff like: balance sheets, P&L's, user-maintained items, system maintained items, accounts receivable, accounts payable, aging, reimbursements, expenses, banks, inventory tracking, layaways, work in progress, loans, etc.

- Next we got into photos, media content, custom documents and ways of connecting with other outside file assets (documentation).

- Natural flow, flex grid tie-ins, payroll, people, deposits, invoices, customers, users, stock/units, floorplan, tons of reports and exports, bank reconciliation, etc.

- Slight switch to more concepts such as: operational lead accounting, mapping, roll calling, translating, where do the numbers come from (relationships and cause and effect options)

- Loyalty points, taxes, sales tax, withholdings, PO's, manufacturing, inventory tracking and manipulation, life cycles, going backwards and forward, and automation.

- Traditional vs non-traditional accounting

- System and how that makes a difference - everything is there and you can start to interconnect the pieces - digital storytelling

- We do accounting because we have good data - the accounting comes from the data

- Tons of permission levels and who gets to see what

- Accounts, ledgers, glossary, terms, and concepts

- Data assembly line, digital story telling, cause & effect, characters interact to solve trouble and problems, more relationships and building, maintaining, and in some cases destroying those relationships. Processes.

- Time - time is a huge piece of the puzzle

- How do we zipper operations and accounting together to close the gap between the two?

- How does the system handle roll call technology, who, how, what, and why???

- If someone can do their accounting by their own design and take it to their accountant (shoe box, spreadsheets, random records) - then why can't I create something that automates and maps out that process.

- We play according to the standards and the rules but we on purpose create the processes to get to those data points.

- Tradition - our biggest competition

- This is daily, real-time, sharing, no batching/waiting, managers and admin can look at things real-time, cloud based, editable, full history, audit trail, cause and effect, cart and horse, data drill-downs, proof behind your numbers.

- Why we chose to build in a non-traditional manner - because we see all the benefits and we want to keep going in this direction - conscience choice

- We are pioneering and we are on purpose creating tools that are proof of concept

- Crazy accounting things like phantom costs, funny money, slush funds, etc.

- Sub inventory and cost controls - perfect costing vs other costing models

- Normal revenue, COGS (cost of goods sold), gross profit, expenses, net profit, assets, liabilities, equity, retained earnings, etc.

- Future - we have a challenge and we build to solve that challenge that is before us - this is part of our accounting model

- Some people expect us to be completely done but we are not done - we are going to keep building and breaking, building and breaking. That is part of our model.

- You really need human input at certain places - decisions have to be made - you really can't automate some pieces.

- Ongoing development - bring your ideas - stone soup "Bring what you've got, throw it in the pot. We are making stone soup."

- Open to suggestions and new growth

- Things that drive change: pain, brick walls, burning platforms - all these pain points help to bring about change and new solutions

- Static vs dynamic - both flow and environment - things are built differently based on the conditions (static vs dynamic)

- Allow for updating inventory counts - how do you deal with theft, shrinkage, expiration dates, spoiling, and other inventory reconciliation stuff.

- In-store credit, accounts, discounts for terms, bonuses, games, vendor credits, etc.

- We give you the tools to play the game

- Accounts, sub accounts, locations, sub locations, phases, sub phases, etc. - details, layering, and stacking (aka space)

- Add notes to anything, able to add log notes and tie things together

- Track the story - the story is powerful - telling the story is your audit protection

- We can and do deal with multi-locational stacked models. We also deal with cross corp stuff and multi-worlds rolling up or down into the respective holding containers. It can get really deep and complex.

- We don't require you to do this... this, meaning how we do and track accounting, is optional.

- From Russell Moore back in 2016 - We can be a good companion with any other software package. Run any part of our application without using the pieces you don't want. We can feed information to any other software package you want to use. Adilas is a great companion software package for ANY business.

- Conflict management - it is okay to stand your ground. Be confident in what you have built and why you have built it that way. We are going in this direction! If you like what we are doing, great! If not, great, feel free to use some of our other products, services, or pieces if you would like. You do not need to apologize for things that are in line with your values and your vision. The vision helps us all work and succeed.

Anyways, fun brainstorming session. We will take these ideas and refine them into a section in the presentation gallery that deals with the business function of accounting. Great session and fun stuff.

Bryan and I met to talk about refunds. Those get kinda funky as each corporation may have different steps, fees, requirements, and processes. We talked about some of the possible variables and looked at some situations and scenarios. We did some negative invoices, talked about validation, and even setup a refund recipe to help automate a couple fees that the client wanted. I think it helped to talk through things. Lots of human variables in a refund, partial refund, exchange, or applying in-store credit.

Got up early and merged in some code from Eric and I's project on the sub special accounts. This is for things like rewards, customer loyalty points, gift cards, in-store credit, etc. Anyways, we had about 50 files to merge in and test. Worked on some new help files for the new pages and sections. I got all of that done and launched code to the data 0 for testing. Everything went well, so I pushed up code to all servers. Immediately, we got some calls and texts and people were getting an error. We jumped on it and had it resolved pretty quick but still had some complaints. We try, I literally tested on both local and live before pushing to all servers. Certain people have different settings and sometimes that affects things. We got it done and then I went to the Adobe ColdFusion conference. Busy start to the morning. 

See some of the attached media/content pieces for an overview and preview of a new feature called special accounts. This is for things like rewards, customer loyalty points, gift cards, in-store credit, punch cards, etc.

Thanks for choosing adilas.biz!

Spent the entire afternoon working on the sub special accounts project (sub of the balance sheet). This will be used for customer rewards, loyalty points, gift cards, in-store credit, etc. Lots of good break throughs today. We added a fix for using application scope variables in the cfc's (ColdFusion components - backend logic pieces), tested the submit cart page, and we added in the account rule that dealt with show/hide the loyalty points on the invoice (customer receipt). We also showed totals on the customer log file with a valid drill-down to see the details. We are making progress. I also added some new notes to the main scratch file for the project. See attached. Good session.

Spent some time working on code sign-off and review for the special accounts project. This deals with rewards, loyalty points, gift cards, in-store credit, etc. Working on the methods inside the submit cart page. Lots of nested logic and methods calling other methods. Things like look up account types, see if they should/shouldn't use loyalty points, how many are earned per invoice, how many are redeemed (spent) per invoice, balances, rules (point values), etc.

In working on sub special accounts (rewards, customer loyalty points, gift cards, in-store credit, etc.). Added some new validation and formatting to the show special account transaction report.

Interesting conversation between Josh and Steve. The topic was dealing with project management and how quickly our developers can be highjacked by custom requests. Steve was recommending that we try to capture all of the custom requests out in the adilas community funded projects vs just having the clients go directly to the developers. There are pros and cons to that... If they go directly to the developer, they (our clients) get things quicker, but it has a hidden cost (called distraction and/or highjacking of resources). If they go through a channel, it has some different pros and cons. One, we could mix and blend and figure out project management, allowocations, budgets, and priorities. We could even match funds and do other things. On the flip side, sometimes, if it gets mixed in with all of the other projects, it may not get done quite as quickly. Pros and cons and each side. It is amazing how it comes back to a balance type dance.

Steve and I had some great conversations about our guys, our process, and where we want it to go. Another topic was dealing with returning and reporting and checking in. Sometimes we have huge projects and we don't get any communication for weeks on end. We are going to try to implement more regular communications. That should help everybody know what is what and where things are at. Funny how it goes back to forming, storming, norming, and performing (team building skills).

Eric joined the meeting and we setup some big blocks of time to work on the special accounts project next week. That is for customer loyalty points, rewards, gift cards, in-store credit, and other special payment or special accounts.

Spent a couple of hours back working on the special accounts project (rewards, customer loyalty points, gift cards, in-store credit, etc.).

Glossary Terms:

A

• Actions/Action Page - Often, when you are on the web you interact with a form. This form always submits its data to an action page, where it performs an action. Normally, this is a database action, report filter, or some other logic function that is performed.
• Accounts Payable - All bills, invoices, PO's and reimbursements that are due to be paid. Money that is owed to others from your company. 
• Accounts Receivable - All customer invoices that are not paid. Money that is owed to your company. 
• Active - A status that designates data as being in use. This status relates to almost every database record, or at least all main players within adilas. By default, the active items show up on reports and searches. Inactive items must be specifically requested, if needed.
• Add - This is a general term which usually means create, multiply, or add on to. Common things could be add a customer, add an invoice - basically this means create a new one or apply an additional one. 
• Add to Queue - This assigns a customer to the main queue (waiting room or waiting list). Often this is used in connection with shopping carts and other service oriented checkout processes.
• Adi - Meet our mascot, Adi! Our blue dog avatar, Adi, is the mascot of Adilas, and encompasses what we are comprised of - a trustworthy, invaluable, and loyal sidekick for your business. She's always ready to help!
• Admin Time Clock - This allows admin users to see all active time cards/hours based on requested parameters. It also gives the ability to edit the time cards.
• Adobe/PDF - See PDF. This is a product made by Adobe which requires a reader. PDF stands for Portable Document Format which is a format that can be read across browsers.
• Advanced Add to Cart - The advanced add to cart function is based on permissions. We sometimes call this the haggle mode feature. You can change prices, quantities, back into things, figure out advanced math, change mark-ups, view profit percentages, apply discounts, etc. Super flexible. Not required, but a very flexible add item to the current shopping cart functionality. Inside the system, it can be accessed by clicking on the double plus (++) link per item.
• Advanced Searches - All main sections or player groups in the system have advanced searches. These searches include far more filter options than a standard search. Often, you can even pick and choose what fields, columns, or values to show. Once the reports are returned, there are save options for viewing these reports later. If you are a quick search user, the keyword adv (short for advanced) can get you to the advanced searches without other actions.
• Age Verification - This is a process of checking the age of a patient, or client, for either viewing and/or purchasing options. If age verification is needed, turn that feature on in the corp-wide settings. This can be for ecommerce (viewing and purchasing) and/or internal processing (check-in, verification, diver license swiping, or other identity checks).
• AI - Artificial Intelligence is tied to a LLM or large language model behind the scenes. Often AI is used to automate tasks, it can use "fuzzy logic" to process natural language and then replace normal speech with computer API calls or functions. Various other options exist as well. This is a growing field, and player, in the computer and web space.
• AI Agent - An AI agent is a special function of normal AI. The agent gets, or is given, access to do certain tasks and/or functions. Often, the agents are trained specifically on a certain task or business function. Inside of adilas.biz, we have an AI agent named "Adi". It has been programmed to help with simple navigation, training, deployment, settings, and even some consulting. The goal is to help it keep learning and adapting so that it will be a master adilas.biz user and consultant.
• AI Context Window - The AI context window is a set number of tokens that make up its available (quick) memory. A good way to think of the context window is like a sliding window that can move over tons of data. It doesn't care about all of the pieces, it is only looking for what matches its context, or what is being requested. Often, the context window tries to stay in the same scope or mode. If needed, the context window could shift, so that it can do other tasks. Another way to think of it is like a Google search. Tons of information out on the web, but the search only brings back what you need. Imagine that happening with AI, but even better and possibly layered.
• AI Image Generator - This is an AI tool that takes normal, written, or typed prompts and then creates an image for you using an AI backend. The system has a number of places that allow for AI image generation. Things like item category images, item photo galleries, etc.
• AI Quick Search - This is a super version of the normal quick search. This interface allows you to jump and do almost anything in the system using a simple form (sometimes called a command line interface). Quick help, prompts, and cheat sheets are available from that page. Imagine a simple Google search type interface for the entire system. Very cool!
• AI Tools - An AI tool is a preset, or preprogrammed function or method. These could be API's, sockets, or special tasks that an AI agent knows how to use. They could also be set URL (web addresses) or form submission functionality pieces. The term tool, or tools, is used to help the AI agent know what options it has to do and/or perform.
• API - An API is an application programming interface. Basically, it's a way for computers to talk to other computers. You can do special tasks, request data, and sync records using API's. Very flexible. Most API's have lots of documentation of what is allowed or required. For security, there are often special keys, tokens, and settings that may be assigned or used. API's also have a master switch that either allows or denies access.
• A/P's - See Accounts Payable. A/P's is an acronym for Accounts Payable, which is an accounting term for who do I owe and when is the payment due. 
• A/R's - See Accounts Receivable. A/R's is an acronym for Accounts Receivable, which is an accounting term for who owes me money and how can I collect it.
• Assets - Any resources owned by the business. Assets are tracked on the balance sheet. Assets are one of three main categories. There are assets, liabilities, and equity. Inside the system, many of the assets are automatically tracked or called system-maintained balance sheet items. These are things like bank balances, petty cash, inventory levels, and accounts receivable. We also offer options for other assets to be tracked on the balance sheet through user-maintained balance sheet items (not automated by system). These may be monies that you loaned out, vendor credits, etc.
• Assign to Cart - This is a button on the customer log page (customer profile page) or some other customer report. By clicking this link/button, it will add the current customer to the shopping cart.
• Authorize.net - An available merchant processing gateway - integration for internal shopping cart, online bill pay (clients paying after the fact), and ecommerce solutions.
• Ctrl A - This is a keyboard shortcut on windows for selecting all the content in a certain area. This is control plus the A key.

B

• Balance Sheet Item - A user-maintained account that stores data on the balance sheet. Your company may create any number of these user-maintained balance sheet items. As a note, there are many automated tasks that the system will monitor and track for you as well. Those are called system-maintained balance sheet items. A user-maintained balance sheet item (BSI) may be an asset, liability, or an equity account. Without going super deep, each balance sheet item gets created, gets a starting value, and then it may be connected to any number of other transactions that either bring its value up or down, depending on what is happening. These are used for financial records on the balance sheet report.
• Bank Reconciliation - This is a process of matching what the system says (deposits and expenses) to what the bank says. Most deposits and expenses have a number of dates. These dates are the creation date (you know about it), the verified date (when the bank knows about it), and a posting date (when it becomes locked down). Most bank reconciliation reports deal with the verified date. Things may be verified one-by-one or there are some bulk tools and processes.
• Banks - Inside the system, a bank is a virtual account where you can track monies going in or out. At least one is required if you want to do deposits or expenses. An unlimited number of banks may be created. Some companies also use banks to help track credit cards and other cash tracking accounts.
• Barcode - A barcode is a series of lines and spaces that make up a unique value. They are often used to help speed up the sales process. Inside the system, barcode values may be added to numerous items including inventory items, special POS buttons, discounts, flex grid tie-ins, and all sorts of other id's or numbers. There are fields to record barcodes, or you may create your own. Inside the system, we allow for numbers 0-9, all alpha characters, and even some special characters. There are also a number of barcode generators and label makers built into the system.
• Basic Live PO - There are multiple types of PO's or purchase orders. A basic live PO deals with vendor specific items that are present or available for sale. Without going super deep, there are other PO types such as special PO's, update PO's, build PO's, request PO's, and others. The name basic live PO may be changed in the corp-wide settings (see section C).
• BI or Business Intelligence - This is the process of gathering up smaller pieces of data and being able to show trends, totals, sums, averages, counts, maxes, mins, stats, and other telling data. Business intelligence is often used by companies to show quick values and even tell digital stories over time. Often BI uses lots of reports, exports, and other graphical representations of the data to help the user easily see what is going on.
• Big Data - Think mixing everything... Big data refers to collecting large sets of data that can then be analyzed to reveal trends, patterns, and relationships. These data sets are often too large and varied to be handled by traditional data processing systems. They require more specialized systems to organize and compute the information gathered so it can be better utilized in business decision making.
• Bit Map Image - This is similar to a JPEG, PNG, or a GIF image. Technically a bitmap means little, tiny blocks of color that are organized in an image format to show a picture of some kind. The other kind of image is what is called a vector, which has smooth mathematical lines that creates its visual appearance.
• Black Box - We use this term to talk about custom code or page level take-overs. These page take-overs allow customer specific functionality as requested. Basically, a black box is one or more insertion points where we can make a change. We do a lot of custom coding for our clients. This is part of the technology that allows for that to take place.
• Browser - Browsers are how all web-based content is shown. There are multiple browsers and some of them are based on your operating system or preference. These are things like Google Chrome, Microsoft Edge, Safari, Opera, Firefox, etc.
• BSI - An acronym short for Balance Sheet Items. It may also be shown as B.S.I. See balance sheet item definition for more information. There are system-maintained and user-maintained balance sheet items. Most of the BSI's deal with the user-maintained items. Think of a miniature account for various things. Some of these could be things such as loans, individual or company investments, large assets like buildings, vehicles, machinery, etc.
• Build & Hold - This term is used inside the recipe/builds section. It is used on the raw goods side. The build and hold process uses raw goods and eventually creates an outcome or other product. Technically, we use other terms such as ingredients, outcomes, etc. This build and hold process is usually a preparatory step and those products may be used farther down the manufacturing line, or to be sold independently.
• Build & Sell - This is another term used inside the recipe/build section. The build and sell process is a quick, just in time, preformatted group or kit. If there are multiple things that are sold together you can create this kit or grouping that you can use just in time on an invoice when you are selling these items.  
• Build PO - This is one of the PO or purchase order types. This used to take raw goods and combine them into one or more new items or pieces. There are multiple PO types such as live PO's, request PO's, update PO's, and build PO's.
• Bulk (in general - edit, verify, etc.) - The word bulk means more than one. In the system it is often used such as bulk edit meaning I am going to edit multiple lines at one. Or bulk verify meaning I am going to verify multiple things at one time. There is also bulk labels, bulk printing, etc. We are dealing with multiples of things.
• Bulk Add - This is a term used to denote adding one or more items to a PO or shopping cart at a time. Basically, you do a search, and then you can interact with one or more of the items that are showing from your search. Once the add button is clicked, the values will show up on the correct page as new line items.
• Bulk Edit - This term is used to modify, update, or edit line items. Usually line items are found on invoices, quotes, purchase orders, expense receipts, deposits, etc. Bulk edit will take you to a special page where multiple changes may be made at once. Upon submitting the form, all changes are stored in the shopping cart (memory) or database.
• Bulk Transfer - This term deals with transfer invoices (in the shopping cart mode) of moving things around. Imagine things in a warehouse and then moving them just in time, on a schedule, or for an event. The bulk transfer is very handy and helps save some time. There are also some bulk transfers that happen if you are doing cultivation, harvesting, or other plan related activities. Those bulk transfers happen on special PO's.
• Bulk Verify - Used to verify multiple deposits or expense receipts at one time. 
• Bump Value Up - The term bump just means move in a direction. Some systems would say debit or credit. We just say bump meaning which direction of flow is it going. Bump up means you are somehow increasing a value or total.  
• Bump Value Down - The term bump just means move in a direction. Some systems would say debit or credit. We just say bump meaning which direction of flow is it going. Bump down means you are decreasing a value or total. 

C

• CartPointe - Available merchant processing gateway and hardware for internal shopping cart, online bill pay, and ecommerce transactions.
• Cart - Where items are placed in order to make a purchase (see also Shopping Cart).
• Cash - Money or bills, also used to talk about certain transactions. Money or cash may be used to purchase products and services or used by your customers to pay for products and services.
• Cash Counter - This is a special page inside the system that allows you to put in figures and it helps you count the total cash. For example: I have 103 $20 bills, 37 $10 bills, 56 $5 dollar bills, 17 $1's, etc. It also works for coin or cents.
• Chart Of Accounts - This is a traditional accounting term, meaning a way to organize different parts of the financials. Often, traditionally, they have a number assigned to them that help them show up in the correct spot for the P&L, income statement, and balance sheet. Think of them like named containers for data and records. Often inside of the system, we use the terms expense types, deposit types, and balance sheet types to mean or reference chart of accounts. Without going into too much detail, adilas.biz uses technology and relational databases to simulate what traditional chart of accounts did (paper/pen or 2D model). Tracking objects and data over time to help them show up in the correct financial documents.
• Check - One of many methods of payment, usually flowing out of a bank.
• Check Requests - A check request is a form of an expense receipt which is almost a question. Can I spend this money? It is similar to how a quote and an invoice are related, a quote is a potential precursor to an invoice. This is the same for check requests and expenses. A check request is a potential precursor to an expense. It does not count toward financials at this point. It requires an approval and once it is approved then it can become an actual expense and be booked on the financials. 
• Child - Refers to items in the database that can be sold. Connected to a parent item (parent inventory) which carries the name and some information. The child item is unique and can carry much more unique information (see also Sub Inventory).
• Chooser - Home page interfaces. 40+ choices plus custom options available. Called chooser because the user "chooses" which one is most suitable to their needs. Once chosen, that page becomes the new homepage. Switch as often as you like based on the task or your style.
• Classic - Interface that shows all potential functions in the system. Not geared toward any particular tasks or industry. There is also a thing called the classic cart - one of the original internal shopping carts. For the most part, classic means original or an oldy but goody.
• Clear Cart - Wipes out all actions related to the active shopping cart. Must perform this action in order to log out of the system, or to start a new cart.
• Clock in/out - Tracks users hourly work. Requires user to be assigned to a department.
• Closed - Potential status of a sub or child item. Once a sub/child item is at quantity 0, it can be closed. 
• Clover - Available merchant processing gateway and hardware for internal shopping cart, online bill pay, and ecommerce transactions.
• Corp ID - Identifying number associated with every corp. Assigned upon activation.
• Corp Key or Alias - A corp key is a combination of three letters of the corporation name, a dash, and then a numeric corp id number. For example pla-0053. Pretend that this company's name was Playground and the Corp Id was 53, this could be it's corp key. The alias is like a username for the corp instead of the technical three digit plus numeric. An example for this one could be something like testing or playground. 
• Corp-wide Settings - Admin level settings that affect the database on a corp wide level. Options for setting system wide naming conventions, tax settings, discounts, etc.
• Corporation - This is a virtual world inside of a system. Corporation is also synonymous with entity, business, company, etc. Usually a corporation can have locations and different things within it but it is usually a tax entity. Often in the system you will see us use the word corp as a shortened form of corporation or business entity. 
• Counter Sale - Shopping cart that is not assigned to a customer. Used in sales situations where the customer is unknown and does not need to be.
• Create - This is another word for adding or making something new. For example create a new my cart favorite button or create new invoice link. 
• Cross Corp Invoice to PO - Special function that must be added by a system administrator (fees associated with this function) that allows one corp on the same server as another corp, to send inventory via an invoice. Both corps must agree to connect, then one makes an invoice, and the other turns that invoice automatically into a PO.
• CSS - This is an acronym for a web look and feel tool called a Cascading Style Sheet. The CSS of a site dictates colors, roll overs, margins, spacing, font, and other look and feel pieces. Inside of the system/platform we allow you to change a lot of these.  
• CSV - Comma Separated Values is a simple file format used to store tabular data, such as a spreadsheet or database. Files in the csv format can be imported to and exported from programs that store data in tables.
• Ctrl A - This is a keyboard shortcut on windows for selecting all the content in a certain area.
• Ctrl C - This is a keyboard shortcut on windows for copying a certain selection and putting it on the clipboard for future use. Ctrl V is used to paste.
• Ctrl N - This is a keyboard shortcut on windows for creating a new tab in your browser window. Often you can do the same thing by right clicking a tab and clicking new or duplicate, etc. 
• Ctrl P - This is a keyboard shortcut on windows for printing a certain page.
• Ctrl V - This is a keyboard shortcut on windows for pasting a certain selection held in memory. Either Ctrl C or Ctrl X are the ways of copying something to memory. 
• Ctrl X - This is a keyboard shortcut on windows for cutting a certain selection and putting it on the clipboard for future use. Ctrl V is used to paste.
• Ctrl Y - This is a keyboard shortcut on windows for redoing something that has been undone. It's brother command is Ctrl Z or undo.
• Ctrl Z - This is a keyboard shortcut on windows for undoing a previous action. It's brother command is Ctrl Y or redo.  
• Ctrl + - This is a keyboard shortcut on windows for zooming in on the webpage or browser. This is control plus sign (+). 
• Ctrl - - This is a keyboard shortcut on windows for zooming out on a webpage or browser. This is control minus sign (-).
• Cultivation - This is general term dealing with plants and herbs. Cultivation usually means the entire of process from planting, cloning, growing, and harvesting.
• Custom - This is a broad term and can be used in many different ways. Often we use custom to refer to custom code, custom look and feel, custom flow, or custom processes. Also we use it generally to say we could add that in but it would be custom, meaning it would be specific to your needs and wants and go through a process of design and development to meet your needs. 
• Custom Logic - This is part of custom code but the term custom logic usually resides more toward the top of the page. It is like the brain for the page. This is how we control what is happening or could happen on a single page. You may often hear us say, "We could black box that." Meaning we could add code and logic at an insertion point to make the page perform custom actions, logic, flow, or other code related options. 
• Customer Queue - Customers waiting to make purchases can be placed in line or a queue so that they are seen in a first come first served order. Multiple queues can be used to designate customers as VIP, Pickup, etc.
• Customers - The people or companies you sell items or services to. There are settings inside the system to allow you to name your customers as you see fit. Examples: clients, members, students, patients, buyers, VIP's, guests, etc.

D

• Dashboard - A dashboard is a special interface that shows quick access buttons, charts, graphs, and stats. They come in all kinds of varieties but basically speed up commonly used functionality. Usually, there is some representation of the underlying data in some sort of summary, count, total, or other aggregated function. Often, users like to use dashboards to speed up processes and/or control their layout and space (what they like to see and/or use).
• Data - This is a generic term for digital information. It could mean all kinds of things. A real-time data portal where you can cache, send, upload, and archive your data.
• Data Table - This is a special kind of web table that allows for special exports, local searching, sorting table columns, and a thing called pagination (next or previous page). Great for showing tables of data or tabulated data (reports with rows and columns).
• Database - This is a background storage engine that holds all of the data tables, rows, and columns. The database engine that we use is called a MySQL server. This database server is very robust and can handle millions and millions of records, queries, and actions at a single time. Technically the database is that storage engine but sometimes we generally refer to it when discussing data or the storage area. For example, when a cart is fully submitted it transfers from session memory into the database.
• Default Homepages - Every user gets to set their default homepage. This is where you land, or are taken to, when you click your logo or home link. Think of this as your virtual starting spot or home base. The reason it says homepages is there are hundreds of choices that you could set as your default. As a side note you can also switch at any point to facilitate the task at hand. The original goal of this was like a person with a shed in their back yard. If they are paining they want painting stuff from the shed, if they are doing yard work you want yard work from the shed. Depending on the task at hand you may want easier access to options and/or tools. If you want you can even have a custom dashboard or default homepage made. 
• Default Settings - The system has a base of permissions and settings. This is how things interact and are used. A default setting means where it was set originally without any interaction or where that setting has currently been set to. Often these default setting will be changed based on needs, wants, or dictations from administration or higher authority. Settings come on a corporation level, a player group level, a page level, and even on a user level. 
• Delayed Inventory Counter - Used to count parent inventory by scanning barcode and entering quantity.
• Delete - This is the act of making something go away. Inside of adilas, most delete actions or remove actions occur by changing what is called a status from active to inactive. This is how you hide/show or use/don't use certain items. All main player items and their subs have status fields inside of adilas. Once you get into a multi-relational database, you don't really want to do real deletes and start making holes all over you data. Inside of adilas, most things are deleted by changing a status value.
• Delivery - This usually means that an invoice or order needs to be delivered by a driver or carrier. If your company uses delivery options, they may be setup in the settings. If not, no delivery options will show up. Some delivery options include vehicles, sales staff, travel routes, estimated times, etc. Delivery is also sometimes used by or from external entities that need to pick up products and then make those deliveries.
• Departments - Used to organize employees. Allows employees to utilize the clock in/out function (see above).
• Deposits - A total amount of money that flows into a bank.
• Deposit Types - Chart of accounts for deposits. System comes with several options and the user creates the rest.
• Dewy Decimal System - This was a funny name used as a code name/alias for a project to take functionality from 2 decimal points to 5 decimal points. Sorry librarians, no pun intended. ;) This was just taking numeric quantities, costs, and prices to multiple decimals of accuracy. 
• Direct Deposit - This is when a company sends or wires money directly to someone's bank account. This could be for payroll, commissions, or bill payments.
• Disabled - One of the three statuses that refers to items and their ability to be sold or not sold. In this case, when an item is disabled, it is part of inventory but is unable to be sold (on lock down until enabled).
• Discount Calculator - Feature in the shopping cart that allows salesperson to discount items by dollar amount or percentage. Discounts can be by line item or added to the shopping cart as a whole.
• Discount Engine - Used to create reoccurring discounts. Settings determine if discounts are by category or item, and if by day, date, or time.
• DPI (Dots Per Inch) - This deals with image resolution both on screen and for printing. If you are printing something you want your DPI higher. If you are just viewing it on screen usually 72 DPI is enough for your eye to catch on the screen versus images for print are usually printed at at least 300-600 DPI. 
• Drill-Downs - This is a term for navigating through layers. An example might be you doing a customer search and it returned a number of customers. Then you would drill-down on the associated link to see their details, or drill-down to see their history, or drill-down to see other information, etc. 
• Due Date - This is used on invoices, statements, expenses, and other key documents. A due date is when something is due. In business, usually that means a payment is due. Inside the system, there are various fields and search options for due dates. If you or your company use due dates for your customer/clients, they may be setup in the corp-wide settings. Once setup, they will be available in the cart, quotes, and invoice sections.
• Duplicate Invoice to New Cart - Allows user to take an existing invoice and create a new shopping cart that is exactly the same as the original. Great for repeat sales in certain industries.

E

• E-Commerce - This is any sort of online web presence where you sell your goods and services over the internet. The software has both free and paid versions of ECommerce that are fully integrated and built in for our clients. Some of the cool features that you can harness are mobile ready, bill pay - where customers can come in and pay some of their bills, photo gallery, expanded descriptions, technical specs, automated emailing, and tons of custom display options.
• Edit - Function associated with all aspects of database- customers, vendors, items, banks, e/rs, deposits, invoices, etc. 
• Edit Line Items - Makes changes to the line items (second section) that have been added to a PO, deposit, invoice or E/R. 
• Edit Main - Makes changes to the main section (first section) of a PO, deposit, invoice, or E/R.
• Edit Payments - Makes changes to the payment section (third section) of an E/R or invoice.
• Elements of Time - May be defined by your business. Giant toolset that can be customized to meet your needs. Customer time clock, an appointment book, a scheduler of sorts, a dispatching solution, a payroll timesheet for employees, a mini blog, a general reminder system, etc. You name it, you set it up, and then you get to use it over and over again. You can search it, display it, add to it, create new templates, invoice time, quote time, and generally work with almost anything that has a time element associated with it.
• Employees - An employee is technically someone who works for a company. Inside of the system employee is a term that is used for persons who use the system and have permissions inside the system. Employees may have time cards, payroll, permissions, settings; they can also be used on expense/receipts and PO's and in these instances can be used virtually like a vendor. They also populate the salesperson list. 
• Equity - Equity is a section on the balance sheet which means some sort of long-term value. You can have different things like owner equity, paid in equity, investments, worth and distribution of wealth.
• EOT's - See Elements of Time. EOT is an acronym for Elements of Time. Another term is Time. When you search for time you are searching for an Element of Time. Technically you can have unlimited number of templates which are like cookie cutters. And then you can make an unlimited amount of cookies from those cookie cutters. It can go very deep.  
• ER's - Expense Receipt- these words used together mean any total amount of money that flows out of a bank.
• Expense Types - Chart of accounts for expenses. System comes with several options and the user creates the rest.

F

• Favorites - There are two primary ways that we use the word favorites in the system. One is a list of saved reports called your favorites. Another one is actually where favorites is a shortened term for My Favorite Buttons which are graphical point of sale buttons. 
• Flash - Flash is a shortened term for an Adobe Flash player. Flash has been used on the internet since early times. It could as simple as animations, special buttons, rich interfaces, etc. The software application uses Flash for navigation screens, check writing, barcode generating, and my cart favorite buttons (customer point of sale buttons). Sadly, flash was discontinued by most major browser. We really liked it for multiple parts of the system.
• Flash Bubble Interfaces -  There are three Flash interfaces that were designed my Russell Moore that may be used as default navigation homepages. They have special features such as rollovers, sliding menus, and drop downs. Sadly, this interface no longer exists due to browsers no longer supporting flash interfaces.
• Flash Buttons - Once again these are a shortened term for the my cart favorite buttons. Custom point of sale buttons setup by companies. These can be named, organized, colored, nest them, group them, preset settings, setup special pricing parameters, etc. These are often used as standalone sales buttons or in the split cart view. Split cart has one screen of buttons, and the other screen shows the cart so that you can see what has been added to the cart. Sadly, these flash buttons have been replaced with normal web buttons, due to browser support.
• Flex Attribute - This is a custom field or fields that allow you to setup custom naming and data types for special fields. Flex attributes are somewhat like a database extension. Meaning, if you need a field or value tracked that doesn't exist, you simply create it. Those values are then searchable, and you are able to track that extra or special data (flags, tags, custom data, and other options).
• Flex Grid - Allows a user to custom code up to 30 fields per each main section. In short, flex grid allows the user to add additional tie ins, database fields and notes. This may be setup in a one-to-many relationship and allows for interconnecting different pieces within the system. Admin settings allow for limited fields to show up for simple add/edit processes. Very flexible and help with custom data tracking and reports.
• Footers - A footer is anything that happens on the bottom of the page that is consistently there. Usually such things as navigation, branding, logos, copyrights, or other consistent notifications. 
• Form/Submit Form -  Anytime that a user can interact with a website is usually in a form. The software application has tons of web forms. Without getting super detailed you can have text fields, number fields, drop downs, text areas, radial groups, list boxes, check boxes, toggle switches, buttons, and other form features. The submit part of a form is when it actually gets sent back to the server and some sort of action takes place such as a search, an add, an update, a commit, a continue, etc.
• Fracture - This is a code name for a future buildout of the adilas.biz application. It involves all kind of toggle on/off settings, aliases, deeper code structure, and ability to customize anything. The term fracture came as we started seeing main components and pieces start sub diving into subs or fractures. There are whole pages about what this means - future buildout and master plans - also called adilas lite - https://data0.adilas.biz/lite/
• Fulfillment - This is the act of finishing or fulfilling an order or invoice. Fulfillment is a step in the process. Within the system, there are special settings and pages to help with this functionality. Often, once something has been fulfilled, it gets stamped or approved and then passed on to the next stage or phase.
• Functions - This is a general term that could be used for what is your business function meaning process or flow. It could mean a logic decision behind the scenes - pass this variable to the function and you will get this result. It could also just generally mean how do things function meaning how do things work, how does it interact. Another term that we use sometimes is if you are dealing with API sockets (Application Programming Interface), we will often talk about the socket as if you are calling a certain function. 

G

• Gallery - A gallery is usually a collection of things most often photos, media/content, files, some sort of digital content. All of the 12 main players have their own galleries. Most galleries are tied to individual items within the groups. 
• General Tie-in - This could be one of two things. It could be talking about a thing called a flex grid tie-in which would be additional data related to the main item. Another reason we use general tie-in is if we don't know where the connection is going to go it can be tied to all sorts of things. Basically, the tie-in means a relationship and general means you will need to categorize it.
• Gift Cards or Gift Certificates - Gift cards deal with selling a future I owe you to a customer or client. The value is held on the side until it is redeemed or used. Gift cards and gift certificates are part of the section called special accounts. This section deals with loyalty points, gift cards, vendor credits, in-store credits, and other miniature tracking accounts. Once turned on, this functionality is available at no charge from within the POS system. Your company is in charge of the actual cards (if using a physical card), but the tracking and usage of the system is built in.
• GIF Image - A GIF image is a graphic and is considered to be in the Bitmap family. They have somewhat of a limitation on colors but they can still go up into the hundreds (like 256 colors). Some other really good benefits is they can have a transparent background and they can contain small animations.
• Global - This is a general term. We use it in a couple different ways. One would be a global variable meaning it is available for all. We have global settings which are generic across the whole system or a starting point. Then dealing with a world-building concept - global means within a world what is the style, attributes, presets, etc. for that world. All of these uses indicate broader or more general terms. 
• Global Context - This is a term that often refers to AI or artificial intelligence. The global context is a term that deals with the overarching what, when, who, why, and how type values. Global context helps the AI figure out what goes where. Lots of moving pieces, but basically content to keep it aligned with the current or programmed tasks or functions.
• Go Mode - This is a special keyword to help the system use the most possible navigation options. There is a feature inside of adilas called the quick search. It exits on every page in the system. If you use the quick search, you can jump and bounce to any other part of the system. If you type in the keywords "go mode" into the quick search, it will take you to a special page that is programmed to show you almost every possible option in the system. Some people like to select this page as their main homepage from the chooser. It's that fast... Go mode is for let's go! Super powerful search page.
• GPS - Global Positioning System. Basically, inside of the software application, GPS can mean a physical location like an actual GPS or sometimes it is used as a term for a virtual locator of where I am in this world or in the system. Indicating a location, such as I am in invoices or deposits, etc. A cousin to GPS is something called an RFID tag. Both of them use some sort of X, Y, and Z coordinates but the main difference is that GPS is over a broader spectrum and RFID is in the confines of some smaller geo-fence but you can still tell where things are moving and can track things in spatial ways. 
• Gram Counter - Control added to the shopping cart for the cannabis industry that helps salesperson stay compliant in how much cannabis they sell to a customer. Multiple varieties exist based on requirements of the state of operation.

H

• Half Baked - This is when a product or feature is mostly done and/or partially done. Haft baked means it still needs a little bit of loving to make it perfect. Sometimes features are released in a beta or trial version. We call that half baked or half-baked.
• Hardware - Technically this is computer peripheral type term. It usually means something that physically exists or something you physically connect to a computer. There is a physical aspect to it. You can see it, touch it, connect to it, it can contain it's own programs and software, etc. Some common pieces are laptops, desktops, monitor, disc drive, scanners, printers, and so on. Almost anything that has a physical component and an electronic piece that can be associated with a computer is called hardware. 
• Harvest - Part of the plant cultivation cycle. This is when you take a part or all of a plant and turn it into something. If you company does this type of process, there are special tools inside of the system to help with the harvest process.
• Hash - The word hash has a number of different meanings. Usually inside of a computer system a hash means a small encrypted value that may be de-crypted or decoded by the computer. A way to make something non-human readable but still decipherable to a computer with the correct codes to unwind it. A general term for hash is a mix of things that gives you a new item or output at the end. 
• Headers - These are usually at the top of the page and have a reoccurring look, feel, theme, navigation, search options, menus, etc. It is basically a way of standardizing multiple pages to look similar - you can use or create a header. 
• History - History inside of the software application takes on numerous different flavors. History could be just what happens over time. It could also be user interactions, cause and effect cycles, check points, etc. The history is also a shortened word for the audit trail, the log files, and the decision trees within the system. Most histories inside of the system are unalterable - they are caught and monitored behind the scenes as actions take place. History inside of the software application can take on a couple different forms - effectual, historical, financial. These are all aspects of history but they all have a little bit of their own flavor. 
• Homepages - This is a web term for a starting spot or a spot that has like pieces. What we do is allow everyone to start with their own homepage or starting area. This allows them to navigate the system or have quicker access for the features they use. The other use of the term homepage in the system is for each of the 12 main players. All of these 12 main players have their own homepage or main hub for the features associated with that player. Such as invoice homepage, PO homepage, expense/receipt homepage, etc. Sometimes these are called sub homepages. 
• Hover - Action used to view links in the database. At the top of every page user can 'hover' over the main links to access myriad other pages in the database.
• HTML Buttons - There are two different terms for HTML buttons. Any form inside of the system technically has an HTML button to help it submit or do any other process. The other use of the term HTML buttons deals with my cart favorites and this is a comparison between Flash buttons or HTML buttons - meaning how the buttons are generated. 

I

• Ice Down - This is a term for basically permission based locking. This goes back to an analogy we use with liquid water turning more solidly into ice. As data in the system becomes more firm or set it virtually gets iced down. 
• Inactive - A status that designates data as being out of use. Inactive means remove, hide, or don't use. Inside the system, a status of inactive is how you virtually delete things. When inactive, data will not show up in searches and reports by default. A user must specifically request to view inactive data.
• Interactive Map - This is a graphic that shows a lot of the key elements inside of the system. A number of different departments, homepages, areas that have their own tools, etc. It is one of the standard navigation homepages. It is also used often for training when we are trying to show flow between the different areas or departments. The help file for that page goes into major details as to why things are organized on the map the way they are. 
• Internal Build PO - This type of PO is used internally to take raw goods and combine them to create something new (kitting, packages, groups, mini manufacturing, etc.). For example, say you wanted to make a cake, the raw goods might be flour, sugar, eggs, butter, etc. The internal build PO would subtract the raw goods from inventory (negative quantities) and create a new product called cake or cookies (positive quantities). This PO type has it's own permission and is very powerful.This same PO type is used by the system when using the internal recipe/build process. The recipes are basically a pre-set group of ingredients, parts, items, and/or outputs. These recipes are called "build and hold" recipes. The internal build PO may also be used when taking a certain part, painting it, heating it, cutting it, chopping it, combining it, or somehow changing it into some other part (any type of mini manufacturing). This PO type, internal build, is how you physically control your inventory counts. Similar to the update PO, this PO is not vendor specific and does require a special permission to use this PO type.
• Internal Repair - This deals with a stock/unit. Basically it makes an internal serialized item become a customer and you can use anything from your shop or store and attribute it or apply it to that specific stock/unit. 
• Invoice - Use to record a sale of any item or service to a customer.

J

• JPEG Image - A format for compressing image files. Every form in the database has a storage space for jpegs that can be accessed from the photo/scan button.
• Jump - This could be a couple different things. Often we will use the word jump to indicate some sort of motion or movement. This could be let's jump into this or jump to this place on the page or somewhere else in the application. Sometimes we use the same phrase when we talk about using the quick search inside of the system to navigate somewhere. So while this is an action term indicating movement and navigation it can also refer to times when you skip multiple steps by clicking or jumping somewhere. 
• Junk - This could refer to email, junk email. It could also refer to doing something which you are going to get rid of. Or it could be if you are putting garbage into the system, you are going to get garbage back out. This refers to putting bad data in the system - junk, garbage. 
• Just in Time - An acronym for this is JIT. This was originally developed in manufacturing and operational warehouses. Now it has been modified and is used in all kinds of things such as just in time inventory management, just in time bill pay, just in time project management, just in time communications, and so on. Instead of planning and preparing everything out to the nines sometimes you can do it just in time which saves both time and money and is an efficiency factor.  

K

• Keep - This is usually some sort of an action where you are maintaining or keeping something for later use. It could also involve something that you do continuously - for instance keep clicking on this, keep drilling down, keep refreshing, keep checking back, etc. Saying either save that or continue on that path. 
• Kill - This is a general term usually meaning to delete, destroy, make inactive, hide, etc. It is a general term that means to get rid of something. Other times you might talk about if it is going to kill the system meaning too heavy of a load, too intense, too many sub details, etc. 
• Knock knock - Who's there? It could be a joke but actually we use it in computer speaking when we are trying to gain access to API sockets. You play knock knock with the server. The server responds who are you? What do you want? Then you have to respond that those questions/requests. It is kind of a back and forth protocol.
• Knox Report - Special sales report for invoices and payments made. It has the ability to show quick stats, counts, and other math totals. You can also run comparisons on different date ranges if wanted. The original report, and all of the columns and/or numbers, were requested by an operations manager named Phillip Knox, out of Canada. Thus the name. It's really just an awesome sales report.
• KPI or Key Performance Indicators - These are a set of values (totals, counts, averages, sums, etc.) that are used to determine how things (people, processes, or campaigns) are doing. Some of these KPI's are used on reports, dashboards, and in other areas. Basically, someone setups up a rule and and benchmark goal. Then things are evaluated based on those key performance indicators.
• Kush Cart - This is a version of the internal shopping cart. The three main versions are the classic cart, the Kush cart, and the mini scan cart.

L

• Labels - Can be printed via browser settings from multiple locations in the database. Item labels can be used to add items to the shopping cart, item labels can be printed from within the shopping cart for certain industries, labels can be printed for plants from the cultivation homepage.
• Label Builder - Special application and/or functionality to help with custom labels. Inside the system, there are various label builders. Some are very basic (auto linked from specific pages to the label generator) and other allow for all kinds of drawing, graphics, dynamic text, colors, rotation, barcodes, QR codes, custom naming, saving, etc. Multiple versions, based on needs.
• Liabilities - Financial obligations of a company. Tracked on the balance sheet.
• Line Items - "Meat and potatoes of a form." Can be inventory items on a PO, expenses on an expense receipt, and invoice sales on a deposit.
• Link - A link could be an actual web link where you go from page to page. These are often used in navigation or drill-downs. A link could also be things that get connected or tied in. Such as an invoice might be linked with a customer or an item is linked with a PO. Another definition for link is an item within a chain of a process. What are the links that it needs to go through?
• Locations - Way to sort inventory, allocate sales tax rates, organize operations in the database. Completely dynamic.
• Lock - A lock usually means that something becomes more secure. It could be locking people out, locking things down, it could be advancing something so that people with lower permissions cannot access or see it. Another example could be a system being put or going on lock down - like the system or a database table. A lock is used to inhibit access. 
• Logout - Function that allows a user to leave the database. Once logged out, another user can log in from that computer. Note.. logging out does not clock out the user.
• Logs - Associated with customers/clients. Area where notes may be kept for historical reference.
• Look and Feel - Basically this deals with what you see. Your interface colors, your color choices, your navigation buttons, your interface layout design, your defaults, your style, etc. The software system allows for all kinds of dynamic colors, fonts, watermarks, graphics, logos, and styling to help with your look and feel. 
• Look Back Date - Usually this means that we are going back in time to look at data or content. Very common for inventory levels, sales, and balance sheet items.
• Loyalty Points - This is the process of assigning points and values (dollars) to a customer or client who purchases from you. These loyalty points can have ratios (how many points for how many dollars spent), date rules, redemption rules, etc. Inside the system, you have to turn it on, but the system will automate this process for you (checkout, accumulation, redemption, etc.). The bigger section is called special accounts and deals with things like loyalty points, gift cards, vendor credits, in-store credits, etc. The use of loyalty points, in the system if built-in, once turned on at no extra charge.
• LPI (Lines Per Inch) - This is a printing term that deals with resolution. Another common one for this is DPI which is dots per inch. Often computer screens and printers deal with DPI where LPI is for professional print shops.

M

• M terms connected in the sub notes below - click to view whole document

N

• N terms connected in the sub notes below - click to view whole document

O

• O terms connected in the sub notes below - click to view whole document

P

• P terms connected in the sub notes below - click to view whole document

Q

• Q terms connected in the sub notes below - click to view whole document

R

• R terms connected in the sub notes below - click to view whole document

S

• S terms connected in the sub notes below - click to view whole document

T

• T terms connected in the sub notes below - click to view whole document

U

• U terms connected in the sub notes below - click to view whole document

V

• V terms connected in the sub notes below - click to view whole document

W

• W terms connected in the sub notes below - click to view whole document

X

• X terms connected in the sub notes below - click to view whole document

Y

• Y terms connected in the sub notes below - click to view whole document

Z

• Z terms connected in the sub notes below - click to view whole document

Back on the loyalty points, gift cards, and in-store credit project. It has been on the side lines for a couple of months. Back in looking around on the sub special account tracking project that includes the loyalty points, gift cards, etc. Took about an hour to review notes, get back to the correct branch, look around and find a spot to start back in on the project. I would call that transitioning.

Spent the rest of the time doing code review, checking, and moving forward. Started back in on the corporation special account transactions homepage.

Pretty quite meeting this morning. Dustin checked in and then bailed out. Alan jumped on and gave me a small report. We also spent some time looking at the custom tables for holding sub inventory attributes. We talked about some possible rework options and helping that process. We logged into a server and looked around at database activity, column counts, row counts, and basic database stuff.

I got back on the code review and code sign-off for the special account tracking project. This deals with things like customer loyalty points, gift cards, in-store credit, etc.

Back working on the code sign-off for the sub special account tracking project (customer loyalty points, gift cards, in-store credit, etc.).

Got a call from Bryan and we had to jump onto the SWC dedicated server to check on a database problem. We found a locked table and had to reset the database server.

4.32 - Gift Cards, Rewards, & Loyalty Points

-Tons of custom options are available. Often these reward programs have some corporation specific flare.  

-The Adilas standards are still currently under construction. Expected release data first quarter of 2019. Some of the standards will include: loyalty/rewards, gift cards, punch cards, in-store credit, vendor credits, etc.

-Technically all of these special account types or payment types are subs of the balance sheet. Behind the scenes all of these accounts will be run under a general title called sub special account tracking. Within that we will allow you to name the special programs according to your needs. For example, if you want to call your gift cards XYZ Bucks, that is totally fine.

-All of the programs that get setup will automatically inherit a default set of rules. Then we will let you modify those rules to match your company. This may be custom naming, special ratios, values, redemption exceptions, all kinds of rules, etc.

Working on the special account transaction homepage. This is part of Eric's special account tracking project (sub of the balance sheet and deals with customer loyalty points, gift cards, and in-store credit type stuff). Made some headway on the special account transaction search and homepage (what are the individual recorded details).

Also helped Shawn with getting back into the invoice due date project.

It must be Monday... We started out on the morning meeting and only Steve and I were on at first. We chatted about the transition over to the AWS (amazon) stuff. We have a number of questions and aren't really sure which way to turn. Steve needs to provide some of our clients with an answer, can we service them or not, and we need to know how long it will take to get the AWS stuff fully up and running. Lots of unknowns, but some great potential. Part of us wants to return to what we know (older stable ground) and the other part of us wants to keep pushing forward (new and uncharted but promising ground). It creates an emotional battle of sorts.

We switched gears and Steve had some questions about a project where he is tying in balance sheet numbers to vendors. As part of his project, he was trying to come up with a switch that we could flip to help us know if a vendor was an inventory (parts or items) vendor or just a normal vendor. As we talked about it, we decided to take it out to an app type level (the 12 main system players). We talked about that and Steve liked that idea. I got him some code to help him get started. It is amazing how much, as we keep going, that the system keeps organizing itself into main player groups and what kind of relationships are needed per system or main player group. Very interesting. Almost like it likes to be organized into groups and related functions. We sure have learned a lot along the way.

Alan joined the meeting and we were talking about some of his projects. He is still working on automating some of the reoccurring invoice stuff. We also talked about having Bryan work on the dynamic field names and settings per main player group. That is pretty deep and we may keep it tabled for now. Also, as we were talking about it, we were talking about how an object oriented programming approach may be a better solution for some of these new settings and defaults. Currently, we build and break, build and break (speaking about pulling and accessing settings). It may be nice to keep and hold some of the persistent or permanent settings and features. An object oriented model may be better equipped for that type of transaction. Currently, we look things up just in time. In the future, we may need to catch and hold those settings and maintain them in the user's session (stored in memory) options.

Eric popped in and we did some check in and follow-up with his code review on the sub special account tracking project. This project is a sub of the balance sheet and deals with special accounts (mini bank account type objects) like customer loyalty points, gift cards, in-store credit, etc. That project is promised by next Monday. I will be trying to focus on the code sign-off this week.

After that, Eric and Steve and I started talking about some of the new look and feel, CSS, and user interface stuff that Eric is wanting to help with. Both Steve and Eric were talking about a virtual "Adilas Cafe" or a global landing spot for the adilas users. This all goes back to separating the users from the main application code. There will still be a tie-in, but we are seeing a bigger need to keep users on the outside as a single entity and then allow them to go in and work or be a part of a corporation. We have many users that  have and/or will need access to multiple corporations, and even be able to bridge across physical servers. Currently, our model is based on users per server and then tied to corporations based on active permissions to those corporations. We are seeing a need to break that down even further and have a master or global user id (virtual pool of users) and then allow them to be bridged to different corporations on a more global scale vs just per server (physical box) vs the possibilities of dynamic cloud networks.

As we got deeper into the conversation about the potential of the Adilas café type model, we were talking about doing mock-ups, flow charts, etc. Eric had some questions about authentication servers and how that would all roll into the mix. We told him that he would need to get with Wayne to get more details. As we talked, we decided that Eric and Wayne should work together in a mini team type environment. As we explored the options, some of Steve and I's concerns (listed at the top of this entry) started to go away. We ended up somewhat asking Eric to be a project manager type role for this transition project between Newtek and AWS. That little tweak in the plan and how the developers were paired up, made a ton of difference and some of the anxiety started to go away.

We need to crate a list of specs for Wayne and what we want the application to do. Plan and play as if for years. We also talked about in-house coordination and communication. That is a huge key and helps all parties involved. Steve was talking about skating to where the puck (pretend we are playing hockey) is going to be. He and Eric were talking about the existing login pages and the corporation chooser page as being the beginning of the adilas café (landing spot or centralized common ground area). Good discussion.

We would really like to keep pushing the ball forward and making each system its own entity. This means having a centralized database controlling users and access to different corporations and/or entities and then having the individual entities having their own database or system for just their stuff. Currently, there are a number of tables that are shared between parties. For speed and efficiency, we really need to split things up more. This may also affect how we are able to bill for storage and processing vs a set monthly system fee. Anyways, as the conversation progresses, Steve and Eric were talking about using the choose corporation page as the starting common spot or commons area. Steve was also saying that he would like the users to be able to go to work (assigned or authorized corporations) as well as go play (demo sites, play grounds, or play sites). Basically, anybody could have an adilas account, and then they could either go into a real site (aka work) or a play site (aka play and testing). Fun ideas.

One of Eric's and Wayne's first item of business will be to do a virtual inventory check of where things are at on the project and what will still be needed and/or stands in the way. That will be awesome. It really was an mini answer to prayers that we decided to team up Eric and Wayne. It helped us let go and be willing to embrace some of the unknowns. As part of that, we are hoping that having the guys work together in mini teams helps us prioritize what really needs to be done and when. Sometimes, by yourself, it is hard to know what needs attention first, especially if it feels like everything is vying or trying to get the input, attention, and/or priority. Crazy stuff, I'm been there before and will be back again.

Steve and I talked about cycling through hardware and how that is just part of the line of work we are in. Later this year, we will need to buy some new laptops and upgrade some of our development environments.

One of the breakthroughs for today was the mini team concept. We have Steve and I, Steve and Dustin and Josh, Brandon and Alan, Wayne and Eric, Shari O. and Pat and Drea, etc. There are starting to be all kinds of little teams. That is awesome.

Shawn popped in and reported on some payroll updates and changes. We scheduled a time to meet again tomorrow. He is also willing to help me out with some of my projects and such. After that, I spent the rest of the session recording notes and trying to get caught up (as good as I could).

Josh joined the meeting and we worked through a few small things. He has 5 files that needed to be looked at. We talked about a few things and he will be reporting back in tomorrow for the final sign-off.

Wayne jumped in and had some questions about where and how we are storing images. We talked about what it would take to get all of those images pushed out and stored on the adilas content server. As part of our conversation, we did a quick search to see how many pages may need to be updated. We got a number around 340 pages that deal with images and/or image paths. All of those files would need to be updated.

Back on the code review project for Eric and the sub special account tracking stuff - sub of the balance sheet for things like loyalty points, gift cards, in-store credit, etc.

Shannon and I met and talked about progress. I shared with her that we have 4-5 big projects that are coming into play in the next little while that all have a balance sheet flavor of sorts. We went over those pieces and how they play in. Some of the projects are: expand the transitional invoices and adding in inventory in transit (shown as an asset), new transitional PO project that Will is working on (in code sign-off but stills needs a little work), sales tax expansion project (on phase 5 of 5 and just need to finish some things up), Eric's sub special account tracking project (sub of the balance sheet for things like loyalty points, gift cards, in-store credit, etc.), and sub inventory with mini conversions (deeper inventory tracking and how that affects the balance sheet).

I also spent some time drawing out some changes that are coming with our transition out to AWS (amazon web services - new web hosting model) and things that Wayne is working on. I drew our current model and also what I know of the newer AWS model. We talked about pros and cons and I tried hard to help Shannon know where things are going. Some exciting stuff coming down the pipeline.

We talked about the concept of filtering and boiling things down and using a funnel type analogy to get towards the goal. Sometimes it takes years and years, but we are still making progress and learning along the way. We ended our meeting by using a quote from an author (different Shannon - Shannon Hale) - "There will still be time..." Sometimes that really helps me out, if I'm stressed or something. There will still be time...

Back doing code review for Eric's sub special account tracking project. This is a sub of the balance sheet and will end up allowing for things like reward points, loyalty points, gift cards, gift certificates, punch cards, in-store credit, lunch cards, vendor credits, employee payroll draws, affiliate programs, tiered marketing options, and tons of other special accounts. Basically, we will track all of the special accounts and then connect them to a single balance sheet item. The main balance sheet item will show up on the actual balance sheet. Behind the scenes, we will keep track of all of the tiny twists and turns and individual transactions. The summed up results will then be available for the balance sheet as part of the assets, liabilities, equity accounts, or even phantom accounts (kinda there and kinda not there). Pretty interesting.

Going through code done by Eric for the sub special account tracking project (loyalty points, gift cards, in-store credit, etc.). I was working through master account rules today.

Steve and Dustin were on the morning meeting. Steve had a quick question about a custom report for owners. We talked about some security hashes that could help the report be more secure. The admin report needs to be outside the secured environment and kinda a quick access link to a quick breakdown report for admin users. Steve has the report built, he is just adding some security and then going to add an access point from inside the secured environment.

I got a call from Russell. We talked for quite a bit about some custom client needs and how best to proceed with those requests. We also spent some time talking about using Bridgerland or BTech to help build out some of the fracture type pieces. The term "Fracture" comes from an idea that Steve had back in June of 2017. Everything in adilas seems to be fracturing and breaking into smaller and smaller pieces. Just discussions at this point, but basically a centralized brain (backend engine) and then a deployable front end that could be hosted on any client server or through a commercial web host. No special setup and a fully customizable frontend interface. The whole thing would talk and/or communicate through API socket connections and back and forth API traffic. We talked about ideas, options, etc.

If I were to put together a small fracture tick list, it would be something like this: (just ideas)

- Customizable look and feel (corp-level, department level, user level, and whatever in between)

- Preset defaults with ability to tweak out the defaults and settings (good starting spot and/or basic structure - starting templates)

- Permissioned out and/or micro permissioned (down to the functions per section)

- Settings for layout, settings for display (show/hide, sort order, aliases, instructions, required yes/no, validation rules, etc.) - As of right now, we are seeing settings on 4 different levels. They are world (corporation or business entity), groups or system player level (customers, invoices, deposits, expense/receipts, PO's, parts/items, vendors, users, stock/units, balance sheet items, quotes, elements of time, etc.), page level settings (what will show/hide, sort order, placement, flow, etc.), and finally, user level settings and defaults. How do I want to play the game (at a personal level)?

- Existing structure and flow, but it could be modified. Basically, a template of the starting procedure and/or process but make it able to be modular (build mini data assembly line type options per procedure/task). Think of our model with the mini bubbles and/or pods. These interface with flow, permissions, time, flex, and mapping clear out to the accounting levels.

- Real in-line database extensions. This allows us to provide a basic starting point (database tables and template flow) but also allows for things to be expanded and/or contracted (lessened) based off of configuration. These database extensions could be data types and allow for numeric, decimals, text, dates, on/off toggles, and even long text or JSON storage.

- Be able to save and build any kinda of report or data export - using existing tools

- graphics, charts, graphs, and other summary type options

- Support of both transactional data (what happens day to day) as well as aggregated (summed or pre-calculated values)

- Digital story telling, using characters, relationships, cause/effect choices, consequences, etc. World building concepts.

- Configurable interfaces and functionality per business vertical - click of button to switch layouts and/or processes.

- Customizable (data or logic hooks or black box technology) on client side, server side, and display and logic sides.

- Responsive and/or mobile ready

- Tons of flags, tags, and special callouts

- Be able to tie everything to time or elements of time. This could allow for groups, categories, types, sub locations, sub phases, sub status, etc.

- The list goes on... Most of the ideas have been recorded somewhere in the adilas developer's notebook pages. A great resource, it just may take some time to review and categorize. 

----------------------------------------

Back to other topics, Eric popped in and we made a few more notes and decisions on the sub special account tracking stuff (gift cards, loyalty points, in-store credit, etc.). After that, Wayne jumped on and we talked a little bit about email servers and what is needed there. I spent the rest of the time recording notes and reviewing to do lists. Busy times.

On with Steve and Dustin. We got caught up from happenings over the weekend and both Steve and Dustin had a couple of questions. After that, we then all of us went on mute and started working on our own projects. My first task was buckets full of emails and what not. Setup some sub account stuff for Wayne on the Newtek site to help manage some of our servers, support tickets, and account details.

Eric popped in and we setup some blocks of time to work on the sub special account tracking stuff - first couple weeks in January. This is for things like rewards/loyalty points, gift cards, in-store credit, etc. It will be good to get some dedicated time to work on that project.

Eric and I had a work session on the sub special account tracking project. This is where we are going to be allowing rewards, loyalty points, gift cards, in-store credit, and other special tracking needs. We spent most of the block reading over a brainstorming doc and refining it a bit more. We made a few decisions and added a number of new notes. Towards the end of the session, we even added a new payment type (money type) to the data 0 box for "Rewards/Loyalty". Our plan is to hit it again tomorrow.

See attached for a copy of the current notes.

See attached and fill in some info about the meeting. Planning out the next level of the sub special tracking accounts (sub of the balance sheet) for things like loyalty points, rewards, gift cards, in-store credit, etc.

Jumped on the meeting with Eric. We were working through more flow and logic on the special tracking accounts (balance sheet subs of subs and used for things like loyalty points, gift cards, in-store credit, etc.). We made some good progress on the master level settings and rules (super high up on the adilas admin level).

Eric and I were working on special tracking accounts. He was wanting to know how to create a master list and then have all servers play accordingly. I showed him how we currently use the copy tables and update tables function from the data 0 box to all other serves, including local development boxes. That got him thinking and excited about possibilities.

After that, we went back and started building from where we were yesterday. We are way up high on the add/edit special accounts page (master or universe level for things like loyalty points, gift cards, in-store credit, punch cards, etc.). We finished up the day by having a simple add/edit form, a results page, and an action page. Eric has done tons of custom code inside of adilas. Having said that, most times, he has been tweaking what already exists. This project is a good one for him, because he is building from the ground up. He is chewing it up by leaps and bounds. Really cool.

Working with Eric on the special accounts project (sub of the balance sheet). This will be for things like rewards, loyalty points, gift cards, in-store credit, punch cards, etc. The task today was boiling things down into a small to do list. After that, I made a small clean-up function, wrote some new documentation, and started into the basic page layout and structure. Once that is done, Eric will take the project and start filling in code on the different pages and components.

Eric and I jumped on a meeting. We spent the afternoon working on the special account tracking stuff for things like loyalty points, gift cards, in-store credit, punch cards, etc. Our task today was to build the database structure. I was mostly building things, while Eric was watching and working on some of the next pieces. Once we get all of the pieces ready to play, Eric will be doing most of the wiring of the pages. We created branch elt-2 for the new code.

Steve popped in towards the end after Eric left. We worked on some of his pages and talked about 3rd party solutions and how to help integrate with more of them that offer great functionality and customized solutions. Good ideas. We'd also love to keep up good relations with both Russell Moore and Calvin Chipman. Both are great developers and could bring some fun tools and features to the party. We'll have to see how things play out.

Emails and tech support stuff. Writing updates on the compromised data server from this morning. Light follow-up.

Checking in on the morning meeting. I have been out of the office most of the week. Steve and I chatted this morning about the need for new independent developers and getting people into the mix and into the family. There is a real need there. We then merged in some code from his branches and pushed up files to all servers.

Looking over ideas for loyalty points. Lots of good info on element of time # 3778 in the adilas shop.

What is a liability? What are the differences between real and phantom values? We need the values recorded for both real and phantom, the difference is how firm and/or fixed the liability is. Steve mentioned a term called a "shadow account" (that exists, but may not be fully tangible). We also talked about how it is the actual company that is creating these phantom and/or shadow type liabilities. That kinda changes things... it is the company creating their own liability based off of a point system to encourage customer loyalty.

There seems to be two main part of the puzzle. How many points (ins and outs) and what is the value of those points? Lots of balance sheet transactions.

Simple to more complex transactions... simple gift cards or simple gift certificates, basic loyalty points, punch cards, in-store credits, coupons. As a fun side note, some of these transactions are subs of the balance sheet. Kinda like sub inventory but on the balance sheet side. Maybe we need to think about how the transaction takes place. Is there already cash on hand (paid in advance)? or is it just lowering the total owed, like a form of a discount? Who pays for what? What about coupons that a manufacture pays for or pays a part of?

On the main balance sheet items, we may need another switch to help us know if this is a main account and/or a sub account. We may also need to know if the asset, liability, and/or equity account is real or phantom (shadow). This is kinda fun, but we are seeing a fracture that is needed in order to record the balance sheet items. Everything is breaking into sub accounts.

Going back to discounts and special discounts... do we apply the discount to the cart/invoice on a whole or do we have to re-distribute that discount back through the system?

On a different note, we had a request from a client to be able to permission and/or fully turn off standalone discounts. Also, we are seeing that taxes make the discounts more complicated. We have options to do both in-line discounts and/or standalone discounts. Things get really fuzzy as you try to tax, especially with excise taxes and taxing things at the different levels (per item category, per customer type, per inventory type, etc.).

We had a great talk about "bad debt" payments. Don't worry about the words (verbage), think about the concept. That helps to satisfy the invoice (monies owed to us), the taxes are fully correct,  but it is then showed as an adjustment to revenue (rewards, coupons, loyalty points, etc.) on the income statement. Both coupons and loyalty points are similar. It is the internal company basically saying "I'm going to cover that part of the invoice". We claim that that invoice and/or ticket is x dollars and has y amounts of tax. We then cover the invoice by real monies and/or monies that mean something, but no real money changed hands. Look deeper in this. The main difference is the verbage between bad debt vs rewards or loyalty points.

Maybe we should add some new standard payment types such as: Rewards, Loyalty Points, Coupon, In-Store Credit, Gift Card/Gift Certificate, etc.

We are seeing the need for a good mix of user-maintained pieces, system-maintained pieces, and possibly some mixed-maintained pieces (user and system). We are seeing this in the watchers, feeders, standalone declarations, time templates, settings, etc. We need to let them play where they can and need to, but also make sure they have the tools and pieces to get the job done, even if we control the pieces behind the scenes.

Eric would like to check in on loyalty points around 11 am for a couple of hours. He texted me and said that he was unable to meet today due to some things that came up. So, in the meantime, Steve and I had a great discussion and made some good breakthroughs. Good stuff.

Morning meeting... got reports from Alan, Steve, and Russell. I was working on some small changes and taking the rounding error off of the mini invoice (3" customer receipt). Other small changes.

Eric will be coming in at 10 am to talk about loyalty points. Eric and I talked for a couple of hours about the special account tracking project. This deals with loyalty points, gift cards, in-store credits, you name it... We did a lot of drawing and even got into some small scenarios. We went full circle... we decided that they all go together and then not all together and then back to all together. Eric was tasked with looking into things a little bit deeper to see what we can do and what plans we can make.

Shawn came over and was working on state payroll stuff.