[jira] [Assigned] (OFBIZ-7356) OFBIZ-6964: Document finalized design to support replenishment planning through any inter-company facility

2017-05-26 Thread Swapnil Shah (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Swapnil Shah reassigned OFBIZ-7356:
---

Assignee: Swapnil Shah

> OFBIZ-6964: Document finalized design to support replenishment planning 
> through any inter-company facility
> --
>
> Key: OFBIZ-7356
> URL: https://issues.apache.org/jira/browse/OFBIZ-7356
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: manufacturing, order, product
>Reporter: Swapnil Shah
>Assignee: Swapnil Shah
>
> Here are high level design notes to based on the requirement specified under 
> OFBIZ-7355 to support the product level replenishment from any inter-company 
> facility before raising the ordering from an outside vendor.
> * We could extend the MRP logic (MrpEvent,Requirenent) to honor these new 
> types and create corresponding event & requirement for Stock transfer between 
> facilities.
> * Introduce two new entities ProductFacilityAssoc & FacilityAssocType and use 
> them in conjunction with MrpEventType and corresponding RequirementType to 
> serve the requirement for replenishing the store's via Inter-facility 
> transfers mode.  The data model & UI could be extended as follows:
> {code}
> 
>  title="Define associations between Product facilities">
> 
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
>  rel-entity-name="Facility">
> 
> 
>  rel-entity-name="Facility">
> 
> 
>  rel-entity-name="FacilityAssocType">
> 
> 
> 
> 
>  title="Define associations between facilities">
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  description="Facility that serves another facility in terms of inventory"/>
> 
>  facilityIdTo="StoreWarehouse_01" facilityAssocTypeId="BACKUP_WAREHOUSE" 
> sequenceNum="01" fromDate="2001-01-01 12:00:00"/>
>  facilityIdTo="StoreWarehouse_01" facilityAssocTypeId="BACKUP_WAREHOUSE" 
> sequenceNum="02" fromDate="2001-01-01 12:00:00"/>
>  facilityIdTo="StoreWarehouse_01" facilityAssocTypeId="BACKUP_WAREHOUSE" 
> sequenceNum="03" fromDate="2001-01-01 12:00:00"/>
>  facilityIdTo="RegionalWarehouse_01" facilityAssocTypeId="BACKUP_WAREHOUSE" 
> sequenceNum="01" fromDate="2001-01-01 12:00:00"/>
>  facilityIdTo="RegionalWarehouse_02" facilityAssocTypeId="BACKUP_WAREHOUSE" 
> sequenceNum="01" fromDate="2001-01-01 12:00:00"/>
> 
> 
> 
> 
>  requirementTypeId="TRANSFER_REQUIREMENT"/>
> 
>  enumTypeId="PROD_REQ_METHOD"/>
> 
>  checkInventory="N" oneInventoryFacility="N" requireInventory="N" 
> reserveInventory="Y" reserveOrderEnumId="INVRO_FIFO_REC" /> 
> 
>  requirementMethodEnumId="XFERRQM_STOCK_ATP" fromDate="2001-04-13 12:00:00"/>
> 
>  lastInventoryCount="20.00" minimumStock="100.00" productId="GZ-8544"/>
>  lastInventoryCount="40.00" minimumStock="200.00" productId="GZ-8544"/>
>  lastInventoryCount="60.00" minimumStock="200.00" productId="GZ-8544"/>
>  lastInventoryCount="200.00" minimumStock="300.00" 
> productId="GZ-8544"/>
> {code}
> MRP engine would start creating event beginning with store's primary facility 
> based on set RMEI under ProductStoreFacility e.g, XFERRQM_STOCK_ATP for 
> StoreWarehouse_01, In other words if MinStock < ATP , then MRP algorithm 
> would: 
> # Look up and consume the respective ATP from all the eligible "facilityIdTo" 
> (based on ProductFacilityAssoc), from where given product is transferable. 
> Based on their priorities start allocating ATP unless it meet the 
> (MinStock-ATP) requirement for a given store e.g., 'StoreWarehouse_01' .
> # Create new MRP Event with Event type "PROP_ATP_STOCK_TRANSFER" with 
> Proposed Quantity = MINIMUM STOCK - ATP from the facility (with highest 
> priority i.e.,RegionalWarehouse_01) to the destination facility.
> ## If demand for (MinStock-ATP) is still not fully met by any facility with 
> higher priority then repeat step#1 for all the associated facilities in 
> descending order of priority unless ATP from all eligible facilities is 
> exhausted.
> # Based on above MRP Event Type and proposed quantity, In turn create the new 
> Requirement with type TRANSFER_REQUIREMENT between originating and 
> destination facility.
> # Over Requirement screen (UI) we can provide the "Transfer" button against 
> all the requirement with type TRANSFER_REQUIREMENT
> # On hitting the "Transfer" button, The new 'Stock Transfer' requests could 
> be created for a product between eligible facilities based on above step. 
> # The created Stock Transfer request can be completed by shipping and 
> receiving given product from originating facility and destination facility 
> respectively.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (OFBIZ-7357) OFBIZ-6964: Prepare Demo Data based on the propsed design to support replenishment planning through any inter-company facility

2017-05-26 Thread Swapnil Shah (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Swapnil Shah reassigned OFBIZ-7357:
---

Assignee: Swapnil Shah  (was: Divesh Dutta)

> OFBIZ-6964: Prepare Demo Data based on the propsed design to support 
> replenishment planning through any inter-company facility
> --
>
> Key: OFBIZ-7357
> URL: https://issues.apache.org/jira/browse/OFBIZ-7357
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: manufacturing, order, product
>Affects Versions: 15.12.01
>Reporter: Swapnil Shah
>Assignee: Swapnil Shah
> Fix For: Upcoming Release
>
>
> We can start preparing demo data for implementation and testing purpose based 
> on requirement and design details shared over OFBIZ-7355 & OFBIZ-7356



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (OFBIZ-6964) Support for replenishment of a secondary warehouse from a main warehouse

2017-05-26 Thread Swapnil Shah (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Swapnil Shah reassigned OFBIZ-6964:
---

Assignee: Swapnil Shah  (was: Divesh Dutta)

> Support for replenishment of a secondary warehouse from a main warehouse
> 
>
> Key: OFBIZ-6964
> URL: https://issues.apache.org/jira/browse/OFBIZ-6964
> Project: OFBiz
>  Issue Type: New Feature
>  Components: manufacturing, product
>Reporter: Shrenik Bhura
>Assignee: Swapnil Shah
>  Labels: features
> Fix For: Upcoming Release
>
> Attachments: screenshot-1.png
>
>
> At the onset let me define a few terms clearly as I mean it in the story 
> description below :
> Requirement - A request generated for a particular product for a specific 
> quantity that needs to be purchased from a supplier for satisfying certain 
> inventory needs of a particular facility.
> Replenishment - A request generated for a particular product for a specific 
> quantity that needs to be transferred from a "backup facility" for satisfying 
> certain inventory needs of a particular facility.
> Fulfilment - The process of reserving, picking, packing and shipping the 
> ordered quantity of product(s) as per a sales order.
> Terms 'warehouse' and 'facility' have been used interchangeably.
> *The Use Case:*
> Consider a scenario wherein there is a website and a physical retail store of 
> the same Company.
> Each having its own facility i.e. 1:1 mapping.
> {{Store A (webstore) -> associated with facility 1 (webstore facility)}}
> {{Store B (retailstore) -> associated with facility 2 (retailstore facility)}}
> However, both the stores share the same catalog/products. But both have 
> independent inventory requirement and replenishment rules for the same 
> product. 
> There is a Requirement Method Enum ID (RMEI) of each product which is 
> applicable irrespective of the store and supersedes the RMEI defined, if any, 
> on a store. 
> A product's inventory thresholds (Minimum Stock, Reorder Quantity) are 
> independently managed via the facilities tab for the product. A product has 
> its ATP and QOH levels on a per facility basis. _Do note that all these 
> inventory numbers are at a facility level and has no bearing at a store 
> level._
> Where the difficulty crops up with the current implementation is the way 
> requirements are generated. A product can have only one RMEI. When an order 
> is placed from any store, then based on the combination of a product's RMEI 
> and the store mapped facility's inventory threshold, requirements are 
> generated. This is without consideration of the inventory status (surplus or 
> otherwise) at another facility of the same Company. If a store has multiple 
> facilities associated with it then the one defined in the ProductStore entity 
> -> inventoryFacilityId field would be considered for picking the inventory 
> threshold values and thus for requirement generation. 
> Most typical real-world facility arrangements: 
>   1. Usually an organisation would have a main facility/warehouse where 
> all the purchases are received and sub-facilities which are replenished from 
> the main facility after QA, internal processes, etc. OR 
>   2. For each product there would be a primary facility where the product 
> is received from the supplier (to derive benefits of demographic convenience 
> and consumption patterns) and then replenished to other facilities on a 
> demand based pull basis.
> To drive efficiencies across an organisation they need methods to consider 
> open fulfilment needs, in process purchase orders and inventory levels across 
> multiple facilities and thereafter propose inventory transfers across them to 
> facilitate better stocking and thus order fulfilment.
> Coming back to our use case, the webstore warehouse is the main facility at 
> which incoming shipments from suppliers are received for the entire Company 
> but sales order fulfilment happens only for the webstore. The retail 
> warehouse is primarily 're-stocked' via replenishment requests raised upon 
> the webstore warehouse and thus need not issue direct purchase orders to 
> suppliers. However, if the need be, requirement generated based on the 
> product's RMEI and the retail facility's inventory thresholds can also be 
> approved, converted into Purchase order and issued.
> *Proposed Solution:*
> There doesn't seem to be an out of the box solution for this in OFBiz. This 
> could work if either we think of -
> Approach A: Setting RMEI at a ProductFacility level as well which shall 
> supersede the Product level RMEI setting OR 
> Approach B: Build in support for a solution that I have encountered in 
> Opentaps (a system built atop OFBiz) i.e. implement support for a new setting 
> 

[jira] [Issue Comment Deleted] (OFBIZ-6964) Support for replenishment of a secondary warehouse from a main warehouse

2017-05-26 Thread Swapnil Shah (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Swapnil Shah updated OFBIZ-6964:

Comment: was deleted

(was: Assigning to [~diveshdut] as he is interested in picking it up for 
implementation)

> Support for replenishment of a secondary warehouse from a main warehouse
> 
>
> Key: OFBIZ-6964
> URL: https://issues.apache.org/jira/browse/OFBIZ-6964
> Project: OFBiz
>  Issue Type: New Feature
>  Components: manufacturing, product
>Reporter: Shrenik Bhura
>Assignee: Divesh Dutta
>  Labels: features
> Fix For: Upcoming Release
>
> Attachments: screenshot-1.png
>
>
> At the onset let me define a few terms clearly as I mean it in the story 
> description below :
> Requirement - A request generated for a particular product for a specific 
> quantity that needs to be purchased from a supplier for satisfying certain 
> inventory needs of a particular facility.
> Replenishment - A request generated for a particular product for a specific 
> quantity that needs to be transferred from a "backup facility" for satisfying 
> certain inventory needs of a particular facility.
> Fulfilment - The process of reserving, picking, packing and shipping the 
> ordered quantity of product(s) as per a sales order.
> Terms 'warehouse' and 'facility' have been used interchangeably.
> *The Use Case:*
> Consider a scenario wherein there is a website and a physical retail store of 
> the same Company.
> Each having its own facility i.e. 1:1 mapping.
> {{Store A (webstore) -> associated with facility 1 (webstore facility)}}
> {{Store B (retailstore) -> associated with facility 2 (retailstore facility)}}
> However, both the stores share the same catalog/products. But both have 
> independent inventory requirement and replenishment rules for the same 
> product. 
> There is a Requirement Method Enum ID (RMEI) of each product which is 
> applicable irrespective of the store and supersedes the RMEI defined, if any, 
> on a store. 
> A product's inventory thresholds (Minimum Stock, Reorder Quantity) are 
> independently managed via the facilities tab for the product. A product has 
> its ATP and QOH levels on a per facility basis. _Do note that all these 
> inventory numbers are at a facility level and has no bearing at a store 
> level._
> Where the difficulty crops up with the current implementation is the way 
> requirements are generated. A product can have only one RMEI. When an order 
> is placed from any store, then based on the combination of a product's RMEI 
> and the store mapped facility's inventory threshold, requirements are 
> generated. This is without consideration of the inventory status (surplus or 
> otherwise) at another facility of the same Company. If a store has multiple 
> facilities associated with it then the one defined in the ProductStore entity 
> -> inventoryFacilityId field would be considered for picking the inventory 
> threshold values and thus for requirement generation. 
> Most typical real-world facility arrangements: 
>   1. Usually an organisation would have a main facility/warehouse where 
> all the purchases are received and sub-facilities which are replenished from 
> the main facility after QA, internal processes, etc. OR 
>   2. For each product there would be a primary facility where the product 
> is received from the supplier (to derive benefits of demographic convenience 
> and consumption patterns) and then replenished to other facilities on a 
> demand based pull basis.
> To drive efficiencies across an organisation they need methods to consider 
> open fulfilment needs, in process purchase orders and inventory levels across 
> multiple facilities and thereafter propose inventory transfers across them to 
> facilitate better stocking and thus order fulfilment.
> Coming back to our use case, the webstore warehouse is the main facility at 
> which incoming shipments from suppliers are received for the entire Company 
> but sales order fulfilment happens only for the webstore. The retail 
> warehouse is primarily 're-stocked' via replenishment requests raised upon 
> the webstore warehouse and thus need not issue direct purchase orders to 
> suppliers. However, if the need be, requirement generated based on the 
> product's RMEI and the retail facility's inventory thresholds can also be 
> approved, converted into Purchase order and issued.
> *Proposed Solution:*
> There doesn't seem to be an out of the box solution for this in OFBiz. This 
> could work if either we think of -
> Approach A: Setting RMEI at a ProductFacility level as well which shall 
> supersede the Product level RMEI setting OR 
> Approach B: Build in support for a solution that I have encountered in 
> Opentaps (a system 

[jira] [Updated] (OFBIZ-9381) Convert RateServices.xml mini-lang to groovyDSL

2017-05-26 Thread Nicolas Malin (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Malin updated OFBIZ-9381:
-
Attachment: OFBIZ-9381.patch

> Convert RateServices.xml mini-lang to groovyDSL
> ---
>
> Key: OFBIZ-9381
> URL: https://issues.apache.org/jira/browse/OFBIZ-9381
> Project: OFBiz
>  Issue Type: Task
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>Priority: Minor
>  Labels: groovy, mini-lang
> Attachments: OFBIZ-9381.patch, OFBIZ-9381.patch
>
>
> With the purpose to deprecate mini-lang OFBIZ-9350, I tried to convert some 
> mini-lang service to groovy script.
> I converted updateRateAmount, deleteRateAmount, updatePartyRate and 
> deleteRateAmount.
> Delete isn't a good definition for the service who expire the element instead 
> of remove if. So I propose with the patch to move the deleteRateAmount and 
> deletePartyRate to expireRateAmount and expirePartyRate.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (OFBIZ-9381) Convert RateServices.xml mini-lang to groovyDSL

2017-05-26 Thread Nicolas Malin (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Malin updated OFBIZ-9381:
-
Attachment: OFBIZ-9381.patch

I load a first patch version. I will continue to add some unit tests

> Convert RateServices.xml mini-lang to groovyDSL
> ---
>
> Key: OFBIZ-9381
> URL: https://issues.apache.org/jira/browse/OFBIZ-9381
> Project: OFBiz
>  Issue Type: Task
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>Priority: Minor
>  Labels: groovy, mini-lang
> Attachments: OFBIZ-9381.patch
>
>
> With the purpose to deprecate mini-lang OFBIZ-9350, I tried to convert some 
> mini-lang service to groovy script.
> I converted updateRateAmount, deleteRateAmount, updatePartyRate and 
> deleteRateAmount.
> Delete isn't a good definition for the service who expire the element instead 
> of remove if. So I propose with the patch to move the deleteRateAmount and 
> deletePartyRate to expireRateAmount and expirePartyRate.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (OFBIZ-9381) Convert RateServices.xml mini-lang to groovyDSL

2017-05-26 Thread Nicolas Malin (JIRA)
Nicolas Malin created OFBIZ-9381:


 Summary: Convert RateServices.xml mini-lang to groovyDSL
 Key: OFBIZ-9381
 URL: https://issues.apache.org/jira/browse/OFBIZ-9381
 Project: OFBiz
  Issue Type: Task
  Components: accounting
Affects Versions: Trunk
Reporter: Nicolas Malin
Assignee: Nicolas Malin
Priority: Minor


With the purpose to deprecate mini-lang OFBIZ-9350, I tried to convert some 
mini-lang service to groovy script.

I converted updateRateAmount, deleteRateAmount, updatePartyRate and 
deleteRateAmount.

Delete isn't a good definition for the service who expire the element instead 
of remove if. So I propose with the patch to move the deleteRateAmount and 
deletePartyRate to expireRateAmount and expirePartyRate.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (OFBIZ-9380) renderDateTimeField works in IE, not working with lastest Chrome

2017-05-26 Thread Deepak Dixit (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Deepak Dixit resolved OFBIZ-9380.
-
Resolution: Pending Closed

> renderDateTimeField works in IE, not working with lastest Chrome
> 
>
> Key: OFBIZ-9380
> URL: https://issues.apache.org/jira/browse/OFBIZ-9380
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release Branch 14.12
>Reporter: Chuck Kosta
>Assignee: Deepak Dixit
> Fix For: 16.11.03, Release Branch 15.12, Release Branch 14.12
>
>
>  {code}
>  <@htmlTemplate.renderDateTimeField ... />
> {code}
> Works correctly in IE; but in firefox and chrome, it ignores the values when 
> sent to an entity updating service call. The page gets refreshed with the 
> original date.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (OFBIZ-9380) renderDateTimeField works in IE, not working with lastest Chrome

2017-05-26 Thread Deepak Dixit (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Deepak Dixit updated OFBIZ-9380:

Fix Version/s: Release Branch 14.12
   Release Branch 15.12
   16.11.03

> renderDateTimeField works in IE, not working with lastest Chrome
> 
>
> Key: OFBIZ-9380
> URL: https://issues.apache.org/jira/browse/OFBIZ-9380
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release Branch 14.12
>Reporter: Chuck Kosta
>Assignee: Deepak Dixit
> Fix For: Release Branch 14.12, Release Branch 15.12, 16.11.03
>
>
>  {code}
>  <@htmlTemplate.renderDateTimeField ... />
> {code}
> Works correctly in IE; but in firefox and chrome, it ignores the values when 
> sent to an entity updating service call. The page gets refreshed with the 
> original date.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (OFBIZ-9380) renderDateTimeField works in IE, not working with lastest Chrome

2017-05-26 Thread Deepak Dixit (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Deepak Dixit reassigned OFBIZ-9380:
---

Assignee: Deepak Dixit

> renderDateTimeField works in IE, not working with lastest Chrome
> 
>
> Key: OFBIZ-9380
> URL: https://issues.apache.org/jira/browse/OFBIZ-9380
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release Branch 14.12
>Reporter: Chuck Kosta
>Assignee: Deepak Dixit
> Fix For: Release Branch 14.12, Release Branch 15.12, 16.11.03
>
>
>  {code}
>  <@htmlTemplate.renderDateTimeField ... />
> {code}
> Works correctly in IE; but in firefox and chrome, it ignores the values when 
> sent to an entity updating service call. The page gets refreshed with the 
> original date.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (OFBIZ-9380) renderDateTimeField works in IE, not working with lastest Chrome

2017-05-26 Thread Deepak Dixit (JIRA)

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

Deepak Dixit commented on OFBIZ-9380:
-

Improved code and made formName field optional for renderDateTime macro. 
This has been committed at
Trunk at r#1796262
16.11 at r#1796263
15.12 at r#1796264
14.12 at r#1796265

Thanks Chuck Kosta for reporting the issue. 

> renderDateTimeField works in IE, not working with lastest Chrome
> 
>
> Key: OFBIZ-9380
> URL: https://issues.apache.org/jira/browse/OFBIZ-9380
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release Branch 14.12
>Reporter: Chuck Kosta
>
>  {code}
>  <@htmlTemplate.renderDateTimeField ... />
> {code}
> Works correctly in IE; but in firefox and chrome, it ignores the values when 
> sent to an entity updating service call. The page gets refreshed with the 
> original date.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (OFBIZ-9380) renderDateTimeField works in IE, not working with lastest Chrome

2017-05-26 Thread Deepak Dixit (JIRA)

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

Deepak Dixit edited comment on OFBIZ-9380 at 5/26/17 8:53 AM:
--

Thanks [~chuck_kosta] for details, 
Html5 form attribute works with id, if you want to use form attribute then you 
need to pass an form id.
IE does not support form attribute that why case mentioned by you working in IE 
only.
http://caniuse.com/#feat=form-attribute

HTML5 introduced a new form attribute that allows you to associate any orphaned 
form control with any  element on the page
In your case you don;t need to pass formName in renderDateTime macro as you are 
defining the field inside form.

I think we can make this formName field as optional parameter as this is not 
required in all cases.





was (Author: deepak.dixit):
Thanks [~chuck_kosta] for details, 
Html5 form tag work with id, if you want to use form attribute then you need to 
pass an form id in this. 
IE does not support form attribute that why case mentioned by you working in IE 
only.
http://caniuse.com/#feat=form-attribute

HTML5 introduced a new form attribute that allows you to associate any orphaned 
form control with any  element on the page
In your case you don;t need to pass formName in renderDateTime macro as you are 
defining the field inside form.

I think we can make this formName field as optional parameter as this is not 
required in all cases.




> renderDateTimeField works in IE, not working with lastest Chrome
> 
>
> Key: OFBIZ-9380
> URL: https://issues.apache.org/jira/browse/OFBIZ-9380
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release Branch 14.12
>Reporter: Chuck Kosta
>
>  {code}
>  <@htmlTemplate.renderDateTimeField ... />
> {code}
> Works correctly in IE; but in firefox and chrome, it ignores the values when 
> sent to an entity updating service call. The page gets refreshed with the 
> original date.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (OFBIZ-9380) renderDateTimeField works in IE, not working with lastest Chrome

2017-05-26 Thread Deepak Dixit (JIRA)

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

Deepak Dixit commented on OFBIZ-9380:
-

Thanks [~chuck_kosta] for details, 
Html5 form tag work with id, if you want to use form attribute then you need to 
pass an form id in this. 
IE does not support form attribute that why case mentioned by you working in IE 
only.
http://caniuse.com/#feat=form-attribute

HTML5 introduced a new form attribute that allows you to associate any orphaned 
form control with any  element on the page
In your case you don;t need to pass formName in renderDateTime macro as you are 
defining the field inside form.

I think we can make this formName field as optional parameter as this is not 
required in all cases.




> renderDateTimeField works in IE, not working with lastest Chrome
> 
>
> Key: OFBIZ-9380
> URL: https://issues.apache.org/jira/browse/OFBIZ-9380
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release Branch 14.12
>Reporter: Chuck Kosta
>
>  {code}
>  <@htmlTemplate.renderDateTimeField ... />
> {code}
> Works correctly in IE; but in firefox and chrome, it ignores the values when 
> sent to an entity updating service call. The page gets refreshed with the 
> original date.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)