A major bug in OFBiz Manufacturing MRP function

[Schumann]

Dear Gurus,

I found a serious bug in MRP calculation function (hope I was wrong) and I've created a JIRA note OFBIZ-10321.
In a word, OFBiz MRP function seems currently not supportive of multilevel BOM calculation with same material (raw material in my case test) located in different BOM level.

While the tested scenario above is quite normal in various industries, so my question is, is there any workaround or we have to wait until next patch or release?

Thanks

Best Regards

Schumann

[Jacopo Cappellato-5]

Dear Schumann,

thanks for your report and analysis.
What version of MySQL are you using? I suspect that the error is caused by
the fact that your version doesn't support milliseconds in the DATETIME
field and this causes the "duplicate record" condition.

Kind regards,

Jacopo


On Thu, Mar 29, 2018 at 11:04 AM, Schumann Ye <[hidden email]>
wrote:

> Dear Gurus,
>
> I found a serious bug in MRP calculation function (hope I was wrong) and
> I've created a JIRA note OFBIZ-10321.
> In a word, OFBiz MRP function seems currently not supportive of multilevel
> BOM calculation with same material (raw material in my case test) located
> in different BOM level.
>
> While the tested scenario above is quite normal in various industries, so
> my question is, is there any workaround or we have to wait until next patch
> or release?
>
> Thanks
>
> Best Regards
>
> Schumann
>
>
>

[Schumann]

Dear Jacopo,

Thanks for your guiding and you're such a genius.
I just check the version of the installed mysql by using "select version();" and it shows me 5.7.19.
Then I try to google if mysql support milliseconds and I find the following 2 links:
https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html
https://dev.mysql.com/doc/refman/5.6/en/fractional-seconds.html

It seems like starting from version 5.6 mysql had supported microseconds (so as milliseconds), which could be proven by using the code "SELECT MICROSECOND('2010-12-10 14:12:09.019473');".
However, when MySQL stores a value into a column of any temporal data type, it discards any fractional part and does not store it.

Solution to this would be:
To define a column that includes a fractional seconds part, use the syntax type_name(fsp), where type_name is TIME, DATETIME, or TIMESTAMP, and fsp is the fractional seconds precision. For example:
CREATE TABLE t1 (t TIME(3), dt DATETIME(6));
The fsp value, if given, must be in the range 0 to 6. A value of 0 signifies that there is no fractional part. If omitted, the default precision is 0. (This differs from the standard SQL default of 6, for compatibility with previous MySQL versions.)

So I assume you are right then what table field in mysql ofbiz table I should change to verify your theory.
According to the code snippet, it should be the field Event_Date of the table ofbiz.mrp_event as shown in MrpServices.java.

So after updating the column by "ALTER TABLE ofbiz.mrp_event change EVENT_DATE EVENT_DATE DATETIME(6); " and a reboot, MRP is running correctly.
Everything now works like a charm.

BTW, shall I set the JIRA note to closed or someone else would do so?
Thanks again.

Schumann

-----邮件原件-----
发件人: Jacopo Cappellato <[hidden email]>
发送时间: 2018年3月29日 22:23
收件人: [hidden email] ML <[hidden email]>
主题: Re: A major bug in OFBiz Manufacturing MRP function

Dear Schumann,

thanks for your report and analysis.
What version of MySQL are you using? I suspect that the error is caused by the fact that your version doesn't support milliseconds in the DATETIME field and this causes the "duplicate record" condition.

Kind regards,

Jacopo


On Thu, Mar 29, 2018 at 11:04 AM, Schumann Ye <[hidden email]>
wrote:

> Dear Gurus,
>
> I found a serious bug in MRP calculation function (hope I was wrong)
> and I've created a JIRA note OFBIZ-10321.
> In a word, OFBiz MRP function seems currently not supportive of
> multilevel BOM calculation with same material (raw material in my case
> test) located in different BOM level.
>
> While the tested scenario above is quite normal in various industries,
> so my question is, is there any workaround or we have to wait until
> next patch or release?
>
> Thanks
>
> Best Regards
>
> Schumann
>
>
>

[Rajesh Mallah]

