Okay, so we're talking about hot, hairy, sweaty problems with reclassification. We've dealt for a moment about the default answer. If you change history on the transactions or the balances to solve answers, you're going to get a switch view, everything from that point forward will be reclass to processing shown under the new classification scheme. If you do a join process and look up to like the department number, for example, from the customer ID, and you change that department, then you get a recast view. You change history. So all over the world before this change, and now it all shows up under the new department, the old department isn't showing up.

So how can we instead of having to over produce to master files to maintain multiple copies an idea that will Help in this situation, if we do a date effective join, what we need is we need two departments. And we need to know which department is effective as of which day. And then we have to be able to say, How do I want to report? Which way do I want to report. So imagine for a moment our reference file, instead of just having the customer ID with the department next to it, we have the customer ID. And next to it, we have an effective date.

And then we have the department ID. And we put two rows into this reference file. When we make our change our first row that's always been in there would be our customer ID. And the date for that, let's just say is all zeros this effective this record has been effective since time began, in a certain sense, and this is our old department. Now, when we do a business event of changing department changing the department is considered a valid business event, we capture that business event in the reference data. And instead of changing the reference data, we add a new row to say, hey, as of this day, the department ID is now this.

So we have the same customer ID. But as of the first of the month, we now say, it's now this customer. So now we have to reference data. Now, what this means is, as we're processing transactions and doing our join processing, we have to supply another parameter, we have to say which date we want to report as up. If we if our view if our reporting process passes in a date, that is the end of last month, it's going to search and it's going to find the first record because the new date with the first new month is greater than the date of reporting as of date that we passed in and so are we would see the old department. If we pass in a date, in the view in the process of the reporting process, that is the second of the new month, it's going to fall back to the it'll find the new department because it now sees the back is effective.

There, there are ways of doing data effective processing, where all the transact, all the data is stored with an effective date. And you basically replicate all the reference data. Every time you make a change, you copy all of the reference data that starts to accumulate too much data. Our reference data files begin to grow to voluminous if I have to copy everything with a new effective date. Showing the new process this way that I'm talking about doing keeps the data small for the reference data processing, but it requires greater processing logic in our joint processing because we now have to compare less than or greater than Against dates to determine which one of these is valid to us. Having this sort of reference file means that now I could choose which way I want to report, I could do a recast view that is takes all of my data and, and shows that as of the second month, and everything will be under the new department.

Or I could do a view where I pass in the date as a prior first to the last day of the last month, excluding any new transactions and I will get the historical view. I could also pass in the date on the transaction and have it join based upon the date on the transaction. That would give me a switch view transactions that came in before the first of the month world join and get the old department transactions that come in after the first of the month. We'll get the new departments all of these processes are available with the data Effective join. And it changes our reference data processes to follow the principles behind a business event based system as well. This is a very powerful concept and very useful in helping us to create more flexible reporting systems and one of the key attributes we would have to have in order to build a metric engine