I am preparing an Operational Budget for next year for my company.
I am working with operations managers to define target at stock point level and I want to see how the monthly targets look using last year actuals distribution.
Bellow, you have a google docs link which you can use to better understand the situation.
I have trouble doing this with one of the KPIs which is %Orders Sent On Time. Since the company performs rather well, when I define a annual target of 99% and then distribute that by the months, using last year distribution, some of the months go over 100%. Do you have any methods which I can use to set a limit so that each individual month does not go over that.
https://docs.google.com/spreadsheets/d/1z7WF-M5CaH52ANtYD9j-Z5_P0FvBiVZnmIQTonPaquU/edit?usp=sharing
Edit: I need the solution to be available on google sheets, for cooperation between teams.
try in H22:
=IF($P$22*H10/$P$15>1; 1; $P$22*H10/$P$15)
Related
So I have an issue I cannot wrap my brain around. I am creating an employee vacation tracker, and I have already multiple sheets with different data, i.e. one consists of Google Form answers about when the employee wants to take time off work for holidays. Please note that I also already have data on employee availability each standard day of the workweek.
Alright, onto the problem. Let's say 'Lukas' is a part-time employee and only works Tuesdays, Wednesdays, and Fridays. He sends in his vacation plan: he will be enjoying the seaside from 1.8. until 15.8. How on earth can I combine multiple sheets and data in such a way, to only count his holidays by his actual workdays? I can not even begin to write the formula - this is where I should note I am a beginner at Sheets.
Alright - I took a look at your mock-up sheet, I must admit it's still felt somewhat unorganized.
Due to the lack of enough dummy data and without being certain whether or not you empty/refresh the weekly availability tabs (I'd recommend you not to do so), it wasn't fully clear what you wanted.
Nonetheless, I couldn't resist, I've been working on several projects and your topic gave me some creative inspiration, so I went ahead and did a major rebuild in your mock-sheet.
Should you want to use or implement it, here's some info good to know:
The Employees tab is meant as an input field for any coming and going employees; just add any names there and they will be automatically added to the main schedule.
I mocked some more data, so the output might not be what you expected, but;
In the Holiday overview tab you can see all employees with the days they've taken, planned, and left.
In the Schedule Dashboard tab, you will find three main sections.
The working schedule based on the data from the Weekly Availability tab of which I guess you manually move over data to from the Availability Responses tab.
The Holiday schedule; this fully takes into account whether or not it overlaps with a supposed working day, or if the person was off already anyhow. Therefore; Holiday is shown when it overlaps with a scheduled working day and Day Off is shown when it doesn't. Only the Holidays are deducting the remaining holidays.
The right one I did based on my own experiences; it works like an alerting sign that whill show you if holidays are approved while still being scheduled, where I work we do this the other way around. Holiday Request > We unschedule > We approve holidays > No overlaps should exist.
I posted some comments in the sheet here and there on orange tiles.
Curious to know if this helped!
According to description of Remaining Work field available here https://learn.microsoft.com/en-us/azure/devops/boards/queries/query-numeric?view=azure-devops#fields-used-to-estimate-and-track-work I set my ProcessConfiguration with "h" for hours.
Since Remaining Work is declared as double, I guess that is possible to enter in this field hours but also minutes. Is it ok to set "half an hour" with 0.5? "10 minutes" with 0,16 and so on?
Yes, you could track it like that. I think if you try to track individual times less than a quarter hour it brings on a lot of other problems though. If you have multiple people working on the same task, the out-of-box functionality is not great for tracking that. If you want to roll-up tasks time to a feature or PBI, the roll-up is not that great.
I've worked on projects that were billable to different customers and we billed in quarter-hour increments. We tracked the time for billing and used a paid extension, Timetracker. It was good at managing to the level of detail you might desire based on the wording in your question.
Our group is working on a sentiment analysis research project. We are trying to use the Twitter API to collect tweets. Out aimed dataset involves a lot of query terms and filters. However, since each of us has a developer account, we were wondering if we can pool API access tokens to accelerate the data collection. For example, we will make an app that allows us to define a configuration file that contains a list of our access tokens that the app will try to use to search for a tweet. This app will be run on our local computer. Since the app uses our individual access tokens, we believe that we are not actually not bypassing or changing any Twitter limit as the record is kept for each access token. Are there any problems legal/technical that may arise from this methodology? Thank you! =D
Here is a pseudocode for what we are trying to do:
1. define a list of search terms such as 'apple', 'banana'
and 'oranges' (we have 100 of these search terms, we are okay
with the 100 limit per tweet)
2. define a list of frequent emotional adjectives such as 'happy', 'sad', 'crazy', etc. (we have have 100 of these) using TF-IDF
3. get the product of the search terms and emotional adjectives,
in total we have 10,000 query terms and we have computed
through the rate limit rules that we would need at least
55 runs of 15-minute sessions with 180 tweets per 15-minute.
55 * 15 = 825 minutes or ~14 hours to collect this amount of tweets.
4. we were thinking of improving the data collection by
pooling access tokens so that we can trim down the time
of collection from 14 hours to ~4 hours, e.g. by dividing the query items into subsets and letting a specific access token work on a subset
We were pushing for this since we just think it's efficient if it's possible and permitted since why not and it might help future researches as well?
The question is, are we actually breaking any Twitter rules or policies by doing this? By sharing one access token per each of us three and creating an app that we name as clones of the research project, we believe that in turn we are also losing something which is the headroom for one more app that we fully control.
I can't find specific rule in Twitter so far about this. Our concern is that we will publish a paper and will publish the app we will program and use for documentation and the app we plan to build. Disclaimer: Only the app's source code will be published and not the dataset because of Twitter's explicit rules about datasets.
This is absolutely not allowed under the Twitter Developer Policy and Agreement.
Twitter developer policy 5a:
Do not do any of the following:
Use a single application API key for multiple use cases or multiple application API keys for the same use case.
Feel free to check with Twitter directly via the developer forums. StackOverflow is not really the best place for this question since it is not specifically a coding question.
Currently I have a live iPhone app. I need to convert it to a paid one with territory limitations. That means I need to make my app paid for some territories and free for the rest.
Will apple allow this?
Can I upload 2 separate apps with same features, one is free and other is paid but their no feature changes. Only territory limitations.
First thing is you can not change price of the same Application for different territory. Apple will not allow to do so. In fact there is no such option to set different price for different territory.
So for the second you mentioned i say YES. To do so you to keep few things in mind.
Let say you have created 2 different applications with same features for 2 different countries with different price tags
Make sure the version which you uploaded for Country-A should be only visible to Country-A. And same for Country-B.
Keep Description & keywords localized language.
Make sure there is something different in both app versions. Otherwise Apple team will feel its a similar concept & they might reject the application.
Hope it will guide you.
We are contemplating changing the version number in the next release of an iOS app from using the traditional Major.Minor.Patch version number scheme to instead use a date based scheme such as 2012.month.patch to better reflect to our users the currency of the app.
Apple's only version number guidance in iTunes Connect is as follows:
The version number of the app you are adding. Numbering should follow
typical software versioning conventions (for example, 1.0 or 1.0.1 or
1.1).
My question - do they enforce this traditional scheme?
Is there any downside to using a date based scheme?
Are there any gotchas that might emerge from changing schemes on an app that has already been widely deployed?
Update: To explain a bit more of the justification for going to a date-based versioning scheme... The apps in question are updated primarily to reflect new datasets being added a few times a year. It is useful for a user to know that version 2012.2 has current data - version 2.6 does not convey that.
The apple scheme is generally enforced, seeing as your bundle is checked twice for the proper version number (once at validation, once at upload). And if not by apple, by general accepted tradition. Besides, why would you need to go beyond the recommended decimal places if you could just use the build number field for that?
Anyways, there is but one gotcha. Sometimes, iTunes Connect has trouble with double digit numbers in decimal places. What I mean, it that V1.1 and V1.10 sometimes show up as the same version (because the zero is ignored). But, V1.11 is fine.
As per your suggestion, it would seem slightly outlandish, but I would go ahead and try it. The app store does not prominently display version numbers (except during software updates, and even then, it's a subtitle), so I'll bet it could just slip right by. If you need to, just amend the name of the app to reflect the year.
In my experience they do not enforce it except that the first version is not less than 1.0 and you cannot release a lower numbered version.
The upside to the traditional scheme is it focuses on features which may be updated at your pace instead of the date which is always ticking away and changing much too fast. It is easy to tell where the release fits in relation to the other releases and shorter using dates.
Why would you want to? If you submit 2012.02.08 to the app store but it is not approved until the 15th of February then immediately there is a disparity. The app store lists the date the app was last updated, your users can go read that or your website.
If you regularly update it, and they download the updates, then I'm sure they'll get the message that your app is being updated frequently. I certainly notice when apps are updated. Other than actually seeing the version number while downloading it or within the app, changing the version number to dates doesn't help them know it is updated frequently.
After doing some research to submit my first build I am writing this.
First upload of the App can not be less than 1.0 ( no beta version ideas allowed)
Every subsequent upload should be incremented by one at the least
Maximum sub-version format allowed is X.X.X (where X can only be numbers)
No alphabets
Make sure only one version number is followed in all the version related parameters in Info.plist file before archiving to upload to the app store
I wanted to comment on this to say that using a year.month.day versioning scheme is fine.
I checked my phone to see who's doing something similar and here's what I found:
ideviceinstaller -l | grep 2020
com.bestbuy.buyphone, "202003261603", "Best Buy"
com.google.Docs, "1.2020.10202", "Docs"
com.huang.speedtest, "2020043002", "Oka Speed Test"
com.alibaba.iAliexpress, "8.7.1.2020031010", "AliExpress"
com.wayfair.WayfairApp, "20200326.72595", "Wayfair"
com.nguyenvh.holeio, "202003271450", "Hole.io"
com.adobe.Adobe-Reader, "20200326.133802", "Acrobat"
com.clearchannel.iheartradio, "2020022503", "iHeartRadio"
com.google.Sheets, "1.2020.12203", "Sheets"
com.google.Classroom, "2.2020.12205", "Classroom"