> However, when MySQL stores a value into a column of any temporal data
> type, it discards any fractional part and does not store it.Kind regards,
>

I thought MySQL had by now gotten over from the childhood disease of
discarding data silently  ;-)
in many contexts it was like that even 10 year back.

regds
mallah.

[Schumann]

Hi Rajesh,

According to the official website documents, it looks like that, which is bad for the programmers and the end users.
What is your suggestion for a production environment, mysql or mssql or others?
I am afraid of future potential similar traps.

B.R.
Schumann

-----邮件原件-----
发件人: Rajesh Mallah <[hidden email]>
发送时间: 2018年3月29日 23:24
收件人: [hidden email]
主题: Re: 答复: A major bug in OFBiz Manufacturing MRP function

> However, when MySQL stores a value into a column of any temporal data
> type, it discards any fractional part and does not store it.Kind
> regards,
>

I thought MySQL had by now gotten over from the childhood disease of discarding data silently  ;-) in many contexts it was like that even 10 year back.

regds
mallah.

[Rajesh Mallah]

Hi Schmann ,

You may consider exploring PostgreSQL.

regds
mallah.

On Thu, Mar 29, 2018 at 8:58 PM, Schumann Ye <[hidden email]>
wrote:

> Hi Rajesh,
>
> According to the official website documents, it looks like that, which is
> bad for the programmers and the end users.
> What is your suggestion for a production environment, mysql or mssql or
> others?
> I am afraid of future potential similar traps.
>
> B.R.
> Schumann
>
> -----邮件原件-----
> 发件人: Rajesh Mallah <[hidden email]>
> 发送时间: 2018年3月29日 23:24
> 收件人: [hidden email]
> 主题: Re: 答复: A major bug in OFBiz Manufacturing MRP function
>
> > However, when MySQL stores a value into a column of any temporal data
> > type, it discards any fractional part and does not store it.Kind
> > regards,
> >
>
> I thought MySQL had by now gotten over from the childhood disease of
> discarding data silently  ;-) in many contexts it was like that even 10
> year back.
>
> regds
> mallah.
>

[marcopaul]

Postgres is pretty much standard now, especially now that Amazon AWS has support for it on Aurora.  
—P

> On Mar 29, 2018, at 14:51, Rajesh Mallah <[hidden email]> wrote:
>
> Hi Schmann ,
>
> You may consider exploring PostgreSQL.
>
> regds
> mallah.
>
> On Thu, Mar 29, 2018 at 8:58 PM, Schumann Ye <[hidden email]>
> wrote:
>
>> Hi Rajesh,
>>
>> According to the official website documents, it looks like that, which is
>> bad for the programmers and the end users.
>> What is your suggestion for a production environment, mysql or mssql or
>> others?
>> I am afraid of future potential similar traps.
>>
>> B.R.
>> Schumann
>>
>> -----邮件原件-----
>> 发件人: Rajesh Mallah <[hidden email]>
>> 发送时间: 2018年3月29日 23:24
>> 收件人: [hidden email]
>> 主题: Re: 答复: A major bug in OFBiz Manufacturing MRP function
>>
>>> However, when MySQL stores a value into a column of any temporal data
>>> type, it discards any fractional part and does not store it.Kind
>>> regards,
>>>
>>
>> I thought MySQL had by now gotten over from the childhood disease of
>> discarding data silently  ;-) in many contexts it was like that even 10
>> year back.
>>
>> regds
>> mallah.
>>

[Schumann]

Dear Rajesh and Paul,

Thanks for your comments.
Will have a check on Postgres later.

B.R.
Schumann

-----邮件原件-----
发件人: Paul Mandeltort <[hidden email]>
发送时间: 2018年3月30日 3:02
收件人: [hidden email]
主题: Re: A major bug in OFBiz Manufacturing MRP function

Postgres is pretty much standard now, especially now that Amazon AWS has support for it on Aurora.  
—P

