openerp-community team mailing list archive

[Ovnicraft <ovnicraft@xxxxxxxxx>]

On Thu, Feb 14, 2013 at 10:54 AM, Arturo Galvan Rdz. <agalvan@xxxxxxxxxxx>wrote:

> Hi
>
>   We are using OpenERP version 6.1 on Mexico's western timezone (UTC minus
> 7).
>
>   Since the server uses UTC, whenever an account_move gets created after 5
> p.m. its date is set to the next day. That wouldn't be a problem if the
> date field of the account.move object were of the type datetime. In that
> case we would add (or subtract) the appropriate offset and obtain the
> correct date. The way things are, however, we have no way of knowing if a
> movement took place on the date stored or on the day before (with
> implications for taxes as well as monthly reports, etc.)
>
>
Hello this is highly critical error, use UTC was a good move but must be
tested to put it in production.

Ask to accountant what can happen if this bug break the system in
production, as you mention tax declaration, balance by date or period,
auditing, it breaks all the system.

Please check updating the branch.

Here in Gnuthink still working with 6.1 eventually goes to 7.0

Regards,



>   I understand the need to represent something as a date (with no hour)
> but we cannot, at present, accurately represent the date of an account.move
> because the hour is not included in the date.
>
>   Shouldn't all the columns of type date be of the type datetime ??
>
>
>   Arturo Galvan
>   OpenBIAS S. de R.L. de C.V.
>
>
>
> ______________________________**_________________
> Mailing list: https://launchpad.net/~**openerp-community<https://launchpad.net/~openerp-community>
> Post to     : openerp-community@lists.**launchpad.net<openerp-community@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~**openerp-community<https://launchpad.net/~openerp-community>
> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>



-- 
Cristian Salamea
@ovnicraft