[jira] [Closed] (OFBIZ-6899) Overview of payment methods in party profile misses function to set company check payment
[ https://issues.apache.org/jira/browse/OFBIZ-6899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-6899. --- > Overview of payment methods in party profile misses function to set company > check payment > - > > Key: OFBIZ-6899 > URL: https://issues.apache.org/jira/browse/OFBIZ-6899 > Project: OFBiz > Issue Type: New Feature > Components: accounting, order, party, specialpurpose/ecommerce >Affects Versions: Trunk >Reporter: Pierre Smits >Assignee: Swapnil Shah > Labels: check, payment > Fix For: Upcoming Branch > > Attachments: CC_1.png, CC_2.png, CC_3.png, CC_4.png, > OFBIZ-6899.patch, OFBIZ-6899.patch, OFBIZ-6899.patch > > > The payment methods overview in the party profile shows various options to > define and create a payment method. > However there is no option to create payment method for a company check -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6899) Overview of payment methods in party profile misses function to set company check payment
[ https://issues.apache.org/jira/browse/OFBIZ-6899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15460582#comment-15460582 ] Swapnil Shah commented on OFBIZ-6899: - Thanks [~Jagpreet Kaur] [~diveshdut] for the contribution. I have validated the fixes and seems to be working as expected via following testing: # Add a 'Company Check Account' via Party profile screen # Able to fill all the required details and have the Check account successfully created in system # From profile screen also successfully expired the added Check account successfully I am closing this ticket and waiting to see the upcoming features for Updating the check account and using the same during order entry process. > Overview of payment methods in party profile misses function to set company > check payment > - > > Key: OFBIZ-6899 > URL: https://issues.apache.org/jira/browse/OFBIZ-6899 > Project: OFBiz > Issue Type: New Feature > Components: accounting, order, party, specialpurpose/ecommerce >Affects Versions: Trunk >Reporter: Pierre Smits >Assignee: Swapnil Shah > Labels: check, payment > Fix For: Upcoming Branch > > Attachments: CC_1.png, CC_2.png, CC_3.png, CC_4.png, > OFBIZ-6899.patch, OFBIZ-6899.patch, OFBIZ-6899.patch > > > The payment methods overview in the party profile shows various options to > define and create a payment method. > However there is no option to create payment method for a company check -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7533) Not able to set new Lot Id to existing inventory item
[ https://issues.apache.org/jira/browse/OFBIZ-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7533. --- > Not able to set new Lot Id to existing inventory item > - > > Key: OFBIZ-7533 > URL: https://issues.apache.org/jira/browse/OFBIZ-7533 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Upcoming Branch >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Fix For: Upcoming Branch > > Attachments: II_LOT.png, OFBIZ-7533.patch > > > When any new lot is assigned to exiting inventory item then it ends up > throwing foreign key constraint. > We could allow it by creating first new lot (if its not found already > existent in DB) and then associate the same with given inventory item. (Also > currently i couldn't find any screen to create new lot in given facility) > Please refer to attached screenshot for reference. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7533) Not able to set new Lot Id to existing inventory item
[ https://issues.apache.org/jira/browse/OFBIZ-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466872#comment-15466872 ] Swapnil Shah commented on OFBIZ-7533: - Thanks [~ankush.upadhyay] [~diveshdut] for contribution. I validated the fixes as follows and found to be working better now: # Updated the lotId (using non-existent lot) on existing inventoryItem without any error/stack-trace (*PASS*) # Checked that a new Lot is created in DB (*PASS*) Though i expect that in future we might need to overhaul the existing lot management process (as per OFBIZ-5704) but i reckon many existing users are still using the current version of this feature and the fixes here could be helpful, Closing this ticket for now. > Not able to set new Lot Id to existing inventory item > - > > Key: OFBIZ-7533 > URL: https://issues.apache.org/jira/browse/OFBIZ-7533 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Upcoming Branch >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Fix For: Upcoming Branch > > Attachments: II_LOT.png, OFBIZ-7533.patch > > > When any new lot is assigned to exiting inventory item then it ends up > throwing foreign key constraint. > We could allow it by creating first new lot (if its not found already > existent in DB) and then associate the same with given inventory item. (Also > currently i couldn't find any screen to create new lot in given facility) > Please refer to attached screenshot for reference. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-7389) Allow user to select multiple options in "Purchases by Organization" report from basic search criterias while generating report
[ https://issues.apache.org/jira/browse/OFBIZ-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reassigned OFBIZ-7389: --- Assignee: Mohammad Kathawala (was: Swapnil Shah) > Allow user to select multiple options in "Purchases by Organization" report > from basic search criterias while generating report > --- > > Key: OFBIZ-7389 > URL: https://issues.apache.org/jira/browse/OFBIZ-7389 > Project: OFBiz > Issue Type: Improvement > Components: order >Reporter: Swapnil Shah >Assignee: Mohammad Kathawala > Fix For: Upcoming Branch > > Attachments: OFBIZ-7389.patch, PurchasebyOrg.png > > > Currently system allow user to select any specific search criteria link and > hence 'Purchases by Organization' report is generated only based on any one > given selected criteria. > We can add the feature for generating single report based on multiple values > (possibly via checkbox?) within basic search criteria in this report namely: > 1) To Party > 2) Order Status -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (OFBIZ-7389) Allow user to select multiple options in "Purchases by Organization" report from basic search criterias while generating report
[ https://issues.apache.org/jira/browse/OFBIZ-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reopened OFBIZ-7389: - > Allow user to select multiple options in "Purchases by Organization" report > from basic search criterias while generating report > --- > > Key: OFBIZ-7389 > URL: https://issues.apache.org/jira/browse/OFBIZ-7389 > Project: OFBiz > Issue Type: Improvement > Components: order >Reporter: Swapnil Shah >Assignee: Mohammad Kathawala > Fix For: Upcoming Branch > > Attachments: OFBIZ-7389.patch, PurchasebyOrg.png > > > Currently system allow user to select any specific search criteria link and > hence 'Purchases by Organization' report is generated only based on any one > given selected criteria. > We can add the feature for generating single report based on multiple values > (possibly via checkbox?) within basic search criteria in this report namely: > 1) To Party > 2) Order Status -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7389) Allow user to select multiple options in "Purchases by Organization" report from basic search criterias while generating report
[
https://issues.apache.org/jira/browse/OFBIZ-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467232#comment-15467232
]
Swapnil Shah commented on OFBIZ-7389:
-
[~Mohammad K] I have tested the fixes and currently search on available
criteria is showing following error:
{code}
The Following Errors Occurred:
Unable to transform FO file: org.apache.fop.apps.FOPException:
org.xml.sax.SAXParseException; lineNumber: 27; columnNumber: 177; The content
of elements must consist of well-formed character data or markup.
javax.xml.transform.TransformerException: org.xml.sax.SAXParseException;
lineNumber: 27; columnNumber: 177; The content of elements must consist of
well-formed character data or markup.
{code}
> Allow user to select multiple options in "Purchases by Organization" report
> from basic search criterias while generating report
> ---
>
> Key: OFBIZ-7389
> URL: https://issues.apache.org/jira/browse/OFBIZ-7389
> Project: OFBiz
> Issue Type: Improvement
> Components: order
>Reporter: Swapnil Shah
>Assignee: Swapnil Shah
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7389.patch, PurchasebyOrg.png
>
>
> Currently system allow user to select any specific search criteria link and
> hence 'Purchases by Organization' report is generated only based on any one
> given selected criteria.
> We can add the feature for generating single report based on multiple values
> (possibly via checkbox?) within basic search criteria in this report namely:
> 1) To Party
> 2) Order Status
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OFBIZ-7440) Donation amount over Sales Order is getting invoiced pro-rated based on shipped qty
[ https://issues.apache.org/jira/browse/OFBIZ-7440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7440. --- > Donation amount over Sales Order is getting invoiced pro-rated based on > shipped qty > --- > > Key: OFBIZ-7440 > URL: https://issues.apache.org/jira/browse/OFBIZ-7440 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: D1.png, D2.png, D3.png, OFBIZ-7440.patch > > > Many a times business provide the option for customer to donate any amount > towards any specific purpose (like Welfare/Charity etc.) and such amount get > invoiced along upon sales shipment > As per current systemic behavior its seen that donation amount gets pro-rated > based on shipped qty (in case of partial shipments). We could try to capture > donation in very first shipment for the sales order. > Please refer the attached screenshot for more details -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7440) Donation amount over Sales Order is getting invoiced pro-rated based on shipped qty
[ https://issues.apache.org/jira/browse/OFBIZ-7440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466977#comment-15466977 ] Swapnil Shah commented on OFBIZ-7440: - Thanks [~ankush.upadhyay] [~diveshdut] for the contribution, I have validated the fixes as follows and it seems to be working as expected now: # Partially shipped an order with donation adjustment and validated that corresponding Invoice Item for Donation is corrected created with full donation amount (*PASS*) # Shipped the remaining quantity of order and validated the corresponding invoice items don't have any entry for donations as all is already accounted for in very first invoice against first shipment (*PASS*) Based on above test results closing the issue now. > Donation amount over Sales Order is getting invoiced pro-rated based on > shipped qty > --- > > Key: OFBIZ-7440 > URL: https://issues.apache.org/jira/browse/OFBIZ-7440 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: D1.png, D2.png, D3.png, OFBIZ-7440.patch > > > Many a times business provide the option for customer to donate any amount > towards any specific purpose (like Welfare/Charity etc.) and such amount get > invoiced along upon sales shipment > As per current systemic behavior its seen that donation amount gets pro-rated > based on shipped qty (in case of partial shipments). We could try to capture > donation in very first shipment for the sales order. > Please refer the attached screenshot for more details -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7403) Allow user to select multiple options in "Purchases by Payment Method" report from basic search criterias while generating report
[ https://issues.apache.org/jira/browse/OFBIZ-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467013#comment-15467013 ] Swapnil Shah commented on OFBIZ-7403: - Thanks [~Mohammad K] for contribution. I have validated the fixes and found following issues: # Upon searching on 'Purchase Order' type, the report is keeps fetching all the data from Sales Order only # Upon selecting 'Any' StatusId, we can possibly auto-select all the respective statuses via checkbox or can show this option as well in multi-select drop down fashion a la Product Store Id/Origin Facility Id Assigning back to you for fixing them further. > Allow user to select multiple options in "Purchases by Payment Method" report > from basic search criterias while generating report > - > > Key: OFBIZ-7403 > URL: https://issues.apache.org/jira/browse/OFBIZ-7403 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Trunk, 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: Purchase_by_Payment_Method.png > > > Currently system allow user to select any specific search criteria link and > hence 'Purchases by Payment Method' report is generated only based on any one > given selected criteria. > We can add the feature for generating single report based on multiple values > (possibly via checkbox?) within basic search criteria in this report namely: > 1) Product Store > 2) Origin Facility > 3) Status > 4) Let's convert Order type into radio button so it only work either for > Sales Order or for PO at one time/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-7403) Allow user to select multiple options in "Purchases by Payment Method" report from basic search criterias while generating report
[ https://issues.apache.org/jira/browse/OFBIZ-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reassigned OFBIZ-7403: --- Assignee: Mohammad Kathawala (was: Swapnil Shah) > Allow user to select multiple options in "Purchases by Payment Method" report > from basic search criterias while generating report > - > > Key: OFBIZ-7403 > URL: https://issues.apache.org/jira/browse/OFBIZ-7403 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Trunk, 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Mohammad Kathawala > Attachments: Purchase_by_Payment_Method.png > > > Currently system allow user to select any specific search criteria link and > hence 'Purchases by Payment Method' report is generated only based on any one > given selected criteria. > We can add the feature for generating single report based on multiple values > (possibly via checkbox?) within basic search criteria in this report namely: > 1) Product Store > 2) Origin Facility > 3) Status > 4) Let's convert Order type into radio button so it only work either for > Sales Order or for PO at one time/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (OFBIZ-7403) Allow user to select multiple options in "Purchases by Payment Method" report from basic search criterias while generating report
[ https://issues.apache.org/jira/browse/OFBIZ-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reopened OFBIZ-7403: - > Allow user to select multiple options in "Purchases by Payment Method" report > from basic search criterias while generating report > - > > Key: OFBIZ-7403 > URL: https://issues.apache.org/jira/browse/OFBIZ-7403 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Trunk, 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Mohammad Kathawala > Attachments: Purchase_by_Payment_Method.png > > > Currently system allow user to select any specific search criteria link and > hence 'Purchases by Payment Method' report is generated only based on any one > given selected criteria. > We can add the feature for generating single report based on multiple values > (possibly via checkbox?) within basic search criteria in this report namely: > 1) Product Store > 2) Origin Facility > 3) Status > 4) Let's convert Order type into radio button so it only work either for > Sales Order or for PO at one time/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-7394) Allow user to select multiple options in "Purchases by Product" report from basic search criterias while generating report
[ https://issues.apache.org/jira/browse/OFBIZ-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467022#comment-15467022 ] Swapnil Shah edited comment on OFBIZ-7394 at 9/6/16 10:01 AM: -- Thanks [~Mohammad K] [~diveshdut] for contribution. I have tried to validate the fixes and UI changes and reported data seems to be working in line with expectations. Closing the issue now. was (Author: swash78): Thanks [~Mohammad K] [~diveshdut] for contribution. I have tried to validate the fixes and UI changes and reported data seems to be working in line with expectations. Closing the issue for now. > Allow user to select multiple options in "Purchases by Product" report from > basic search criterias while generating report > -- > > Key: OFBIZ-7394 > URL: https://issues.apache.org/jira/browse/OFBIZ-7394 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Trunk, 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Fix For: Upcoming Branch > > Attachments: OFBIZ-7394+OFBIZ-7403.patch, > OFBIZ-7394+OFBIZ-7403.patch, PurchasebyProduct.png > > > Currently system allow user to select any specific search criteria link and > hence 'Purchases by Product' report is generated only based on any one given > selected criteria. > We can add the feature for generating single report based on multiple values > (possibly via checkbox?) within basic search criteria in this report namely: > 1) Product Store > 2) Origin Facility > 3) Let's remove Order type and make it only work for Purchase Order type as > for Sales we already have similar report called "Sales by Store" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7394) Allow user to select multiple options in "Purchases by Product" report from basic search criterias while generating report
[ https://issues.apache.org/jira/browse/OFBIZ-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467022#comment-15467022 ] Swapnil Shah commented on OFBIZ-7394: - Thanks [~Mohammad K] [~diveshdut] for contribution. I have tried to validate the fixes and UI changes and reported data seems to be working in line with expectations. Closing the issue for now. > Allow user to select multiple options in "Purchases by Product" report from > basic search criterias while generating report > -- > > Key: OFBIZ-7394 > URL: https://issues.apache.org/jira/browse/OFBIZ-7394 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Trunk, 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Fix For: Upcoming Branch > > Attachments: OFBIZ-7394+OFBIZ-7403.patch, > OFBIZ-7394+OFBIZ-7403.patch, PurchasebyProduct.png > > > Currently system allow user to select any specific search criteria link and > hence 'Purchases by Product' report is generated only based on any one given > selected criteria. > We can add the feature for generating single report based on multiple values > (possibly via checkbox?) within basic search criteria in this report namely: > 1) Product Store > 2) Origin Facility > 3) Let's remove Order type and make it only work for Purchase Order type as > for Sales we already have similar report called "Sales by Store" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7475) Provide the option to update Payment Method details for Check from party profile
[ https://issues.apache.org/jira/browse/OFBIZ-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15463992#comment-15463992 ] Swapnil Shah commented on OFBIZ-7475: - Thanks [~Jagpreet Kaur] [~diveshdut] for the contribution. I have validated the fixes as follows and seems to be working as expected: # Updated an existing Check account details and found the existing corresponding PaymentMethod expired (*PASS*) # New CheckAccount & PaymentMethod records got created with revised details (*PASS*) # Only active and revised CheckAccount is appearing on Party Profile (*PASS*) Based on above results i am closing this ticket now. > Provide the option to update Payment Method details for Check from party > profile > > > Key: OFBIZ-7475 > URL: https://issues.apache.org/jira/browse/OFBIZ-7475 > Project: OFBiz > Issue Type: Improvement > Components: party >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: CC.png, OFBIZ-7475.patch > > > Let's provide the option to update Checking payment method as well like other > payment methods via party profile. (please refer attached screenshot) > We could update following information: > # Bank Name > # From/Thru date -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7475) Provide the option to update Payment Method details for Check from party profile
[ https://issues.apache.org/jira/browse/OFBIZ-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7475. --- > Provide the option to update Payment Method details for Check from party > profile > > > Key: OFBIZ-7475 > URL: https://issues.apache.org/jira/browse/OFBIZ-7475 > Project: OFBiz > Issue Type: Improvement > Components: party >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: CC.png, OFBIZ-7475.patch > > > Let's provide the option to update Checking payment method as well like other > payment methods via party profile. (please refer attached screenshot) > We could update following information: > # Bank Name > # From/Thru date -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7548) OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for 'WorkEffort' component
[ https://issues.apache.org/jira/browse/OFBIZ-7548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7548. --- Tested the fixes and found them working fine. > OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for > 'WorkEffort' component > > > Key: OFBIZ-7548 > URL: https://issues.apache.org/jira/browse/OFBIZ-7548 > Project: OFBiz > Issue Type: Sub-task > Components: workeffort >Affects Versions: Trunk >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7548.patch > > > Please refer to details shared over OFBIZ-7542 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7386) Allow user to select multiple options in "Open Order Items" report from basic search criterias while generating report
[ https://issues.apache.org/jira/browse/OFBIZ-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7386. --- Tested the fixes and found them working fine. > Allow user to select multiple options in "Open Order Items" report from basic > search criterias while generating report > -- > > Key: OFBIZ-7386 > URL: https://issues.apache.org/jira/browse/OFBIZ-7386 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Upcoming Branch >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7386.patch, OrderItemReport.png > > > Currently system allow user to select any specific search criteria link and > hence 'Open Order Items' report is generated only based on any one given > selected criteria. > We can add the feature for generating single report based on multiple values > (possibly via checkbox?) within basic search criteria in this report namely: > 1) Product Store > 2) Order Type (could make it either or selection i.e. either SO or PO with > help of radio button) > 2) Order Status (Here just allow to list only "Created"/"Approved"/"Hold" > order (as systemically only these status should have open item) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7547) OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for 'Content' component
[ https://issues.apache.org/jira/browse/OFBIZ-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7547. --- Tested the fixes and found them working fine. > OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for > 'Content' component > - > > Key: OFBIZ-7547 > URL: https://issues.apache.org/jira/browse/OFBIZ-7547 > Project: OFBiz > Issue Type: Sub-task > Components: content >Affects Versions: Trunk >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7547.patch > > > Please refer to details shared over OFBIZ-7542 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7546) OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for 'Accounting' component
[ https://issues.apache.org/jira/browse/OFBIZ-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7546. --- Tested the fixes and found them working fine. > OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for > 'Accounting' component > > > Key: OFBIZ-7546 > URL: https://issues.apache.org/jira/browse/OFBIZ-7546 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7546.patch > > > Please refer to details shared over OFBIZ-7542 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7550) OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for 'Project' component
[ https://issues.apache.org/jira/browse/OFBIZ-7550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7550. --- Tested the fixes and found them working fine. > OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for > 'Project' component > - > > Key: OFBIZ-7550 > URL: https://issues.apache.org/jira/browse/OFBIZ-7550 > Project: OFBiz > Issue Type: Sub-task > Components: specialpurpose/projectmgr >Affects Versions: Trunk >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7550.patch > > > Please refer to details shared over OFBIZ-7542 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7650) OFBIZ-7649: Display From date with default now() on all screens under Catalog Application
[ https://issues.apache.org/jira/browse/OFBIZ-7650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7650. --- Tested and found them working as expected > OFBIZ-7649: Display From date with default now() on all screens under Catalog > Application > - > > Key: OFBIZ-7650 > URL: https://issues.apache.org/jira/browse/OFBIZ-7650 > Project: OFBiz > Issue Type: Sub-task > Components: product >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah >Priority: Minor > Attachments: OFBIZ-7650.patch > > > To begin with can start fixing it under : > # "Add Product Price" form on > https://ofbiz-vm.apache.org:18443/catalog/control/EditProductPrices?productId=SV-1000 > # "Add Product Category" form on > https://ofbiz-vm.apache.org:18443/catalog/control/EditProductCategories?productId=SV-1000 > # "Add Product Cost Component Calc" form on > https://ofbiz-vm.apache.org:18443/catalog/control/EditProductCosts?productId=SV-1000 > # "Add Content to Product" form on > https://ofbiz-vm.apache.org:18443/catalog/control/EditProductContent?productId=GZ-1000 > Let's keep on adding other screens where it could be fixed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7545) OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for 'Facility' component
[ https://issues.apache.org/jira/browse/OFBIZ-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7545. --- Tested the fixes and found them working fine > OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for > 'Facility' component > -- > > Key: OFBIZ-7545 > URL: https://issues.apache.org/jira/browse/OFBIZ-7545 > Project: OFBiz > Issue Type: Sub-task > Components: product >Affects Versions: Trunk >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7545.patch > > > Please refer to details shared over OFBIZ-7542 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7544) OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for 'Manufacturing' component
[ https://issues.apache.org/jira/browse/OFBIZ-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7544. --- Tested the fixes and found them working fine. > OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for > 'Manufacturing' component > --- > > Key: OFBIZ-7544 > URL: https://issues.apache.org/jira/browse/OFBIZ-7544 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7544.patch > > > Please refer to details shared over OFBIZ-7542 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7549) OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for 'HR' component
[ https://issues.apache.org/jira/browse/OFBIZ-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7549. --- Tested the fixes and found them working fine. > OFBIZ-7542: Convert search criteria on 'Status' into multi-select pattern for > 'HR' component > > > Key: OFBIZ-7549 > URL: https://issues.apache.org/jira/browse/OFBIZ-7549 > Project: OFBiz > Issue Type: Sub-task > Components: humanres >Affects Versions: Trunk >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7549.patch > > > Please refer to details shared over OFBIZ-7542 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-8028) OFBIZ-7649: Display From date with default now() on all screens under Accounting Application
[ https://issues.apache.org/jira/browse/OFBIZ-8028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-8028. --- Validated the fixes and found them working as expected > OFBIZ-7649: Display From date with default now() on all screens under > Accounting Application > > > Key: OFBIZ-8028 > URL: https://issues.apache.org/jira/browse/OFBIZ-8028 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Ratnesh Upadhyay >Assignee: Swapnil Shah > Attachments: OFBIZ-8028.patch > > > Display From date with default now() on all screens under Accounting > Application. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7665) OFBIZ-7649: Display From date with default now() on all screens under Content Application
[ https://issues.apache.org/jira/browse/OFBIZ-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7665. --- Validated the fixes and found them working as expected > OFBIZ-7649: Display From date with default now() on all screens under Content > Application > - > > Key: OFBIZ-7665 > URL: https://issues.apache.org/jira/browse/OFBIZ-7665 > Project: OFBiz > Issue Type: Sub-task > Components: content >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7665.patch > > > To begin with can start fixing it under > # > https://ofbiz-vm.apache.org:8443/content/control/ListWebSiteContent?webSiteId=WebStore > # https://ofbiz-vm.apache.org:8443/content/control/createWebSiteContactList > # > https://ofbiz-vm.apache.org:8443/content/control/findForums?forumGroupId=WebStoreFORUM > # > https://ofbiz-vm.apache.org:8443/content/control/forumGroupRoles?forumGroupId=WebStoreFORUM > # > https://ofbiz-vm.apache.org:8443/content/control/EditContentRole?contentId=BLOGROOTBIGAL > # > https://ofbiz-vm.apache.org:8443/content/control/EditContentAssoc?contentId=BLOGROOTBIGAL > # > https://ofbiz-vm.apache.org:8443/content/control/EditContentWorkEfforts?contentId=BLOGROOTBIGAL > # > https://ofbiz-vm.apache.org:8443/content/control/EditDataResourceRole?dataResourceId=STDWRAP001 > # https://ofbiz-vm.apache.org:8443/content/control/EditAddContenta -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7666) OFBIZ-7649: Display From date with default now() on all screens under Project Application
[ https://issues.apache.org/jira/browse/OFBIZ-7666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7666. --- Validated the fixes and found them working as expected > OFBIZ-7649: Display From date with default now() on all screens under Project > Application > - > > Key: OFBIZ-7666 > URL: https://issues.apache.org/jira/browse/OFBIZ-7666 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7666.patch > > > To begin with can start fixing it under > # > https://ofbiz-vm.apache.org:8443/projectmgr/control/ListWorkEffortPartyAssigns?projectId=9000 > # > https://ofbiz-vm.apache.org:8443/projectmgr/control/EditTaskPartyAssigns?workEffortId=9106 > # > https://ofbiz-vm.apache.org:8443/projectmgr/control/EditWorkEffortSurveyAppls?workEffortId=9106 > # > https://ofbiz-vm.apache.org:8443/projectmgr/control/listResourcesProject?partyId=admin > # > https://ofbiz-vm.apache.org:8443/projectmgr/control/listResourcesTask?partyId=admin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-7670) OFBIZ-7517:SpecialPurpose/ecommerce: Correct all the checkboxes and radio buttons in all the ecommerce FTLs.
[ https://issues.apache.org/jira/browse/OFBIZ-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-7670: Summary: OFBIZ-7517:SpecialPurpose/ecommerce: Correct all the checkboxes and radio buttons in all the ecommerce FTLs. (was: SpecialPurpose/ecommerce: Correct all the checkboxes and radio buttons in all the ecommerce FTLs.) > OFBIZ-7517:SpecialPurpose/ecommerce: Correct all the checkboxes and radio > buttons in all the ecommerce FTLs. > > > Key: OFBIZ-7670 > URL: https://issues.apache.org/jira/browse/OFBIZ-7670 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: Mohammad Kathawala >Assignee: Mohammad Kathawala >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-8014) Introduce the "Product" Screen under Party app to manage the products supplied by any supplier
[ https://issues.apache.org/jira/browse/OFBIZ-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-8014: Description: Currently, upon logging into the Party application (or login as supplier itself) and go to any specific supplier view then there is no way to manage the list of supplied products. # We can try introducing the "Product" tab/screen along with other tabs. (to begin with we can simply mimic the Supplier screen from Catalog app e.g., https://ofbiz-vm.apache.org:8443/catalog/control/EditProductSuppliers?productId=MAT_A_COST) # We can also choose to show the "Products" tab for only Parties in supplier role and later can try to extend for other roles with further needed refinements. Please refer to attached screenshot for the same. was: Currently, upon logging into the Party application (or login as supplier itself) and go to any specific supplier view then there is no way to manage the list of supplied products. # We can try introducing the "Product" tab/screen along with other tabs. (to begin with we can simply mimic the Supplier screen from Catalog app e.g., https://ofbiz-vm.apache.org:8443/catalog/control/EditProductSuppliers?productId=MAT_A_COST) # We can also choose to show the "Products" tab for only Parties in supplier role and later can try to extend with further refinements. Please refer to attached screenshot for the same. > Introduce the "Product" Screen under Party app to manage the products > supplied by any supplier > -- > > Key: OFBIZ-8014 > URL: https://issues.apache.org/jira/browse/OFBIZ-8014 > Project: OFBiz > Issue Type: New Feature >Affects Versions: Release Branch 14.12, Upcoming Branch, Release Branch > 15.12 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: SupplierProduct.png > > > Currently, upon logging into the Party application (or login as supplier > itself) and go to any specific supplier view then there is no way to manage > the list of supplied products. > # We can try introducing the "Product" tab/screen along with other tabs. (to > begin with we can simply mimic the Supplier screen from Catalog app e.g., > https://ofbiz-vm.apache.org:8443/catalog/control/EditProductSuppliers?productId=MAT_A_COST) > > # We can also choose to show the "Products" tab for only Parties in supplier > role and later can try to extend for other roles with further needed > refinements. > Please refer to attached screenshot for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-8014) Introduce the "Product" Screen under Party app to manage the products supplied by any supplier
Swapnil Shah created OFBIZ-8014: --- Summary: Introduce the "Product" Screen under Party app to manage the products supplied by any supplier Key: OFBIZ-8014 URL: https://issues.apache.org/jira/browse/OFBIZ-8014 Project: OFBiz Issue Type: New Feature Affects Versions: Release Branch 15.12, Release Branch 14.12, Upcoming Branch Reporter: Swapnil Shah Assignee: Swapnil Shah Attachments: SupplierProduct.png Currently, upon logging into the Party application (or login as supplier itself) and go to any specific supplier view then there is no way to manage the list of supplied products. 1) We can try introducing the "Product" tab/screen (to begin with we can simply mimic the Supplier screen from Catalog app e.g., https://ofbiz-vm.apache.org:8443/catalog/control/EditProductSuppliers?productId=MAT_A_COST) along with other tabs. 2) We can also choose to show the "Products" tab for only Parties in supplier role and later can try to extend with further refinements. Please refer to attached screenshot for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-7478) Mark the Requirement against purchase 'Ordered' only upon PO approval
[ https://issues.apache.org/jira/browse/OFBIZ-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15442689#comment-15442689 ] Swapnil Shah edited comment on OFBIZ-7478 at 8/28/16 3:56 AM: -- Thanks [~rahul.bhooteshwar] [~diveshdut] for the contribution. I have tested the fixes as follows and found them working fine: # Trigger the MRP run # Approve any 'Product Requirement' # Create a PO through above approved requirement # Checked the Requirement status and it was still 'APPROVED' # Approve the created PO and again checked the Requirement status which is now moved to 'ORDERED' as expected I am closing the issue based on above validations. was (Author: swash78): Thanks [~rahul.bhooteshwar] [~diveshdut] for the contribution. I have tested the fixes as follows and found them working fine: # Trigger the MRP run # Approve and 'Product Requirement' # Create the PO through the above approved requirement # Checked the Requirement status and it was still 'APPROVED' # Approve the created PO and again checked the Requirement status which is now moved to 'ORDERED' as expected I am closing the issue based on above validations. > Mark the Requirement against purchase 'Ordered' only upon PO approval > - > > Key: OFBIZ-7478 > URL: https://issues.apache.org/jira/browse/OFBIZ-7478 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Fix For: Release Branch 14.12, Release Branch 15.12 > > Attachments: OFBIZ-7478.patch > > > Currently purchase requirement get moved into Ordered state as soon PO is > created through the requirement, We should ideally mark it as Ordered once PO > is approved and ready for receiving. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7651) OFBIZ-7649: Display From date with default now() on all screens under Party Application
[ https://issues.apache.org/jira/browse/OFBIZ-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7651. --- I have tested for reported screens and found it working good. > OFBIZ-7649: Display From date with default now() on all screens under Party > Application > --- > > Key: OFBIZ-7651 > URL: https://issues.apache.org/jira/browse/OFBIZ-7651 > Project: OFBiz > Issue Type: Sub-task > Components: party >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah >Priority: Minor > Attachments: OFBIZ-7651.patch > > > To begin with let's start fixing it under > # "Add Party Content" form on > https://ofbiz-vm.apache.org:18443/partymgr/control/EditPartyContents?partyId=DemoCustCompany > # "Edit Product Store Roles" from on > https://ofbiz-vm.apache.org:18443/partymgr/control/ViewProductStoreRoles?partyId=DemoCustCompany -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7172) Introduce Material Trace-ability at Inventory Item level on Production Run Declaration and Actual Material screen
[ https://issues.apache.org/jira/browse/OFBIZ-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7172. --- Resolution: Fixed Thanks [~anuj.jain] for fixing #2-3 in OFBIZ-7173. I am closing it now as you mentioned #1 is going to be taken care in OFBIZ-7174. > Introduce Material Trace-ability at Inventory Item level on Production Run > Declaration and Actual Material screen > - > > Key: OFBIZ-7172 > URL: https://issues.apache.org/jira/browse/OFBIZ-7172 > Project: OFBiz > Issue Type: New Feature > Components: manufacturing >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Fix For: Upcoming Branch > > Attachments: AM_1.png, PRD_1.png > > > Currently The projected material requirement over 'Production Run > Declaration" screen and "Actual Material" screen don't work in sync. > It would help > # if The Inventory level details for projected material requirement based on > BoM, start getting reflected over 'Actual Material' screen as well (even if > its not issued) to track inventory against all required material at one > place. We can add "Issued" column to know whether given inventory item is > issued or not. > # Currently even if a task is not started but as soon as new product is added > against that task it gets issued (though we can still not issue anything for > such task from Declaration screen). We can probably allow to get added > product issued only from Declaration screen using 'Issue Component' button > against each task. Over Actual material screen we can just list the added > items with inventory level details. > # Similar inventory related information could be embedded over Declaration > screen under "Material Required by Running Task" section by adding Inventory > Item Id column that could show list of all InventoryItemIds against product > (on click of a button) > Please refer to attached screenshot for further reference. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7649) Display "From Date" with default now() time-stamp and asterix sign on all forms where its part of Primary Key
[ https://issues.apache.org/jira/browse/OFBIZ-7649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7649. --- Closing the ticket as all child tickets are closed now. > Display "From Date" with default now() time-stamp and asterix sign on all > forms where its part of Primary Key > - > > Key: OFBIZ-7649 > URL: https://issues.apache.org/jira/browse/OFBIZ-7649 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > > Currently on many create/edit/add forms, where From Date is part of primary > key is shown as blank, If user leaves it as blank then system either doesn't > stop submitting the form but simply set it with now() timestamp implicitly or > errors out. > As part of common UX practice, In all such forms/screen we could always try > defaulting and display From Date with now() time stamp (with asterix sign) > rather than showing it blank. So user is aware what would be set and its one > of the required fields on given form -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7653) OFBIZ-7649: Display From date with default now() on all screens under Manufacturing Application
[ https://issues.apache.org/jira/browse/OFBIZ-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7653. --- I have tested it on reported screens and found it working as per expectations. > OFBIZ-7649: Display From date with default now() on all screens under > Manufacturing Application > --- > > Key: OFBIZ-7653 > URL: https://issues.apache.org/jira/browse/OFBIZ-7653 > Project: OFBiz > Issue Type: Sub-task > Components: manufacturing >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7653.patch > > > To begin with we can start fixing it under > # https://ofbiz-vm.apache.org:18443/manufacturing/control/CreateProductionRun > # "Edit Routing Task Association" on > https://ofbiz-vm.apache.org:18443/manufacturing/control/EditRoutingTaskAssoc?workEffortId=DEFAULT_ROUTING > # "Edit Routing-Product Link" over > https://ofbiz-vm.apache.org:18443/manufacturing/control/EditRoutingProductLink?workEffortId=DEFAULT_ROUTING > # "Add Routing Task Costs" over > https://ofbiz-vm.apache.org:18443/manufacturing/control/EditRoutingTaskCosts?workEffortId=DEFAULT_TASK > # "Edit Routing Task Product" over > https://ofbiz-vm.apache.org:18443/manufacturing/control/ListRoutingTaskProducts?workEffortId=DEFAULT_TASK > # https://ofbiz-vm.apache.org:18443/manufacturing/control/EditProductBom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7542) Convert search criteria on 'Status' into multi-select pattern on all search screens
[ https://issues.apache.org/jira/browse/OFBIZ-7542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7542. --- Closing the issue as all sub tasks are successfully closed now after validation. > Convert search criteria on 'Status' into multi-select pattern on all search > screens > --- > > Key: OFBIZ-7542 > URL: https://issues.apache.org/jira/browse/OFBIZ-7542 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: Upcoming Branch >Reporter: Swapnil Shah >Assignee: Swapnil Shah > > here are many screens where search can be performed on on given status at a > time as its shown in form of dropdown and user can select only one value from > it. > Like Order list screen, we can try using this multi-select as generic search > pattern starting with 'Status' and leveraging upon it for any other eligible > search criteria. It should behave as follows: > # Selecting "All" (via checkbox) should auto-select all applicable statuses > # De-selecting "All" should remove selection from all selected statuses > # After selecting "All" if any other status(es) are selected and "All" should > be de-selected automatically > # Multiple statuses should be selectable simultaneously > # The search result should honor the selected statuses -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-8445) OFBIZ-7520: Consistency and Readability improvements for if-compare tag
[ https://issues.apache.org/jira/browse/OFBIZ-8445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-8445: Summary: OFBIZ-7520: Consistency and Readability improvements for if-compare tag (was: Consistency and Readability improvements for if-compare tag) > OFBIZ-7520: Consistency and Readability improvements for if-compare tag > --- > > Key: OFBIZ-8445 > URL: https://issues.apache.org/jira/browse/OFBIZ-8445 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Affects Versions: Upcoming Branch >Reporter: Devanshu Vyas >Priority: Minor > > Code written in Minilang for the if-compare tag is not consistent throughout > the application. The correct pattern to write is > > I found various other ways in which this tag is written, like > type="Boolean"> > type="Boolean"> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-8450) OFBIZ-7520: Consistency and Readability improvements for include-screen tag
[ https://issues.apache.org/jira/browse/OFBIZ-8450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-8450: Summary: OFBIZ-7520: Consistency and Readability improvements for include-screen tag (was: Consistency and Readability improvements for include-screen tag) > OFBIZ-7520: Consistency and Readability improvements for include-screen tag > --- > > Key: OFBIZ-8450 > URL: https://issues.apache.org/jira/browse/OFBIZ-8450 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Affects Versions: Upcoming Branch >Reporter: Devanshu Vyas > > Code written in Minilang for the if-compare tag is not consistent throughout > the application. The correct pattern to write is > location="component://order/widget/ordermgr/OrderPrintScreens.xml"/> > Found a wrong way in which this tag is written, > location="component://party/widget/partymgr/CommunicationEventScreens.xml" > name="commOverview"/> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7714) Introduce a quick way for adding Purchase Price agreements with Suppliers for any specific product from Catalog
[ https://issues.apache.org/jira/browse/OFBIZ-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15689125#comment-15689125 ] Swapnil Shah commented on OFBIZ-7714: - Yes, it would be more simplified version of current 'Create Agreement' screen asking for only relevant details to be filled in by Buyers as specified in description. I would leave UX up to developers, details can be filled in form of modal dialog or new screen whichever is easier route. > Introduce a quick way for adding Purchase Price agreements with Suppliers for > any specific product from Catalog > --- > > Key: OFBIZ-7714 > URL: https://issues.apache.org/jira/browse/OFBIZ-7714 > Project: OFBiz > Issue Type: New Feature > Components: product >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: PPA.png > > > Currently new pricing agreements creation takes user to Accounting app where > it is quite an long and arduous process. And many a times a buyer or > procurement users doesn't have direct accounting permission in case quick > pricing agreement needs to be placed with Supplier for specific product(s). > We can provide a quick option from Catalog >> Product >> Agreement screen > over "Purchase" section that could unfold as follows: > # Have a 'Create Price Agreement' link/button on the 'Purchases' Panel and > hitting this link could ask user to enter following very basic parameters: > #- Party Id From (Default it to facility's owner party id) > #- Party Id To (show list of suppliers like we show at the time of Purchase > Order entry screen) > #- From Date (default it to show as now() timestamp) > #- Through Date > #- Description > #- Price > #- Currency > #- Supplier Product Id > # Upon successful submission of above details system should create Agreement > and AgreementItem & SupplierProduct between Supplier and organization by > passing following default values: > #- Role Type Id From = 'Internal Organization' > #- Role Type Id To = ''Supplier" > #- Agreement Type Id = 'Purchase' > #- Agreement Item Type Id = 'Pricing' > #- Product Id= '' > Please refer to attached screenshot for reference placeholder > !PPA.png|thumbnail! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7714) Introduce a quick way for adding Purchase Price agreements with Suppliers for any specific product from Catalog
[ https://issues.apache.org/jira/browse/OFBIZ-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688935#comment-15688935 ] Swapnil Shah commented on OFBIZ-7714: - I am not sure if the requirements are interpreted in the true sense in which it was described. Here is the real time business case if that can help to put things in perspective: "A buyer is the person who is responsible for negotiating with suppliers on various terms related to products like pricing, discounts, delivery schedule, credit backs, lot sizing etc. While negotiating with suppliers, there are various data points need to be referred e.g. Terms/Quotes offered/negotiated from other or same suppliers in past, current inventory status, selling prices, future contracts, current contracts expiry etc. As essentially buyer is authorized person to initiate or place the formal agreement into system which later can be Approved by higher authorities before making them to come into effect. Role of 'Accounting' users in this process is limited to just referring such agreements in order to reconcile invoices and payments to any given supplier". (Please note that Buyer has all the valid permission and authority to CRUD the "Purchase Agreements" here without necessarily having all other permissions available to a typical Accounting users as specified in description of ticket earlier). In order to support above business processes, Catalog app looked more apt place to be in over other applications as buyers generally have prior permission to access and refer all relevant details without necessarily jumping around across modules with all the necessarily permissions. I am not sure about the original intent of having 'Agreements' tab available under Catalog app but whatever may be the reason, 'Agreement' view could have been leveraged here to enable this requirement. Currently the requirement over this ticket is just for supporting pricing agreements but later can be extended for other eligible types based on logged in user's roles. > Introduce a quick way for adding Purchase Price agreements with Suppliers for > any specific product from Catalog > --- > > Key: OFBIZ-7714 > URL: https://issues.apache.org/jira/browse/OFBIZ-7714 > Project: OFBiz > Issue Type: New Feature > Components: product >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: PPA.png > > > Currently new pricing agreements creation takes user to Accounting app where > it is quite an long and arduous process. And many a times a buyer or > procurement users doesn't have direct accounting permission in case quick > pricing agreement needs to be placed with Supplier for specific product(s). > We can provide a quick option from Catalog >> Product >> Agreement screen > over "Purchase" section that could unfold as follows: > # Have a 'Create Price Agreement' link/button on the 'Purchases' Panel and > hitting this link could ask user to enter following very basic parameters: > #- Party Id From (Default it to facility's owner party id) > #- Party Id To (show list of suppliers like we show at the time of Purchase > Order entry screen) > #- From Date (default it to show as now() timestamp) > #- Through Date > #- Description > #- Price > #- Currency > #- Supplier Product Id > # Upon successful submission of above details system should create Agreement > and AgreementItem & SupplierProduct between Supplier and organization by > passing following default values: > #- Role Type Id From = 'Internal Organization' > #- Role Type Id To = ''Supplier" > #- Agreement Type Id = 'Purchase' > #- Agreement Item Type Id = 'Pricing' > #- Product Id= '' > Please refer to attached screenshot for reference placeholder > !PPA.png|thumbnail! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7559) Material requirements is allowed to be added against already 'Cancelled' Production Run (task)
[ https://issues.apache.org/jira/browse/OFBIZ-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15758216#comment-15758216 ] Swapnil Shah commented on OFBIZ-7559: - Thanks [~anuj.jain] for the fixes and i have validated the reported case as follows: * Cancelled an already created production run * Attempted to add the new component from 'Actual Material' screen * System prevented to add the component with proper message (*PASS*) Based on above result set i am closing this ticket now. > Material requirements is allowed to be added against already 'Cancelled' > Production Run (task) > -- > > Key: OFBIZ-7559 > URL: https://issues.apache.org/jira/browse/OFBIZ-7559 > Project: OFBiz > Issue Type: Improvement > Components: manufacturing >Affects Versions: Trunk >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: P1.png, P2.png, P3.png > > > Currently system allows user to add/issue the new material requirement > against cancelled routing tasks. > Expected Behavior: > System should allow user to add the new material requirement against only > non-cancelled tasks > Please refer to attached screenshot for reference > !https://issues.apache.org/jira/secure/attachment/12812788/P1.png|width=800px! > !https://issues.apache.org/jira/secure/attachment/12812787/P2.png|width=800px! > !https://issues.apache.org/jira/secure/attachment/12812786/P3.png|width=800px! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7559) Material requirements is allowed to be added against already 'Cancelled' Production Run (task)
[ https://issues.apache.org/jira/browse/OFBIZ-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah closed OFBIZ-7559. --- > Material requirements is allowed to be added against already 'Cancelled' > Production Run (task) > -- > > Key: OFBIZ-7559 > URL: https://issues.apache.org/jira/browse/OFBIZ-7559 > Project: OFBiz > Issue Type: Improvement > Components: manufacturing >Affects Versions: Trunk >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: P1.png, P2.png, P3.png > > > Currently system allows user to add/issue the new material requirement > against cancelled routing tasks. > Expected Behavior: > System should allow user to add the new material requirement against only > non-cancelled tasks > Please refer to attached screenshot for reference > !https://issues.apache.org/jira/secure/attachment/12812788/P1.png|width=800px! > !https://issues.apache.org/jira/secure/attachment/12812787/P2.png|width=800px! > !https://issues.apache.org/jira/secure/attachment/12812786/P3.png|width=800px! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7468) Define constraints while adding new material to the task which is in completed/cancel status.
[ https://issues.apache.org/jira/browse/OFBIZ-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15758261#comment-15758261 ] Swapnil Shah commented on OFBIZ-7468: - [~anuj.jain] I have tried to validate the fixes and found that this feature still not working correctly (please refer to attached screenshot for reference). Here are the results: # Component added to already running production run task: ## The component get successfully added (via Actual Material screen) and available to be issued for any already running (i.e. non-completed, non-cancelled) tasks (*PASS*) ## While issuing the component along with regular component from BoM, the newly added component ends up creating new inventory item despite the fact that there is already sufficient ATP available to be consumed from. Expectation is to use the existing ATP for issuance and if nothing is available then don't issue it (*FAIL*) ## The newly created inventory item is linked to WEIA with negative quantity. The expectation is to issue and link only those inventory items that have sufficient ATP to be consumed from (*FAIL*) # When the component are added for already completed production run task then problem starts as follows: ## It only ends up created WEGS (in CREATED State) and doesn't directly issue them. So user has now no option to issue them from anywhere. Expectation is to also get the added component qty directly issued (*FAIL*) !OFBIZ-7468_1.jpg|thumbnail! !OFBIZ-7468_2.jpg|thumbnail! !OFBIZ-7468_3.jpg|thumbnail! > Define constraints while adding new material to the task which is in > completed/cancel status. > - > > Key: OFBIZ-7468 > URL: https://issues.apache.org/jira/browse/OFBIZ-7468 > Project: OFBiz > Issue Type: Improvement > Components: manufacturing >Affects Versions: Trunk >Reporter: Anuj Jain >Assignee: Swapnil Shah > Attachments: OFBIZ-7468.patch, OFBIZ_7468_1.png, OFBIZ_7468_2.png, > OFBIZ_7468_3.png > > > Define actions on adding new material to the task which is in > completed/cancel status. > Actions suggested by Swapnil :- > # We can begin with simple constraint of allowing new material against the > only those routing task that has not cancelled yet within a production run > # Any completed taks for uncomplete Production Run should have WEGS created > in COMPLETED status and WEIA created as well by issuing the added item's qty. > # If production is already completed (aka all its routing task also > completed/cancelled) then don't allow new material to be added from Actual > Material screen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-7468) Define constraints while adding new material to the task which is in completed/cancel status.
[ https://issues.apache.org/jira/browse/OFBIZ-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-7468: Attachment: OFBIZ_7468_3.png OFBIZ_7468_2.png OFBIZ_7468_1.png > Define constraints while adding new material to the task which is in > completed/cancel status. > - > > Key: OFBIZ-7468 > URL: https://issues.apache.org/jira/browse/OFBIZ-7468 > Project: OFBiz > Issue Type: Improvement > Components: manufacturing >Affects Versions: Trunk >Reporter: Anuj Jain >Assignee: Swapnil Shah > Attachments: OFBIZ-7468.patch, OFBIZ_7468_1.png, OFBIZ_7468_2.png, > OFBIZ_7468_3.png > > > Define actions on adding new material to the task which is in > completed/cancel status. > Actions suggested by Swapnil :- > # We can begin with simple constraint of allowing new material against the > only those routing task that has not cancelled yet within a production run > # Any completed taks for uncomplete Production Run should have WEGS created > in COMPLETED status and WEIA created as well by issuing the added item's qty. > # If production is already completed (aka all its routing task also > completed/cancelled) then don't allow new material to be added from Actual > Material screen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-7468) Define constraints while adding new material to the task which is in completed/cancel status.
[ https://issues.apache.org/jira/browse/OFBIZ-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15758261#comment-15758261 ] Swapnil Shah edited comment on OFBIZ-7468 at 12/18/16 5:40 AM: --- [~anuj.jain] I have tried to validate the fixes and found that this feature still not working correctly (please refer to attached screenshot for reference). Here are the results: # Component added to already running production run task: ## The component get successfully added (via Actual Material screen) and available to be issued for any already running (i.e. non-completed, non-cancelled) tasks (*PASS*) ## While issuing the component along with regular component from BoM, the newly added component ends up creating new inventory item despite the fact that there is already sufficient ATP available to be consumed from. Expectation is to use the existing ATP for issuance and if nothing is available then don't issue it (*FAIL*) ## The newly created inventory item is linked to WEIA with negative quantity. The expectation is to issue and link only those inventory items that have sufficient ATP to be consumed from (*FAIL*) # When the component are added for already completed production run task then problem starts as follows: ## It only ends up created WEGS (in CREATED State) and doesn't directly issue them. So user has now no option to issue them from anywhere. Expectation is to also get the added component qty directly issued (*FAIL*) !OFBIZ_7468_1.jpg|thumbnail! !OFBIZ_7468_2.jpg|thumbnail! !OFBIZ_7468_3.jpg|thumbnail! was (Author: swash78): [~anuj.jain] I have tried to validate the fixes and found that this feature still not working correctly (please refer to attached screenshot for reference). Here are the results: # Component added to already running production run task: ## The component get successfully added (via Actual Material screen) and available to be issued for any already running (i.e. non-completed, non-cancelled) tasks (*PASS*) ## While issuing the component along with regular component from BoM, the newly added component ends up creating new inventory item despite the fact that there is already sufficient ATP available to be consumed from. Expectation is to use the existing ATP for issuance and if nothing is available then don't issue it (*FAIL*) ## The newly created inventory item is linked to WEIA with negative quantity. The expectation is to issue and link only those inventory items that have sufficient ATP to be consumed from (*FAIL*) # When the component are added for already completed production run task then problem starts as follows: ## It only ends up created WEGS (in CREATED State) and doesn't directly issue them. So user has now no option to issue them from anywhere. Expectation is to also get the added component qty directly issued (*FAIL*) !OFBIZ-7468_1.jpg|thumbnail! !OFBIZ-7468_2.jpg|thumbnail! !OFBIZ-7468_3.jpg|thumbnail! > Define constraints while adding new material to the task which is in > completed/cancel status. > - > > Key: OFBIZ-7468 > URL: https://issues.apache.org/jira/browse/OFBIZ-7468 > Project: OFBiz > Issue Type: Improvement > Components: manufacturing >Affects Versions: Trunk >Reporter: Anuj Jain >Assignee: Swapnil Shah > Attachments: OFBIZ-7468.patch, OFBIZ_7468_1.png, OFBIZ_7468_2.png, > OFBIZ_7468_3.png > > > Define actions on adding new material to the task which is in > completed/cancel status. > Actions suggested by Swapnil :- > # We can begin with simple constraint of allowing new material against the > only those routing task that has not cancelled yet within a production run > # Any completed taks for uncomplete Production Run should have WEGS created > in COMPLETED status and WEIA created as well by issuing the added item's qty. > # If production is already completed (aka all its routing task also > completed/cancelled) then don't allow new material to be added from Actual > Material screen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (OFBIZ-7468) Define constraints while adding new material to the task which is in completed/cancel status.
[ https://issues.apache.org/jira/browse/OFBIZ-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reopened OFBIZ-7468: - Assignee: Anuj Jain (was: Swapnil Shah) > Define constraints while adding new material to the task which is in > completed/cancel status. > - > > Key: OFBIZ-7468 > URL: https://issues.apache.org/jira/browse/OFBIZ-7468 > Project: OFBiz > Issue Type: Improvement > Components: manufacturing >Affects Versions: Trunk >Reporter: Anuj Jain >Assignee: Anuj Jain > Attachments: OFBIZ-7468.patch, OFBIZ_7468_1.png, OFBIZ_7468_2.png, > OFBIZ_7468_3.png > > > Define actions on adding new material to the task which is in > completed/cancel status. > Actions suggested by Swapnil :- > # We can begin with simple constraint of allowing new material against the > only those routing task that has not cancelled yet within a production run > # Any completed taks for uncomplete Production Run should have WEGS created > in COMPLETED status and WEIA created as well by issuing the added item's qty. > # If production is already completed (aka all its routing task also > completed/cancelled) then don't allow new material to be added from Actual > Material screen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (OFBIZ-7713) Introduce a quick way for adding Sales Price agreements with customers for any specific product from Catalog
[ https://issues.apache.org/jira/browse/OFBIZ-7713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reopened OFBIZ-7713: - > Introduce a quick way for adding Sales Price agreements with customers for > any specific product from Catalog > > > Key: OFBIZ-7713 > URL: https://issues.apache.org/jira/browse/OFBIZ-7713 > Project: OFBiz > Issue Type: New Feature > Components: product >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Mohammad Kathawala > Attachments: OFBIZ-7713.patch, SPA.png > > > Currently new pricing agreements creation takes user to Accounting app where > it is quite an long and arduous process. And many a times a catalog or sales > manager doesn't have accounting permission in case quick pricing agreement > needs to be placed with customer for specific product(s). > We can provide a quick option from Catalog >> Product >> Agreement screen > over "Sales" section that could unfold as follows: > # Have a 'Create Price Agreement' link/button on the Sales Panel and hitting > this link could ask user to enter following very basic parameters: > #- Party Id From > #- Party Id To (Default it to product store's owner party id) > #- From Date (default it to show as now() timestamp) > #- Through Date > #- Description > #- Price > #- Currency > # Upon successful submission of above details system should create Agreement > and Agreement Item between customer and organization by passing following > default values: > #- Role Type Id From = 'Customer' > #- Role Type Id To = 'Internal Organization' > #- Agreement Type Id = 'Sales' > #- Agreement Item Type Id = 'Pricing' > #- Product Id= '' > Please refer to attached screenshot for reference placeholder -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-7713) Introduce a quick way for adding Sales Price agreements with customers for any specific product from Catalog
[ https://issues.apache.org/jira/browse/OFBIZ-7713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15758277#comment-15758277 ] Swapnil Shah edited comment on OFBIZ-7713 at 12/18/16 5:53 AM: --- Thanks [~Mohammad K] for the fixes. i have tried to validate the feature and seems to be all working good except the following minor issues for defaulting the values over Create Sales Agreement form: # "Party Id To" is not defaulting to product store's owner party id # "From Date" is not defaulting to now() time stamp. Assigning it back to take care of above changes. was (Author: swash78): Thanks [~Mohammad K] for the fixes. i have tried to validate the feature and seems to be all working good except the following minor issues for defaulting the values: # "Party Id To" is not defaulting to product store's owner party id # "From Date" is not defaulting to now() time stamp. Assigning it back to take care of above changes. > Introduce a quick way for adding Sales Price agreements with customers for > any specific product from Catalog > > > Key: OFBIZ-7713 > URL: https://issues.apache.org/jira/browse/OFBIZ-7713 > Project: OFBiz > Issue Type: New Feature > Components: product >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7713.patch, SPA.png > > > Currently new pricing agreements creation takes user to Accounting app where > it is quite an long and arduous process. And many a times a catalog or sales > manager doesn't have accounting permission in case quick pricing agreement > needs to be placed with customer for specific product(s). > We can provide a quick option from Catalog >> Product >> Agreement screen > over "Sales" section that could unfold as follows: > # Have a 'Create Price Agreement' link/button on the Sales Panel and hitting > this link could ask user to enter following very basic parameters: > #- Party Id From > #- Party Id To (Default it to product store's owner party id) > #- From Date (default it to show as now() timestamp) > #- Through Date > #- Description > #- Price > #- Currency > # Upon successful submission of above details system should create Agreement > and Agreement Item between customer and organization by passing following > default values: > #- Role Type Id From = 'Customer' > #- Role Type Id To = 'Internal Organization' > #- Agreement Type Id = 'Sales' > #- Agreement Item Type Id = 'Pricing' > #- Product Id= '' > Please refer to attached screenshot for reference placeholder -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-7713) Introduce a quick way for adding Sales Price agreements with customers for any specific product from Catalog
[ https://issues.apache.org/jira/browse/OFBIZ-7713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reassigned OFBIZ-7713: --- Assignee: Mohammad Kathawala (was: Swapnil Shah) > Introduce a quick way for adding Sales Price agreements with customers for > any specific product from Catalog > > > Key: OFBIZ-7713 > URL: https://issues.apache.org/jira/browse/OFBIZ-7713 > Project: OFBiz > Issue Type: New Feature > Components: product >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Mohammad Kathawala > Attachments: OFBIZ-7713.patch, SPA.png > > > Currently new pricing agreements creation takes user to Accounting app where > it is quite an long and arduous process. And many a times a catalog or sales > manager doesn't have accounting permission in case quick pricing agreement > needs to be placed with customer for specific product(s). > We can provide a quick option from Catalog >> Product >> Agreement screen > over "Sales" section that could unfold as follows: > # Have a 'Create Price Agreement' link/button on the Sales Panel and hitting > this link could ask user to enter following very basic parameters: > #- Party Id From > #- Party Id To (Default it to product store's owner party id) > #- From Date (default it to show as now() timestamp) > #- Through Date > #- Description > #- Price > #- Currency > # Upon successful submission of above details system should create Agreement > and Agreement Item between customer and organization by passing following > default values: > #- Role Type Id From = 'Customer' > #- Role Type Id To = 'Internal Organization' > #- Agreement Type Id = 'Sales' > #- Agreement Item Type Id = 'Pricing' > #- Product Id= '' > Please refer to attached screenshot for reference placeholder -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7713) Introduce a quick way for adding Sales Price agreements with customers for any specific product from Catalog
[ https://issues.apache.org/jira/browse/OFBIZ-7713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15758277#comment-15758277 ] Swapnil Shah commented on OFBIZ-7713: - Thanks [~Mohammad K] for the fixes. i have tried to validate the feature and seems to be all working good except the following minor issues for defaulting the values: # "Party Id To" is not defaulting to product store's owner party id # "From Date" is not defaulting to now() time stamp. Assigning it back to take care of above changes. > Introduce a quick way for adding Sales Price agreements with customers for > any specific product from Catalog > > > Key: OFBIZ-7713 > URL: https://issues.apache.org/jira/browse/OFBIZ-7713 > Project: OFBiz > Issue Type: New Feature > Components: product >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah >Assignee: Swapnil Shah > Attachments: OFBIZ-7713.patch, SPA.png > > > Currently new pricing agreements creation takes user to Accounting app where > it is quite an long and arduous process. And many a times a catalog or sales > manager doesn't have accounting permission in case quick pricing agreement > needs to be placed with customer for specific product(s). > We can provide a quick option from Catalog >> Product >> Agreement screen > over "Sales" section that could unfold as follows: > # Have a 'Create Price Agreement' link/button on the Sales Panel and hitting > this link could ask user to enter following very basic parameters: > #- Party Id From > #- Party Id To (Default it to product store's owner party id) > #- From Date (default it to show as now() timestamp) > #- Through Date > #- Description > #- Price > #- Currency > # Upon successful submission of above details system should create Agreement > and Agreement Item between customer and organization by passing following > default values: > #- Role Type Id From = 'Customer' > #- Role Type Id To = 'Internal Organization' > #- Agreement Type Id = 'Sales' > #- Agreement Item Type Id = 'Pricing' > #- Product Id= '' > Please refer to attached screenshot for reference placeholder -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (OFBIZ-7111) Total Actual cost of production run need to be passed on to produced stock's unit cost for completed production run
[ https://issues.apache.org/jira/browse/OFBIZ-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reopened OFBIZ-7111: - Assignee: Anuj Jain (was: Divesh Dutta) > Total Actual cost of production run need to be passed on to produced stock's > unit cost for completed production run > --- > > Key: OFBIZ-7111 > URL: https://issues.apache.org/jira/browse/OFBIZ-7111 > Project: OFBiz > Issue Type: New Feature > Components: manufacturing >Affects Versions: Release Branch 14.12, 14.12.01, Release Branch 15.12, > 15.12.01 >Reporter: Swapnil Shah >Assignee: Anuj Jain > Attachments: ActualCostXfer_1.png, ActualCostXfer_2.png, > OFBIZ-7111.patch, OFBIZ-7111_V2.patch > > > Currently as soon as item is produced into inventory once production run is > completed then inventory get created with ZERO unit cost. > We could pass on the total actual cost (Material+Labor+Resource etc.) to > Produced Item's inventory item i.e. = Total Actual Cost/ Produced in Stock > Please refer to attached screenshot for reference -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7111) Total Actual cost of production run need to be passed on to produced stock's unit cost for completed production run
[ https://issues.apache.org/jira/browse/OFBIZ-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15758299#comment-15758299 ] Swapnil Shah commented on OFBIZ-7111: - Thanks [~anuj.jain] for the fixes. I have tried to validate the fixes and here are the results: # Total Actual cost was correctly prorated When product was produced and stocked after completing the production run task (*PASS*) # The unit cost was set as ZERO, when product was produced and stocked before completing the production run task (this is expected). But when production run task was completed and production got completed then it was expected to calculate and transfer the total Actual cost on already produced item(s) which it didn't. (*FAIL*) Assigning back to take care of above failing scenario > Total Actual cost of production run need to be passed on to produced stock's > unit cost for completed production run > --- > > Key: OFBIZ-7111 > URL: https://issues.apache.org/jira/browse/OFBIZ-7111 > Project: OFBiz > Issue Type: New Feature > Components: manufacturing >Affects Versions: Release Branch 14.12, 14.12.01, Release Branch 15.12, > 15.12.01 >Reporter: Swapnil Shah >Assignee: Divesh Dutta > Attachments: ActualCostXfer_1.png, ActualCostXfer_2.png, > OFBIZ-7111.patch, OFBIZ-7111_V2.patch > > > Currently as soon as item is produced into inventory once production run is > completed then inventory get created with ZERO unit cost. > We could pass on the total actual cost (Material+Labor+Resource etc.) to > Produced Item's inventory item i.e. = Total Actual Cost/ Produced in Stock > Please refer to attached screenshot for reference -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-7111) Total Actual cost of production run need to be passed on to produced stock's unit cost for completed production run
[ https://issues.apache.org/jira/browse/OFBIZ-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15758299#comment-15758299 ] Swapnil Shah edited comment on OFBIZ-7111 at 12/18/16 6:15 AM: --- Thanks [~anuj.jain] for the fixes. I have tried to validate the fixes and here are the results: # Total Actual cost was correctly prorated When product was produced and stocked after completing the production run task (*PASS*) # The unit cost was set as ZERO, when product was produced and stocked before completing the production run task (this is expected). But when production run task was completed and production got completed then it was expected to calculate and transfer the total Actual cost on already produced item(s) which it didn't. (*FAIL*) Assigning back to take care of above failing scenario (please refer to attached screenshot for reference) was (Author: swash78): Thanks [~anuj.jain] for the fixes. I have tried to validate the fixes and here are the results: # Total Actual cost was correctly prorated When product was produced and stocked after completing the production run task (*PASS*) # The unit cost was set as ZERO, when product was produced and stocked before completing the production run task (this is expected). But when production run task was completed and production got completed then it was expected to calculate and transfer the total Actual cost on already produced item(s) which it didn't. (*FAIL*) Assigning back to take care of above failing scenario > Total Actual cost of production run need to be passed on to produced stock's > unit cost for completed production run > --- > > Key: OFBIZ-7111 > URL: https://issues.apache.org/jira/browse/OFBIZ-7111 > Project: OFBiz > Issue Type: New Feature > Components: manufacturing >Affects Versions: Release Branch 14.12, 14.12.01, Release Branch 15.12, > 15.12.01 >Reporter: Swapnil Shah >Assignee: Anuj Jain > Attachments: ActualCostXfer_1.png, ActualCostXfer_2.png, > OFBIZ-7111.patch, OFBIZ-7111_V2.patch > > > Currently as soon as item is produced into inventory once production run is > completed then inventory get created with ZERO unit cost. > We could pass on the total actual cost (Material+Labor+Resource etc.) to > Produced Item's inventory item i.e. = Total Actual Cost/ Produced in Stock > Please refer to attached screenshot for reference -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-7111) Total Actual cost of production run need to be passed on to produced stock's unit cost for completed production run
[ https://issues.apache.org/jira/browse/OFBIZ-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-7111: Attachment: OFBIZ_7111.png > Total Actual cost of production run need to be passed on to produced stock's > unit cost for completed production run > --- > > Key: OFBIZ-7111 > URL: https://issues.apache.org/jira/browse/OFBIZ-7111 > Project: OFBiz > Issue Type: New Feature > Components: manufacturing >Affects Versions: Release Branch 14.12, 14.12.01, Release Branch 15.12, > 15.12.01 >Reporter: Swapnil Shah >Assignee: Anuj Jain > Attachments: ActualCostXfer_1.png, ActualCostXfer_2.png, > OFBIZ-7111.patch, OFBIZ-7111_V2.patch, OFBIZ_7111.png > > > Currently as soon as item is produced into inventory once production run is > completed then inventory get created with ZERO unit cost. > We could pass on the total actual cost (Material+Labor+Resource etc.) to > Produced Item's inventory item i.e. = Total Actual Cost/ Produced in Stock > Please refer to attached screenshot for reference -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7468) Define constraints while adding new material to the task which is in completed/cancel status.
[ https://issues.apache.org/jira/browse/OFBIZ-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15760507#comment-15760507 ] Swapnil Shah commented on OFBIZ-7468: - I reckon systemically allowing inventory pegging to cancelled jobs makes more sense only when issued/related components are physically consumed during production processing in real time. But possibly there can be some better ways to just correct reporting in accounting books or backward cost adjustment. In real time as well, if inbound material requirements are actually consumed at any stage of production processing then it must have been physically issued on shop floor first and system should be honoring this process. If its happening otherwise then it looks to be a case of business process re-engineering first before allowing system to honor such cases. We can definitely develop this feature as custom requirement but not sure if it can be considered as norm. Current OFbiz behavior also doesn't support it as it works something like as follows: 1) Production run(tasks) can only be cancelled before it moves into 'Confirmed' status (i.e. none of the tasks has started yet). Thereafter its not possible to mark the production run as cancelled. Nor is it possible to issue the components for task before starting it, What it essentially means is that if production run is cancelled then none of the task could have been started and hence nothing was physically consumed. That's one of the reason in this task we tried to prevent component from being added to cancelled task. 2) Once production run comes into 'Running' state (i.e. task(s) have been started) then its not possible to Cancel the production run. What it means is that issuance must be made in order to complete the production run(tasks).System provides flexibility to add components to Completed task as they have been physically consumed before completion. And its still intact. Also in none of the above cases system perform any backward cost transfer on production run upon any release/issuance or returns made after production run stands completed or cancelled. (We might need to define and finalize the generic workflow first before supporting this) > Define constraints while adding new material to the task which is in > completed/cancel status. > - > > Key: OFBIZ-7468 > URL: https://issues.apache.org/jira/browse/OFBIZ-7468 > Project: OFBiz > Issue Type: Improvement > Components: manufacturing >Affects Versions: Trunk >Reporter: Anuj Jain >Assignee: Anuj Jain > Attachments: OFBIZ-7468.patch, OFBIZ_7468_1.png, OFBIZ_7468_2.png, > OFBIZ_7468_3.png > > > Define actions on adding new material to the task which is in > completed/cancel status. > Actions suggested by Swapnil :- > # We can begin with simple constraint of allowing new material against the > only those routing task that has not cancelled yet within a production run > # Any completed taks for uncomplete Production Run should have WEGS created > in COMPLETED status and WEIA created as well by issuing the added item's qty. > # If production is already completed (aka all its routing task also > completed/cancelled) then don't allow new material to be added from Actual > Material screen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (OFBIZ-6964) Support for replenishment of a secondary warehouse from a main warehouse
[
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] [Assigned] (OFBIZ-7356) OFBIZ-6964: Document finalized design to support replenishment planning through any inter-company facility
[
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-6964) Support for replenishment of a secondary warehouse from a main warehouse
[
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] [Assigned] (OFBIZ-7357) OFBIZ-6964: Prepare Demo Data based on the propsed design to support replenishment planning through any inter-company facility
[ 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] [Commented] (OFBIZ-4514) Taxes are not handled correctly when creating accounting transactions from purchase invoices
[ https://issues.apache.org/jira/browse/OFBIZ-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16019121#comment-16019121 ] Swapnil Shah commented on OFBIZ-4514: - [~deepak.nigam] Its nice that patch has been submitted, Can we please now summarize what was the "Before Behavior" and what would be "After Behavior" of system so everyone can refer to that and understand easily what changes have been made instead of digging into code/patch every time. It would be nice if we can follow this as a practice to put a very quick summary of before and after behavior on every ticket if code changes have been made before closing it. > Taxes are not handled correctly when creating accounting transactions from > purchase invoices > > > Key: OFBIZ-4514 > URL: https://issues.apache.org/jira/browse/OFBIZ-4514 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Trunk >Reporter: Martin Kreidenweis >Priority: Trivial > Labels: VAT, tax > Attachments: OFBIZ-4514_combined.patch, OFBIZ-4514.patch > > > Taxes are not handled correctly when creating accounting transactions from > purchase invoices in GeneralLedgerServices#createAcctgTransForPurchaseInvoice -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OFBIZ-9369) Add order priority management on sale order creation
[ https://issues.apache.org/jira/browse/OFBIZ-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16019116#comment-16019116 ] Swapnil Shah commented on OFBIZ-9369: - As [~pfm.smits] mentioned there can be many factors that could govern the reservations and their order of importance may vary from business to business and its possible that we might not be supporting all of the them in Ofbiz yet. Hence It would be nice if we can list out all the factors which are currently honored systemically in code while promising any sales order and then where exactly "Order Priority" falls in that hierarchy. It could help us to define a "Sales Order Reservation Rules Guide" which everyone can refer to and update it once any new variable is introduced. Having said this, one very commonly used parameter is ESD (Estimated Ship Date or Est. Delivery Date) set at Order item or Order Header level. It would be interesting to know how it would behave once we have Priorities also set on orders. > Add order priority management on sale order creation > > > Key: OFBIZ-9369 > URL: https://issues.apache.org/jira/browse/OFBIZ-9369 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Trunk >Reporter: Leila Mekika >Priority: Minor > Attachments: OFBIZ-9369.patch > > > I made a patch to allow order priority setting when creating sale order. > This add option on order first step creation an add it to the OrderHeader > during creation so that reservation SECA is triggered. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OFBIZ-7183) Completed Service Order Items are being allowed to be received along with finished goods over Approved PO
[ https://issues.apache.org/jira/browse/OFBIZ-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16177735#comment-16177735 ] Swapnil Shah commented on OFBIZ-7183: - [~jacques.le.roux] Done !! > Completed Service Order Items are being allowed to be received along with > finished goods over Approved PO > -- > > Key: OFBIZ-7183 > URL: https://issues.apache.org/jira/browse/OFBIZ-7183 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Upcoming Release >Reporter: Swapnil Shah >Assignee: Ankush Upadhyay > Attachments: COMP_REC_1.png > > > Whenever a PO has both service type and finished good products then order > items having service type products get completed on Order approval itself. > But when such PO is received the service type items (despite being completed) > are listed along with finished goods to be received and eventually get > received as well if done so. > We could try preventing service type items to be listed like we do for any > regular finished good items when they get completed. > Please refer to attached screenshot for reference. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-7714) Introduce a quick way for adding Purchase Price agreements with Suppliers for any specific product from Catalog
[ https://issues.apache.org/jira/browse/OFBIZ-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reassigned OFBIZ-7714: --- Assignee: (was: Swapnil Shah) > Introduce a quick way for adding Purchase Price agreements with Suppliers for > any specific product from Catalog > --- > > Key: OFBIZ-7714 > URL: https://issues.apache.org/jira/browse/OFBIZ-7714 > Project: OFBiz > Issue Type: New Feature > Components: product >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah > Attachments: PPA.png > > > Currently new pricing agreements creation takes user to Accounting app where > it is quite an long and arduous process. And many a times a buyer or > procurement users doesn't have direct accounting permission in case quick > pricing agreement needs to be placed with Supplier for specific product(s). > We can provide a quick option from Catalog >> Product >> Agreement screen > over "Purchase" section that could unfold as follows: > # Have a 'Create Price Agreement' link/button on the 'Purchases' Panel and > hitting this link could ask user to enter following very basic parameters: > #- Party Id From (Default it to facility's owner party id) > #- Party Id To (show list of suppliers like we show at the time of Purchase > Order entry screen) > #- From Date (default it to show as now() timestamp) > #- Through Date > #- Description > #- Price > #- Currency > #- Supplier Product Id > # Upon successful submission of above details system should create Agreement > and AgreementItem & SupplierProduct between Supplier and organization by > passing following default values: > #- Role Type Id From = 'Internal Organization' > #- Role Type Id To = ''Supplier" > #- Agreement Type Id = 'Purchase' > #- Agreement Item Type Id = 'Pricing' > #- Product Id= '' > Please refer to attached screenshot for reference placeholder > !PPA.png|thumbnail! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-7377) Introduce the option for specifying Check (Reference) Number upon using Check as payment method during ordering
[ https://issues.apache.org/jira/browse/OFBIZ-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reassigned OFBIZ-7377: --- Assignee: (was: Swapnil Shah) > Introduce the option for specifying Check (Reference) Number upon using Check > as payment method during ordering > --- > > Key: OFBIZ-7377 > URL: https://issues.apache.org/jira/browse/OFBIZ-7377 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Trunk >Reporter: Swapnil Shah > Attachments: OrdPmt.png > > > Currently there is no option during ordering to specify the actual Check > Number that could be used for making payment upon selecting Check as payment > method. > We could provide a text entry box for recording check number and same could > be set as Payment.PaymentRefNumber upon order creation. > Please refer to attached screenshot -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-7183) Completed Service Order Items are being allowed to be received along with finished goods over Approved PO
[ https://issues.apache.org/jira/browse/OFBIZ-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reassigned OFBIZ-7183: --- Assignee: (was: Divesh Dutta) > Completed Service Order Items are being allowed to be received along with > finished goods over Approved PO > -- > > Key: OFBIZ-7183 > URL: https://issues.apache.org/jira/browse/OFBIZ-7183 > Project: OFBiz > Issue Type: Improvement > Components: order >Reporter: Swapnil Shah > Attachments: COMP_REC_1.png > > > Whenever a PO has both service type and finished good products then order > items having service type products get completed on Order approval itself. > But when such PO is received the service type items (despite being completed) > are listed along with finished goods to be received and eventually get > received as well if done so. > We could try preventing service type items to be listed like we do for any > regular finished good items when they get completed. > Please refer to attached screenshot for reference. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-7607) Promotions Shouldn't get auto-applied when "Sales/Price Agreement" is in force on sales order
[ https://issues.apache.org/jira/browse/OFBIZ-7607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reassigned OFBIZ-7607: --- Assignee: (was: Swapnil Shah) > Promotions Shouldn't get auto-applied when "Sales/Price Agreement" is in > force on sales order > - > > Key: OFBIZ-7607 > URL: https://issues.apache.org/jira/browse/OFBIZ-7607 > Project: OFBiz > Issue Type: New Feature > Components: order >Affects Versions: 14.12.01, 15.12.01 >Reporter: Swapnil Shah > Attachments: PA_1.png, PA_2.png, PA_3.png > > > More often than not if any sales(price) agreement with customer on any > product is in play on any order then other active promotions/discounts/price > rules (which are supposed to get auto-applied on List/Default price on any > normal order) should take back seat unless specified otherwise. > Currently, it seems to be happening otherwise, all the normal > adjustments/discounts gets activated on Agreement Price itself (that are > supposed to be applied on List/Default prices) whenever agreement is > enforced while placing the sales order. > Even if we need to do so, it could be allowed to be done on case by case > basis as follows: > *Proposed solution:* > # Let's add the flag (checkbox) on screen Order Entry where any active > agreements is allowed to be selected with label "Apply Active Promotions" > ## If above flag is not checked, then order should be placed only and only > with prices set on selected active agreement > ## If above flag is checked then as its happening currently, do apply all > active promotions/discounts/rules on agreement prices. > ## By default the flag should remain unchecked, so it gets activated only if > user specially select it to give other promotions on such order and it > doesn't happen inadvertently. > Please refer to attached screenshot for references. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-8014) Introduce the "Product" Screen under Party app to manage the products supplied by any supplier
[ https://issues.apache.org/jira/browse/OFBIZ-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reassigned OFBIZ-8014: --- Assignee: (was: Swapnil Shah) > Introduce the "Product" Screen under Party app to manage the products > supplied by any supplier > -- > > Key: OFBIZ-8014 > URL: https://issues.apache.org/jira/browse/OFBIZ-8014 > Project: OFBiz > Issue Type: New Feature >Affects Versions: Release Branch 14.12, 16.11.01, Release Branch 15.12 >Reporter: Swapnil Shah > Attachments: SupplierProduct.png > > > Currently, upon logging into the Party application (or login as supplier > itself) and go to any specific supplier view then there is no way to manage > the list of supplied products. > # We can try introducing the "Product" tab/screen along with other tabs. (to > begin with we can simply mimic the Supplier screen from Catalog app e.g., > https://ofbiz-vm.apache.org:8443/catalog/control/EditProductSuppliers?productId=MAT_A_COST) > > # We can also choose to show the "Products" tab for only Parties in supplier > role and later can try to extend for other roles with further needed > refinements. > Please refer to attached screenshot for the same. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-7610) Product Price set based on 'Purchase Price Agreement' isn't honored while same is used during ordering
[ https://issues.apache.org/jira/browse/OFBIZ-7610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah reassigned OFBIZ-7610: --- Assignee: (was: Swapnil Shah) > Product Price set based on 'Purchase Price Agreement' isn't honored while > same is used during ordering > -- > > Key: OFBIZ-7610 > URL: https://issues.apache.org/jira/browse/OFBIZ-7610 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Swapnil Shah > Attachments: SA_1.png, SA_2.png, SA_3.png, SA_4.png, SA_5.png > > > Once any Purchase Agreement is created with supplier for certain products at > pre-determined price, its get successfully transformed into SupplierProduct. > But at the time of Purchase order creation is same agreement is enforced then > agreement prices for products are ignored while setting the price on cart and > eventually on order itself. > Please refer to attached screenshot for reference. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-7356) OFBIZ-6964: Document finalized design to support replenishment planning through any inter-company facility
[
https://issues.apache.org/jira/browse/OFBIZ-7356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134415#comment-16134415
]
Swapnil Shah commented on OFBIZ-7356:
-
The initial rational for keeping RMEI at ProductStoreFacilty level was
basically to allow the system to set the replenishment policy at store level in
coherence with real time business practices. Many a times its possible that
multiple stores are served by same primary facility (which can be defined
using ProductStore) and possibly setting RMEI at ProductFacility would
implicitly end up apply the same replenishment policy for all linked stores.
One such typical scenarios that could be pretty common is that replenishment
for certain Product are part of DSD arrangement at certain store whereas it
could be replenished via intra company transfers for other stores due to
different logistical & other factors.
The purpose of introducing PFA (ProductFacilityAssoc) was to support multiple
bill of distributions eventually (and as of now business can live by just
setting and limiting it for the products that are eligible for intra-company
transfers) as most of the design and algorithm revolves around it. Any kind of
data delinquency might lead to inaccurate planning.
> 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
[jira] [Commented] (OFBIZ-10372) Caculate estimated shipment delivery time
[
https://issues.apache.org/jira/browse/OFBIZ-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16457491#comment-16457491
]
Swapnil Shah commented on OFBIZ-10372:
--
As we are dealing it on Time dimension, it would be worthwhile to make it honor
the working (or holiday) calendars at shipper's or shipping carrier's or for
that matter even at receiver's end. For instance many a times there may be
fixed working days/hours to dispatch the goods from shipper's end or to pick up
the shipments at carrier's end or to receive the goods at receiver's end. In
such cases promising Est. Delivery Date (EDD) merely based on lead time may not
be so accurate.
Currently one of possible ways to manage calendars could be using
CustomTimePeriod, if that is trun then 'ShipmentTimeEstimate' can be extended
by adding the 'customTimePeriodId' and enahance the code to honor it as well
while deriving EDD.
> Caculate estimated shipment delivery time
> -
>
> Key: OFBIZ-10372
> URL: https://issues.apache.org/jira/browse/OFBIZ-10372
> Project: OFBiz
> Issue Type: New Feature
> Components: order
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>Priority: Major
> Labels: order, shipment, time
> Attachments: OFBIZ-10372.patch
>
>
> Currently when you pass an order in ofbiz you can select the shipment method
> to delivery finish good and obtains an amount cost but you have nothing to
> indicate how the delivration will during.
> We have a good example with ship by plane or boat and for road the time is
> different between the Portugal to Spain and Portugal to Slovenia.
> With this information, we can planned the estimated delivery date with the
> estimated date to produce finish good and the time to delivery them
> To fill this gap, we introduce a new entity ShipmentTimeEstimate modelled as
> ShipmentCostEstimate to define the estimated time for a shipment method, a
> carrier and two geo location:
> {code:java}
> package-name="org.apache.ofbiz.shipment.shipment"
> title="Shipment Time Estimation Entity">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ...
> {code}
> We have two asks related to this issue on users
> [1|https://lists.apache.org/thread.html/de58aa36744804c28eccef6fc7ebc8f0311f65b0dc6b17f1fa5234d4@%3Cuser.ofbiz.apache.org%3E]
>
> [2|https://lists.apache.org/thread.html/1d79dd9f42fc256e5986271e9e0447bde2980bf0310c4b5f04a35e9f@%3Cuser.ofbiz.apache.org%3E]
>
> The first patch made in collaboration with Leila Mekika lays bricks to
> implement this idea
> All remark and suggest are welcome to continue it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10372) Calculate estimated shipment delivery time
[
https://issues.apache.org/jira/browse/OFBIZ-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Shah updated OFBIZ-10372:
-
Summary: Calculate estimated shipment delivery time (was: Caculate
estimated shipment delivery time)
> Calculate estimated shipment delivery time
> --
>
> Key: OFBIZ-10372
> URL: https://issues.apache.org/jira/browse/OFBIZ-10372
> Project: OFBiz
> Issue Type: New Feature
> Components: order
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>Priority: Major
> Labels: order, shipment, time
> Attachments: OFBIZ-10372.patch
>
>
> Currently when you pass an order in ofbiz you can select the shipment method
> to delivery finish good and obtains an amount cost but you have nothing to
> indicate how the delivration will during.
> We have a good example with ship by plane or boat and for road the time is
> different between the Portugal to Spain and Portugal to Slovenia.
> With this information, we can planned the estimated delivery date with the
> estimated date to produce finish good and the time to delivery them
> To fill this gap, we introduce a new entity ShipmentTimeEstimate modelled as
> ShipmentCostEstimate to define the estimated time for a shipment method, a
> carrier and two geo location:
> {code:java}
> package-name="org.apache.ofbiz.shipment.shipment"
> title="Shipment Time Estimation Entity">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ...
> {code}
> We have two asks related to this issue on users
> [1|https://lists.apache.org/thread.html/de58aa36744804c28eccef6fc7ebc8f0311f65b0dc6b17f1fa5234d4@%3Cuser.ofbiz.apache.org%3E]
>
> [2|https://lists.apache.org/thread.html/1d79dd9f42fc256e5986271e9e0447bde2980bf0310c4b5f04a35e9f@%3Cuser.ofbiz.apache.org%3E]
>
> The first patch made in collaboration with Leila Mekika lays bricks to
> implement this idea
> All remark and suggest are welcome to continue it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10372) Calculate estimated shipment delivery time
[
https://issues.apache.org/jira/browse/OFBIZ-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16457491#comment-16457491
]
Swapnil Shah edited comment on OFBIZ-10372 at 4/28/18 9:35 AM:
---
As we are dealing it on Time dimension, it would be worthwhile to make it honor
the working (or holiday) calendars at shipper's or shipping carrier's or for
that matter even at receiver's end. For instance many a times there may be
fixed working days/hours to dispatch the goods from shipper's end or to pick up
the shipments at carrier's end or to receive the goods at receiver's end. In
such cases promising Est. Delivery Date (EDD) merely based on lead time may not
be so accurate.
Currently one of possible ways to manage calendars could be using
CustomTimePeriod, if that is true then 'ShipmentTimeEstimate' can be extended
by adding the 'customTimePeriodId' and enahance the code to honor it as well
while deriving EDD.
was (Author: swash78):
As we are dealing it on Time dimension, it would be worthwhile to make it honor
the working (or holiday) calendars at shipper's or shipping carrier's or for
that matter even at receiver's end. For instance many a times there may be
fixed working days/hours to dispatch the goods from shipper's end or to pick up
the shipments at carrier's end or to receive the goods at receiver's end. In
such cases promising Est. Delivery Date (EDD) merely based on lead time may not
be so accurate.
Currently one of possible ways to manage calendars could be using
CustomTimePeriod, if that is trun then 'ShipmentTimeEstimate' can be extended
by adding the 'customTimePeriodId' and enahance the code to honor it as well
while deriving EDD.
> Calculate estimated shipment delivery time
> --
>
> Key: OFBIZ-10372
> URL: https://issues.apache.org/jira/browse/OFBIZ-10372
> Project: OFBiz
> Issue Type: New Feature
> Components: order
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>Priority: Major
> Labels: order, shipment, time
> Attachments: OFBIZ-10372.patch
>
>
> Currently when you pass an order in ofbiz you can select the shipment method
> to delivery finish good and obtains an amount cost but you have nothing to
> indicate how the delivration will during.
> We have a good example with ship by plane or boat and for road the time is
> different between the Portugal to Spain and Portugal to Slovenia.
> With this information, we can planned the estimated delivery date with the
> estimated date to produce finish good and the time to delivery them
> To fill this gap, we introduce a new entity ShipmentTimeEstimate modelled as
> ShipmentCostEstimate to define the estimated time for a shipment method, a
> carrier and two geo location:
> {code:java}
> package-name="org.apache.ofbiz.shipment.shipment"
> title="Shipment Time Estimation Entity">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ...
> {code}
> We have two asks related to this issue on users
> [1|https://lists.apache.org/thread.html/de58aa36744804c28eccef6fc7ebc8f0311f65b0dc6b17f1fa5234d4@%3Cuser.ofbiz.apache.org%3E]
>
> [2|https://lists.apache.org/thread.html/1d79dd9f42fc256e5986271e9e0447bde2980bf0310c4b5f04a35e9f@%3Cuser.ofbiz.apache.org%3E]
>
> The first patch made in collaboration with Leila Mekika lays bricks to
> implement this idea
> All remark and suggest are welcome to continue it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-9744) Inventory count is not updating correctly.
[ https://issues.apache.org/jira/browse/OFBIZ-9744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223278#comment-16223278 ] Swapnil Shah commented on OFBIZ-9744: - Thanks [~tejas.khanna] for reporting and [~ankush.upadhyay] for validating. I did try to replicate it but could no longer reproduce it, We can close it for now. > Inventory count is not updating correctly. > -- > > Key: OFBIZ-9744 > URL: https://issues.apache.org/jira/browse/OFBIZ-9744 > Project: OFBiz > Issue Type: Bug > Components: hhfacility > Environment: > https://demo-trunk.ofbiz.apache.org/accounting/control/InventoryValuation >Reporter: Tejas Khanna >Assignee: Ankush Upadhyay > Attachments: IV report 1.png, IV report 2.png, InventoryItems.png, > InventoryValuationOnCurrentDate.png, InventoryValuationOnPreviousDate.png > > > Steps to reproduce: > 1. Place purchase order with some quantities. > 2. Receive and complete the invoice of purchase order. > 3. Check the Inventory count and its respective valuation in Inventory > Valuation report. > Actual Behavior: > Inventory count is not updating in Inventory Valuation Report. > Expected result: > Inventory count should update in report. Also, the valuation should get > change. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-10986) Have a Store Dimension
[ https://issues.apache.org/jira/browse/OFBIZ-10986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16851770#comment-16851770 ] Swapnil Shah commented on OFBIZ-10986: -- Is it eventually going to be associated with Sales Channel dimension. > Have a Store Dimension > -- > > Key: OFBIZ-10986 > URL: https://issues.apache.org/jira/browse/OFBIZ-10986 > Project: OFBiz > Issue Type: Improvement > Components: bi >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Labels: StoreDimension, birt, dimension, dwh, store > Attachments: OFBIZ-10986-StoreDimension.patch > > > The component would benefit from a store dimension for future fact tables and > star schema view entities. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-11051) Have a TimeEntryFact entity
[ https://issues.apache.org/jira/browse/OFBIZ-11051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846949#comment-16846949 ] Swapnil Shah commented on OFBIZ-11051: -- Would it help elaborating the context in which its going to be used. > Have a TimeEntryFact entity > --- > > Key: OFBIZ-11051 > URL: https://issues.apache.org/jira/browse/OFBIZ-11051 > Project: OFBiz > Issue Type: Improvement > Components: bi >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Labels: Fact, TimeEntry, TimeEntryFact, birt, dwh, timesheet > > Have a TimeEntryFact entity -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10990) Improve the SalesInvoiceItemStarSchema
[
https://issues.apache.org/jira/browse/OFBIZ-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829158#comment-16829158
]
Swapnil Shah commented on OFBIZ-10990:
--
{quote}
Regarding the other points:
{noformat}
Product Dimesion - Can help in getting the Brand, Style, Assortments, Component
level info for different views.{noformat}
For sure we can add more dimensions (like the ones suggested). The thing to
keep in mind here is whether a product can be sold under different brands,
styles, etc) or not. I don't think we can dictate one approach here, but we
have to start somewhere. And - as always - our adopters can (and will) extend
entity-packages and individual entities as they see fit.
{quote}
Here didn't mean to necessarily add the new dimensions for
Brand/Style/Assortment etc. We could rather consider them as different possible
views out of Product Dimension itself (as the above mentioned details can be
very well captured through it at product level). For example. a sales managers
who may like to track the sales performance for products by Brands.or by Style
can possibly do so by traversing through the product dimension itself.
> Improve the SalesInvoiceItemStarSchema
> --
>
> Key: OFBIZ-10990
> URL: https://issues.apache.org/jira/browse/OFBIZ-10990
> Project: OFBiz
> Issue Type: Improvement
> Components: bi
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Pierre Smits
>Priority: Major
> Labels: birt, dwh
>
> The star schema should be improved to include elements from:
> * Customer dimension
> * Country dimension
> * Store dimension
> * Catalog dimension
> * Channel dimension
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10990) Improve the SalesInvoiceItemStarSchema
[
https://issues.apache.org/jira/browse/OFBIZ-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829196#comment-16829196
]
Swapnil Shah edited comment on OFBIZ-10990 at 4/29/19 12:19 PM:
{quote}..But where should the style and assortment come from? Can you reference
entities from [https://demo-trunk.ofbiz.apache.org/webtools/control/entityref]
? That will give a clue regarding determining what is achievable.
{quote}
I think we usually model and identify the styles and assortment through
virtual/variant pairing via ProductAssoc
[https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=ProductAssoc]
(where productAssocTypeId='PRODUCT_VARIANT'). Here the virtual product could
contain the styles and all the variants (based on their standard features i.e.
Size/Color/Taste/Material etc.) as assortment. e.g,
https://demo-trunk.ofbiz.apache.org/catalog/control/EditProductAssoc?productId=SAUCE
[https://demo-trunk.ofbiz.apache.org/catalog/control/EditProductAssoc?productId=GZ-1006]
was (Author: swash78):
{quote}
..But where should the style and assortment come from? Can you reference
entities from [https://demo-trunk.ofbiz.apache.org/webtools/control/entityref]
? That will give a clue regarding determining what is achievable.
{quote}
I think we usually model and identify the styles and assortment through
virtual/variant pairing via ProductAssoc
[https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=ProductAssoc]
(where productAssocTypeId='PRODUCT_VARIANT'). Here the virtual product could
contain the styles and all the variants (based on their standard features i.e.
Size/Color/Taste/Material etc.) as assortment. e.g,
[https://demo-trunk.ofbiz.apache.org/catalog/control/EditProductAssoc?productId=SAUCE
]
[https://demo-trunk.ofbiz.apache.org/catalog/control/EditProductAssoc?productId=GZ-1006]
> Improve the SalesInvoiceItemStarSchema
> --
>
> Key: OFBIZ-10990
> URL: https://issues.apache.org/jira/browse/OFBIZ-10990
> Project: OFBiz
> Issue Type: Improvement
> Components: bi
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Pierre Smits
>Priority: Major
> Labels: birt, dwh
>
> The star schema should be improved to include elements from:
> * Customer dimension
> * Country dimension
> * Store dimension
> * Catalog dimension
> * Channel dimension
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10990) Improve the SalesInvoiceItemStarSchema
[
https://issues.apache.org/jira/browse/OFBIZ-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829196#comment-16829196
]
Swapnil Shah commented on OFBIZ-10990:
--
{quote}
..But where should the style and assortment come from? Can you reference
entities from [https://demo-trunk.ofbiz.apache.org/webtools/control/entityref]
? That will give a clue regarding determining what is achievable.
{quote}
I think we usually model and identify the styles and assortment through
virtual/variant pairing via ProductAssoc
[https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=ProductAssoc]
(where productAssocTypeId='PRODUCT_VARIANT'). Here the virtual product could
contain the styles and all the variants (based on their standard features i.e.
Size/Color/Taste/Material etc.) as assortment. e.g,
[https://demo-trunk.ofbiz.apache.org/catalog/control/EditProductAssoc?productId=SAUCE
]
[https://demo-trunk.ofbiz.apache.org/catalog/control/EditProductAssoc?productId=GZ-1006]
> Improve the SalesInvoiceItemStarSchema
> --
>
> Key: OFBIZ-10990
> URL: https://issues.apache.org/jira/browse/OFBIZ-10990
> Project: OFBiz
> Issue Type: Improvement
> Components: bi
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Pierre Smits
>Priority: Major
> Labels: birt, dwh
>
> The star schema should be improved to include elements from:
> * Customer dimension
> * Country dimension
> * Store dimension
> * Catalog dimension
> * Channel dimension
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10990) Improve the SalesInvoiceItemStarSchema
[
https://issues.apache.org/jira/browse/OFBIZ-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829184#comment-16829184
]
Swapnil Shah commented on OFBIZ-10990:
--
{quote}
{noformat}
Time Dimension - can help in getting financial/merchandising calendars with
Years, Season, quarters, weeks , days etc. for different views. {noformat}
We already have a date dimension catering for year, week, days. This dimension
can, of course, be extended with missing elements (like season, trimesters,
etc.)
As for time. yes we can add a static time dimension having are all time
increments between 00:00:00 and 23:59:59. If only using the minute
discriminator this would be a table consisting of 1440 records.
Businesses are not that much interested in sales/purchases/etc. per second,
whereas IT more often is (transactions per second), but at least the time
dimension will allow doing that in fact tables and star schemas. Businesses are
interested in stuff like: how do our sales in the morning compare to sales in
the afternoon, and how do our morning sales trend over time
I will add a new ticket for this.
{quote}
If we already have Date Dimension then i guess no need to add new Time
Dimension (if needed this itself can be relablled as Time Dimension). Later, if
required can add 'Hour' as next granular level below Date in it.
> Improve the SalesInvoiceItemStarSchema
> --
>
> Key: OFBIZ-10990
> URL: https://issues.apache.org/jira/browse/OFBIZ-10990
> Project: OFBiz
> Issue Type: Improvement
> Components: bi
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Pierre Smits
>Priority: Major
> Labels: birt, dwh
>
> The star schema should be improved to include elements from:
> * Customer dimension
> * Country dimension
> * Store dimension
> * Catalog dimension
> * Channel dimension
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10990) Improve the SalesInvoiceItemStarSchema
[
https://issues.apache.org/jira/browse/OFBIZ-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829210#comment-16829210
]
Swapnil Shah commented on OFBIZ-10990:
--
{quote}
My point being: why not bring it back in the olap db to one single entity that
is commonly understood, because most elements are hierarchical to the country?
{quote}
I would not be very particular about naming convention at this point of time as
long as we are able to capture the market segmentation based on the different
geographies. For a typical global business, the sales hierarchy based on the
geographic market segmentation might even start from above the country level
like APAC,EMEA,AMER etc. and goes down till City or zip code level.
> Improve the SalesInvoiceItemStarSchema
> --
>
> Key: OFBIZ-10990
> URL: https://issues.apache.org/jira/browse/OFBIZ-10990
> Project: OFBiz
> Issue Type: Improvement
> Components: bi
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Pierre Smits
>Priority: Major
> Labels: birt, dwh
>
> The star schema should be improved to include elements from:
> * Customer dimension
> * Country dimension
> * Store dimension
> * Catalog dimension
> * Channel dimension
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10990) Improve the SalesInvoiceItemStarSchema
[ https://issues.apache.org/jira/browse/OFBIZ-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829976#comment-16829976 ] Swapnil Shah commented on OFBIZ-10990: -- I am not sure if i would be able to browse through all the tix history anytime soon. Please feel free to ignore and move on if raised issues are already being handled one way or other. I just happened to stumble upon this ticket and shared few thoughts from the targetted end user perspective on BI and reporting . > Improve the SalesInvoiceItemStarSchema > -- > > Key: OFBIZ-10990 > URL: https://issues.apache.org/jira/browse/OFBIZ-10990 > Project: OFBiz > Issue Type: Improvement > Components: bi >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Pierre Smits >Priority: Major > Labels: birt, dwh > > The star schema should be improved to include elements from: > * Customer dimension > * Country dimension > * Store dimension > * Catalog dimension > * Channel dimension -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10990) Improve the SalesInvoiceItemStarSchema
[ https://issues.apache.org/jira/browse/OFBIZ-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16828878#comment-16828878 ] Swapnil Shah commented on OFBIZ-10990: -- How about renaming Country Dimension as 'Geographic(Geo) Dimension' to make it more generic and let there be multiple level underneath it to define Country/Region/Territory/States/City etc.as per the sales org structuring. > Improve the SalesInvoiceItemStarSchema > -- > > Key: OFBIZ-10990 > URL: https://issues.apache.org/jira/browse/OFBIZ-10990 > Project: OFBiz > Issue Type: Improvement > Components: bi >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Pierre Smits >Priority: Major > Labels: birt, dwh > > The star schema should be improved to include elements from: > * Customer dimension > * Country dimension > * Store dimension > * Catalog dimension > * Channel dimension -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10990) Improve the SalesInvoiceItemStarSchema
[ https://issues.apache.org/jira/browse/OFBIZ-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16828881#comment-16828881 ] Swapnil Shah commented on OFBIZ-10990: -- Can we also try to add followng more dimensions as well (if not done already): : * *Product Dimesion* - Can help in getting the Brand, Style, Assortments, Component level info for different views. * *Time Dimension* - can help in getting financial/merchandising calendars with Years, Season, quarters, weeks , days etc. for different views. * *Supplier Dimension* - can help in getting Supplier, Vendors or any other product sourcing agency info for different views. > Improve the SalesInvoiceItemStarSchema > -- > > Key: OFBIZ-10990 > URL: https://issues.apache.org/jira/browse/OFBIZ-10990 > Project: OFBiz > Issue Type: Improvement > Components: bi >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Pierre Smits >Priority: Major > Labels: birt, dwh > > The star schema should be improved to include elements from: > * Customer dimension > * Country dimension > * Store dimension > * Catalog dimension > * Channel dimension -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10990) Improve the SalesInvoiceItemStarSchema
[ https://issues.apache.org/jira/browse/OFBIZ-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16828881#comment-16828881 ] Swapnil Shah edited comment on OFBIZ-10990 at 4/29/19 3:40 AM: --- Can we try to add followng more dimensions as well (if not done already): : * *Product Dimesion* - Can help in getting the Brand, Style, Assortments, Component level info for different views. * *Time Dimension* - can help in getting financial/merchandising calendars with Years, Season, quarters, weeks , days etc. for different views. * *Supplier Dimension* - can help in getting Supplier, Vendors or any other product sourcing agency info for different views. was (Author: swash78): Can we also try to add followng more dimensions as well (if not done already): : * *Product Dimesion* - Can help in getting the Brand, Style, Assortments, Component level info for different views. * *Time Dimension* - can help in getting financial/merchandising calendars with Years, Season, quarters, weeks , days etc. for different views. * *Supplier Dimension* - can help in getting Supplier, Vendors or any other product sourcing agency info for different views. > Improve the SalesInvoiceItemStarSchema > -- > > Key: OFBIZ-10990 > URL: https://issues.apache.org/jira/browse/OFBIZ-10990 > Project: OFBiz > Issue Type: Improvement > Components: bi >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Pierre Smits >Priority: Major > Labels: birt, dwh > > The star schema should be improved to include elements from: > * Customer dimension > * Country dimension > * Store dimension > * Catalog dimension > * Channel dimension -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-11012) Documentation: SalesInvoiceItemStarSchema Design Updates
[ https://issues.apache.org/jira/browse/OFBIZ-11012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-11012: - Issue Type: Task (was: Bug) > Documentation: SalesInvoiceItemStarSchema Design Updates > > > Key: OFBIZ-11012 > URL: https://issues.apache.org/jira/browse/OFBIZ-11012 > Project: OFBiz > Issue Type: Task > Components: bi >Reporter: Swapnil Shah >Priority: Major > Labels: birt, dwh > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-11012) Documentation: SalesInvoiceItemStarSchema Design Updates
Swapnil Shah created OFBIZ-11012: Summary: Documentation: SalesInvoiceItemStarSchema Design Updates Key: OFBIZ-11012 URL: https://issues.apache.org/jira/browse/OFBIZ-11012 Project: OFBiz Issue Type: Bug Components: bi Reporter: Swapnil Shah -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-11457) Expected arrival of Incoming Shipment needs to be reflected over back-order
Swapnil Shah created OFBIZ-11457: Summary: Expected arrival of Incoming Shipment needs to be reflected over back-order Key: OFBIZ-11457 URL: https://issues.apache.org/jira/browse/OFBIZ-11457 Project: OFBiz Issue Type: New Feature Components: order Affects Versions: 17.12.02 Reporter: Swapnil Shah *Business Case* Many a times its required to promise the delivery date to customers for her sales orders that are back-order (BO) based on the expected arrival of future incoming/purchase shipments. Currently its not possible without either manually pegging the supply to demand or running the whole MRP engine. *Possible Solution* To solve for this problem on real time basis, the Reservation flow can be leveraged as that makes the determination whether the punched in sales order (or demand for production run for that matter) is going to be backordered or not. If and when there is SHIPMENT.ESTIMATED_ARRIVAL_DATE available against the scheduled or incoming receipts in the system say with SHIPMENT_TYPE_ID=PURCHASE_SHIPMENT (or INCOMING_SHIPMENT) then the reservation or post-reservation run can be triggered to peg and allocate the expected shipment volume to backorders on FIFO basis and inherit the earliest SHIPMENT.ESTIMATED_ARRIVAL_DATE over ORDER_ITEM_SHIP_GRP_INV_RES.PROMISED_DATETIME which can be promised and communicated to customer. *Use Cases* 1. Product GZ-2644 has 50 units backordered across 2 sales order placed on different dates: ORDER_1 : Placed as BO on 01/01/2020 with Order Qty = 30 units with all units backordered ORDER_2 : Placed as BO on 01/03/2020 with Order Qty = 20 units with all units backordered Two Shipments for Product GZ-2644 scheduled to arrive on different dates as follows: SHIPMENT_1 : Estimated Arrival Date on 01/25/2020 with Qty=20 units SHIPMENT_2 : Estimated Arrival Date on 01/31/2020 with Qty=40 units _*Expected Result*_ Upon reservation, here is how they would get their promised date: ORDER_1: Although its pegged to both the shipment (i.e., 20 units from SHIPMENT_1 and 10 units from SHIPMENT_2) but gets the Promise Date of 01/25/2020 (as shortness takes precedence over lateness) ORDER_2: It gets pegged to second shipment (20 units from SHIPMENT_2) and gets the Promise Date of 01/31/2020 2. Product GZ-2644 has 50 units backordered across 2 sales order placed on different dates but also has Safety Stock threshold of 30 units to be maintained: ORDER_1 : Placed as BO on 01/01/2020 with Order Qty = 30 units with all units backordered ORDER_2 : Placed as BO on 01/03/2020 with Order Qty = 20 units with all units backordered Two Shipments for Product GZ-2644 scheduled to arrive on different dates as follows: SHIPMENT_1 : Estimated Arrival Date on 01/25/2020 with Qty=20 units SHIPMENT_2 : Estimated Arrival Date on 01/31/2020 with Qty=40 units _*Expected Result*_ Upon reservation, here is how they would get their promised date: ORDER_1: After allocating 30 units for Safety Stock (i,e., 20 units from SHIPMENT_1 and 10 units from SHIPMENT_2), its pegged to the second shipment (i.e., 20 units left from SHIPMENT_2) and gets the Promise Date of 01/31/2020 (as Safety Stock takes precedence over sales orders) ORDER_2: It gets no shipment left to peg to and hence no promised date or can be defaulted based on average lead time from supplier. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11457) Expected arrival of Incoming Shipment needs to be reflected over back-order
[ https://issues.apache.org/jira/browse/OFBIZ-11457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-11457: - Affects Version/s: (was: 17.12.02) > Expected arrival of Incoming Shipment needs to be reflected over back-order > --- > > Key: OFBIZ-11457 > URL: https://issues.apache.org/jira/browse/OFBIZ-11457 > Project: OFBiz > Issue Type: New Feature > Components: order >Reporter: Swapnil Shah >Priority: Major > Fix For: Upcoming Branch > > > *Business Case* > Many a times its required to promise the delivery date to customers for her > sales orders that are back-order (BO) based on the expected arrival of future > incoming/purchase shipments. Currently its not possible without either > manually pegging the supply to demand or having the MRP run. > *Scope* > The scope of demand versus supply pegging is limited to purchase shipments > only assuming that shipment data would be synced back in Ofbiz and > procurement/replenishment would be external to OFbiz universe. If that is not > the case then MRP run might be preferred way to achieve the same. > *Possible Solution* > To solve for this problem on real time basis, the Reservation flow can be > leveraged as that makes the determination whether the punched in sales order > (or demand for production run for that matter) is going to be backordered or > not. > If and when there is SHIPMENT.ESTIMATED_ARRIVAL_DATE available against the > scheduled or incoming receipts in the system say with > SHIPMENT_TYPE_ID=PURCHASE_SHIPMENT (or INCOMING_SHIPMENT) then the > reservation or post-reservation run can be triggered to peg and allocate the > expected shipment volume to backorders on FIFO basis and inherit the earliest > SHIPMENT.ESTIMATED_ARRIVAL_DATE over > ORDER_ITEM_SHIP_GRP_INV_RES.PROMISED_DATETIME which can be promised and > communicated to customer. > *Use Cases* > 1. Product GZ-2644 has 50 units backordered across 2 sales order placed on > different dates: > ORDER_1 : Placed as BO on 01/01/2020 with Order Qty = 30 units with all > units backordered > ORDER_2 : Placed as BO on 01/03/2020 with Order Qty = 20 units with all > units backordered > Two Shipments for Product GZ-2644 scheduled to arrive on different dates as > follows: > SHIPMENT_1 : Estimated Arrival Date on 01/25/2020 with Qty=20 units > SHIPMENT_2 : Estimated Arrival Date on 01/31/2020 with Qty=40 units > _*Expected Result*_ > Upon reservation, here is how they would get their promised date: > ORDER_1: Although its pegged to both the shipment (i.e., 20 units from > SHIPMENT_1 and 10 units from SHIPMENT_2) but gets the Promise Date of > 01/25/2020 (as shortness takes precedence over lateness) > ORDER_2: It gets pegged to second shipment (20 units from SHIPMENT_2) and > gets the Promise Date of 01/31/2020 > 2. Product GZ-2644 has 50 units backordered across 2 sales order placed on > different dates but also has Safety Stock threshold of 30 units to be > maintained: > ORDER_1 : Placed as BO on 01/01/2020 with Order Qty = 30 units with all > units backordered > ORDER_2 : Placed as BO on 01/03/2020 with Order Qty = 20 units with all > units backordered > Two Shipments for Product GZ-2644 scheduled to arrive on different dates as > follows: > SHIPMENT_1 : Estimated Arrival Date on 01/25/2020 with Qty=20 units > SHIPMENT_2 : Estimated Arrival Date on 01/31/2020 with Qty=40 units > _*Expected Result*_ > Upon reservation, here is how they would get their promised date: > ORDER_1: After allocating 30 units for Safety Stock (i,e., 20 units from > SHIPMENT_1 and 10 units from SHIPMENT_2), its pegged to the second shipment > (i.e., 20 units left from SHIPMENT_2) and gets the Promise Date of 01/31/2020 > (as Safety Stock takes precedence over sales orders) > ORDER_2: It gets no shipment left to peg to and hence no promised date or > can be defaulted based on average lead time from supplier. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11457) Expected arrival of Incoming Shipment needs to be reflected over back-order
[ https://issues.apache.org/jira/browse/OFBIZ-11457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-11457: - Description: *Business Case* Many a times its required to promise the delivery date to customers for her sales orders that are back-order (BO) based on the expected arrival of future incoming/purchase shipments. Currently its not possible without either manually pegging the supply to demand or having the MRP run. *Scope* The scope of demand versus supply pegging is limited to purchase shipments only assuming that shipment data would be synced back in Ofbiz and procurement/replenishment would be external to OFbiz universe. If that is not the case then MRP run might be preferred way to achieve the same. *Possible Solution* To solve for this problem on real time basis, the Reservation flow can be leveraged as that makes the determination whether the punched in sales order (or demand for production run for that matter) is going to be backordered or not. If and when there is SHIPMENT.ESTIMATED_ARRIVAL_DATE available against the scheduled or incoming receipts in the system say with SHIPMENT_TYPE_ID=PURCHASE_SHIPMENT (or INCOMING_SHIPMENT) then the reservation or post-reservation run can be triggered to peg and allocate the expected shipment volume to backorders on FIFO basis and inherit the earliest SHIPMENT.ESTIMATED_ARRIVAL_DATE over ORDER_ITEM_SHIP_GRP_INV_RES.PROMISED_DATETIME which can be promised and communicated to customer. *Use Cases* 1. Product GZ-2644 has 50 units backordered across 2 sales order placed on different dates: ORDER_1 : Placed as BO on 01/01/2020 with Order Qty = 30 units with all units backordered ORDER_2 : Placed as BO on 01/03/2020 with Order Qty = 20 units with all units backordered Two Shipments for Product GZ-2644 scheduled to arrive on different dates as follows: SHIPMENT_1 : Estimated Arrival Date on 01/25/2020 with Qty=20 units SHIPMENT_2 : Estimated Arrival Date on 01/31/2020 with Qty=40 units _*Expected Result*_ Upon reservation, here is how they would get their promised date: ORDER_1: Although its pegged to both the shipment (i.e., 20 units from SHIPMENT_1 and 10 units from SHIPMENT_2) but gets the Promise Date of 01/25/2020 (as shortness takes precedence over lateness) ORDER_2: It gets pegged to second shipment (20 units from SHIPMENT_2) and gets the Promise Date of 01/31/2020 2. Product GZ-2644 has 50 units backordered across 2 sales order placed on different dates but also has Safety Stock threshold of 30 units to be maintained: ORDER_1 : Placed as BO on 01/01/2020 with Order Qty = 30 units with all units backordered ORDER_2 : Placed as BO on 01/03/2020 with Order Qty = 20 units with all units backordered Two Shipments for Product GZ-2644 scheduled to arrive on different dates as follows: SHIPMENT_1 : Estimated Arrival Date on 01/25/2020 with Qty=20 units SHIPMENT_2 : Estimated Arrival Date on 01/31/2020 with Qty=40 units _*Expected Result*_ Upon reservation, here is how they would get their promised date: ORDER_1: After allocating 30 units for Safety Stock (i,e., 20 units from SHIPMENT_1 and 10 units from SHIPMENT_2), its pegged to the second shipment (i.e., 20 units left from SHIPMENT_2) and gets the Promise Date of 01/31/2020 (as Safety Stock takes precedence over sales orders) ORDER_2: It gets no shipment left to peg to and hence no promised date or can be defaulted based on average lead time from supplier. was: *Business Case* Many a times its required to promise the delivery date to customers for her sales orders that are back-order (BO) based on the expected arrival of future incoming/purchase shipments. Currently its not possible without either manually pegging the supply to demand or running the whole MRP engine. *Possible Solution* To solve for this problem on real time basis, the Reservation flow can be leveraged as that makes the determination whether the punched in sales order (or demand for production run for that matter) is going to be backordered or not. If and when there is SHIPMENT.ESTIMATED_ARRIVAL_DATE available against the scheduled or incoming receipts in the system say with SHIPMENT_TYPE_ID=PURCHASE_SHIPMENT (or INCOMING_SHIPMENT) then the reservation or post-reservation run can be triggered to peg and allocate the expected shipment volume to backorders on FIFO basis and inherit the earliest SHIPMENT.ESTIMATED_ARRIVAL_DATE over ORDER_ITEM_SHIP_GRP_INV_RES.PROMISED_DATETIME which can be promised and communicated to customer. *Use Cases* 1. Product GZ-2644 has 50 units backordered across 2 sales order placed on different dates: ORDER_1 : Placed as BO on 01/01/2020 with Order Qty = 30 units with all units backordered ORDER_2 : Placed as BO on 01/03/2020 with Order Qty = 20 units with all units backordered Two Shipments for Product GZ-2644 scheduled to arrive on
[jira] [Updated] (OFBIZ-11457) Expected arrival of Incoming Shipment needs to be reflected over back-order
[ https://issues.apache.org/jira/browse/OFBIZ-11457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-11457: - Fix Version/s: Upcoming Branch > Expected arrival of Incoming Shipment needs to be reflected over back-order > --- > > Key: OFBIZ-11457 > URL: https://issues.apache.org/jira/browse/OFBIZ-11457 > Project: OFBiz > Issue Type: New Feature > Components: order >Affects Versions: 17.12.02 >Reporter: Swapnil Shah >Priority: Major > Fix For: Upcoming Branch > > > *Business Case* > Many a times its required to promise the delivery date to customers for her > sales orders that are back-order (BO) based on the expected arrival of future > incoming/purchase shipments. Currently its not possible without either > manually pegging the supply to demand or running the whole MRP engine. > *Possible Solution* > To solve for this problem on real time basis, the Reservation flow can be > leveraged as that makes the determination whether the punched in sales order > (or demand for production run for that matter) is going to be backordered or > not. > If and when there is SHIPMENT.ESTIMATED_ARRIVAL_DATE available against the > scheduled or incoming receipts in the system say with > SHIPMENT_TYPE_ID=PURCHASE_SHIPMENT (or INCOMING_SHIPMENT) then the > reservation or post-reservation run can be triggered to peg and allocate the > expected shipment volume to backorders on FIFO basis and inherit the earliest > SHIPMENT.ESTIMATED_ARRIVAL_DATE over > ORDER_ITEM_SHIP_GRP_INV_RES.PROMISED_DATETIME which can be promised and > communicated to customer. > *Use Cases* > 1. Product GZ-2644 has 50 units backordered across 2 sales order placed on > different dates: > ORDER_1 : Placed as BO on 01/01/2020 with Order Qty = 30 units with all units > backordered > ORDER_2 : Placed as BO on 01/03/2020 with Order Qty = 20 units with all units > backordered > Two Shipments for Product GZ-2644 scheduled to arrive on different dates as > follows: > SHIPMENT_1 : Estimated Arrival Date on 01/25/2020 with Qty=20 units > SHIPMENT_2 : Estimated Arrival Date on 01/31/2020 with Qty=40 units > _*Expected Result*_ > Upon reservation, here is how they would get their promised date: > ORDER_1: Although its pegged to both the shipment (i.e., 20 units from > SHIPMENT_1 and 10 units from SHIPMENT_2) but gets the Promise Date of > 01/25/2020 (as shortness takes precedence over lateness) > ORDER_2: It gets pegged to second shipment (20 units from SHIPMENT_2) and > gets the Promise Date of 01/31/2020 > 2. Product GZ-2644 has 50 units backordered across 2 sales order placed on > different dates but also has Safety Stock threshold of 30 units to be > maintained: > ORDER_1 : Placed as BO on 01/01/2020 with Order Qty = 30 units with all units > backordered > ORDER_2 : Placed as BO on 01/03/2020 with Order Qty = 20 units with all units > backordered > Two Shipments for Product GZ-2644 scheduled to arrive on different dates as > follows: > SHIPMENT_1 : Estimated Arrival Date on 01/25/2020 with Qty=20 units > SHIPMENT_2 : Estimated Arrival Date on 01/31/2020 with Qty=40 units > _*Expected Result*_ > Upon reservation, here is how they would get their promised date: > ORDER_1: After allocating 30 units for Safety Stock (i,e., 20 units from > SHIPMENT_1 and 10 units from SHIPMENT_2), its pegged to the second shipment > (i.e., 20 units left from SHIPMENT_2) and gets the Promise Date of 01/31/2020 > (as Safety Stock takes precedence over sales orders) > ORDER_2: It gets no shipment left to peg to and hence no promised date or can > be defaulted based on average lead time from supplier. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OFBIZ-12053) Promising against Future Supply of Inventory
Swapnil Shah created OFBIZ-12053: Summary: Promising against Future Supply of Inventory Key: OFBIZ-12053 URL: https://issues.apache.org/jira/browse/OFBIZ-12053 Project: OFBiz Issue Type: New Feature Components: order Reporter: Swapnil Shah Requirement Elicitation: Promising delivery of any product or SKU to a customer out of On Hand inventory against any firm or forecasted demand arising either in the form of Sales Order or Production Runs(Jobs) in the system has been now been a established practice and well supported to a great extent within Ofbiz. However, there is a strong need felt to have a solution that can address the problem in making promises to customer for any product or SKU out of any future or expected supply of inventory through inbound shipments from vendors or suppliers. There may be different natures of demand for which such kind of solution capability can serve well like: * Demand from orders or jobs which couldn't get any commitment out of on hand inventory and thus are often termed as Backordered (BO) * Demand from Advanced or Pre-booked orders while launching new product line as inventory is yet to arrive at fulfilment locations * Demand from booked orders against limited edition version of existing product line as inventory is yet to arrive at fulfilment locations * Demand from sample lines booked during pre-launch event * and so on... While attempting to promise customer from future supply for a product/SKU then from solutioning stand point, anything that can try to address the following questions should be a good start to begin with: * How to promise (i.e., what should be the rules or constraints or basis for promising order) * How much to promise (i.e. how many units out of ordered units need to be promised for any given order) * How much is Available to Promise (i.e. how many promisable units available from different sources or inbound shipments for a given product/SKU) * Where to Promise from (i.e. from which source or inbound shipment the order can be promised) * When to promise (i.e. on what date a given order can be promised) Let's use this space to add on to it with more such real time use scenarios or questions that needs the right answer. We could try writing the design to solve for it in a separate linked ticket -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-12053) Promising against Future Supply of Inventory
[ https://issues.apache.org/jira/browse/OFBIZ-12053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-12053: - Description: *Requirement Elicitation:* Promising delivery of any product or SKU to a customer out of On Hand inventory against any firm or forecasted demand arising either in the form of Sales Order or Production Runs(Jobs) in the system has been now been a established practice and well supported to a great extent within Ofbiz. However, there is a strong need felt to have a solution that can address the problem in making promises to customer for any product or SKU out of any future or expected supply of inventory through inbound shipments from vendors or suppliers. There may be different natures of demand for which such kind of solution capability can serve well like: * Demand from orders or jobs which couldn't get any commitment out of on hand inventory and thus are often termed as Backordered (BO) * Demand from Advanced or Pre-booked orders while launching new product line as inventory is yet to arrive at fulfilment locations * Demand from booked orders against limited edition version of existing product line as inventory is yet to arrive at fulfilment locations * Demand from sample lines booked during pre-launch event * and so on... While attempting to promise customer from future supply for a product/SKU then from solutioning stand point, anything that can try to address the following questions should be a good start to begin with: * How to promise (i.e., what should be the rules or constraints or basis for promising order) * How much to promise (i.e. how many units out of ordered units need to be promised for any given order) * How much is Available to Promise (i.e. how many promisable units available from different sources or inbound shipments for a given product/SKU) * Where to Promise from (i.e. from which source or inbound shipment the order can be promised) * When to promise (i.e. on what date a given order can be promised) Let's use this space to add on to it with more such real time use scenarios or questions that needs the right answer. We could try writing the design to solve for it in a separate linked ticket was: Requirement Elicitation: Promising delivery of any product or SKU to a customer out of On Hand inventory against any firm or forecasted demand arising either in the form of Sales Order or Production Runs(Jobs) in the system has been now been a established practice and well supported to a great extent within Ofbiz. However, there is a strong need felt to have a solution that can address the problem in making promises to customer for any product or SKU out of any future or expected supply of inventory through inbound shipments from vendors or suppliers. There may be different natures of demand for which such kind of solution capability can serve well like: * Demand from orders or jobs which couldn't get any commitment out of on hand inventory and thus are often termed as Backordered (BO) * Demand from Advanced or Pre-booked orders while launching new product line as inventory is yet to arrive at fulfilment locations * Demand from booked orders against limited edition version of existing product line as inventory is yet to arrive at fulfilment locations * Demand from sample lines booked during pre-launch event * and so on... While attempting to promise customer from future supply for a product/SKU then from solutioning stand point, anything that can try to address the following questions should be a good start to begin with: * How to promise (i.e., what should be the rules or constraints or basis for promising order) * How much to promise (i.e. how many units out of ordered units need to be promised for any given order) * How much is Available to Promise (i.e. how many promisable units available from different sources or inbound shipments for a given product/SKU) * Where to Promise from (i.e. from which source or inbound shipment the order can be promised) * When to promise (i.e. on what date a given order can be promised) Let's use this space to add on to it with more such real time use scenarios or questions that needs the right answer. We could try writing the design to solve for it in a separate linked ticket > Promising against Future Supply of Inventory > > > Key: OFBIZ-12053 > URL: https://issues.apache.org/jira/browse/OFBIZ-12053 > Project: OFBiz > Issue Type: New Feature > Components: order >Reporter: Swapnil Shah >Priority: Major > > *Requirement Elicitation:* > Promising delivery of any product or SKU to a customer out of On Hand > inventory against any firm or forecasted demand arising either in the form of > Sales Order or Production Runs(Jobs) in the
[jira] [Updated] (OFBIZ-12053) Promising against Future Supply of Inventory
[ https://issues.apache.org/jira/browse/OFBIZ-12053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-12053: - Fix Version/s: Upcoming Branch > Promising against Future Supply of Inventory > > > Key: OFBIZ-12053 > URL: https://issues.apache.org/jira/browse/OFBIZ-12053 > Project: OFBiz > Issue Type: New Feature > Components: order >Reporter: Swapnil Shah >Priority: Major > Fix For: Upcoming Branch > > > *Requirement Elicitation:* > Promising delivery of any product or SKU to a customer out of On Hand > inventory against any firm or forecasted demand arising either in the form of > Sales Order or Production Runs(Jobs) in the system has been now been a > established practice and well supported to a great extent within Ofbiz. > However, there is a strong need felt to have a solution that can address the > problem in making promises to customer for any product or SKU out of any > future or expected supply of inventory through inbound shipments from vendors > or suppliers. There may be different natures of demand for which such kind of > solution capability can serve well like: > * Demand from orders or jobs which couldn't get any commitment out of on > hand inventory and thus are often termed as Backordered (BO) > * Demand from Advanced or Pre-booked orders while launching new product line > as inventory is yet to arrive at fulfilment locations > * Demand from booked orders against limited edition version of existing > product line as inventory is yet to arrive at fulfilment locations > * Demand from sample lines booked during pre-launch event > * and so on... > While attempting to promise customer from future supply for a product/SKU > then from solutioning stand point, anything that can try to address the > following questions should be a good start to begin with: > * How to promise (i.e., what should be the rules or constraints or basis for > promising order) > * How much to promise (i.e. how many units out of ordered units need to be > promised for any given order) > * How much is Available to Promise (i.e. how many promisable units available > from different sources or inbound shipments for a given product/SKU) > * Where to Promise from (i.e. from which source or inbound shipment the > order can be promised) > * When to promise (i.e. on what date a given order can be promised) > Let's use this space to add on to it with more such real time use scenarios > or questions that needs the right answer. > We could try writing the design to solve for it in a separate linked ticket > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-12053) Promising against Future Supply of Inventory
[ https://issues.apache.org/jira/browse/OFBIZ-12053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-12053: - Description: *Requirement Elicitation:* Promising delivery of any product or SKU to a customer out of On Hand inventory against any firm or forecasted demand arising either in the form of Sales Order in the system has been now been a established practice and well supported to a great extent within Ofbiz. However, there is a strong need felt to have a solution that can address the problem in making promises to customer for any product or SKU out of any future or expected supply of inventory through inbound shipments from vendors or suppliers. There may be different natures of demand for which such kind of solution capability can serve well like: * Demand from orders which couldn't get any commitment out of on hand inventory and thus are often termed as Backordered (BO) * Demand from Advanced or Pre-booked orders while launching new product line as inventory is yet to arrive at fulfilment locations * Demand from booked orders against limited edition version of existing product line as inventory is yet to arrive at fulfilment locations * Demand from sample lines booked during pre-launch event * and so on... While attempting to promise customer from future supply for a product/SKU then from solutioning stand point, anything that can try to address the following questions should be a good start to begin with: * How to promise (i.e., what should be the rules or constraints or basis for promising order) * How much to promise (i.e. how many units out of ordered units need to be promised for any given order) * How much is Available to Promise (i.e. how many promisable units available from different sources or inbound shipments for a given product/SKU) * Where to Promise from (i.e. from which source or inbound shipment the order can be promised) * When to promise (i.e. on what date a given order can be promised) Let's use this space to add on to it with more such real time use scenarios or questions that needs the right answer. We could try writing the design to solve for it in a separate linked ticket was: *Requirement Elicitation:* Promising delivery of any product or SKU to a customer out of On Hand inventory against any firm or forecasted demand arising either in the form of Sales Order or Production Runs(Jobs) in the system has been now been a established practice and well supported to a great extent within Ofbiz. However, there is a strong need felt to have a solution that can address the problem in making promises to customer for any product or SKU out of any future or expected supply of inventory through inbound shipments from vendors or suppliers. There may be different natures of demand for which such kind of solution capability can serve well like: * Demand from orders or jobs which couldn't get any commitment out of on hand inventory and thus are often termed as Backordered (BO) * Demand from Advanced or Pre-booked orders while launching new product line as inventory is yet to arrive at fulfilment locations * Demand from booked orders against limited edition version of existing product line as inventory is yet to arrive at fulfilment locations * Demand from sample lines booked during pre-launch event * and so on... While attempting to promise customer from future supply for a product/SKU then from solutioning stand point, anything that can try to address the following questions should be a good start to begin with: * How to promise (i.e., what should be the rules or constraints or basis for promising order) * How much to promise (i.e. how many units out of ordered units need to be promised for any given order) * How much is Available to Promise (i.e. how many promisable units available from different sources or inbound shipments for a given product/SKU) * Where to Promise from (i.e. from which source or inbound shipment the order can be promised) * When to promise (i.e. on what date a given order can be promised) Let's use this space to add on to it with more such real time use scenarios or questions that needs the right answer. We could try writing the design to solve for it in a separate linked ticket > Promising against Future Supply of Inventory > > > Key: OFBIZ-12053 > URL: https://issues.apache.org/jira/browse/OFBIZ-12053 > Project: OFBiz > Issue Type: New Feature > Components: order >Reporter: Swapnil Shah >Priority: Major > Fix For: Upcoming Branch > > > *Requirement Elicitation:* > Promising delivery of any product or SKU to a customer out of On Hand > inventory against any firm or forecasted demand arising either in the form of > Sales Order in the system has been
[jira] [Updated] (OFBIZ-12053) Promising against Future Supply of Inventory
[ https://issues.apache.org/jira/browse/OFBIZ-12053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-12053: - Description: *Requirement Elicitation:* Promising delivery of any product or SKU to a customer out of On Hand inventory against any firm or forecasted demand arising in the form of Sales Order in the system has been now been a established practice and well supported to a great extent within Ofbiz. However, there is a strong need felt to have a solution that can address the problem in making promises to customer for any product or SKU out of any future or expected supply of inventory through inbound shipments from vendors or suppliers. There may be different natures of demand for which such kind of solution capability can serve well like: * Demand from orders which couldn't get any commitment out of on hand inventory and thus are often termed as Backordered (BO) * Demand from Advanced or Pre-booked orders while launching new product line as inventory is yet to arrive at fulfilment locations * Demand from booked orders against limited edition version of existing product line as inventory is yet to arrive at fulfilment locations * Demand from sample lines booked during pre-launch event * and so on... While attempting to promise customer from future supply for a product/SKU then from solutioning stand point, anything that can try to address the following questions should be a good start to begin with: * How to promise (i.e., what should be the rules or constraints or basis for promising order) * How much to promise (i.e. how many units out of ordered units need to be promised for any given order) * How much is Available to Promise (i.e. how many promisable units available from different sources or inbound shipments for a given product/SKU) * Where to Promise from (i.e. from which source or inbound shipment the order can be promised) * When to promise (i.e. on what date a given order can be promised) Let's use this space to add on to it with more such real time use scenarios or questions that needs the right answer. We could try writing the design to solve for it in a separate linked ticket was: *Requirement Elicitation:* Promising delivery of any product or SKU to a customer out of On Hand inventory against any firm or forecasted demand arising either in the form of Sales Order in the system has been now been a established practice and well supported to a great extent within Ofbiz. However, there is a strong need felt to have a solution that can address the problem in making promises to customer for any product or SKU out of any future or expected supply of inventory through inbound shipments from vendors or suppliers. There may be different natures of demand for which such kind of solution capability can serve well like: * Demand from orders which couldn't get any commitment out of on hand inventory and thus are often termed as Backordered (BO) * Demand from Advanced or Pre-booked orders while launching new product line as inventory is yet to arrive at fulfilment locations * Demand from booked orders against limited edition version of existing product line as inventory is yet to arrive at fulfilment locations * Demand from sample lines booked during pre-launch event * and so on... While attempting to promise customer from future supply for a product/SKU then from solutioning stand point, anything that can try to address the following questions should be a good start to begin with: * How to promise (i.e., what should be the rules or constraints or basis for promising order) * How much to promise (i.e. how many units out of ordered units need to be promised for any given order) * How much is Available to Promise (i.e. how many promisable units available from different sources or inbound shipments for a given product/SKU) * Where to Promise from (i.e. from which source or inbound shipment the order can be promised) * When to promise (i.e. on what date a given order can be promised) Let's use this space to add on to it with more such real time use scenarios or questions that needs the right answer. We could try writing the design to solve for it in a separate linked ticket > Promising against Future Supply of Inventory > > > Key: OFBIZ-12053 > URL: https://issues.apache.org/jira/browse/OFBIZ-12053 > Project: OFBiz > Issue Type: New Feature > Components: order >Reporter: Swapnil Shah >Priority: Major > Fix For: Upcoming Branch > > > *Requirement Elicitation:* > Promising delivery of any product or SKU to a customer out of On Hand > inventory against any firm or forecasted demand arising in the form of Sales > Order in the system has been now been a established practice and well >
[jira] [Updated] (OFBIZ-12054) Solution Design - OFBIZ-12053: Promising against Future Supply
[ https://issues.apache.org/jira/browse/OFBIZ-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-12054: - Description: *Solution Design* In search of answers for few basic questions around promising, here is the list of few possible design options to explore and build on further: * *How much to Promise* Before making any systemic or manual promise its important to know how much is remaining to be promised for any given order(item). It could be determined as follows: ** Let system first promise out of on hand inventory using its current reservation mechanism. ** Post inventory reservation, if Order item is still found backordered (BO) i.e. couldn't get any promise from Inventory then it could easily be adjudged how much more need to be promised yet based on summing up ORDER_ITEM_SHIP_GRP_INV_RES(OISGIR).QUANTIT_NOT_AVAILABLE for given order item * *How much is 'Promisable' or 'Available to Promise' (ATP) against supply:* Before systemic or manual promises against new demand/orders, It must be known how much is left or available to be promised. To begin with, all the future supply scheduled to come into the system from vendors or suppliers are usually gauged through Advance Shipment Notifications (ASNs) which can be expressed via SHIPMENT model in OFBiz. Assuming this to be true, here are few possible options: ** SHIPMENT with dedicated SHIPMENT_TYPE either as 'INCOMING_SHIPMENT' or 'PURCHASE_SHIPMENT' can be recognized as scheduled inbound supply on a certain ESTIMATED_ARRIVAL_DATE (EAD) ** SHIPMENT_ITEM can express the Product/SKU wise details of supply in terms of QUANTITY ** *_Extend SHIPMENT_ITEM (SI)_* _with new field_ *_'AVAILABLE_TO_PROMISE' (ATP)_* _to now maintain the remaining qty left to be promised at product level within a given shipment_ ** All the promises to be made for any open demand/order can be based off SI.ATP. At the same time, all the promises made based on it needs to keep on reducing it so as to reflect correct supply snapshot (very much in line with ATP on Inventory Item in OFBiz) * *How to Promise* There can be many ways to promise the demand against supply. Few of the automated or manual ways that can be honored (in line with how on hand Inventory is promised in OFBiz) could be based on following criteria: ** *_FIFO_*: Order with earlier Estimated Ship Date (ESD) could get higher precedence in getting supply promised than that of later ESDs. In case of missing ESD, Order Date can be referred as fall back option ** _*Order Priority*_: Order with higher priority takes precedence in getting supply promised than that of lower priority order. ** _*Order Priority + FIFO*_ : Order with higher priority gets precedence but within same priority orders, FIFO based rules can be applied ** _*Fair Share*_: In this manual approach control could be more in hand of users to determine and set how much can be promised. It could come handy when sales reps or merchandisers have their own set of custom rules to be applied rather than having system making promises in automated fashion. Depending upon the any of the preferred technique, system needs to keep pegging the 'Promisable Supply' against 'Yet to be promised demand'. One of the possible ways to maintain and capture this pegging could be: * Add new table _*ORDER_ITEM_SHIP_GRP_SHIPMENT_RES (OISGSR)*_ with ** ORDER_ID (PK) ** SHIP_GROUP_SEQ_ID (PK) ** ORDER_ITEM_SEQ_ID (PK) ** SHIPMENT_ID (PK) ** SHIPMENT_ITEM_SEQ_ID (PK) ** RESERVE_ORDER_ENUM_ID (to capture the basis for promising i.e. FIFO, PRIORITY, FAIR_SHARE etc.) ** QUANTITY (Ordered Qty) ** QUANTITY_NOT_AVAILABLE (Un-promised Qty left if any) ** PROMISED_DATETIME (promised date based on S.EAD) ** PRIORITY (optional - to adjudge the shipment to be used first if same order item gets promised from multiple shipments. Lower the number, higher the priority) ** Standard 4 timestamps * All the promises for an ordered item against future supply in (the form of inbound shipment) could be made based off SI.ATP * Any promise made from Inbound shipments could keep getting captured through above table and get reflected on SI.ATP unless it gets completely exhausted i.e. goes down to ZERO. * *Where to Promise from* At times it might be required to know from which part of supply the order is being promised specially in case there are multiple inbound supply from one or more sources. ** OISGSR.SHIPMENT_ID and OISGSR.SHIPMENT_ITEM_SEQ_ID could help in determining supply from which source is pegged for given order (item) * *When to Promise*: Once its known which part of inbound supply is being used to promise order, what is equally important is to know what date should be promised to customer ** OISGSR.PROMISED_DATETIME should be able to help in suggesting the dates to be promised for any given order of customer
[jira] [Updated] (OFBIZ-12054) Solution Design - OFBIZ-12053: Promising against Future Supply
[ https://issues.apache.org/jira/browse/OFBIZ-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-12054: - Description: *Solution Design* In search of answers for few basic questions around promising, here is the list of few possible design options to explore and build on further: * *How much to Promise* Before making any systemic or manual promise its important to know how much is remaining to be promised for any given order(item). It could be determined as follows: ** Let system first promise out of on hand inventory using its current reservation mechanism. ** Post inventory reservation, if Order item is still found backordered (BO) i.e. couldn't get any promise from Inventory then it could easily be adjudged how much more need to be promised yet based on summing up ORDER_ITEM_SHIP_GRP_INV_RES(OISGIR).QUANTIT_NOT_AVAILABLE for given order item * *How much is 'Promisable' or 'Available to Promise' (ATP) against supply:* Before systemic or manual promises against new demand/orders, It must be known how much is left or available to be promised. To begin with, all the future supply scheduled to come into the system from vendors or suppliers are usually gauged through Advance Shipment Notifications (ASNs) which can be expressed via SHIPMENT model in OFBiz. Assuming this to be true, here are few possible options: ** SHIPMENT with dedicated SHIPMENT_TYPE either as 'INCOMING_SHIPMENT' or 'PURCHASE_SHIPMENT' can be recognized as scheduled inbound supply on a certain ESTIMATED_ARRIVAL_DATE (EAD) ** SHIPMENT_ITEM can express the Product/SKU wise details of supply in terms of QUANTITY ** *_Extend SHIPMENT_ITEM (SI)_* _with new field_ *_'AVAILABLE_TO_PROMISE' (ATP)_* _to now maintain the remaining qty left to be promised at product level within a given shipment_ ** All the promises to be made for any open demand/order can be based off SI.ATP. At the same time, all the promises made based on it needs to keep on reducing it so as to reflect correct supply snapshot (very much in line with ATP on Inventory Item in OFBiz) * *How to Promise* There can be many ways to promise the demand against supply. Few of the automated or manual ways that can be honored (in line with how on hand Inventory is promised in OFBiz) could be based on following criteria: ** *_FIFO_*: Order with earlier Estimated Ship Date (ESD) could get higher precedence in getting supply promised than that of later ESDs. In case of missing ESD, Order Date can be referred as fall back option ** _*Order Priority*_: Order with higher priority takes precedence in getting supply promised than that of lower priority order. ** _*Order Priority + FIFO*_ : Order with higher priority gets precedence but within same priority orders, FIFO based rules can be applied ** _*Fair Share*_: In this manual approach control could be more in hand of users to determine and set how much can be promised. It could come handy when sales reps or merchandisers have their own set of custom rules to be applied rather than having system making promises in automated fashion. Depending upon the any of the preferred technique, system needs to keep pegging the 'Promisable Supply' against 'Yet to be promised demand'. One of the possible ways to maintain and capture this pegging could be: * Add new table _*ORDER_ITEM_SHIP_GRP_SHIPMENT_RES (OISGSR)*_ with ** ORDER_ID (PK) ** SHIP_GROUP_SEQ_ID (PK) ** ORDER_ITEM_SEQ_ID (PK) ** SHIPMENT_ID (PK) ** SHIPMENT_ITEM_SEQ_ID (PK) ** RESERVE_ORDER_ENUM_ID (to capture the basis for promising i.e. FIFO, PRIORITY, FAIR_SHARE etc.) ** QUANTITY (Ordered Qty) ** QUANTITY_NOT_AVAILABLE (Un-promised Qty left if any) ** PROMISED_DATETIME (promised date based on S.EAD) ** PRIORITY (optional - to adjudge the shipment to be used first if same order item gets promised from multiple shipments. Lower the number, higher the priority) ** Standard 4 timestamps * All the promises for an ordered item against future supply in (the form of inbound shipment) could be made based off SI.ATP * Any promise made from Inbound shipments could keep getting captured through above table and get reflected on SI.ATP unless it gets completely exhausted i.e. goes down to ZERO. * *Where to Promise from* At times it might be required to know from which part of supply the order is being promised specially in case there are multiple inbound supply from one or more sources. ** OISGSR.SHIPMENT_ID and OISGSR.SHIPMENT_ITEM_SEQ_ID could help in determining supply from which source is pegged for given order (item) * *When to Promise*: Once its known which part of inbound supply is being used to promise order, what is equally important is to know what date should be promised to customer ** OISGSR.PROMISED_DATETIME should be able to help in suggesting the dates to be promised for any given order of customer
[jira] [Updated] (OFBIZ-12054) Solution Design - OFBIZ-12053: Promising against Future Supply
[ https://issues.apache.org/jira/browse/OFBIZ-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-12054: - Description: *Solution Design* In search of answers for few basic questions around promising, here is the list of few possible design options to explore and build on further: * *How much to Promise* Before making any systemic or manual promise its important to know how much is remaining to be promised for any given order(item). It could be determined as follows: ** Let system first promise out of on hand inventory using its current reservation mechanism. ** Post inventory reservation, if Order item is still found backordered (BO) i.e. couldn't get any promise from Inventory then it could easily be adjudged how much more need to be promised yet based on summing up ORDER_ITEM_SHIP_GRP_INV_RES(OISGIR).QUANTIT_NOT_AVAILABLE for given order item * *How much is 'Promisable' or 'Available to Promise' (ATP) against supply:* Before systemic or manual promises against new demand/orders, It must be known how much is left or available to be promised. To begin with, all the future supply scheduled to come into the system from vendors or suppliers are usually gauged through Advance Shipment Notifications (ASNs) which can be expressed via SHIPMENT model in OFBiz. Assuming this to be true, here are few possible options: ** SHIPMENT with dedicated SHIPMENT_TYPE either as 'INCOMING_SHIPMENT' or 'PURCHASE_SHIPMENT' can be recognized as scheduled inbound supply on a certain ESTIMATED_ARRIVAL_DATE (EAD) ** SHIPMENT_ITEM can express the Product/SKU wise details of supply in terms of QUANTITY ** *_Extend SHIPMENT_ITEM (SI)_* _with new field_ *_'AVAILABLE_TO_PROMISE' (ATP)_* _to now maintain the remaining qty left to be promised at product level within a given shipment_ ** All the promises to be made for any open demand/order can be based off SI.ATP. At the same time, all the promises made based on it needs to keep on reducing it so as to reflect correct supply snapshot (very much in line with ATP on Inventory Item in OFBiz) * *How to Promise* There can be many ways to promise the demand against supply. Few of the automated or manual ways that can be honored (in line with how on hand Inventory is promised in OFBiz) could be based on following criteria: ** *_FIFO_*: Order with earlier Estimated Ship Date (ESD) could get higher precedence in getting supply promised than that of later ESDs. In case of missing ESD, Order Date can be referred as fall back option ** _*Order Priority*_: Order with higher priority takes precedence in getting supply promised than that of lower priority order. ** _*Order Priority + FIFO*_ : Order with higher priority gets precedence but within same priority orders, FIFO based rules can be applied ** _*Fair Share*_: In this manual approach control could be more in hand of users to determine and set how much can be promised. It could come handy when sales reps or merchandisers have their own set of custom rules to be applied rather than having system making promises in automated fashion. Depending upon the any of the preferred technique, system needs to keep pegging the 'Promisable Supply' against 'Yet to be promised demand'. One of the possible ways to maintain and capture this pegging could be: * Add new table _*ORDER_ITEM_SHIP_GRP_SHIPMENT_RES (OISGSR)*_ with ** ORDER_ID (PK) ** SHIP_GROUP_SEQ_ID (PK) ** ORDER_ITEM_SEQ_ID (PK) ** SHIPMENT_ID (PK) ** SHIPMENT_ITEM_SEQ_ID (PK) ** RESERVE_ORDER_ENUM_ID (to capture the basis for promising i.e. FIFO, PRIORITY, FAIR_SHARE etc.) ** QUANTITY (Ordered Qty) ** QUANTITY_NOT_AVAILABLE (Un-promised Qty left if any) ** PROMISED_DATETIME (promised date based on S.EAD) ** PRIORITY (optional - to adjudge the shipment to be used first if same order item gets promised from multiple shipments. Lower the number, higher the priority) ** Standard 4 timestamps * All the promises for an ordered item against future supply in (the form of inbound shipment) could be made based off SI.ATP * Any promise made from Inbound shipments could keep getting captured through above table and get reflected on SI.ATP unless it gets completely exhausted i.e. goes down to ZERO. * *Where to Promise from* At times it might be required to know from which part of supply the order is being promised specially in case there are multiple inbound supply from one or more sources. ** OISGSR.SHIPMENT_ID and OISGSR.SHIPMENT_ITEM_SEQ_ID could help in determining supply from which source is pegged for given order (item) * *When to Promise*: Once its known which part of inbound supply is being used to promise order, what is equally important is to know what date should be promised to customer ** OISGSR.PROMISED_DATETIME should be able to help in suggesting the dates to be promised for any given order of customer
[jira] [Updated] (OFBIZ-12054) Solution Design - OFBIZ-12053: Promising against Future Supply
[ https://issues.apache.org/jira/browse/OFBIZ-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Shah updated OFBIZ-12054: - Description: *Solution Design* In search of answers for few basic questions around promising, here is the list of few possible design options to explore and build on further: * *How much to Promise* Before making any systemic or manual promise its important to know how much is remaining to be promised for any given order(item). It could be determined as follows: ** Let system first promise out of on hand inventory using its current reservation mechanism. ** Post inventory reservation, if Order item is still found backordered (BO) i.e. couldn't get any promise from Inventory then it could easily be adjudged how much more need to be promised yet based on summing up ORDER_ITEM_SHIP_GRP_INV_RES(OISGIR).QUANTIT_NOT_AVAILABLE for given order item * *How much is 'Promisable' or 'Available to Promise' (ATP) against supply:* Before systemic or manual promises against new demand/orders, It must be known how much is left or available to be promised. To begin with, all the future supply scheduled to come into the system from vendors or suppliers are usually gauged through Advance Shipment Notifications (ASNs) which can be expressed via SHIPMENT model in OFBiz. Assuming this to be true, here are few possible options: ** SHIPMENT with dedicated SHIPMENT_TYPE either as 'INCOMING_SHIPMENT' or 'PURCHASE_SHIPMENT' can be recognized as scheduled inbound supply on a certain ESTIMATED_ARRIVAL_DATE (EAD) ** SHIPMENT_ITEM can express the Product/SKU wise details of supply in terms of QUANTITY ** *_Extend SHIPMENT_ITEM (SI)_* _with new field_ *_'AVAILABLE_TO_PROMISE' (ATP)_* _to now maintain the remaining qty left to be promised at product level within a given shipment_ ** All the promises to be made for any open demand/order can be based off SI.ATP. At the same time, all the promises made based on it needs to keep on reducing it so as to reflect correct supply snapshot (very much in line with ATP on Inventory Item in OFBiz) * *How to Promise* There can be many ways to promise the demand against supply. Few of the automated or manual ways that can be honored (in line with how on hand Inventory is promised in OFBiz) could be based on following criteria: ** *_FIFO_*: Order with earlier Estimated Ship Date (ESD) could get higher precedence in getting supply promised than that of later ESDs. In case of missing ESD, Order Date can be referred as fall back option ** _*Order Priority*_: Order with higher priority takes precedence in getting supply promised than that of lower priority order. ** _*Order Priority + FIFO*_ : Order with higher priority gets precedence but within same priority orders, FIFO based rules can be applied ** _*Fair Share*_: In this manual approach control could be more in hand of users to determine and set how much can be promised. It could come handy when sales reps or merchandisers have their own set of custom rules to be applied rather than having system making promises in automated fashion. Depending upon the any of the preferred technique, system needs to keep pegging the 'Promisable Supply' against 'Yet to be promised demand'. One of the possible ways to maintain and capture this pegging could be: * Add new table _*ORDER_ITEM_SHIP_GRP_SHIPMENT_RES (OISGSR)*_ with ** ORDER_ID (PK) ** SHIP_GROUP_SEQ_ID (PK) ** ORDER_ITEM_SEQ_ID (PK) ** SHIPMENT_ID (PK) ** SHIPMENT_ITEM_SEQ_ID (PK) ** RESERVE_ORDER_ENUM_ID (to capture the basis for promising i.e. FIFO, PRIORITY, FAIR_SHARE etc.) ** QUANTITY (Ordered Qty) ** QUANTITY_NOT_AVAILABLE (Un-promised Qty left if any) ** PROMISED_DATETIME (promised date based on S.EAD) ** PRIORITY (optional - to adjudge the shipment to be used first if same order item gets promised from multiple shipments. Lower the number, higher the priority) ** Standard 4 timestamps * All the promises for an ordered item against future supply in (the form of inbound shipment) could be made based off SI.ATP * Any promise made from Inbound shipments could keep getting captured through above table and get reflected on SI.ATP unless it gets completely exhausted i.e. goes down to ZERO. * *Where to Promise from* At times it might be required to know from which part of supply the order is being promised specially in case there are multiple inbound supply from one or more sources. ** OISGSR.SHIPMENT_ID and OISGSR.SHIPMENT_ITEM_SEQ_ID could help in determining supply from which source is pegged for given order (item) * *When to Promise*: Once its known which part of inbound supply is being used to promise order, what is equally important is to know what date should be promised to customer ** OISGSR.PROMISED_DATETIME should be able to help in suggesting the dates to be promised for any given order of customer
