0021996: Wrong "Order Date" field in the created sales order when ticket was created in a different time&date

Notes
(0053468) marvintm (manager) 2012-10-18 16:49	There are two things to consider here: * The "time" part cannot be stored. This is how Openbravo works. The dateordered column (and the rest of the date columns in c_order) has a "date" reference, and therefore only the "date" part is stored. Orders created directly in the backoffice work exactly the same way as the ones created in the POS in this regard (you can check by creating an order in Openbravo, and then doing the same query you mentioned in the report). * The "date" part sent by the client is saved directly in the backend, without any changes (so it should be the exact same date generated in the client side). However, here the behaviour you see might not be what you would expect, and maybe this has to do with timezone differences. I need a bit more information to conclude whether there is a bug in this second part, or not. An specific example would be useful for this: * What is the difference between client and server sides in regards to the system dates? It's very important to note that generally, it doesn't make sense that client and server system dates are different (because both are running in the same time-space interval :)). However, it might be (and this of course would make all the sense in the world) that the client and server dates are set in different timezones. So, was the timezone, or the hour itself, what was different between the client and server? If the hour itself was different, then I would say this is a configuration issue. If the hour is the same, but the timezone is different, and a strange behaviour was noticed, then it's likely this is a bug. * What was specifically the strange behaviour noticed in regards to the date? (apart from the 0:00:00 side, which was already explained). Was the order created in a different "day", or was other behaviour noticed? Thanks in advance.

(0054249) xplacesc (reporter) 2012-11-14 21:59	Hello, in regards to the time, we should think about it. Without a valid time information, specially in Retail, retailer is loosing critical sales information, for example the hourly sales reports, which are used very often and help to know how a store is performing during the day. I'm not saying which field must provide this, but it is something required. Maybe it is not a bug but a feature request, but it is a business requirement. In regards to the date, what we saw is that the stored date was not corresponding to that in the Web POS, but another one, which seems to be the server date. We changed the local settings (timezone), and this was properly reflected in the Web POS UI and receipts, but it was not the case in the created order in the BackOffice, which means you can really have different dates because of the time difference. You can test it simply by setting a local timezone that causes a date difference with the backend at the moment of the sale. This behaviour can be worst, when for example a ticket can't be synchronized, and will be later (the difference is bigger). What we were discusing with Isma, was that he thinks that this behaviour is correct because it is always needed a central time reference (the backend). The problem comes when you need to analyze all this information by considering the original timezones and to provide meaningfull info for each store. If you have stores in different countries with different timezones, your reporting should be able to differentiate this. Isma considers this is more a UI layer issue that a data layer issue, but sincerely I don't see it clear. At any case, each transaction should have the backend date/time, but also maybe a reference to the timezone that originated the transaction (if not the origin time/date). Otherwise, I don't see how you will be able to present reporting on different zones with meaningful time information. Don't know if it is clear... We can talk if it helps. Xavi

(0054290) marvintm (manager) 2012-11-16 13:05	Hi, In regards to the date part, the problem is now clear (and reproducible). A fix for this will be committed very soon. In regards to the time part, the problem is acknowledged, and will be fixed in a slightly different way, by setting the "created" column correctly. I will send an email with more information soon. Regards, Antonio.

(0054292) hgbot (developer) 2012-11-16 13:17	Repository: erp/pmods/org.openbravo.retail.posterminal Changeset: 5b8923d5d9dc8e83b99971fd22af0c3d4d55ffd0 Author: Antonio Moreno <antonio.moreno <at> openbravo.com> Date: Fri Nov 16 13:07:09 2012 +0100 URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/5b8923d5d9dc8e83b99971fd22af0c3d4d55ffd0 [^] Fixed issue 21996. Changed how the dates are stored in the Web POS backend side. From now on, the dates will be transformed to the original timezone in which they were generated, and then stored. This is done because when the server and the client are in different timezones, it could happen that at some points in time they are in different 'days', and the client should always prevail. --- M src/org/openbravo/retail/posterminal/JSONPropertyToEntity.java M src/org/openbravo/retail/posterminal/OrderLoader.java M web/org.openbravo.retail.posterminal/js/data/dataordersave.js ---

(0054596) adrianromero (manager) 2012-11-27 18:44	Closed for RMP17

Issue History
Date Modified	Username	Field	Change
2012-10-18 13:22	xplacesc	New Issue
2012-10-18 13:22	xplacesc	Assigned To	=> adrianromero
2012-10-18 13:30	adrianromero	Summary	Date & Time wrong in the "Order Date" field in the created sales order when => Wrong "Order Date" field in the created sales order when ticket was created in a different time&date
2012-10-18 16:49	marvintm	Note Added: 0053468
2012-10-18 16:49	marvintm	Status	new => feedback
2012-11-14 18:23	adrianromero	Assigned To	adrianromero => marvintm
2012-11-14 21:59	xplacesc	Note Added: 0054249
2012-11-16 13:05	marvintm	Note Added: 0054290
2012-11-16 13:17	hgbot	Checkin
2012-11-16 13:17	hgbot	Note Added: 0054292
2012-11-16 13:17	hgbot	Status	feedback => resolved
2012-11-16 13:17	hgbot	Resolution	open => fixed
2012-11-16 13:17	hgbot	Fixed in SCM revision	=> http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/5b8923d5d9dc8e83b99971fd22af0c3d4d55ffd0 [^]
2012-11-27 10:19	adrianromero	Target Version	=> RMP17
2012-11-27 18:44	adrianromero	Note Added: 0054596
2012-11-27 18:44	adrianromero	Status	resolved => closed

Relationships [ Relation Graph ] [ Dependency Graph ]