I don't know if the recent time zone work would have any affect on this. It's a
possibility.
I'm not familiar with POS and entity sync, so I'll describe the changes I made and maybe others who
are more familiar with Vince's setup can figure it out.
The basic concept is:
1. Date/time String in UI (user's time zone) gets converted to TimeStamp (which is referenced to
GMT), then it is stored.
2. TimeStamp in storage (GMT) gets converted to date/time String for UI (user's
time zone).
3. Only the screen widget and Freemarker template code was changed.
You shouldn't have to set all of your terminals to the same time zone as the server. If the problem
is in OFBiz, we should fix it.
-Adrian
Vince M. Clark wrote:
Yes. I pulled it from trunk about a week ago.
----- Original Message -----
From: "Jacopo Cappellato" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, December 7, 2007 8:36:18 AM (GMT-0700) America/Denver
Subject: Re: Strange behavior with Entity Sync
Hi Vince,
are you running a recent OFBiz revision?
I guess that Scott asked you about the timezones because we have
recently refactored the way datetimes are treated in OFBiz: Adrian Crum
worked on this, and he could better explain, but the idea is that when a
date field is edited it is converted from the user session locale to the
system locale.
I think that Scott could be right... Adrian, do you think that your work
could have caused some side effects on the entity synch stuff?
Jacopo
Vince M. Clark wrote:
It could be a timezone issue. We will test a bit more and try to nail down a pattern. We can isolate the problem to the same set of records that always get pulled incomplete.
The server is set to GMT and all the POS terminals are mountain. When first setting up sync I had some difficulty getting the PULL to start running and suspected it was due to the timezone being in the future on the server. But we got past that.
Given that we will have terminals in all US timezones it is not really a good option to set them all to the same time as the server.
----- Original Message -----
From: "Scott Gray" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, December 6, 2007 11:32:11 PM (GMT-0700) America/Denver
Subject: Re: Strange behavior with Entity Sync
Just a stab in the dark but do these issues arise if the server and terminal
are in the same timezone?
Regards
Scott
On 07/12/2007, Vince M. Clark <[EMAIL PROTECTED]> wrote:
BJ - your question is not ignorant, but I have no idea how to answer.
We'll have to depend on others in the community much smarter than us.
Entity Sync is a feature available in the system. We are using it and I
can only assume that it works if configured properly. I have figured out the
basics of push and pull synchronization. That is about as much intelligence
as I can claim.
I can get into the details of what I loaded and where if necessary, such
as EnityGroup, EnittySync, RecurrenceRule, etc.
----- Original Message -----
From: "BJ Freeman" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, December 6, 2007 4:35:09 PM (GMT-0700) America/Denver
Subject: Re: Strange behavior with Entity Sync
ignorant question
does not entity sync mess up the accounting.
how are the ecas that are suppose to fire based on certain services,
that do CRUD of the entity suppose to fire?
am I missing some documentation on how this works?
Vince M. Clark sent the following on 12/6/2007 1:58 PM:
We are using entity sync to keep POS terminals and a central server
synchronized. We are going direct from POS to MCS, no Per Store Server
involved. We have a pull sync (MCS to POS) and a push sync (POS to MCS.)
Some data such as inventory is going both ways.
A few issues:
1) Records deleted on MCS are not deleted on POS.
2) Pull sync is not getting complete records in some cases. Two entities
we see this consistenly is on Facility and InventoryItem. We get partial
records sometimes. Note that this only seems to occur on the initial pull
when we are first populating a new POS terminal from the central server.
Once we identify a record, such as a facility, that didn't come down
completely we can update the timestamp on the server and the next pull gets
the complete record.
3) Related to item 2. If a push occurs from the POS terminal BEFORE we
get the initial data correct, it overwrites the data on MCS. For example, if
a facility record was pulled down and the store id is missing then when the
terminal push occurs it trashes the facility record on the server. Strange
thing is we aren't pushing facility data, only pulling.
Note that the server time is different than the terminals (different
timezones.)
Vince Clark
Global Era
The Freedom of Open Source
[EMAIL PROTECTED]
(303) 493-6723
