How to calculate outstanding amount and interest using dataframe - dataframe

I want to subtract the repayment amount from the outstanding amount in the previous row and store the result as shown in the image and repeat it for the rest of the rows

Related

How to add/subtract from next row in SQL

How do I take the following table:
and make it so the Amount 3 column subtracts from the remaining amount in the row above?
Basically, I know I can do Amount 1 - Amount 2 to get the difference, but if I have multiple values I am trying to subtract from an original value, how can I write a SQL function so the Amount 2 column is added to the cumulative remaining balance in the above Amount 3 column to have a new cumulative remaining amount?
I'm assuming it's some sort of LAG function, but I still need help.

AWS QuickSight: maxOver() calculated field?

I am a stock trader who visualizes data in QuickSight. I identify the trades I want to submit to the market, sometimes for the same stock, at the same time, but in opposite directions depending on the price of the stock at that time. See below for an example of trades I might identify for 1/19/22 0800:
Date
Hour
Stock
Direction
Price
Volume
1/19/22
0800
Apple
BUY
$10
2
1/19/22
0800
Apple
SELL
$20
1
1/19/22
0800
Microsoft
BUY
$15
3
Using QuickSight, I want to visualize (in pivot tables and charts) the volume that I trade, using the maximum possible trade volume. For example, QuickSight simply sums the Volume column to 6, when really I want it to sum to 5, because the max possible trade volume for that hour is 5 (the Apple trades in the example are mutually exclusive, because the stock price cannot be both beneath $10, triggering a BUY, and above $20, triggering a SELL at the same date-time. Therefore, I want the day's traded volume to reflect the MAX possible volume I could have traded (2+3)).
I have used the maxOver() function as so: maxOver({volume}, [{stock}, {date}, {hour}], PRE_AGG), but I would like to view my trade volume rolled up to the day as so:
Date
Volume
1/19
5
Is there a way to do this using QuickSight calculated fields? Should this aggregation be done with a SQL custom field?
Add a new calculated field called
volume_direction_specifier
{Volume} * 10 + ifelse({Direction}='BUY', 1, 2)
This is a single number that will indicate the direction and volume. (this is needed in cases where the max possible volume is the same for both the BUY and SELL entries within the same hour).
Then compute the maxOver on this new field in a calculated field called max_volume_direction_specifier
maxOver({volume_direction_specifier}, [{stock}, {date}, {hour}], PRE_AGG)
Add a new field which will give the Volume for rows that have the max volume_direction_specifier per hour
volume_for_max_trade_volume_per_hour
ifelse(volume_direction_specifier = max_volume_direction_specifier, {volume}, null)
And finally, you should be able to add volume_for_max_trade_volume_per_hour to your table (grouped by day) and its SUM will give the maximum possible trade volume per day.

SQL GROUPING SETS averages with multiple many-to-many dimensions

I have a table of data with the following:
User,Platform,Dt,Activity_Flag,Total_Purchases
1,iOS,05/05/2016,1,1
1,Android,05/05/2016,1,2
2,iOS,05/05/2016,1,0
2,Android,05/05/2016,1,2
3,iOS,05/05/2016,1,1
3,Android,06/05/2016,1,3
1,iOS,06/05/2016,1,2
4,Android,06/05/2016,1,2
1,Android,06/05/2016,1,0
3,iOS,07/05/2016,1,2
2,iOS,08/05/2016,1,0
I want to do a GROUPING SETS (Platform,Dt,(Platform,Dt),()) aggregation to be able to find for each combination of Platform and Dt the following:
Total Purchases
Total Unique Users
Average Purchases per User per Day
The first two are simple as these can be achieved via a sum(Total_Purchases) and count(distinct user) respectively.
The problem I have is with the last metric. The result set should look like this but I don't know how to get the last column to be calculated correctly:
Platform,Dt,Total_Purchases,Total_Unique_Users,Average_Purchases_Per_User_Per_Day
Android,05/05/2016,4,2,2.0
iOS,05/05/2016,2,3,0.7
Android,06/05/2016,5,3,1.7
iOS,06/05/2016,2,1,2.0
iOS,07/05/2016,2,1,2.0
iOS,08/05/2016,0,1,0.0
,05/05/2016,6,3,2.0
,06/05/2016,7,3,2.3
,07/05/2016,1,1,1.0
,08/05/2016,1,1,1.0
Android,,9,4,1.8
iOS,,6,3,1.2
,,15,4,1.6
For the first ten rows we see that getting the Average purchase per user per day is a simple division of the first two columns as the dimension in these rows represent a single date only. But when we look at the final 3 rows we see that the division is not the way to achieve the desired result. This is because it needs to take an average for each day in turn to get the overall per day amount.
If this isn't clear please let me know and I'll be happy to explain better. This is my first post on this site!

"Average" aggregation of sparsely populated percentage values

I have cost center allocation data that is currently fully populated, one record per day, each with one cost center dimension key. The cube has a head count measure (the data is set to "1"), and the aggregate function is set to "LastChild". This means that a head count report will count a person only once in a cost center in any given time period.
Introducing partial allocations - a new measure will have a percentage value for the allocation, allowing for multiple concurrent cost centers where the allocation should add up to 100% (with "day" being the granular level). I am trying to figure out how to configure the aggregation over other time periods. I thought that "Average" should work just fine, i.e. a person who is allocated to a cost center at 50% for half the time period will be reported at 25% for that period.
The problem that I see is that my facts are not populated for days where the allocation to a cost center was 0%. To illustrate:
Employee1 CostCenterA 1/1/2013 50%
Employee1 CostCenterB 1/1/2013 50%
Employee1 CostCenterA 1/2/2013 100%
Employee1 CostCenterA 1/3/2013 100%
... etc with 100% in CostCenterA for all days
The above data on a report by month shows 50% for the allocation to CostCenterB, even though the person was only allocated for one day, and the average percentage on a monthly basis should be 1.6%.
I suppose I could generate the 0%-allocations in the data, but my fact table would explode as a result, so I'd much rather change how the "average" aggregation treats percentage values in facts that are sparsely populated, i.e. the average should be calculated based on the number of granular units in the reporting period (days in the month, in this case 0.5/31), not the number of rows in the fact table (0.5/1). Can this be done in SSAS?
If the measure with the average allocation is off by a factor that is proportional to the "sparseness" of my facts, i.e. the ratio of days in a period and actual fact rows, then it can be corrected as follows:
adjusted average allocation =
(calculated average allocation) * (fact count)/(number of days in period)
I created two new hidden measures, one named [Fact Count] for the fact count (a measure using the AggregateFunction "Count") and a calculated measure named [Days In Period Count] for the number of days, using the expression
COUNT(Descendants([Date].[Calendar].CurrentMember,5),INCLUDEEMPTY)
with [Calendar] being the name of the hierarchy in my Date dimension.
Finally, I added a calculated measure that implements the corrective formula:
[Measures].[Allocative Head Count]/
(
[Measures].[Days In Period Count]/[Measures].[Fact Count]
)
and named it [Adjusted Average Allocation]. This I can now use in reports and it appears to somewhat approximate the average cost center allocation over longer periods.
The formular for [Days In Period Count] btw does not work for the row totals when filters are involved. I opened another question for this.

Predictive Ordering Logic

I have a problem and was wondering if anyone could help or if it is even possible to have an algorithm for something like this.
I need to create a predictive ordering wizard. So based on previous sales, we will determine that that a certain amount of an item is required. E.g 31 apples. Now i need to work out the number of cases that needs to be ordered. If the cases come in say 60, 30, 15, 10 apples, the order should be a case of 30 and a case of 10 apples.
The number of items that need to be ordered change in each row of the result set. The case sizes could also change for each item. So some items may have an option of 5 different cases and some items may land up with an option of only one case.
Other examples would be i need 39 cans of coke and the cases come in only 24 per case. Therefore needing 2 cases. I need 2 shots of baileys and the bottle of baileys come in 50cl or 70cl. Therefore i need the 50cl.
The results sets columns are ItemName, ItemSize, QuantityRequired, PackSize and PackSizeMultiple.
The ItemName is the item to be ordered. ItemSize is the size the item is used in eg. can of coke. QuantityRequired how man of the item, in this case cans of coke, need to be ordered. PackSize is the size of the case. PackSizeMultiple is the number to multiply the item with to work out how many of the items are in the case.
ps. this will be a query in SQL Server 2008
Sounds like you need a UOM (Unit of Measure) table and a function to calc co-pack measure count and and unit count measure qty. with UOM type based on time between orders. You would also need to create a cron cycle and freeze table managed by week/time interval in order to create a freeze view of the current qty sold each week and the number of units since last order. Based on the 2 previous orders to your prior order you would set the current prediction based on min time between the last 2 freeze cycles containing an order and the duration of days between them. based on the average time between orders and the unit qty in each order, you can create a unit decay ratio percentage based on days and store it in each slice forward. Based on a reference to this data you will be able to create a prediction that will allow you to trigger a notice to sales or a message to the client to reorder. In addition, if you engage response data from sales based on unit count feedback from the client, you can reference an actual and tune your decay rate against your prediction. You should also consider managing and rolling up these freezes by month, so that you can view historical trending and forecast revenue based on velocity of reorder and same period last year. Basically this is similar to sales forcasting and we are switching out your opportunity percentage of close with Predicted Remaining Qty. percentage remaining.