You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Pierre Smits (Jira)" <ji...@apache.org> on 2020/05/16 08:00:00 UTC

[jira] [Comment Edited] (OFBIZ-10905) Have a service that runs periodically to generate CustomTimePeriod records

    [ https://issues.apache.org/jira/browse/OFBIZ-10905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108680#comment-17108680 ] 

Pierre Smits edited comment on OFBIZ-10905 at 5/16/20, 7:59 AM:
----------------------------------------------------------------

Hi Jacques,

I will revisit the code, visavis your remarks regarding the coding formats.

I trust you executed the createFuturePeriod service from the 'run service' function in web tools, like [https://demo-trunk.ofbiz.apache.org/webtools/control/runService.]

If you executed it the first time the service should have created 2 CustomTimePeriod records: 1 for the upcoming month and 1 for the related parent, provided you have:
 # the SystemProperty settings loaded into the database (as suggested/provided, and
 # have in the PartyAcctgPreference record for the appropriate INTERNAL_ORGANIZATIO party the field 'enableAccounting' have the value 'Y".

Otherwise, no CustomTimePeriod records will be created.

Indeed with the service scheduled in accordance with the provided JobSandbox record as defined and provided in the included [CommonScheduledServicesDemoData.xml|https://github.com/apache/ofbiz-framework/pull/133#diff-d0318bc81c4688a18811a087168d26cb] in the PR, there should be a new JobSandBox record for the next run moment (see attached image what the upload of the JobSandbox record in demo-trunk yielded). If you have something similar, then that would be an indication that the service has been scheduled properly. If not, we need to dig deeper. Can you provide a screenshot and a log excerpt?

See also latest attached screenshot (generated today) regarding the expected result.

 


was (Author: pfm.smits):
Hi Jacques,

I will revisit the code, visavis your remarks regarding the coding formats.

I trust you executed the createFuturePeriod service from the 'run service' function in web tools, like [https://demo-trunk.ofbiz.apache.org/webtools/control/runService.]

If you executed it the first time the service should have created 2 CustomTimePeriod records: 1 for the upcoming month and 1 for the related parent, provided you have:
 # the SystemProperty settings loaded into the database (as suggested/provided, and
 # have in the PartyAcctgPreference record for the appropriate INTERNAL_ORGANIZATIO party the field 'enableAccounting' have the value 'Y".

Otherwise, no CustomTimePeriod records will be created.

Indeed with the service scheduled in accordance with the provided JobSandbox record as defined and provided in the included [CommonScheduledServicesDemoData.xml|https://github.com/apache/ofbiz-framework/pull/133#diff-d0318bc81c4688a18811a087168d26cb] in the PR, there should be a new JobSandBox record for the next run moment (see attached image what the upload of the JobSandbox record in demo-trunk yielded). If you have something similar, then that would be an indication that the service has been scheduled properly. If not, we need to dig deeper. Can you provide a screenshot and a log excerpt?

 

> 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
>         Attachments: Screen Shot 2020-05-15 at 23.32.14.png, Screen Shot 2020-05-16 at 09.58.07.png
>
>
> 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)