So, this situation has become most interesting. A little more background might be helpful.
My company develops specialized software for a vertical industry (Long term Healthcare) and we have an add-on module to SL that is cataloged under its own module ID (RB for resident billing). This problem is with any of the reports under that module that have the posting period fields on the ROI screen. Resident Billing is basically a very specialized invoice generation process that feeds into AR. Consequently, the reports under this module that want to provide the posting period field on the ROI screen pull the posting period from AR setup as defined on the report control screen. This has worked fine for years and works fine for all of our clients using 6.5, 7.0 and 2011 except for this one client and this one of their two application databases.
Now for the details of what I have found.
As indicated earlier, the client has two application databases under one system database and only one of the databases exhibits this problem. Since both databases are under one system database, the issue cannot be with the report control since that is shared. Further, all RB report in this one database exhibit this problem and the very same reports in the other application database do not. Reports under AR show the correct posting period on the ROI screen in both application databases. In an attempt to run this down, I temporarily changed ARSetup to have the current posting period be 02-2014 and the ROI screen continued to show 12-2013. I reset ARSetup back to 01-2014 and then temporarily changed GLSetup to 01-2014 and now the ROI screen shows 01-2014. Clearly, ROI is pulling the posting period from GLSetup as opposed to ARSetup for some reason even though the report control says to pull it from ARSetup. However, if the second application database, which also has GLSetup still indicating 12-2013, I do not have the problem so that contradicts the premise that I just made. I set GLSetup back to 12-2013 in the failing database and the ROI screen fails again showing 12-2013.
This tells me that the issue is within the particular application database. However, as indicated in a prior post, when I ran the SQL trace, I saw that the stored procedure fetch_modulepernbr is called to determine the posting periods for each of the modules that have posting periods. If I execute this stored procedure out of SQL Manager it returns the correct posting period for AR. This tells me that there is some logic in the ROI code that takes the results from this stored procedure and applies some more logic and, for some reason, decides, in this database and not the other, that it needs to use the current GL posting period and not the current AR posting period but only in this particular application database.
I am thinking that the issue is, somehow, related to fact that the report is in a module that is not an SL standard module (though it is defined in the module table). But, it has to be something unique to this particular database since it does not do this in the other application database and it does not do this in any of my other client databases.
This issue has become a rather interesting conflict in findings. It appears that only someone with access to the program logic of ROI can determine what is unique in this situation. This probably means that this issue needs to be presented as an SL incident and my company pay for the incident charge but I really am not in favor of paying that charge under these circumstances.
By the way, this client used to be on version 6.5 and upgraded to SL 2011 and this application database never exhibited this problem under 6.5. Further, I am pretty sure, but cannot state for certain, that this problem was not there after moving to SL 2011 but the problem is that, in most cases, they keep GL in the same period as AR so it could have been there and the combination of the AR and GL periods were such that it did not show itself. GL is being held at 12-2013 because of the year-end needs on the GL side.
I sure wish that I could just take a peek at the ROI code that exists between the execution of that stored procedure and the setting of the posting period field on the screen. I guess that is the programmer in me.