> On Mar 29, 2018, at 14:51, Rajesh Mallah <[hidden email]> wrote:
>
> Hi Schmann ,
>
> You may consider exploring PostgreSQL.
>
> regds
> mallah.
>
> On Thu, Mar 29, 2018 at 8:58 PM, Schumann Ye
> <[hidden email]>
> wrote:
>
>> Hi Rajesh,
>>
>> According to the official website documents, it looks like that,
>> which is bad for the programmers and the end users.
>> What is your suggestion for a production environment, mysql or mssql
>> or others?
>> I am afraid of future potential similar traps.
>>
>> B.R.
>> Schumann
>>
>> -----邮件原件-----
>> 发件人: Rajesh Mallah <[hidden email]>
>> 发送时间: 2018年3月29日 23:24
>> 收件人: [hidden email]
>> 主题: Re: 答复: A major bug in OFBiz Manufacturing MRP function
>>
>>> However, when MySQL stores a value into a column of any temporal
>>> data type, it discards any fractional part and does not store
>>> it.Kind regards,
>>>
>>
>> I thought MySQL had by now gotten over from the childhood disease of
>> discarding data silently  ;-) in many contexts it was like that even
>> 10 year back.
>>
>> regds
>> mallah.
>>

[Shi Jinghai-3]

As I know, Oracle sells MySQL service to enterprises very well in China, the OFBiz-10321 may be a common problem for prove of concept test, I'd suggest don't close it until we resolve it.

@Schumann:
A question: do you use exploded view in your assembly? If yes, what's the format of the exploded view?

Kind Regards,

Shi Jinghai

-----邮件原件-----
发件人: Schumann Ye [mailto:[hidden email]]
发送时间: 2018年3月30日 8:50
收件人: [hidden email]
主题: 答复: A major bug in OFBiz Manufacturing MRP function

Dear Rajesh and Paul,

Thanks for your comments.
Will have a check on Postgres later.

B.R.
Schumann

-----邮件原件-----
发件人: Paul Mandeltort <[hidden email]>
发送时间: 2018年3月30日 3:02
收件人: [hidden email]
主题: Re: A major bug in OFBiz Manufacturing MRP function

Postgres is pretty much standard now, especially now that Amazon AWS has support for it on Aurora.  
—P

> On Mar 29, 2018, at 14:51, Rajesh Mallah <[hidden email]> wrote:
>
> Hi Schmann ,
>
> You may consider exploring PostgreSQL.
>
> regds
> mallah.
>
> On Thu, Mar 29, 2018 at 8:58 PM, Schumann Ye
> <[hidden email]>
> wrote:
>
>> Hi Rajesh,
>>
>> According to the official website documents, it looks like that,
>> which is bad for the programmers and the end users.
>> What is your suggestion for a production environment, mysql or mssql
>> or others?
>> I am afraid of future potential similar traps.
>>
>> B.R.
>> Schumann
>>
>> -----邮件原件-----
>> 发件人: Rajesh Mallah <[hidden email]>
>> 发送时间: 2018年3月29日 23:24
>> 收件人: [hidden email]
>> 主题: Re: 答复: A major bug in OFBiz Manufacturing MRP function
>>
>>> However, when MySQL stores a value into a column of any temporal
>>> data type, it discards any fractional part and does not store
>>> it.Kind regards,
>>>
>>
>> I thought MySQL had by now gotten over from the childhood disease of
>> discarding data silently  ;-) in many contexts it was like that even
>> 10 year back.
>>
>> regds
>> mallah.
>>

[Schumann]

Dear Jinghai,

I assume you're referring what Type that I use for BOM simulation (Route: Manufacturing - Bill Of Materials - Bom Simulation).

If that is the case, yes.
Actually it makes no difference for my case by using the type "Explosion" or "Explosion (only for products needing manufacturing)" because the my test Bom Type is "Manufacturing Bill of Materials".
Back to your question again, I don't understand what you mean by "format of the exploded view". It's the response ftl from server, located in "manufacturing/template/bom/BomSimulation.ftl".
So I would reply the format in html table looks ok and could be adapted as we want!

However, if you asked what would be the MRP logic related to explosion type, as per my observations on MrpServices, it seems they are not related.

HIH.

B.R.
Schumann

-----邮件原件-----
发件人: Shi Jinghai <[hidden email]>
发送时间: 2018年3月30日 9:21
收件人: [hidden email]
主题: Re: A major bug in OFBiz Manufacturing MRP function

