Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0019002Openbravo ERP01. General setuppublic2011-11-07 01:202024-11-13 16:19
Reporterpjuvara 
Assigned Toplujan 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version3.0MP4.1 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0019002: System is not fully working with date format MM-DD-YYYY
DescriptionBy executing a superficial test with date format MM-DD-YYYY, I could detect two major defects: 19000 and 19001.

Both issues are significant enough to make the system inoperable for a US customer.

More issues can be present in the system and a comprehensive review and test of the support of alternative date formats is needed.
Steps To ReproduceN/A
Proposed Solution
Additional Information
TagsAccountingDemo
Relationships
related to defect 0019331 closed marvintm Format date dd/mm/yyyy fails in P&E in return from customer 
depends on defect 0019000 closed vmromanos Balance sheet and P&L report does not work when system configured with MM-DD-YYYY date format 
depends on defect 0019001 closed vmromanos Incorrect accounting date and period in GL Journal Header when system date format is MM-DD-YYYY 
depends on defect 0019455 closed marvintm The process scheduling fails after some time if using a different date format 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-11-07 01:20pjuvaraNew Issue
2011-11-07 01:20pjuvaraAssigned To => jonalegriaesarte
2011-11-07 01:20pjuvaraModules => Core
2011-11-07 01:20pjuvaraRelationship addeddepends on 0019000
2011-11-07 01:20pjuvaraRelationship addeddepends on 0019001
2011-11-07 01:21pjuvaraversion => 3.0MP4.1
2011-11-07 01:43pjuvaraTag Attached: AccountingDemo
2011-12-19 10:47iciordiaAssigned Tojonalegriaesarte => marvintm
2011-12-19 12:56psarobeRelationship addedrelated to 0019331
2012-01-10 18:34marvintmRelationship addeddepends on 0019455
2012-02-29 12:45iciordiaAssigned Tomarvintm => plujan
2012-02-29 12:45iciordiaTypedefect => design defect
2012-12-12 17:26ioritzCiaTriggers an Emergency Pack => No
2012-12-12 17:26ioritzCiaSeveritycritical => major
2015-01-14 16:23plujanStatusnew => scheduled
2015-01-14 16:23plujanfix_in_branch => pi
2015-01-14 16:28plujanNote Added: 0073496
2015-01-14 16:28plujanStatusscheduled => resolved
2015-01-14 16:28plujanFixed in Version => 3.0PR15Q4
2015-01-14 16:28plujanFixed in SCM revision => n/a
2015-01-14 16:28plujanResolutionopen => fixed
2015-01-14 16:32plujanFixed in SCM revisionn/a => n.a.
2015-01-14 16:32plujanfix_in_branchpi =>
2015-01-19 20:29iciordiaStatusresolved => closed
2024-11-13 16:15hgbotNote Added: 0171942
2024-11-13 16:19hgbotNote Added: 0171943
2024-11-13 17:53shuehnerNote Deleted: 0171943
2024-11-13 17:53shuehnerNote Deleted: 0171942

Notes
(0073496)
plujan   
2015-01-14 16:28   
After several iterations, we have now automated some basic flows using MM-DD-YYYY format and also we have included this, including the use of point and comma as decimal and thousands separators, into our regular QA cycles.

Due the generic nature of the issue, it is not possible to declare that the system is "fully working" on MM-DD-YYYY format, but we have minimised the risk of an issue on this topic enough to consider it working as expected.

If any other issue related to this functionality is found in the coming releases, it should be treated as a separate issue linked to this one as "related".