[
https://issues.apache.org/jira/browse/OFBIZ-10905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108314#comment-17108314 ]
Jacques Le Roux commented on OFBIZ-10905:
-----------------------------------------
Thanks Pierre,
I have succesfully run the createFuturePeriod service after a loadAll and checked in [
https://localhost:8443/webtools/control/entity/find/CustomTimePeriod] I see no new CustomTimePeriod, normal? With 1ST_AND_15TH_MONTH should one CustomTimePeriod not be created today? JobSandbox and SystemProperty data are OK.
I aldo reviewed the code. It's seems good to me, but please apply the same formatting in Groovy than we do in Java. like
* lines not longer than 120 chars;
* spaces after while, if, and other alike statements
You may look in above code to see what I'm talking about. For now Checkstyle is not effective on Groovy code, not a reason to not doing it right. We plan to use Codenarc one day...
> Have a service that runs periodically to generate CustomTimePeriod records
> --------------------------------------------------------------------------
>
> Key: OFBIZ-10905
> URL:
https://issues.apache.org/jira/browse/OFBIZ-10905> Project: OFBiz
> Issue Type: New Feature
> Components: accounting
> Affects Versions: Release Branch 15.12, Release Branch 16.11, Release Branch 18.12, Release Branch 17.12, Trunk
> Reporter: Pierre Smits
> Assignee: Pierre Smits
> Priority: Major
> Labels: CustomTimePeriod, usability
>
> Currently no service exists that creates CustomTimePeriod records on a scheduled basis. One could think of:
> * a yearly schedule that creates the next fiscal year period
> * a quarterly schedule that creates the next fiscal quartered period
> * a monthly schedule that creates the next fiscal month period
> Considerations regarding requirements:
> # Following requirements are to be considered static:
> ## the highest granularity regarding a custom time period is a year (parameter value = YEAR)
> # Following requirements are to be configured/set via SystemProperty records:
> ## the applicability based on data PeriodType records: currently we can derive/identify two categories: FISCAL and SALES;
> ## the highest period granularity is static and set to "YEAR"
> ## the lowest period granularity is configurable and set to "MONTH";
> ## whether intermediate granularities (between lowest and highest) should be created for a given type (see 2.1) (intermediate indicator: "true"/"false" or "Y"/"N").
> # A CustomTimePeriod is only to be created:
> ## when a PartyAcctgPreference record exists, and
> ## when the 'enableAccounting' field of that record has the value set to "Y"
> # Each lower granularity CustomTimePeriod record must reference higher granularity CustomTimePeriod record (Parent/Child principle), when requirement consideration 2.4 is set to true or Y.
> Based on requirement considerations stated above, following examples can be thought of:
> # with lowest granularity set to "MONTH" and intermediate indicator = "N" and type ="FISCAL:
> {code:java}
> <CustomTimePeriod customTimePeriodId="202000001" periodTypeId="FISCAL_MONTH" fromDate="2020-01-01 00:00:00.000" thruDate="2020-01-31 23:59:59.000" isClosed="N" periodNum="20200000" periodName="2020-JAN" organizationPartyId="Company" />
> <CustomTimePeriod customTimePeriodId="202000002" periodTypeId="FISCAL_MONTH" fromDate="2020-01-02 00:00:00.000" thruDate="2020-02-29 23:59:59.000" isClosed="N" periodNum="20200000" periodName="2020-FEB" organizationPartyId="Company" />
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Locked