As I know, Oracle sells MySQL service to enterprises very well in China, the OFBiz-10321 may be a common problem for prove of concept test, I'd suggest don't close it until we resolve it.

@Schumann:
A question: do you use exploded view in your assembly? If yes, what's the format of the exploded view?

Kind Regards,

Shi Jinghai

-----邮件原件-----
发件人: Schumann Ye [mailto:[hidden email]]
发送时间: 2018年3月30日 8:50
收件人: [hidden email]
主题: 答复: A major bug in OFBiz Manufacturing MRP function

Dear Rajesh and Paul,

Thanks for your comments.
Will have a check on Postgres later.

B.R.
Schumann

-----邮件原件-----
发件人: Paul Mandeltort <[hidden email]>
发送时间: 2018年3月30日 3:02
收件人: [hidden email]
主题: Re: A major bug in OFBiz Manufacturing MRP function

Postgres is pretty much standard now, especially now that Amazon AWS has support for it on Aurora.  
—P

> On Mar 29, 2018, at 14:51, Rajesh Mallah <[hidden email]> wrote:
>
> Hi Schmann ,
>
> You may consider exploring PostgreSQL.
>
> regds
> mallah.
>
> On Thu, Mar 29, 2018 at 8:58 PM, Schumann Ye
> <[hidden email]>
> wrote:
>
>> Hi Rajesh,
>>
>> According to the official website documents, it looks like that,
>> which is bad for the programmers and the end users.
>> What is your suggestion for a production environment, mysql or mssql
>> or others?
>> I am afraid of future potential similar traps.
>>
>> B.R.
>> Schumann
>>
>> -----邮件原件-----
>> 发件人: Rajesh Mallah <[hidden email]>
>> 发送时间: 2018年3月29日 23:24
>> 收件人: [hidden email]
>> 主题: Re: 答复: A major bug in OFBiz Manufacturing MRP function
>>
>>> However, when MySQL stores a value into a column of any temporal
>>> data type, it discards any fractional part and does not store
>>> it.Kind regards,
>>>
>>
>> I thought MySQL had by now gotten over from the childhood disease of
>> discarding data silently  ;-) in many contexts it was like that even
>> 10 year back.
>>
>> regds
>> mallah.
>>

[Shi Jinghai-3]

Sorry for my question is not clear enough. It's an off-topic investigation.

I want to add a new function of exploded view in OFBiz, three.js as the display engine.

I want to know if you are using PDM tool/system, what formats it can export as exploded view, whether value of torque exported in the view.



-----邮件原件-----
发件人: Schumann Ye [mailto:[hidden email]]
发送时间: 2018年3月30日 9:40
收件人: [hidden email]
主题: 答复: A major bug in OFBiz Manufacturing MRP function

Dear Jinghai,

I assume you're referring what Type that I use for BOM simulation (Route: Manufacturing - Bill Of Materials - Bom Simulation).

If that is the case, yes.
Actually it makes no difference for my case by using the type "Explosion" or "Explosion (only for products needing manufacturing)" because the my test Bom Type is "Manufacturing Bill of Materials".
Back to your question again, I don't understand what you mean by "format of the exploded view". It's the response ftl from server, located in "manufacturing/template/bom/BomSimulation.ftl".
So I would reply the format in html table looks ok and could be adapted as we want!

However, if you asked what would be the MRP logic related to explosion type, as per my observations on MrpServices, it seems they are not related.

HIH.

B.R.
Schumann

-----邮件原件-----
发件人: Shi Jinghai <[hidden email]>
发送时间: 2018年3月30日 9:21
收件人: [hidden email]
主题: Re: A major bug in OFBiz Manufacturing MRP function

As I know, Oracle sells MySQL service to enterprises very well in China, the OFBiz-10321 may be a common problem for prove of concept test, I'd suggest don't close it until we resolve it.

@Schumann:
A question: do you use exploded view in your assembly? If yes, what's the format of the exploded view?

Kind Regards,

Shi Jinghai

-----邮件原件-----
发件人: Schumann Ye [mailto:[hidden email]]
发送时间: 2018年3月30日 8:50
收件人: [hidden email]
主题: 答复: A major bug in OFBiz Manufacturing MRP function

