Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0013601
TypeCategorySeverityReproducibilityDate SubmittedLast Update
feature request[Openbravo ERP] 01. General setupmajoralways2010-06-10 09:282010-12-31 09:58
ReportermgerkeView Statuspublic 
Assigned Tovmromanos 
PriorityhighResolutionopenFixed in Version
StatusclosedFix in branchFixed in SCM revisionorgvalidfrom
ProjectionnoneETAnoneTarget Version
OSLinux 32 bitDatabasePostgreSQLJava version1.6.0_18
OS VersionCommunity ApplianceDatabase version8.3.9Ant version1.7.1
Product Version2.50MP14SCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0013601: "Valid from Date" field in Organization

DescriptionThere is a need for a "Valid from Date" field in Organization.

We may want to register new organizations but do not want to allow their selection in transaction until a date, defined in the "Valid from Date" field in Organization window.
Proposed SolutionThis has to be built in an extension module.

1) Add a "Valid from Date" mandatory field in Organization window (see screenshot). "On create default" value will be '01-01-1900' [1]

2) Add a validation logic to the Organization drop-down in ALL the transactional windows in order that only valid ones (the ones which Valid From Date >= Today) can be selected.

[1] http://wiki.openbravo.com/wiki/ERP/2.50/Developers_Guide/How_to_define_an_oncreatedefault [^]
TagsModuleCandidate
Attached Filespng file icon ValidFromOrg.png [^] (52,455 bytes) 2010-06-10 09:28

- Relationships Relation Graph ] Dependency Graph ]
depends on feature request 0015559 newplatform DAL: Add support to @#Date@ as default value for a column 
Not all the children of this issue are yet resolved or closed.

-  Notes
(0028434)
psanjuan (manager)
2010-06-15 10:30
edited on: 2010-10-20 11:43

Michael sent an email with below information:
Hi all,
I must refine and extend this requirement. We need both fields
validFrom and validTo for tables:

ad_org
ad_treenode

I will give you some examples in Pamplona next week. Ad_tree was not in our focus until now.

(0031812)
dalsasua (reporter)
2010-10-13 16:13

Hi,

IMHO what is here required is to have an "intelligent" Active flag. Adding any other field is not possible to ensure that all validations (even the ones coming from module extensions, or added in the future to core) will check this new constraint.

My proposal is to create a module that:

1. Adds the valid from field in the organization window
2. If that date is in the future, then the Active flag in the organization window will be un-checked, and turned into not editable
3. A background process will check every day @0.00 hour all organizations, and those ones that get to the valid from date will turn the Active flag checked, and editable automatically.

With this solution we cover the functionality with no change in core code.

Regards.

David.
(0031832)
dmitry_mezentsev (developer)
2010-10-13 20:39

Hello All,

Just as my observation on this feature (primarily targeting Mikel and Anja).

Do you think you will have lots of new organizations to manage this way?
I feel we might be creating too many complexity that can be avoided with a manual (but very simple, takes seconds) step of setting Active flag. With 3.0 it will be even faster course will be doable from grid.

For me it should perfectly work on-demand (once needed to change, - changed).
(0033131)
psanjuan (manager)
2010-12-13 15:53
edited on: 2010-12-31 10:01

This note is meant to be a detailed explanation of the way we are going to implement this feature:

1) A new field must be added in the application path:"General Setup//Enterprise // Organization - Organization tab ; named "Valid > From date" - QA OK

2) "Valid From date" must be a mandatory field- QA OK

3) "Valid From date" must be filled-in by default with the date 01-01-1900, which can be changed by the end-user whenever is needed - QA OK

4) An Organization will be shown in any of the Openbravo windows where there is an "organization" field, only if that organization is Active and only in case its Valid From Date is <= system's date - QA OK

This feature will be either implemented as 5a) or 5b) -> to be decided.
It has been decided we will go for 5b) while processing invoices.

5a) Openbravo will check the accounting date entered in any document which can be posted in the system, and it will compare it against the "Valid From Date" of the corresponding Organization while "POSTING" the document.

5b) Openbravo will check the accounting date entered in the Invoices, and it will compare it against the "Valid From Date" of the corresponding Organization while "PROCESSING" the invoices.

6) Based on 5 above, documents will not be processed nor posted in case the accounting date is < Organization Valid From Date. (updated to < Organization Valid From date, as per Michael feedback)

It has been finally agreed that we will implement 5b) which means that:
Openbravo will check the accounting date entered in the Invoices, and it will compare it against the "Valid From Date" of the corresponding Organization while "PROCESSING" the invoices - QA OK

New!!:
7) A background process named "Organization Valid From" will have to be scheduled from the application path: General Setup || Process Scheduling || Process Request || Process Request - QA OK

8) This process will automatically mark an Organization as "active" or "Not Active" depending on its "Valid From" date value and the current date - QA OK

9) Above validation will also take place while saving an Organization at the application path: "General Setup // Enterprise // Organization". An Organization will be automatically mark as Active or Not Active by comparing Valid From date with the System Date while saving.

(0033219)
mgerke (reporter)
2010-12-16 08:49

