There are two questions here: how can we represent this in a user story and how do I break it up? Because nothing in agile or scrum forces us to use user stories (unless you're practicing XP specifically) let's start with the second question.
Splitting Backlog Items
We always want to try to deliver either customer value or at least proven knowledge value with each increment of the product. I don't know anything about your system, but at first glance, it seems like the weekly report is the full report with some extra filtering and care to make sure nothing gets missed, so there would be the first split.
Assuming that the full report is too big, we can focus on validating knowledge in two ways:
1) if this file needs to be imported somewhere, have it build a fake file that the importing system successfully accepts. This proves out that you've got the structure right and then you just have to plug data in.
2) Look for subsets of fields that can be added to the file with the other fields either blank or hard-coded, again to show that the pieces you are adding are working fine. You probably won't release this to production, but you can show users these pieces of data to make sure it's what they are looking for and you may catch data quality and integration problems in the process.
Depending on the circumstances of your system, you may have backlog items around performance as well.
User Stories
A user story expresses a need or a problem that a real user is having. For example:
As a front-desk clerk, I need warehouse inventory levels to refresh to
my local store at least once per week so that I know what is available
to sell.
That could be a comma-delimited file, a web service, or a dozen other perfectly reasonable solutions. The potential advantage this gives me is that I can more easily deliver pieces of the need. For example, maybe I've got 20 data sources that need to flow into this update, but two of them contain our fastest-selling products. Well, I now know that there is huge value in delivering an update with just those two data sources.
It isn't impossible to go from having a detailed solution in place to a user story - you just have to pretend you don't have a solution in mind, write a user story that speaks to the need, then don't tell anyone the solution you were thinking of so you don't anchor them. Of course, I've never seen someone actually do that, so my recommendation in this situation is usually to keep using what you have already - it isn't a user story, but don't worry too much about that, then practice with user stories on the next thing before coming up with the solution.
