Just came across this exact same problem yesterday, and found your post while searching for an answer myself. I have a SQL Report that has a subscription that publishes a PDF, Excel, and MHTML file to a document library. That document library has an event receiver that does something to those files when they get published. The event receiver runs fine when a file is either added or updated using the SharePoint UI, but not when the subscription runs.
After giving this some thought I figured maybe the event receiver doesn't run in the context of the SharePoint web application. I tried setting a breakpoint in my event receiver and attaching the debugger to the OWSTimer service, which didn't yield anything, and then I tried again attaching it the SQL Reporting Service application, which in turn hit my breakpoint. My problem was that in my event receiver code I used the following code:
When the event receiver runs in the context of SharePoint, it checks the web.config for the appSettings key. When this runs in the context of SQL Reporting Services it checks this file:
Program Files\Microsoft SQL Server\MSRS10_50.LYNC\Reporting Services\ReportServer\bin\ReportingServicesService.exe.config
Because I only deployed my appSettings to the web.config for my site, the event receiver fails. I had to change the approach I use to pull up my configurable variables. At first thought this seems like a ridiculous approach to implementing event receivers, but after more thought it makes sense. For Reporting Services to publish a file, it would use the SharePoint API and call the method:
which at some point would need to check if there were event receivers which needed to be fired, both synchronously and asynchronously. Because the code is running in the context of the external application, in this case Reporting Services, everything in that methods code needs to be locally accessible by the calling application.
Long and short of this, if you coded your event receiver correctly and it fires in SharePoint but it doesn't appear to be firing from Reporting Services, make sure the DLL is GAC deployed, not in the bin folder, doesn't use web.config values in the code, and doesn't try to access anything that the SQL Reporting Services Service Account doesn't have access to.