Okay, let's continue talking about hairy, sweaty, dirty problems. And we're going to talk now about reclass reclassification, these we talked about switch views, which change things as an appointed time to recast views, which change history. We're now going to talk about reclassification, which you'd like to see under our reclassification example of changing the Department for a set of customers and particular city. In a reclass view, you'd like to see that the transaction the bounces or the transactions in a in a report would show up as they occurred over time for the old department. At the moment that we make the change to a new department for those set of customers you'd like to see negating balance there and again, transaction for all of the accumulated history for those customers. And so that now the balance under that old department becomes zero.

As of the moment we make the department change, then under the new department, we'd like to see an opening position that shows us all of those balances for those customers in that old department. And that's the starting position for our new department. And then we'd like to see new transactions for the customers under the new department from that point going forward. That's a reclass view. So what's so difficult about that? Well, the difficulty with that is that most reporting processes that we've defined to date, when we have these kinds of things like the department IDs, that sort of reference data, typically is not supposed to have any impact on the inbound transactions on business events that are created in some way.

It's what To be somehow static and independent of all that, but here we have a case where we're changing a reference data item in some way. And we want to generate a new business event. That is the negating position for the old department and the opening position for the new department and have that all happen based upon the change in reference data. This isn't the only problem we talked a little bit about stranded balances earlier, stranded balances are are related in the same way. Suppose instead of what we're talking about, instead of joining to get our our department, we actually stamp the department on the transactions as they come in the door. When we make this rule change, and the new department is assigned to any new transactions going forward, the balance for the old department will live in in perpetuity.

There will not be a transaction that ever hits That old balance, it may actually be completely dead, that there's no rule that even contains the old department number. So that that balance will never get updated will never change in any way it becomes a stranded dead balance. So the same thing is true there. I had one customer one time that told me when they were thinking about these problems that oh, well, if we have this sort of problem, the easy answer is that we'll just reprocess all the transactions. You remember the daily financial cycle and how hard it is for us to get all of the workload done within 24 hours that needs to be done. And we aggregate we summarize very highly in order to make the machines able to do it in an efficient, cost effective manner.

If we have to go back and reprocess days and days and if we have balances that are accumulation of billions of business events over you know, quarters and decades. years, whatever, we'll never have the machine capacity to be able to process all of those transactions against a new set of rules and rebuild the master file. That's just not a practical approach to the problem. reclassification processes start to show where this idea of operational systems being independent from informational systems break down. Because these attributes we're talking about reporting on are tightly integrated to the reports that we're going to generate from those business events. And changes in the reference data can create new business events.

This problem reclassification is one that we'll talk about in more detail in a future episode. As we talk about back data, the processes which even enhance and make this hairy problem even worse,