Most visuals in Power BI expect an aggregated value in the "Values" section of the chart. The exception (I know of) is the table visual.
For that reason, if you put a column into the "Values" section of a chart, Power BI will select an aggregation for you. You can change that aggregation (sum, average, count, min, max, etc) but you cannot select "Do Not Summarize".
If you think about it, this does make sense. Take, for example, a column chart. If you have "Month" on the axis and then you put "Sales" as the value, what do you expect Power BI to do when there is more than one sale in a given month? It needs to know if it should sum, average, count, etc. Even if you know there's only one data point per month, Power BI doesn't know that will always be true.
There are a few ways around this. If you want to break your column chart down to have a single column for every sales record, then you need sales record ID (or another attribute that's unique for every record) on your axis. If, as in the case of the original poster, you want to break down your actual & goal by period, then period needs to be on the axis.
If you know that you have only 1 value per period (say), then using an aggregation such as average or sum shouldn't matter because an average/sum of a single value is that value (as long as you're breaking down your chart by period).
For a scatter chart, the same principals apply but in this case, there is no axis. Instead, you want to put the field you want to break your chart down by into the "Details" or "Legend" section.
In any of these cases, if you don't have a field to break your chart down to the level you want, you'll need to add one. This could be as simple as going to "Edit Query" and adding an Index column (though I'd recommend adding something that makes sense to your problem domain).
Should Power BI have a concept of "row" when displaying data, so you can de-aggregate data to the lowest level without having to manually add your own column? I personally don't think so. Power BI is designed as an interactive data analysis tool. For that reason, charts need to provide context (such as what a column represents). Even if each row represents a single customer or a single month, it makes more sense to provide the customer ID or month name in your chart, than for Power BI to use a meaningless row number. In my opinion, it's good that Power BI puts the onus on you to add that context as a column to your data.
---
Bear in mind, with some of my de-aggregating suggestions, that if you're working with large datasets, Power BI isn't going to perform all that great. Power BI excels at aggregation. A column chart with 10,000 columns is going to be pretty unusable. A scatter chart with 100,000 data points might not perform as well as a traditional graphing tool. It may be worth exploring other tools if that's your end goal (R, Excel, the Sand Dance custom visual).
As other posters have mentioned, data types are important. If your column is numeric, Power BI is generally going to assume that it's a "value" and try to aggregate it. For something like "Period", where you don't want to aggregate it, you will have to deliberately move the column to the axis part of the visual. This also applies in reverse. If your "Goal" is a text field, then Power BI has limited options for aggregation (it can do a first/last/count, but it cannot sum or average a text field).
Overall, I recommend using measures that explicitly sum/average/count things, rather than dragging columns onto visuals and choosing the aggregation on each visual. Reasons: (1) Having a measure for Customer Count saves you from constantly having to take CustomerID and change a sum to a count. (2) It reduces the risk that someone sums a column and thinks it is a count (sometimes it is obvious, but not always). (3) If you later want to redefine who counts as a customer, you can update the measure and all visuals will adjust automatically.
For attributes you would only ever want to use on your axis/legend, I recommend setting the default aggregation in the modeling tab of the data window to "Do Not Summarize" as AWeichselbaum mentioned above. This is indeed useful if you have a ZIP column and you know you never want to sum 2 zip codes together, and want to be able to select Zip Code without it aggregating.
---
Hope this helps as a summary of what might be going on when you find yourself unable to de-aggregate a column. If you're still stuck, I recommend posting a new thread with exactly what you're trying to accomplish (and what isn't working) rather than continuing to ask in this thread.
