backup sent. have fun with it! i'm pretty sure all the data is fine, and there was some hidden/weird error in the report that I ran into.
DB server is on Win7. Client computer is XP. Hmmm... IDK?! But I'm not worried. I know the data is OK, cuz the other reports showed up fine.
-Mark
Deposit Report issues
Re: Deposit Report issues
.
Found Problem:
The problem arose because a manual date range was set using times other than the midnight time range with a non-standard midnight set in config.
Confusing??
This was caused by a rare set of circumstances that I still don't know how to account for due to their complexity other than maybe disabling the non-standard day ending times altogether.
First: the day ending time was set for 3:00am
Second: report was set for manual range on Dec 25 from 9:00a until Dec 25 at 11:00p.
The internal logic was thrown off since this was not a full day, and the report is a multi-day report. It had to guess since the starting and ending times were not anywhere close to the day ending time, and the day ending time was non-standard (not midnight). So what happened, is the report was showing data from Dec 25 at 9:00a until Dec 26 at 11:00p. The items showing on the report were in reality sold on the 26th, not on the 25th.
This situation can still be duplicated with this report in all versions.
Ways to avoid this scenario from occurring. Any single one of these will prevent the situation from occurring which is very rare.
There were no phantom orders.
Data was 100% accurate.
This issue only effects this report, since it is a multi-day report broken down into individual days.
Report couldn't figure out a valid range in the situation presented to it. Use any one of the above steps to prevent this from happening. Again this can only happen on a manually set date range version of this report while using a non-standard day ending time, and the report range using a range that overlaps that midnight time or less than 24 hours.
I will need to think about ways of preventing this from happening, but can't think of any easy fix other than avoiding the situation in the first place or by removing the ability to set the day ending time from the system. I will have to work this one out and will make sure that it is dealt with in some fashion in the next update.
This oddity is not critical and no data was being created from out of the blue. Again, this report is accurate when used as prescribed. It is best to use it for a multiple day period since that is how it was designed to be used.
Scott
Found Problem:
The problem arose because a manual date range was set using times other than the midnight time range with a non-standard midnight set in config.
Confusing??
This was caused by a rare set of circumstances that I still don't know how to account for due to their complexity other than maybe disabling the non-standard day ending times altogether.
First: the day ending time was set for 3:00am
Second: report was set for manual range on Dec 25 from 9:00a until Dec 25 at 11:00p.
The internal logic was thrown off since this was not a full day, and the report is a multi-day report. It had to guess since the starting and ending times were not anywhere close to the day ending time, and the day ending time was non-standard (not midnight). So what happened, is the report was showing data from Dec 25 at 9:00a until Dec 26 at 11:00p. The items showing on the report were in reality sold on the 26th, not on the 25th.
This situation can still be duplicated with this report in all versions.
Ways to avoid this scenario from occurring. Any single one of these will prevent the situation from occurring which is very rare.
- Set your day ending time to midnight (12:00a). There is no need to have it anything other than this unless you are open and taking orders beyond 12 midnight, and want those orders between midnight and closing to show up on the paperwork for the previous date which would technically be the same business day. If you don't take orders past midnight, then there is no need for this to be set to anything other than 12:00a.
- When manually running a report make sure that you include minimum a full 24-hour period that ends on the same exact time as your Day Ending Time is set to.
- Run the report for more than 1 day, and then single out the day that you want from a multi-day version of the report.
There were no phantom orders.
Data was 100% accurate.
This issue only effects this report, since it is a multi-day report broken down into individual days.
Report couldn't figure out a valid range in the situation presented to it. Use any one of the above steps to prevent this from happening. Again this can only happen on a manually set date range version of this report while using a non-standard day ending time, and the report range using a range that overlaps that midnight time or less than 24 hours.
I will need to think about ways of preventing this from happening, but can't think of any easy fix other than avoiding the situation in the first place or by removing the ability to set the day ending time from the system. I will have to work this one out and will make sure that it is dealt with in some fashion in the next update.
This oddity is not critical and no data was being created from out of the blue. Again, this report is accurate when used as prescribed. It is best to use it for a multiple day period since that is how it was designed to be used.
Scott
Re: Deposit Report issues
Ok, I think that I may have found a solution for this report. It took a complete reworking of the date range calculations, but the way it is working now, should cover any situation and be able to deal with any odd span period selected and still allow for setting of a non-standard day ending time.
The spans will be broken down into individual FULL days with the exception of the first day and the last day which will be from report start to midnight time for the first day, and from midnight time to report end on the last day.
If there is only 1 day, then that day will be treated as both the first day and the last day so you should get the actual report start to report end times provided that the selected period is less than a 24-hours AND they don't span the configured midnight time. If the midnight time is spanned (even by 1 second) then the report will contain 2 days (still from start to end) but could effect how things are shown depending on orders paid during the requested period.
Anyway, I am providing a link to a test build of the reports module. You will need to manually install this into your POSPizza6 folder since there is no installer at this time. This is only a test build and will be officially added to an update package at a later time. If your day ending time is set to 12:00a OR you don't use the manual date/time range for this report, then you don't need to worry about updating at this time. As I stated before the situation only occurs in rare instances with non-standard range / midnight settings.
updated: This report fix is now included in 6.20.01 and later
Thanks!
Scott
The spans will be broken down into individual FULL days with the exception of the first day and the last day which will be from report start to midnight time for the first day, and from midnight time to report end on the last day.
If there is only 1 day, then that day will be treated as both the first day and the last day so you should get the actual report start to report end times provided that the selected period is less than a 24-hours AND they don't span the configured midnight time. If the midnight time is spanned (even by 1 second) then the report will contain 2 days (still from start to end) but could effect how things are shown depending on orders paid during the requested period.
Anyway, I am providing a link to a test build of the reports module. You will need to manually install this into your POSPizza6 folder since there is no installer at this time. This is only a test build and will be officially added to an update package at a later time. If your day ending time is set to 12:00a OR you don't use the manual date/time range for this report, then you don't need to worry about updating at this time. As I stated before the situation only occurs in rare instances with non-standard range / midnight settings.
updated: This report fix is now included in 6.20.01 and later
Thanks!
Scott
Re: Deposit Report issues
In a client/server situation, the server could have discrepancies as well. I am not sure what SQL server that you are using with your system, but if it's not one of the big boys like Oracle, it could have some issues that could result in unexpected return data.
Jake
Jake
Re: Deposit Report issues
The server forwards SQL requests to SQLite and responses back to the clients. It doesn't do much to the actual data, so most discrepancies are on the client side of things when they show up.NetTech wrote:In a client/server situation, the server could have discrepancies as well. I am not sure what SQL server that you are using with your system, but if it's not one of the big boys like Oracle, it could have some issues that could result in unexpected return data.
Scott
Re: Deposit Report issues
Guys, I am still considering an upgrade to version 6.2. Especially since the credit processing can use the last card again. That was one of my main reasons for staying with version 5. Also switching over to a server setup seems a bit daunting to me. H-man, I'm not just making excuses, I have genuine worries about making such a big change to my system. In spite of the fact that everyone seems to really like the newest versions. I know the support is good too and my old version is no longer supported. Changes of this scale just seem kind of scary.
Re: Deposit Report issues
Moving from v5 to v6 is fairly easy. I would pick a time of day that is well before you open for business or after you close. You may also want to pick this time based on our business hours in case you need assistance. The process is quite simple you can read about it here http://forums.summitcn.com/viewtopic.php?f=30&t=1064 as well as in the main documentation. You can also do some test conversions ahead of time using the LT version of the software. After converting in LT, take a look at the data to see how it converted. You will want to convert from one to the other between time of business so that all of your real data is in a single database.naalo wrote:Guys, I am still considering an upgrade to version 6.2. Especially since the credit processing can use the last card again. That was one of my main reasons for staying with version 5. Also switching over to a server setup seems a bit daunting to me. H-man, I'm not just making excuses, I have genuine worries about making such a big change to my system. In spite of the fact that everyone seems to really like the newest versions. I know the support is good too and my old version is no longer supported. Changes of this scale just seem kind of scary.
Another thing, you can always hire a network professional to do the installation and they are welcome to call us with any questions or for assistance. Only you know your ability, and if you're not comfortable with it, then by all means hire someone. In the end hiring a pro is actually a lot cheaper because they can do in hours what would take an inexperienced person days in many cases. The upgrade is not hard at all, but only you know what you're truly comfortable with.
Scott