Dear Rajesh and Paul,

Thanks for your comments.
Will have a check on Postgres later.

B.R.
Schumann

-----邮件原件-----
发件人: Paul Mandeltort <[hidden email]>
发送时间: 2018年3月30日 3:02
收件人: [hidden email]
主题: Re: A major bug in OFBiz Manufacturing MRP function

Postgres is pretty much standard now, especially now that Amazon AWS has support for it on Aurora.  
—P

> On Mar 29, 2018, at 14:51, Rajesh Mallah <[hidden email]> wrote:
>
> Hi Schmann ,
>
> You may consider exploring PostgreSQL.
>
> regds
> mallah.
>
> On Thu, Mar 29, 2018 at 8:58 PM, Schumann Ye
> <[hidden email]>
> wrote:
>
>> Hi Rajesh,
>>
>> According to the official website documents, it looks like that,
>> which is bad for the programmers and the end users.
>> What is your suggestion for a production environment, mysql or mssql
>> or others?
>> I am afraid of future potential similar traps.
>>
>> B.R.
>> Schumann
>>
>> -----邮件原件-----
>> 发件人: Rajesh Mallah <[hidden email]>
>> 发送时间: 2018年3月29日 23:24
>> 收件人: [hidden email]
>> 主题: Re: 答复: A major bug in OFBiz Manufacturing MRP function
>>
>>> However, when MySQL stores a value into a column of any temporal
>>> data type, it discards any fractional part and does not store
>>> it.Kind regards,
>>>
>>
>> I thought MySQL had by now gotten over from the childhood disease of
>> discarding data silently  ;-) in many contexts it was like that even
>> 10 year back.
>>
>> regds
>> mallah.
>>

[Schumann]

Dear Jinghai,

No, we are not using PDM system associated with OFBiz yet, though I would like to try it as well later.
So I could not answer to the question.
Certainly I would have to get back to you for your help later.

Thanks and have a nice day!
B.R.
Schumann

-----邮件原件-----
发件人: Shi Jinghai <[hidden email]>
发送时间: 2018年3月30日 11:11
收件人: [hidden email]
主题: Re: A major bug in OFBiz Manufacturing MRP function

Sorry for my question is not clear enough. It's an off-topic investigation.

I want to add a new function of exploded view in OFBiz, three.js as the display engine.

I want to know if you are using PDM tool/system, what formats it can export as exploded view, whether value of torque exported in the view.



-----邮件原件-----
发件人: Schumann Ye [mailto:[hidden email]]
发送时间: 2018年3月30日 9:40
收件人: [hidden email]
主题: 答复: A major bug in OFBiz Manufacturing MRP function

Dear Jinghai,

I assume you're referring what Type that I use for BOM simulation (Route: Manufacturing - Bill Of Materials - Bom Simulation).

If that is the case, yes.
Actually it makes no difference for my case by using the type "Explosion" or "Explosion (only for products needing manufacturing)" because the my test Bom Type is "Manufacturing Bill of Materials".
Back to your question again, I don't understand what you mean by "format of the exploded view". It's the response ftl from server, located in "manufacturing/template/bom/BomSimulation.ftl".
So I would reply the format in html table looks ok and could be adapted as we want!

However, if you asked what would be the MRP logic related to explosion type, as per my observations on MrpServices, it seems they are not related.

HIH.

B.R.
Schumann

-----邮件原件-----
发件人: Shi Jinghai <[hidden email]>
发送时间: 2018年3月30日 9:21
收件人: [hidden email]
主题: Re: A major bug in OFBiz Manufacturing MRP function

As I know, Oracle sells MySQL service to enterprises very well in China, the OFBiz-10321 may be a common problem for prove of concept test, I'd suggest don't close it until we resolve it.

@Schumann:
A question: do you use exploded view in your assembly? If yes, what's the format of the exploded view?

Kind Regards,

Shi Jinghai

-----邮件原件-----
发件人: Schumann Ye [mailto:[hidden email]]
发送时间: 2018年3月30日 8:50
收件人: [hidden email]
主题: 答复: A major bug in OFBiz Manufacturing MRP function

