You would have to build a control flow and data flow for each table. If this was something I had to work on I would look to BIML to generate the SSIS package(s).
It depends on the source system and what access I have to the source system. I prefer using stored procedures on the source system and using OLEDB Source to execute the procedure (with parameters). If the source system is not SQL Server then I usually go with ADO.NET and the appropriate managed provider for that system. The problem with ADO.NET is that it doesn't work with parameters - so you end up using a variable for the query for dynamic queries.
For the destination - I prefer using the OLEDB Destination and setting the option for fast table load - as well as setting the commit and batch sizes. Setting the commit and batch sizes insures that I don't bloat the transaction log and improves the performance.
With that said - if the vendor is providing this - why do you want to recreate it? I would have to assume that the vendor has a reason for how they set this up...in a lot of cases the vendor would be excluding data (rows) that have no value for reporting.