Going over lots of requests for new and enhanced reports. Small errors and fixing a few things. Cory had a small list. Lots of talk about flex attributes and the need to build them out on all 12 main application player groups. Currently, we have them on customers and elements of time. It seems like the next one that is warming up is PO's. We have clients that are wanting to be able to add new and flexible data points to PO's (purchase orders). Of course, once they get added, they for sure want to be able to search by those new flex attributes. They also want them to show up on all the correct spots, forms, searches, reports, and exports. Not a problem, it just takes a goal and some time.

It seems that across the board, our users, on a global level, are wanting more and more control of their reports and exports. This inclues settings, preset and saved favorites, show/hide certain fields or columns, able to rename fields, set and remember the search criteria or filters, and be able to pull down any and all data (reports or exports).

Cory and I were talking about "visibility vs searchability". Our users want "visibility" first, then they want the "searchability". Basically, our users want to see the data and then be able to limit it and/or filter it down from the results that they got. From a coding side, it is easier to filter (control what will show) vs showing everything and then filtering after all of the data is shown and/or pushed out to the user (way more traffic, memory, and bandwidth). On the coding side, we would much rather have you know what you want, then we only have to serve up those records. Sort of a flip flop on who wants what and which way they approach their data and report results.

We have a report that the users want to control multiple parts of an object (say PO's or purchase orders) all from one export and/or report. Granted, the PO has multiple one-to-many relationships, table joins, and records that need to be matched up and presented. Imagine a report search page that has show/hide checkboxes for all of the main PO data (location, vendor, total amounts, PO types, dates, notes, ties to external invoices, etc. - 20 some fields). They then want all of the show/hide checkboxes to show/hide columns for all of the line item details (quantities, costs, prices, items, descriptions, etc. - tons of new fields - 60+ fields). Next, they want any sub inventory information (sub reference id numbers, barcodes, units of measure, special sub attributes, RFID tags, etc. - tons of other fields - another 15-20+ fields). Without going too crazy, they also want any new flex attributes (extra data points or in-line database extensions), parent attributes (inventory level controls for parent items), and other data. I didn't count, but it could be well over 100+ fields that they want to be able to pull, show/hide, filter, and organize. It gets into some advanced settings and big reports with lots of dynamic logic. Not that it is hard to do any of that, it just gets more difficult when you are mixing so many things or parts of the object together.

Cory wants us to start with the "visibility" of the data. As a side note, we may have to off load some of the processing for these bigger reports. I want to be careful about building on possible already tippy code or projects. We have to make sure that everything is stable. After this conversation, Cory and I lightly talked about budgets. We also looked over some code and did some quotes for clients. There are many challenges when trying to mix and bled and mix viewing with searching huge datasets.

Lastly, we talked about fair compensation. We are heavily underpaid and not showing our true value. That gets complicated as well. It's an interesting mix and an interesting game.