Dear Rajesh and Paul,

Thanks for your comments.
Will have a check on Postgres later.

B.R.
Schumann

-----邮件原件-----
发件人: Paul Mandeltort <[hidden email]>
发送时间: 2018年3月30日 3:02
收件人: [hidden email]
主题: Re: A major bug in OFBiz Manufacturing MRP function

Postgres is pretty much standard now, especially now that Amazon AWS has support for it on Aurora.  
—P

> On Mar 29, 2018, at 14:51, Rajesh Mallah <[hidden email]> wrote:
>
> Hi Schmann ,
>
> You may consider exploring PostgreSQL.
>
> regds
> mallah.
>
> On Thu, Mar 29, 2018 at 8:58 PM, Schumann Ye
> <[hidden email]>
> wrote:
>
>> Hi Rajesh,
>>
>> According to the official website documents, it looks like that,
>> which is bad for the programmers and the end users.
>> What is your suggestion for a production environment, mysql or mssql
>> or others?
>> I am afraid of future potential similar traps.
>>
>> B.R.
>> Schumann
>>
>> -----邮件原件-----
>> 发件人: Rajesh Mallah <[hidden email]>
>> 发送时间: 2018年3月29日 23:24
>> 收件人: [hidden email]
>> 主题: Re: 答复: A major bug in OFBiz Manufacturing MRP function
>>
>>> However, when MySQL stores a value into a column of any temporal
>>> data type, it discards any fractional part and does not store
>>> it.Kind regards,
>>>
>>
>> I thought MySQL had by now gotten over from the childhood disease of
>> discarding data silently  ;-) in many contexts it was like that even
>> 10 year back.
>>
>> regds
>> mallah.
>>

[Jacopo Cappellato-5]

Dear Schumann,

thanks for the feedback and for your tests; please see my comment inline:

On Thu, Mar 29, 2018 at 5:14 PM, Schumann Ye <[hidden email]>
wrote:

> [...]
> So after updating the column by "ALTER TABLE ofbiz.mrp_event change
> EVENT_DATE EVENT_DATE DATETIME(6); " and a reboot, MRP is running correctly.
>

OFBiz is configured to assign the DATETIME(3) to that field for MySQL [*];
I am wondering if 3 digits were not enough, even if it is weird because it
was not reported before. also in the error message that you have reported
the digits are not included at all so I am wondering if something went
wrong in the initialization of the database.
It would be useful if you could try to alter the table to use DATETIME(3)
instead of DATETIME(6) and test the MRP use case again. It would also be
useful to know how you setup the database; was it maybe copied from an
older version of OFBiz?

Kind regards,

Jacopo

[*]
https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/framework/entity/fieldtype/fieldtypemysql.xml

[Schumann]

Dear Jacopo,

Sorry for getting back to you late.
To share what I have done for the installation with you:
1. I followed the ReadMe to install the unzipped Ofbiz 16.11.03;
2. Then I changed the database from Derby to MySQL;
3. Everything was running ok until the other day I created the BOM level as elaborated in OFBIZ-10321.
4. I tried many times but all failed and then I decided to install a new release 16.11.04;
5. I repeated only step 2 but without using "Gradlew cleanAll loadDefault";
6. Everything seemed ok until I kept failing step 3 again;
7. So I re-run "Gradlew cleanAll loadDefault";
8. Then I wrote to you all about the issue.

Later I would give a try for DATETIME(3) and would let you know how it go.
Have a nice day!

Schumann


-----邮件原件-----
发件人: Jacopo Cappellato <[hidden email]>
发送时间: 2018年3月30日 17:16
收件人: [hidden email] ML <[hidden email]>
主题: Re: 答复: A major bug in OFBiz Manufacturing MRP function

Dear Schumann,

thanks for the feedback and for your tests; please see my comment inline:

On Thu, Mar 29, 2018 at 5:14 PM, Schumann Ye <[hidden email]>
wrote:

> [...]
> So after updating the column by "ALTER TABLE ofbiz.mrp_event change
> EVENT_DATE EVENT_DATE DATETIME(6); " and a reboot, MRP is running correctly.
>