Correction for item 6:
Based on 5 above, documents will not be processed nor posted in case the accounting date is < Organization Valid From Date. (not '<=')
(0033282)
psanjuan (manager)
2010-12-20 11:41

validation on “Processing” is OK.
Feature signed-off. Ready to start.
(0033497)
psanjuan (manager)
2010-12-31 09:58
edited on: 2010-12-31 11:53

Signed-off requirements dated on Dec 13, 2010 did not explain how the system should behave in case of an Organization being created by using "Initial Organization setup".
It has been agreed that if a new Organization is created by using the Initial Organization setup process, the new field named "Valid From" will take the "system date" as "Valid From" date, because there is no way it can take an static value such as 01-01-1900.
The end-user will be able to set a diferet Valid From date while setting that Organization as Ready.

On the other hand, in case of creating an Organization by "manually" creating a new record in the window "Organization", the system will fill-in the Valid From field with the value "Sys Date" as there is an enhancement required for DAL to be implemented in order to avoid that behaviour, for more information see the feature request (15559)linked to this feature request.


- Issue History
Date Modified Username Field Change
2010-06-10 09:28 rafaroda New Issue
2010-06-10 09:28 rafaroda Assigned To => sathiyan
2010-06-10 09:28 rafaroda File Added: ValidFromOrg.png
2010-06-10 09:30 rafaroda Tag Attached: ModuleCandidate
2010-06-10 09:30 rafaroda Proposed Solution updated
2010-06-10 11:59 rafaroda Proposed Solution updated
2010-06-15 10:30 psanjuan Note Added: 0028434
2010-06-15 10:31 psanjuan Note Edited: 0028434 View Revisions
2010-10-13 16:13 dalsasua Note Added: 0031812
2010-10-13 16:13 dalsasua Assigned To sathiyan => dalsasua
2010-10-13 16:13 dalsasua Status new => feedback
2010-10-13 20:39 dmitry_mezentsev Note Added: 0031832
2010-10-20 11:43 psanjuan Note Edited: 0028434 View Revisions
2010-10-20 15:30 rafaroda Reporter rafaroda => mgerke
2010-10-20 15:30 rafaroda Issue Monitored: rafaroda
2010-11-17 17:06 psanjuan Note Added: 0032678
2010-11-17 17:06 psanjuan Status feedback => new
2010-11-17 18:20 psanjuan Note Deleted: 0032678
2010-12-13 15:53 psanjuan Note Added: 0033131
2010-12-13 16:07 psanjuan Note Edited: 0033131 View Revisions
2010-12-13 16:24 psanjuan Note Edited: 0033131 View Revisions
2010-12-13 16:31 psanjuan Note Edited: 0033131 View Revisions
2010-12-13 16:34 psanjuan Note Edited: 0033131 View Revisions
2010-12-13 19:00 psanjuan Note Edited: 0033131 View Revisions
2010-12-13 19:10 psanjuan Note Edited: 0033131 View Revisions
2010-12-14 12:57 psanjuan Note Edited: 0033131 View Revisions
2010-12-14 12:58 psanjuan Note Edited: 0033131 View Revisions
2010-12-14 13:00 psanjuan Assigned To dalsasua => vmromanos
2010-12-16 08:49 mgerke Note Added: 0033219
2010-12-16 10:07 psanjuan Note Edited: 0033131 View Revisions
2010-12-16 12:07 psanjuan Note Added: 0033232
2010-12-16 12:10 psanjuan Note Deleted: 0033232
2010-12-16 15:11 psanjuan Note Edited: 0033131 View Revisions
2010-12-20 10:21 vmromanos Status new => scheduled
2010-12-20 10:21 vmromanos fix_in_branch => pi
2010-12-20 11:40 psanjuan Note Edited: 0033131 View Revisions
2010-12-20 11:41 psanjuan Note Added: 0033282
2010-12-29 12:28 psanjuan Note Edited: 0033131 View Revisions
2010-12-29 12:32 psanjuan Note Edited: 0033131 View Revisions
2010-12-29 12:50 psanjuan Note Edited: 0033131 View Revisions
2010-12-29 12:55 psanjuan Status scheduled => resolved
2010-12-29 12:55 psanjuan Fixed in Version => 1.0.0
2010-12-29 12:55 psanjuan Fixed in SCM revision => http://forge.openbravo.com/projects/orgvalidfrom [^]
2010-12-29 12:55 psanjuan fix_in_branch pi =>
2010-12-29 12:56 psanjuan Status resolved => closed
2010-12-30 00:00 anonymous sf_bug_id 0 => 3147856
2010-12-31 09:58 psanjuan Note Added: 0033497
2010-12-31 10:01 psanjuan Note Edited: 0033131 View Revisions
2010-12-31 11:27 psanjuan Note Edited: 0033497 View Revisions
2010-12-31 11:44 psanjuan Note Edited: 0033497 View Revisions
2010-12-31 11:49 vmromanos Relationship added depends on 0015559
2010-12-31 11:53 psanjuan Note Edited: 0033497 View Revisions


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker