I have created four TM1 cubes: Rate for hour, Hours, Rate of exchange and Revenue.
In first one, user enters rates(costs) in different currencies.
In second one, user enters customer hours (for example, how much time customer consultation took).
In third, user enters rate of exchange for every currency.
In Revenue, based on data in previous cubes, I calculate all revenue in Euros.
The problem is when user enters same rate in more than one currency. Then revenue in Revenue cube is bigger than it should be.
My question: is there a way to prevent users from entering rates in more than one currency? All approaches I tried ends up with circular reference error.
Your question is almost impossible to answer in specific terms because you've provided no specific details of your cubes, dimensions, elements or rules.
In general terms, however... TM1 is not a relational database and other than picklists has few input restrictions. There are usually at least a couple of ways that you can work around that, though. In this case I assume (again, in the absence of specifics) that the relevant dimension in the first cube has an input element for each currency.
Instead of that you could have two input elements; one for the amount, and another for the currency code (regulated by picklist). Your rule in the Revenue cube then evaluates the relevant currency element by looking at the currency code input. That will allow it to look up the relevant exchange rate from the third cube via a DB() function. That rate is multiplied by the work rate that has been entered into the first cube and the hours entered into the second cube to calculate the revenue.
Related
I'm implementing a software solution for a company. As part of its business processes they give cash advances to its employees when they get on a business trip, let's say 1000 dollars. Those 1000 dollars are withdrawn from one of the cash registers available and the transaction is registered to the database as an expense so at the end of their turns cashiers are able to justify the 1k missing.
Then, sometimes the employee who travels spends just part of the money he was given, let's say 500 on gas, 200 on hotel and 100 on meals, so 800 out of the 1000 he was given.
So here's the situation I'm dealing with: those three expenses (gas, hotel and meals) need also to be registered individually when the employee comes back from his trip for two reasons:
To store the expense under the right expense concept so we can then query the database and see how much the company spends on every concept.
To match the money given to the employee as cash advance for his travel expenses with his actual expenses. So a total of four transactions would be performed: three expenses and one income, the 200 the employee didn't used, to match the original 1K.
Up to this point everything is fine regarding the cash advance transaction: 1000 dollars were given and 1000 dollars where justified, 800 in expenses and 200 as the money back. The problem is, the original 1000K still exist as an expense, so the total balance would be -600: 1800 spent and 200 income, which is obviously not correct.
I've thought of two alternatives:
Subtract the travel expenses (800) from the original cash advance expense (1000). This way, the final balance is right (0). But that would mean modifying an old expense entry which in turn will affect that days cash closing if for some reason it needs to be consulted in the future. I'm not sure if this is actually a bad thing to do since the final balance will match the actual money, it just feels wrong to mess with an old entry that will no longer represent what actually happened that day.
Treat cash advances as a special entity, not as an actual expense. This new entity will have the following fields: withdrawn_money, money_back and spent_money. When calculating the cash closing for that day the outcomes would be the sum of expenses plus the sum of cash advances withdrawn_money thus leaving the cash closing intact. Later when the actual expenses are presented they will go directly to the expenses table but at the same time being registered as a cash_advance spent_money new entry. This way we can keep under control how much of the withdrawn money is returned and at the same time save the actual expenses under the right expense concepts for future querying.
Cash advances not being considered as actual expenses make sense to me since the money is in employees hands so technically is not an expense yet.
Alternative 2 sounds better to me but I'm still trying to find the most appropriate implementation. It would be of great help to get opinions of more experienced developers and database designers on subjects like this.
Thanks in advance for your time and I would gladly clarify anything if I wasn't clear enough.
If you are familiar with the double-entry accounting this situation looks like this:
there is a transaction from account 501 (which refers to the money in cash) using the currency as a reference/article to account 422 (which refers to the company staff) using the employee as a reference/article
when the employee comes back:
if he has paid with credit card only and has not used the cash - you make a reverse transaction (from account 422 to account 501)
otherwise for each receipt/invoice he brings back - you make a transaction from account 422 (using the employee as a reference/article) to account 609 (which is for other expenses - and then referencing the appropriate expense)
if the employee does not have a receipt/invoice for some of the money - it stays in account 422 and on the next salary payment you make a smaller transaction for his salary and compensate with a transaction from account 422 to account 604 (which is the payroll) to clear the remainder
I got this situation. Logic is customer will be given credit sale and they will repay money in installments. I need to store this details about products, qty and the amounts they are giving in installments.
In dashboard i need to show all customers with name total sale amount, paid amount and balance amount.
Approach i thought
tblCredit = Stores as rows for all the time they pay amount
(e.g) shan(Name), paper (product), 1500 (qty) , 2000 (Price), 100
(Debit) { initial purchase) }
shan (Name), -, -, -, 200 (Debit)
In query filter by name and sum(Price) - Sum(Debit amount) will give
balance
But this approach once the data grows is this aggregation will be trouble some ?
Is it possible like caching the aggregated result with timestamps or
something like that and update that at every operation when we are
inserting data in that table and show result from that ?
Note
Data growth rate will be high.
I am very new to designing.
Please guide me the best approach to handle this.
Update
Apart from dashboard i need to show report when users clicks report to know how much credit given for whom. So in any case i need a optimized query and logic and design to handle this.
Usually a dashboard do not need to get the data in real time. You may think of using data snapshot (schedule data insert after your aggregation) rather than maintaining a summary table update by different types of sales transactions, which is difficult in maintaining the integrity especially handling back-day process.
I am writing a rather large application that allows people to send text messages and emails. I will charge 7c per SMS and 2c per email sent. I will allow people to "recharge" their account. So, the end result is likely to be a database table with a few small entries like +100 and many, many entries like -0.02 and -0.07.
I need to check a person's balance immediately when they are trying to send an email or a message.
The obvious answer is to have cached "total" somewhere, and update it whenever something is added or taken out. However, as always in programming, there is more to it: what about monthly statements, where the balance needs to be carried forward from the previous month? My "intuitive" solution is to have two levels of cache: one for the current month, and one entry for each month (or billing period) with three entries:
The total added
The total taken out
The balance to that point
Are there better, established ways to deal with this problem?
Largely depends on the RDBMS.
If it were SQL Server, one solution is to create an Indexed view (or views) to automatically incrementally calculate and hold the aggregated values.
Another solution is to use triggers to aggregate whenever a row is inserted at the finest granularity of detail.
What is the most efficient way, in terms of cost and scalability, to pull stats on large volumes of data?
Let's take a concrete example, there are 1000 companies, each with 10000+ customers.
These companies are all in retail, or let's make it more generic, they are any company in any industry and they want to know certain things from their customers.
10 of these companies wants to know how well their call centres are doing and sends out an email asking customers to rate them 1 - 5, customers click on a link and rate them 1 - 5.
20 of these companies, which could include some of the previous 10, wants to know something else and asks for a rating 1 - 5.
Now if I want to give each of these companies feedback on their average rating or where they stack up against the other companies who sent the same questionnaire or had overlapping questions, what would be the best strategy to calculate these stats?
Option1: Have a special entity just for stats, every time a customer rates the company for something, increment the stats counters (eg increment stats counter for number of votes, vote total, increment male / female counters if you're tracking votes based on gender, etc)
The problem with this approach is that you'll be doing y number of extra writes (where n is the number of stats reports you want to track for) for every data entry and then you're also limited to those stats that you wanted to track. Also, you'll be limited to 1 write/s as Peter mentioned in his response here: Using Objectify to concurrently write data on GAE
If x is the number of entries and y the number of stats reports you want to pull, you'll be doing x * y writes and y reads to report on stats.
Option2: Do something like: ofy.query(MyEntity.class).filter("field", v).count();
Pitfalls being that you're looking up all those entities, does GAE charge for read x operations if you're doing a count that results in x number of entities?
Also, if you're potentially running through 20000 entries, won't you hit some sort of limit in terms of time-outs, max reads per query, etc?
Depending on how often I pull stats, this will mean x number of reads every time I pull stats assuming I won't hit some limits.
Option3: Put an extra property in each feedback entry for every piece of stats you're trying to build. Then have a scheduler run every hour / day / week / ..., use cursors to run through each of the entries, mark the stats column as counted and add that value to a stats entity. If the number of feedback entries are x and you want to pull y number of reports on this data, that means (assuming you do the calculations in memory and not immediately in a stats entity) x number of writes to mark the x number of feedback reports as counted and y number writes every hour / day / week to store the updated stats values.
This means that for x number of feedback reports, I'll be doing at least 2 * x writes and only y number of reads to read the stats.
All of the above seems yucky, is there a better way to do it?
If not, which of the above is the better way to do it that won't break when the volumes are massive and that won't dramatically increase costs over what the costs already are in terms of reads / writes / storage.
GAE is not a good option to do analytics, because of concurrent write limitations and lack of good query language.
If you are serious about analytics you should export data from GAE to BigQuery and do analytics there. Check out Mache and this blogpost.
Say you have a list of events/tasks with time stamps for created, completed.
Examples:
Customer entering a queue, then being served
Business process starting and completing
Order received, order dispatched
Also related fill, take events:
Pay goes into bank account, pay bills, buy food, go to the movies
Fuel tanker replenishes gas station, customers purchase fuel
Store receives stock, customers purchase stock
Now say I have a huge list of this data. I don't know the starting inventory levels because I've come in after the beginning and I can't view the current inventory either.
How can I query this data so I can tell current inventory levels, queue size, etc at any given time? Or even start to plot the size of inventory on a time line?
edit: I'll explain my specific requirements in more detail
Our warehouse management sytem contains historical data for each task that occurs. It doesn't capture the state of a pick bin as the event happens, only how much was picked or how much was replenished. We also have cycle count tasks which does show how much stock is in the pick bin. I am trying to find a way of tying these three processes together, replenishment, picking, cycle counts, so I can plot on a time line:
how many tasks are currently waiting
current stock levels
At the moment with the data, I have only figured out how to plot how many tasks were created or completed in period of time, or how much was picked, based off the time stamps for the task.
Now the reason I would like this data is to track performance, under/over allocation of staff and indentifying config issues that could be causing performance issues.
Now say I have a huge list of this data. I don't know the starting inventory levels because I've come in after the beginning and I can't view the current inventory either.
How can I query this data so I can tell current inventory levels, queue size, etc at any given time?
The short answer is: "You can't."
If all you have are the deposits/withdrawals without an opening balance or a closing balance then there is no way to track the actual current balance because you have no reference point from which to start. You could track the relative balance (or inventory level, or whatever) by assuming a starting balance of 0, or 100, or 1000, or any value you like.
As for plotting the data, Excel is the logical place to start for a task like that.