Okay, so let's continue our discussion here on reclass processes his hairy, messy, sweaty, sort of problem space. So we talked in the first episode kind of easily described a switch view. Let's kind of go over the switch view again. And a little more. Just to remind you what that meant. A switch view is if I reorganized the department, a set of customers that live in a certain city that's on a boundary between two departments and I somehow decide that from going forward, these customers this department, these customers are going to be owned by a new department.

So I'm going to switch to the owning department is and I'm going to have them owned by another department and and reported by the new department so the new department gets credit for the new sales. The old department shows the historical balances and their historical transaction. Let's talk for a moment here about the difference between transactions and balances, right? If I did everything with the transactions, I could and if I stamp on the transaction see this problem comes when we start to classify transactions or balances by particular attributes, and we put those attributes on the transaction or balanced directly, rather than joining to them. So if I put them on the transaction, then it posts into a balance that contains that same attribute. It doesn't really make a difference whether I do things with the transactions are with the balance, I have the same problem.

So I let's say for a moment that I do with the transactions I taken just start recording new sales against the new department, the new department numbers put on the new sales for the customers. If I do all my reporting off the transactions, my old department is listed on those transactions that were sold by the old department and So when I aggregate all of those transactions to create a balance showing the sales for these customers to that department, it'll show up there, I create a balance with that, when I go to create a similar balance for the new department because it's on the transaction detail, it'll aggregate there as well. Now, if I store those balances, it doesn't make any difference the transaction or the balance doesn't make any difference as to how I've tried how I do this reporting. A switch view, though, simply says that from this point going forward after the change in attribute, I'm simply going to record in the new world and when I do reporting, I will see the change.

If I do reporting that includes that attribute, I will see the change in where the balances or where the transactions are recorded for that problem. There are cases when this is useful. There are certain types of reports where Switching view is the most appropriate kind of view that you need. And it's, it's the simplest probably to do. Because it's simply, you you do it on the transactions, and it accumulates to the balances. Now, there is a problem with this, if I make a balance in the new customer, right?

And for some reason the customer has a refund against something that was the old sale, does the refund now come out of the new transaction with the new department or out of the old transaction? Is there ever a time in the accounting process right? If you have a process where a balance is never going to be updated in any way by an automated process ever again, then it becomes what's called a stranded balance. Because they'll never be a change that balance it will live on forever. The could there might be a case where it never has any reason why it ever gets changed, and the All department for old customer balances could in fact, be a stranded balance. There may be nothing that ever removes those balances from the book.

Perhaps their p&l balances and the year end closing process removes them off. But in other cases, you see this problem of a stranded balance. So this is one reason why a reclassification process typically happens is you end up with these stranded balances. So that's kind of a view of the switch view relative to reclassification process. Next time we'll talk about the recast