OFBiz is configured to assign the DATETIME(3) to that field for MySQL [*]; I am wondering if 3 digits were not enough, even if it is weird because it was not reported before. also in the error message that you have reported the digits are not included at all so I am wondering if something went wrong in the initialization of the database.
It would be useful if you could try to alter the table to use DATETIME(3) instead of DATETIME(6) and test the MRP use case again. It would also be useful to know how you setup the database; was it maybe copied from an older version of OFBiz?

Kind regards,

Jacopo

[*]
https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/framework/entity/fieldtype/fieldtypemysql.xml

[Jacopo Cappellato-5]

On Sat, Mar 31, 2018 at 4:50 PM, Schumann Ye <[hidden email]>
wrote:

> [...]

 followed the ReadMe to install the unzipped Ofbiz 16.11.03;
>

Ok, I have verified and in 16.11.* releases the MySQL type set for the
date-time type is DATETIME instead of DATETIME(3):

https://svn.apache.org/repos/asf/ofbiz/branches/release16.11/framework/entity/fieldtype/fieldtypemysql.xml

Ff you edit the file framework/entity/fieldtype/fieldtypemysql.xml and set
DATETIME(3) there and then run "Gradlew cleanAll loadDefault" you should be
able to execute your workflow.

Kind regards,

Jacopo

[Schumann]

Hi Jacopo,

Thanks for your hints.
Actually I am not using SVN now, I've done quite some customizations so I would like to do it directly in the database mysql by using alter table.
Is it ok if I do it this way?
Thanks

Schumann

-----邮件原件-----
发件人: Jacopo Cappellato <[hidden email]>
发送时间: 2018年4月1日 16:22
收件人: [hidden email] ML <[hidden email]>
主题: Re: 答复: 答复: A major bug in OFBiz Manufacturing MRP function

On Sat, Mar 31, 2018 at 4:50 PM, Schumann Ye <[hidden email]>
wrote:

> [...]

 followed the ReadMe to install the unzipped Ofbiz 16.11.03;
>

Ok, I have verified and in 16.11.* releases the MySQL type set for the date-time type is DATETIME instead of DATETIME(3):

https://svn.apache.org/repos/asf/ofbiz/branches/release16.11/framework/entity/fieldtype/fieldtypemysql.xml

Ff you edit the file framework/entity/fieldtype/fieldtypemysql.xml and set
DATETIME(3) there and then run "Gradlew cleanAll loadDefault" you should be able to execute your workflow.

Kind regards,

Jacopo

[Jacopo Cappellato-5]

On Sun, Apr 1, 2018 at 10:30 AM, Schumann Ye <[hidden email]>
wrote:

> Hi Jacopo,
>
> Thanks for your hints.
> Actually I am not using SVN now, I've done quite some customizations so I
> would like to do it directly in the database mysql by using alter table.
> Is it ok if I do it this way?
>

Yes, you can directly alter the MRP_EVENT table.

Regards,

Jacopo

[Schumann]

Dear Jacopo,

Sorry for coming back to you late on the issue.
I've done changing from DATETIME(6) to DATETIME(3). Everything works perfectly without error so far.
However, in order to avoid potential duplicate entry when creating new record, my suggestion is to set it as DATETIME(6).
As the calculating capacity & efficiency increases these days, odds still remain for duplicate data entries when the CPU & RAM are powerful enough.

This is only my personal view for your reference.
HIH.

B.R.
Schumann

-----邮件原件-----
发件人: Jacopo Cappellato <[hidden email]>
发送时间: 2018年4月2日 13:59
收件人: [hidden email] ML <[hidden email]>
主题: Re: 答复: 答复: 答复: A major bug in OFBiz Manufacturing MRP function

On Sun, Apr 1, 2018 at 10:30 AM, Schumann Ye <[hidden email]>
wrote:

> Hi Jacopo,
>
> Thanks for your hints.
> Actually I am not using SVN now, I've done quite some customizations
> so I would like to do it directly in the database mysql by using alter table.
> Is it ok if I do it this way?
>

Yes, you can directly alter the MRP_EVENT table.

Regards,

Jacopo