[jira] [Created] (OFBIZ-10971) Use ReturnContactMech entity
Vaibhav Jain created OFBIZ-10971: Summary: Use ReturnContactMech entity Key: OFBIZ-10971 URL: https://issues.apache.org/jira/browse/OFBIZ-10971 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Vaibhav Jain Use ReturnContactMech entity to capture the contactMech information of parties involved in a return like OrderContactMech is used of orders -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10626) Add Document Content: acc-glossary.adoc
[ https://issues.apache.org/jira/browse/OFBIZ-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1080#comment-1080 ] Vaibhav Jain commented on OFBIZ-10626: -- Hi team, Attached the patch for accounting glossary documentation. Please have a look into this. Thanks! > Add Document Content: acc-glossary.adoc > --- > > Key: OFBIZ-10626 > URL: https://issues.apache.org/jira/browse/OFBIZ-10626 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain >Priority: Major > Attachments: OFBIZ-10626.patch > > > Add content for acc-glossary.adoc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10626) Add Document Content: acc-glossary.adoc
[ https://issues.apache.org/jira/browse/OFBIZ-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-10626: - Attachment: OFBIZ-10626.patch > Add Document Content: acc-glossary.adoc > --- > > Key: OFBIZ-10626 > URL: https://issues.apache.org/jira/browse/OFBIZ-10626 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain >Priority: Major > Attachments: OFBIZ-10626.patch > > > Add content for acc-glossary.adoc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10626) Add Document Content: acc-glossary.adoc
[ https://issues.apache.org/jira/browse/OFBIZ-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain reassigned OFBIZ-10626: Assignee: Vaibhav Jain > Add Document Content: acc-glossary.adoc > --- > > Key: OFBIZ-10626 > URL: https://issues.apache.org/jira/browse/OFBIZ-10626 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain >Priority: Major > > Add content for acc-glossary.adoc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-10626) Add Document Content: acc-glossary.adoc
Vaibhav Jain created OFBIZ-10626: Summary: Add Document Content: acc-glossary.adoc Key: OFBIZ-10626 URL: https://issues.apache.org/jira/browse/OFBIZ-10626 Project: OFBiz Issue Type: Sub-task Components: accounting Reporter: Vaibhav Jain Add content for acc-glossary.adoc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10288) Move Accounting Guide into OFBiz Asciidoc Framework
[ https://issues.apache.org/jira/browse/OFBIZ-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-10288: - Description: This is a general umbrella task for the creation and migration of all accounting related information and documentation into the OFBiz asciidoc documentation framework. Subtasks will be created for each area where documentation needs to be creaated. An initial list is as follows: # accounting.adoc (already created - may create an issue to track any additional work_ # acc-intro.adoc # acc-agreements.adoc # acc-tax-authorities.adoc # acc-invoices.adoc # acc-billing-accounts.adoc # acc-payments.adoc # acc-payment-gateway.adoc # acc-financial-accounts.adoc # acc-global-settings.adoc # acc-glossary.adoc was: This is a general umbrella task for the creation and migration of all accounting related information and documentation into the OFBiz asciidoc documentation framework. Subtasks will be created for each area where documentation needs to be creaated. An initial list is as follows: # accounting.adoc (already created - may create an issue to track any additional work_ # acc-intro.adoc # acc-agreements.adoc # acc-tax-authorities.adoc # acc-invoices.adoc # acc-billing-accounts.adoc # acc-payments.adoc # acc-payment-gateway.adoc # acc-financial-accounts.adoc # acc-global-settings.adoc > Move Accounting Guide into OFBiz Asciidoc Framework > --- > > Key: OFBIZ-10288 > URL: https://issues.apache.org/jira/browse/OFBIZ-10288 > Project: OFBiz > Issue Type: Task > Components: accounting >Reporter: Sharan Foga >Priority: Minor > Labels: accounting, asciidoc, documentation > Fix For: Upcoming Branch > > > This is a general umbrella task for the creation and migration of all > accounting related information and documentation into the OFBiz asciidoc > documentation framework. > Subtasks will be created for each area where documentation needs to be > creaated. An initial list is as follows: > # accounting.adoc (already created - may create an issue to track any > additional work_ > # acc-intro.adoc > # acc-agreements.adoc > # acc-tax-authorities.adoc > # acc-invoices.adoc > # acc-billing-accounts.adoc > # acc-payments.adoc > # acc-payment-gateway.adoc > # acc-financial-accounts.adoc > # acc-global-settings.adoc > # acc-glossary.adoc > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10296) Add Document Content: acc-financial-accounts.adoc
[ https://issues.apache.org/jira/browse/OFBIZ-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1045#comment-1045 ] Vaibhav Jain commented on OFBIZ-10296: -- Hi team, Attached the patch for financial accounting documentation. Please have a look into this. Thanks! > Add Document Content: acc-financial-accounts.adoc > - > > Key: OFBIZ-10296 > URL: https://issues.apache.org/jira/browse/OFBIZ-10296 > Project: OFBiz > Issue Type: Sub-task >Reporter: Sharan Foga >Assignee: Vaibhav Jain >Priority: Minor > Attachments: OFBIZ-10296.patch > > > Add content for acc-financial-accounts.adoc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10296) Add Document Content: acc-financial-accounts.adoc
[ https://issues.apache.org/jira/browse/OFBIZ-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-10296: - Attachment: OFBIZ-10296.patch > Add Document Content: acc-financial-accounts.adoc > - > > Key: OFBIZ-10296 > URL: https://issues.apache.org/jira/browse/OFBIZ-10296 > Project: OFBiz > Issue Type: Sub-task >Reporter: Sharan Foga >Assignee: Vaibhav Jain >Priority: Minor > Attachments: OFBIZ-10296.patch > > > Add content for acc-financial-accounts.adoc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10296) Add Document Content: acc-financial-accounts.adoc
[ https://issues.apache.org/jira/browse/OFBIZ-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain reassigned OFBIZ-10296: Assignee: Vaibhav Jain > Add Document Content: acc-financial-accounts.adoc > - > > Key: OFBIZ-10296 > URL: https://issues.apache.org/jira/browse/OFBIZ-10296 > Project: OFBiz > Issue Type: Sub-task >Reporter: Sharan Foga >Assignee: Vaibhav Jain >Priority: Minor > > Add content for acc-financial-accounts.adoc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7701) Cmssite : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7701. --- Resolution: Won't Do > Cmssite : FTL formatting > > > Key: OFBIZ-7701 > URL: https://issues.apache.org/jira/browse/OFBIZ-7701 > Project: OFBiz > Issue Type: Sub-task > Components: cmssite >Affects Versions: Trunk >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain >Priority: Major > Attachments: OFBIZ-7701.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7863) Ebay : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7863. --- Resolution: Won't Do > Ebay : FTL formatting > - > > Key: OFBIZ-7863 > URL: https://issues.apache.org/jira/browse/OFBIZ-7863 > Project: OFBiz > Issue Type: Sub-task > Components: ebay >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain >Priority: Major > Attachments: OFBIZ-7863.patch, OFBIZ-7863.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7646) Scrum : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7646. --- Resolution: Won't Do > Scrum : FTL formatting > -- > > Key: OFBIZ-7646 > URL: https://issues.apache.org/jira/browse/OFBIZ-7646 > Project: OFBiz > Issue Type: Sub-task > Components: scrum >Reporter: Vaibhav Jain >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7949) E-commerce : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7949. --- Resolution: Won't Do > E-commerce : FTL formatting > --- > > Key: OFBIZ-7949 > URL: https://issues.apache.org/jira/browse/OFBIZ-7949 > Project: OFBiz > Issue Type: Sub-task > Components: ecommerce >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain >Priority: Major > Attachments: OFBIZ-7949.patch, OFBIZ-7949.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7643) Work Effort : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7643. --- Resolution: Won't Do > Work Effort : FTL formatting > > > Key: OFBIZ-7643 > URL: https://issues.apache.org/jira/browse/OFBIZ-7643 > Project: OFBiz > Issue Type: Sub-task > Components: workeffort >Reporter: Vaibhav Jain >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7645) Web POS : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7645. --- Resolution: Won't Do > Web POS : FTL formatting > > > Key: OFBIZ-7645 > URL: https://issues.apache.org/jira/browse/OFBIZ-7645 > Project: OFBiz > Issue Type: Sub-task > Components: webpos >Reporter: Vaibhav Jain >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7639) Manufacturing : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7639. --- Resolution: Won't Do > Manufacturing : FTL formatting > -- > > Key: OFBIZ-7639 > URL: https://issues.apache.org/jira/browse/OFBIZ-7639 > Project: OFBiz > Issue Type: Sub-task > Components: manufacturing >Reporter: Vaibhav Jain >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7642) Product : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7642. --- Resolution: Won't Do > Product : FTL formatting > > > Key: OFBIZ-7642 > URL: https://issues.apache.org/jira/browse/OFBIZ-7642 > Project: OFBiz > Issue Type: Sub-task > Components: product >Reporter: Vaibhav Jain >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7640) Order : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7640. --- Resolution: Won't Do > Order : FTL formatting > -- > > Key: OFBIZ-7640 > URL: https://issues.apache.org/jira/browse/OFBIZ-7640 > Project: OFBiz > Issue Type: Sub-task > Components: order >Reporter: Vaibhav Jain >Assignee: Garima jain >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7638) Content : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7638. --- Resolution: Won't Do > Content : FTL formatting > > > Key: OFBIZ-7638 > URL: https://issues.apache.org/jira/browse/OFBIZ-7638 > Project: OFBiz > Issue Type: Sub-task > Components: content >Reporter: Vaibhav Jain >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7641) Party : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7641. --- Resolution: Won't Do > Party : FTL formatting > -- > > Key: OFBIZ-7641 > URL: https://issues.apache.org/jira/browse/OFBIZ-7641 > Project: OFBiz > Issue Type: Sub-task > Components: party >Reporter: Vaibhav Jain >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7637) Accounting : FTL formating
[ https://issues.apache.org/jira/browse/OFBIZ-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7637. --- Resolution: Won't Do > Accounting : FTL formating > -- > > Key: OFBIZ-7637 > URL: https://issues.apache.org/jira/browse/OFBIZ-7637 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Reporter: Vaibhav Jain >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-7366) FTL formatting in the whole application
[ https://issues.apache.org/jira/browse/OFBIZ-7366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7366. --- Resolution: Won't Do Hello all, At first, thank you very much to all of you for your co-operation and support. After a lot of time, I don't think that it is worthy to put that much efforts to achieve only good code readability. Hence closing the ticket. Even I think that everyone in the community has the same thoughts about it. > FTL formatting in the whole application > --- > > Key: OFBIZ-7366 > URL: https://issues.apache.org/jira/browse/OFBIZ-7366 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain >Priority: Major > > There is a formatting issue in the most of FTL files in OFBiz. > We need to format the code as per best practice to make it more readable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-7366) FTL formatting in the whole application
[ https://issues.apache.org/jira/browse/OFBIZ-7366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473075#comment-16473075 ] Vaibhav Jain commented on OFBIZ-7366: - Hello all, At first, thank you very much to all of you for your co-operation and support. After a lot of time, I don't think that it is worthy to put that much efforts to achieve only good code readability. Hence closing the ticket. Even I think that everyone in the community has the same thoughts about it. > FTL formatting in the whole application > --- > > Key: OFBIZ-7366 > URL: https://issues.apache.org/jira/browse/OFBIZ-7366 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain >Priority: Major > > There is a formatting issue in the most of FTL files in OFBiz. > We need to format the code as per best practice to make it more readable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-10176) Add an option "All" to show entities of all groups
Vaibhav Jain created OFBIZ-10176: Summary: Add an option "All" to show entities of all groups Key: OFBIZ-10176 URL: https://issues.apache.org/jira/browse/OFBIZ-10176 Project: OFBiz Issue Type: Bug Reporter: Vaibhav Jain Steps to regenerate: # Click on Entity Engine tab of Webtools. # By default entities of all the groups are listed down. # If we apply a filter then entities are listed according to the group. # We don't have an option "All" to list entities of all groups. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-9464) Accounting quantity transfer should not be zero while transferring inventory from one facility to another
[ https://issues.apache.org/jira/browse/OFBIZ-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16302304#comment-16302304 ] Vaibhav Jain commented on OFBIZ-9464: - Hello Paul, There are two fields which affect reservation here cogsMethodId in PartyAcctgPreference which address the accounting method of inventory and reservation accordingly COGS_AVG_COSTAverage cost COGS_INV_COST Inventory cost COGS_FIFO First in First out COGS_LIFO Last in First out ReservationEnumId in ProductStore entity which defines inventory reservation like : INVRO_FIFO_EXP FIFO Expire INVRO_FIFO_REC FIFO Received INVRO_GUNIT_COST Greater Unit Cost INVRO_LIFO_EXP LIFO Expire INVRO_LIFO_REC LIFO Received INVRO_LUNIT_COST Less Unit Cost Now the question is either COGS method override the reservation logic or vice versa. Do we have any user story about it? So we can get the direction in it. > Accounting quantity transfer should not be zero while transferring inventory > from one facility to another > - > > Key: OFBIZ-9464 > URL: https://issues.apache.org/jira/browse/OFBIZ-9464 > Project: OFBiz > Issue Type: Bug >Affects Versions: Trunk >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain > Labels: inventory, stock, valuation > Fix For: 16.11.04 > > Attachments: OFBIZ_9464.patch > > > when we transfer inventory, the accountingQuantityTotal field of > _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in > accountingQuantityTotal. > This will create following issues in the system. > # Accounting quantity total will mismatch with the original quantity in the > facility which shows the wrong result when we calculate facility specific > inventory valuation. > # Inventory reservation also throws an error in some specific case like when > AQT of respective product is zero in the specific facility from when > reservation happens. > As we manage 5 different statuses of inventory transfer in OFBiz and > according to my current understanding these processes are associated with the > respective statuses, which are as show below > Requested: As inventory transfer is requested for another facility. > a)ATP, QOH and AQT should decrease from the inventory item of From Facility > and QOH of To Facility should increase. > b)ATP and AQT should be Zero in To Facility as inventory is not transferred > yet. But QOH should increase at To Facility because QOH shows the > xferquantity later. At the time of the completion of the transfer > ATP = ATP + (QOH - ATP) (Adjustment in case of backorder) > AQT = QOH > b)AQT should not decrease because AQT is used for accounting purpose and as > of now quantity is still in From Facility as the transfer is not done yet. > which shows the xferQuantity later > Scheduled: As inventory transfer is Scheduled for another facility. ATP, QOH > and AQT should not affect in both From Facility and To Facility. > En-route: As inventory is routed to reach at To Facility. Even in this case > ATP, QOH and AQT should not affect in both From Facility and To Facility. > Complete: As inventory transfer is completed > a)ATP, QOH and AQT should not affect at From Facility. > b)QOH will be same but ATP and AQT should affect respectively > ATP = ATP + (QOH - ATP) > AQT = QOH > Cancelled: As inventory transfer is cancelled and inventory item record is > already created so > a) ATP, QOH and AQT should decrease from old inventory item and ATP, QOH and > AQT should increase in the newly created inventory item. > Key points: > If the whole ATP and QOH is moved then new inventory item will not create. > Only Facility and location are changed for existing inventory item. > Before Changes:- > As I know there are following processes are associated with respective > statuses > **Note: ATP-> Available to promiseQOH-> Quantity on handAQT-> > Accounting quantity total > 1. Requested:- > ATP =0QOH=Transferred quantity >AQT=0 > 2. Scheduled:- > ATP =0QOH=Transferred quantity >AQT=0 > 3.En-Route:- > ATP =0QOH=Transferred quantity >AQT=0 > 4.Complete:- > If the partial quantity of any inventory item is transferred. > ATP =Transferred quantity QOH=Transferred quantity AQT=0 > If the whole quantity is transferred then only facility id and location > will change no new inventory item record will create. > 5.Cancelled:- > No new inventory item record will create.
[jira] [Updated] (OFBIZ-10040) Create a new entity FacilityCalendar
[ https://issues.apache.org/jira/browse/OFBIZ-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-10040: - Description: create a new entity facilityCalendar which will create the one-to-many relationship between facility and calendar. Here are the entity attributes: *FacilityCalendar* * facilityId* * calendarId* * facilityCalendarTypeId* * fromDate* * thruDate *FacilityCalendarType* * facilityCalendarTypeId* * parentTypeId * description A calendar will be used to store opening time, closing time, working weekdays and all this type of stuff. For further information please refer [http://ofbiz.markmail.org/message/nectwaze6ina7y6z?q=%5BProposal%5D+Extend+facility+entity] was: create a new entity facilityCalendar which will create the one-to-many relationship between facility and calendar. Here are the entity attributes: * facilityId* * calendarId* * fromDate* * thruDate A calendar will be used to store opening time, closing time, working weekdays and all this type of stuff. For further information please refer [http://ofbiz.markmail.org/message/nectwaze6ina7y6z?q=%5BProposal%5D+Extend+facility+entity] > Create a new entity FacilityCalendar > - > > Key: OFBIZ-10040 > URL: https://issues.apache.org/jira/browse/OFBIZ-10040 > Project: OFBiz > Issue Type: Improvement >Reporter: Vaibhav Jain >Assignee: Ayushi Rathod > > create a new entity facilityCalendar which will create the one-to-many > relationship between facility and calendar. Here are the entity attributes: > *FacilityCalendar* > * facilityId* > * calendarId* > * facilityCalendarTypeId* > * fromDate* > * thruDate > *FacilityCalendarType* > * facilityCalendarTypeId* > * parentTypeId > * description > A calendar will be used to store opening time, closing time, working weekdays > and all this type of stuff. > For further information please refer > [http://ofbiz.markmail.org/message/nectwaze6ina7y6z?q=%5BProposal%5D+Extend+facility+entity] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-10040) Create a new entity FacilityCalendar
[ https://issues.apache.org/jira/browse/OFBIZ-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281471#comment-16281471 ] Vaibhav Jain commented on OFBIZ-10040: -- +1 for *FacilityCalendarType* > Create a new entity FacilityCalendar > - > > Key: OFBIZ-10040 > URL: https://issues.apache.org/jira/browse/OFBIZ-10040 > Project: OFBiz > Issue Type: Improvement >Reporter: Vaibhav Jain > > create a new entity facilityCalendar which will create the one-to-many > relationship between facility and calendar. Here are the entity attributes: > * facilityId* > * calendarId* > * fromDate* > * thruDate > A calendar will be used to store opening time, closing time, working weekdays > and all this type of stuff. > For further information please refer > [http://ofbiz.markmail.org/message/nectwaze6ina7y6z?q=%5BProposal%5D+Extend+facility+entity] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-10040) Create a new entity FacilityCalendar
[ https://issues.apache.org/jira/browse/OFBIZ-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281471#comment-16281471 ] Vaibhav Jain edited comment on OFBIZ-10040 at 12/7/17 8:00 AM: --- +1 for *FacilityCalendarType*. Thanks, Nicolas and Jacques was (Author: vaibhav.jain): +1 for *FacilityCalendarType* > Create a new entity FacilityCalendar > - > > Key: OFBIZ-10040 > URL: https://issues.apache.org/jira/browse/OFBIZ-10040 > Project: OFBiz > Issue Type: Improvement >Reporter: Vaibhav Jain >Assignee: Ayushi Rathod > > create a new entity facilityCalendar which will create the one-to-many > relationship between facility and calendar. Here are the entity attributes: > * facilityId* > * calendarId* > * fromDate* > * thruDate > A calendar will be used to store opening time, closing time, working weekdays > and all this type of stuff. > For further information please refer > [http://ofbiz.markmail.org/message/nectwaze6ina7y6z?q=%5BProposal%5D+Extend+facility+entity] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-7481) ProductFacility record must exist before creating inventoryItem for a facility
[ https://issues.apache.org/jira/browse/OFBIZ-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain reassigned OFBIZ-7481: --- Assignee: Vaibhav Jain (was: Suraj Khurana) > ProductFacility record must exist before creating inventoryItem for a facility > -- > > Key: OFBIZ-7481 > URL: https://issues.apache.org/jira/browse/OFBIZ-7481 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: 14.12.01, 16.11.01, 15.12.01, 13.07.04 >Reporter: Suraj Khurana >Assignee: Vaibhav Jain > > ProductFacility entity is used to decide that a particular product is > maintained in which facility. So, in case of receiving a product in a > facility or in case creating InventoryItem for a facility, the > ProductFacility record must exist. But in these cases, currently in OFBiz > inventoryItem gets created even if ProductFacility record doesn't exist. > Proposed solution: > 1) In receiveInventoryProduct service check and create ProductFacility record > if not exist. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OFBIZ-10040) Create a new entity FacilityCalendar
Vaibhav Jain created OFBIZ-10040: Summary: Create a new entity FacilityCalendar Key: OFBIZ-10040 URL: https://issues.apache.org/jira/browse/OFBIZ-10040 Project: OFBiz Issue Type: Improvement Reporter: Vaibhav Jain create a new entity facilityCalendar which will create the one-to-many relationship between facility and calendar. Here are the entity attributes: * facilityId* * calendarId* * fromDate* * thruDate A calendar will be used to store opening time, closing time, working weekdays and all this type of stuff. For further information please refer [http://ofbiz.markmail.org/message/nectwaze6ina7y6z?q=%5BProposal%5D+Extend+facility+entity] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OFBIZ-9998) Remove paymentId, orderId and orderItemSeqId from finAccountTrans entity
Vaibhav Jain created OFBIZ-9998: --- Summary: Remove paymentId, orderId and orderItemSeqId from finAccountTrans entity Key: OFBIZ-9998 URL: https://issues.apache.org/jira/browse/OFBIZ-9998 Project: OFBiz Issue Type: Bug Components: accounting Reporter: Vaibhav Jain As per the discussion int respective mail thread [http://ofbiz.markmail.org/message/i2wk2anzrhacbltq?q=%5BPROPOSAL%5D+Extend+returnId+and+shipmentId+in+FinAccountTrans+entity] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OFBIZ-9842) Service level check is missing on transfer inventory
Vaibhav Jain created OFBIZ-9842: --- Summary: Service level check is missing on transfer inventory Key: OFBIZ-9842 URL: https://issues.apache.org/jira/browse/OFBIZ-9842 Project: OFBiz Issue Type: Bug Reporter: Vaibhav Jain If we mark Complete to the transferred inventory then transfer inventory run twice. Which corrupt the inventory data. Because service level check of status valid change is not working.Which corrupt the inventory data due to execution of SECA on it -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OFBIZ-9790) Billing account entity does not have support to manage the history of contact mech
Vaibhav Jain created OFBIZ-9790: --- Summary: Billing account entity does not have support to manage the history of contact mech Key: OFBIZ-9790 URL: https://issues.apache.org/jira/browse/OFBIZ-9790 Project: OFBiz Issue Type: Improvement Reporter: Vaibhav Jain Billing account entity has a field named "contactMechId". Actual: 1. We can update the postal address of billing account but we do not have the history of a postal address. 2. If contact mech of billing account is updated then we do not have the history of last billing account contact mech. Expected : 1. We should have the history of billing account. 2. we can introduce new entity "BillingAccountContactMech" where we can manage the history of billing account contact mech. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9475) Refactor serialize and non-serialize inventory item implementaion
[ https://issues.apache.org/jira/browse/OFBIZ-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-9475: Attachment: OFBIZ-9475.patch Here is the updated patch. Following changes are done in this patch. 1. Create inventory item detail for both serialized and non-serialized inventory item. 2. ATP, QOH, and AQT of both serialized and non-serialised inventory item are the sum of avilableToPromiseDiff, quantityOnHandDiffTotal and accountingQuantityTotal of inventory item detail entity. 3. Status of both inventory items is not entertaining yet. This will be done in next phase. 4. Removed statuses created specifically for the non-serialised inventory item. The Same status will be used for both serialized and non-serialised inventory item. > Refactor serialize and non-serialize inventory item implementaion > - > > Key: OFBIZ-9475 > URL: https://issues.apache.org/jira/browse/OFBIZ-9475 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Deepak Dixit >Assignee: Vaibhav Jain > Attachments: OFBIZ-9475.patch, OFBIZ-9475.patch, OFBIZ-9475.patch, > OFBIZ-9475.patch > > > As discussed on dev mailing list [1][2] we need to refactor serialize and > non-serialize inventory item design. > As per current implementation serialize inventory item work on status and > non-serialized inventory item work on inventory item detail. > Proposed Design: > - Use inventory item detail for both serialise and non-serialize inventory > item. Only one additional condition for serialized inventory item that qoh > can't be greater then one. > - We can maintain inventory item status record for both type > [1] http://markmail.org/thread/bd2bpiv6c5wvl7km > [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 > As we do a lot of discussion in the respective mail threads. > [1] http://markmail.org/thread/bd2bpiv6c5wvl7km > [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 > According to this email threads, I conclude that:- > There are 2 types of the inventory item in OFBiz. > 1. *Serialized* > 2. *Non serialized* > Majorly there are 3 entities to manage the various transaction of serialised > and non-serialized inventory items. > 1. _InventoryItem_ > 2. _InventoryItemDetail_ > 3. _InventoryItemStatus_ > Following changes need to be done in the workflow of inventory item records:- > 1) There is no need to manage a different workflow for serialised and non- > serialised inventory items. > 2) Transaction of serialised and non-serialised inventory item should be > managed in both InventoryItemStatus and InventoryItemDetail entity. > a) Transaction of serialised inventory items is managed by > inventoryItemstatus entity not managed in inventoryItemDetail entity. While > inventoryItemDetail and inventoryItemStatus should be managed for both > serialised and non-serialised inventory items. > b) As ATP/QOH/AQT are updated on the basis of ATPDIFF/QOHDIFF/AQTDIFF in > non-serialised inventory item. We should follow the same pattern for > serialised inventory item. > c) Change in ATP/QOH/AQT is tracked by inventoryItemDetail entity. > d)Status transaction of an inventory item is tracked in > InventoryItemStatus entity. > 3) No need to manage separate status for serialised and non-serialised > inventory item. They are already distinguished on the basis of inventory item > type. > 1. *Serialised*:- > In a serialised inventory item as of now ATP/QOH/AQT are managed on the > basis of inventory item status.While ATP/QOH/AQT should be the sum of > ATPDIFF/QOHDIFF/AQTDIFF of inventory item detail. > Ex: > 1. If we receive 2 inventory of serialised inventory item then 2 separate > inventory item records are created > InventoryItem:- > inventoryItemId="10001",status="AVAILABLE", ATP="1", QOH="1",AQT="1" > inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" > InventoryItemDetail:- > inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", > QOHDIFF="1", AQTDIFF="1" > inventoryItemId="10002", inventoryItemDetailSeqId="10002", ATPDIFF="1", > QOHDIFF="1", AQTDIFF="1" > InventoryItemStatus:- > inventoryItemId="10001" statusId="AVAILABLE" > inventoryItemId="10002" statusId="AVAILABLE" > 2. If status of inventory item is changed from AVAILABLE -> PROMISED then > InventoryItem:- > inventoryItemId="10001",status="PROMISED", ATP="1", QOH="1",AQT="1" > inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" > InventoryItemDetail:- > inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", > QOHDIFF="1", AQTDIFF="1" > inventoryItemId="10001", inventoryItemDetailSeqId="10002", ATPDIFF="-1", > QOHDIFF="0", AQTDIFF="0" > inventoryItemId="10002", inventoryItemDetailSeqId="10002",
[jira] [Created] (OFBIZ-9580) Use quantityUomId and unitsIncluded field of SupplierProduct entity
Vaibhav Jain created OFBIZ-9580:
---
Summary: Use quantityUomId and unitsIncluded field of
SupplierProduct entity
Key: OFBIZ-9580
URL: https://issues.apache.org/jira/browse/OFBIZ-9580
Project: OFBiz
Issue Type: Improvement
Affects Versions: Trunk
Reporter: Vaibhav Jain
Assignee: Vaibhav Jain
As of now _quantityUomId_ and _unitsIncluded_ fields of
{color:#59afe1}SupplierProdcut{color} entity are just informative fields. There
is no use of these fields in the code base.
A discussion is initiated to define the use of these fields. Here is the
reference
[http://ofbiz.markmail.org/search/?q=Quantity%20UOM%20in%20Supplier%20Product#query:Quantity%20UOM%20in%20Supplier%20Product+page:1+mid:wnvkuyfubn6dewzc+state:results]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OFBIZ-9475) Refactor serialize and non-serialize inventory item implementaion
[ https://issues.apache.org/jira/browse/OFBIZ-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-9475: Attachment: OFBIZ-9475.patch It is an initial patch in which direction I am working. I am still working on this fix. > Refactor serialize and non-serialize inventory item implementaion > - > > Key: OFBIZ-9475 > URL: https://issues.apache.org/jira/browse/OFBIZ-9475 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Deepak Dixit >Assignee: Vaibhav Jain > Attachments: OFBIZ-9475.patch > > > As discussed on dev mailing list [1][2] we need to refactor serialize and > non-serialize inventory item design. > As per current implementation serialize inventory item work on status and > non-serialized inventory item work on inventory item detail. > Proposed Design: > - Use inventory item detail for both serialise and non-serialize inventory > item. Only one additional condition for serialized inventory item that qoh > can't be greater then one. > - We can maintain inventory item status record for both type > [1] http://markmail.org/thread/bd2bpiv6c5wvl7km > [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 > As we do a lot of discussion in the respective mail threads. > [1] http://markmail.org/thread/bd2bpiv6c5wvl7km > [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 > According to this email threads, I conclude that:- > There are 2 types of the inventory item in OFBiz. > 1. *Serialized* > 2. *Non serialized* > Majorly there are 3 entities to manage the various transaction of serialised > and non-serialized inventory items. > 1. _InventoryItem_ > 2. _InventoryItemDetail_ > 3. _InventoryItemStatus_ > Following changes need to be done in the workflow of inventory item records:- > 1) There is no need to manage a different workflow for serialised and non- > serialised inventory items. > 2) Transaction of serialised and non-serialised inventory item should be > managed in both InventoryItemStatus and InventoryItemDetail entity. > a) Transaction of serialised inventory items is managed by > inventoryItemstatus entity not managed in inventoryItemDetail entity. While > inventoryItemDetail and inventoryItemStatus should be managed for both > serialised and non-serialised inventory items. > b) As ATP/QOH/AQT are updated on the basis of ATPDIFF/QOHDIFF/AQTDIFF in > non-serialised inventory item. We should follow the same pattern for > serialised inventory item. > c) Change in ATP/QOH/AQT is tracked by inventoryItemDetail entity. > d)Status transaction of an inventory item is tracked in > InventoryItemStatus entity. > 3) No need to manage separate status for serialised and non-serialised > inventory item. They are already distinguished on the basis of inventory item > type. > 1. *Serialised*:- > In a serialised inventory item as of now ATP/QOH/AQT are managed on the > basis of inventory item status.While ATP/QOH/AQT should be the sum of > ATPDIFF/QOHDIFF/AQTDIFF of inventory item detail. > Ex: > 1. If we receive 2 inventory of serialised inventory item then 2 separate > inventory item records are created > InventoryItem:- > inventoryItemId="10001",status="AVAILABLE", ATP="1", QOH="1",AQT="1" > inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" > InventoryItemDetail:- > inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", > QOHDIFF="1", AQTDIFF="1" > inventoryItemId="10002", inventoryItemDetailSeqId="10002", ATPDIFF="1", > QOHDIFF="1", AQTDIFF="1" > InventoryItemStatus:- > inventoryItemId="10001" statusId="AVAILABLE" > inventoryItemId="10002" statusId="AVAILABLE" > 2. If status of inventory item is changed from AVAILABLE -> PROMISED then > InventoryItem:- > inventoryItemId="10001",status="PROMISED", ATP="1", QOH="1",AQT="1" > inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" > InventoryItemDetail:- > inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", > QOHDIFF="1", AQTDIFF="1" > inventoryItemId="10001", inventoryItemDetailSeqId="10002", ATPDIFF="-1", > QOHDIFF="0", AQTDIFF="0" > inventoryItemId="10002", inventoryItemDetailSeqId="10002", ATPDIFF="1", > QOHDIFF="1", AQTDIFF="1" > InventoryItemStatus:- > inventoryItemId="10001" statusId="AVAILABLE" statusEndDateTime="" > inventoryItemId="10002" statusId="PROMISED" > 2. *Non-serialised*:- > At the time of receive non-serialised inventory, Item should be received > in Available status. So that status of non-serialised inventory item can be > managed further. > Status of non-serialised inventory item should be managed at inventory > item level not on inventory item detail level i.e. there are limited > inventory item status for non-serialised inventory items >
[jira] [Updated] (OFBIZ-9475) Refactor serialize and non-serialize inventory item implementaion
[ https://issues.apache.org/jira/browse/OFBIZ-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-9475: Description: As discussed on dev mailing list [1][2] we need to refactor serialize and non-serialize inventory item design. As per current implementation serialize inventory item work on status and non-serialized inventory item work on inventory item detail. Proposed Design: - Use inventory item detail for both serialise and non-serialize inventory item. Only one additional condition for serialized inventory item that qoh can't be greater then one. - We can maintain inventory item status record for both type [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 As we do a lot of discussion in the respective mail threads. [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 According to this email threads, I conclude that:- There are 2 types of the inventory item in OFBiz. 1. *Serialized* 2. *Non serialized* Majorly there are 3 entities to manage the various transaction of serialised and non-serialized inventory items. 1. _InventoryItem_ 2. _InventoryItemDetail_ 3. _InventoryItemStatus_ Following changes need to be done in the workflow of inventory item records:- 1) There is no need to manage a different workflow for serialised and non- serialised inventory items. 2) Transaction of serialised and non-serialised inventory item should be managed in both InventoryItemStatus and InventoryItemDetail entity. a) Transaction of serialised inventory items is managed by inventoryItemstatus entity not managed in inventoryItemDetail entity. While inventoryItemDetail and inventoryItemStatus should be managed for both serialised and non-serialised inventory items. b) As ATP/QOH/AQT are updated on the basis of ATPDIFF/QOHDIFF/AQTDIFF in non-serialised inventory item. We should follow the same pattern for serialised inventory item. c) Change in ATP/QOH/AQT is tracked by inventoryItemDetail entity. d)Status transaction of an inventory item is tracked in InventoryItemStatus entity. 3) No need to manage separate status for serialised and non-serialised inventory item. They are already distinguished on the basis of inventory item type. 1. *Serialised*:- In a serialised inventory item as of now ATP/QOH/AQT are managed on the basis of inventory item status.While ATP/QOH/AQT should be the sum of ATPDIFF/QOHDIFF/AQTDIFF of inventory item detail. Ex: 1. If we receive 2 inventory of serialised inventory item then 2 separate inventory item records are created InventoryItem:- inventoryItemId="10001",status="AVAILABLE", ATP="1", QOH="1",AQT="1" inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" InventoryItemDetail:- inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" inventoryItemId="10002", inventoryItemDetailSeqId="10002", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" InventoryItemStatus:- inventoryItemId="10001" statusId="AVAILABLE" inventoryItemId="10002" statusId="AVAILABLE" 2. If status of inventory item is changed from AVAILABLE -> PROMISED then InventoryItem:- inventoryItemId="10001",status="PROMISED", ATP="1", QOH="1",AQT="1" inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" InventoryItemDetail:- inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" inventoryItemId="10001", inventoryItemDetailSeqId="10002", ATPDIFF="-1", QOHDIFF="0", AQTDIFF="0" inventoryItemId="10002", inventoryItemDetailSeqId="10002", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" InventoryItemStatus:- inventoryItemId="10001" statusId="AVAILABLE" statusEndDateTime="" inventoryItemId="10002" statusId="PROMISED" 2. *Non-serialised*:- At the time of receive non-serialised inventory, Item should be received in Available status. So that status of non-serialised inventory item can be managed further. Status of non-serialised inventory item should be managed at inventory item level not on inventory item detail level i.e. there are limited inventory item status for non-serialised inventory items Ex: 1. If we receive 10 inventory of non-serialised inventory item. The inventory will receive in Available status. InventoryItem:- status="AVAILABLE", ATP="10", QOH="10",AQT="10" InventoryItemDetail:- ATPDIFF="10", QOHDIFF="10",AQTDIFF="10" Now if we place an order 4 quantity and reservation happens then InventoryItem:- status="AVAILABLE", ATP="6", QOH="10",AQT="10" InventoryItemDetail:- ATPDIFF="10", QOHDIFF="10",AQTDIFF="10" ATPDIFF="-4", QOHDIFF="0",AQTDIFF="0" InventoryItemStatus:- status="AVAILABLE" 2. If status of inventory item is changed from Available -> Defective then InventoryItem:- status="DEFECTIVE", ATP="0", QOH="10",AQT="10" InventoryItemDetail:- ATPDIFF="10",
[jira] [Updated] (OFBIZ-9475) Refactor serialize and non-serialize inventory item implementaion
[ https://issues.apache.org/jira/browse/OFBIZ-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-9475: Description: As discussed on dev mailing list [1][2] we need to refactor serialize and non-serialize inventory item design. As per current implementation serialize inventory item work on status and non-serialized inventory item work on inventory item detail. Proposed Design: - Use inventory item detail for both serialize and non-serialize inventory item. Only one additional condition for serialized inventory item that qoh can't be greater then one. - We can maintain inventory item status record for both type [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 As we do a lot of discussion in the respective mail threads. [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 According to this email threads, I conclude that:- There are 2 types of the inventory item in OFBiz. 1. Serialized 2. Non serialized Majorly there are 3 entities to manage the various transaction of serialised and non-serialized inventory items. 1. InventoryItem 2. InventoryItemDetail 3. InventoryItemStatus Following changes need to be done in the workflow of inventory item records:- 1) There is no need to manage a different workflow for serialised and non- serialised inventory items. 2) Transaction of serialised and non-serialised inventory item should be managed in both InventoryItemStatus and InventoryItemDetail entity. a) Transaction of serialised inventory items is managed by inventoryItemstatus entity not managed in inventoryItemDetail entity. While inventoryItemDetail and inventoryItemStatus should be managed for both serialised and non-serialised inventory items. b) As ATP/QOH/AQT are updated on the basis of ATPDIFF/QOHDIFF/AQTDIFF in non-serialised inventory item. We should follow the same pattern for serialised inventory item. c) Change in ATP/QOH/AQT is tracked by inventoryItemDetail entity. d)Status transaction of an inventory item is tracked in InventoryItemStatus entity. 3) No need to manage separate status for serialised and non-serialised inventory item. They are already distinguished on the basis of inventory item type. 1. Serialised:- In a serialised inventory item as of now ATP/QOH/AQT are managed on the basis of inventory item status.While ATP/QOH/AQT should be the sum of ATPDIFF/QOHDIFF/AQTDIFF of inventory item detail. Ex: 1. If we receive 2 inventory of serialised inventory item then 2 separate inventory item records are created InventoryItem:- inventoryItemId="10001",status="AVAILABLE", ATP="1", QOH="1",AQT="1" inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" InventoryItemDetail:- inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" inventoryItemId="10002", inventoryItemDetailSeqId="10002", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" InventoryItemStatus:- inventoryItemId="10001" statusId="AVAILABLE" inventoryItemId="10002" statusId="AVAILABLE" 2. If status of inventory item is changed from AVAILABLE -> PROMISED then InventoryItem:- inventoryItemId="10001",status="PROMISED", ATP="1", QOH="1",AQT="1" inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" InventoryItemDetail:- inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" inventoryItemId="10001", inventoryItemDetailSeqId="10002", ATPDIFF="-1", QOHDIFF="0", AQTDIFF="0" inventoryItemId="10002", inventoryItemDetailSeqId="10002", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" InventoryItemStatus:- inventoryItemId="10001" statusId="AVAILABLE" statusEndDateTime="" inventoryItemId="10002" statusId="PROMISED" 2. Non-serialised:- At the time of receive non-serialised inventory, Item should be received in Available status. So that status of non-serialised inventory item can be managed further. Status of non-serialised inventory item should be managed at inventory item level not on inventory item detail level i.e. there are limited inventory item status for non-serialised inventory items Ex: 1. If we receive 10 inventory of non-serialised inventory item. The inventory will receive in Available status. InventoryItem:- status="AVAILABLE", ATP="10", QOH="10",AQT="10" InventoryItemDetail:- ATPDIFF="10", QOHDIFF="10",AQTDIFF="10" Now if we place an order 4 quantity and reservation happens then InventoryItem:- status="AVAILABLE", ATP="6", QOH="10",AQT="10" InventoryItemDetail:- ATPDIFF="10", QOHDIFF="10",AQTDIFF="10" ATPDIFF="-4", QOHDIFF="0",AQTDIFF="0" InventoryItemStatus:- status="AVAILABLE" 2. If status of inventory item is changed from Available -> Defective then InventoryItem:- status="DEFECTIVE", ATP="0", QOH="10",AQT="10" InventoryItemDetail:- ATPDIFF="10",
[jira] [Updated] (OFBIZ-9475) Refactor serialize and non-serialize inventory item implementaion
[ https://issues.apache.org/jira/browse/OFBIZ-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-9475: Description: As discussed on dev mailing list [1][2] we need to refactor serialize and non-serialize inventory item design. As per current implementation serialize inventory item work on status and non-serialized inventory item work on inventory item detail. Proposed Design: - Use inventory item detail for both serialise and non-serialize inventory item. Only one additional condition for serialized inventory item that qoh can't be greater then one. - We can maintain inventory item status record for both type [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 As we do a lot of discussion in the respective mail threads. [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 According to this email threads, I conclude that:- There are 2 types of the inventory item in OFBiz. 1. Serialized 2. Non serialized Majorly there are 3 entities to manage the various transaction of serialised and non-serialized inventory items. 1. InventoryItem 2. InventoryItemDetail 3. InventoryItemStatus Following changes need to be done in the workflow of inventory item records:- 1) There is no need to manage a different workflow for serialised and non- serialised inventory items. 2) Transaction of serialised and non-serialised inventory item should be managed in both InventoryItemStatus and InventoryItemDetail entity. a) Transaction of serialised inventory items is managed by inventoryItemstatus entity not managed in inventoryItemDetail entity. While inventoryItemDetail and inventoryItemStatus should be managed for both serialised and non-serialised inventory items. b) As ATP/QOH/AQT are updated on the basis of ATPDIFF/QOHDIFF/AQTDIFF in non-serialised inventory item. We should follow the same pattern for serialised inventory item. c) Change in ATP/QOH/AQT is tracked by inventoryItemDetail entity. d)Status transaction of an inventory item is tracked in InventoryItemStatus entity. 3) No need to manage separate status for serialised and non-serialised inventory item. They are already distinguished on the basis of inventory item type. 1. *Serialised*:- In a serialised inventory item as of now ATP/QOH/AQT are managed on the basis of inventory item status.While ATP/QOH/AQT should be the sum of ATPDIFF/QOHDIFF/AQTDIFF of inventory item detail. Ex: 1. If we receive 2 inventory of serialised inventory item then 2 separate inventory item records are created InventoryItem:- inventoryItemId="10001",status="AVAILABLE", ATP="1", QOH="1",AQT="1" inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" InventoryItemDetail:- inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" inventoryItemId="10002", inventoryItemDetailSeqId="10002", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" InventoryItemStatus:- inventoryItemId="10001" statusId="AVAILABLE" inventoryItemId="10002" statusId="AVAILABLE" 2. If status of inventory item is changed from AVAILABLE -> PROMISED then InventoryItem:- inventoryItemId="10001",status="PROMISED", ATP="1", QOH="1",AQT="1" inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" InventoryItemDetail:- inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" inventoryItemId="10001", inventoryItemDetailSeqId="10002", ATPDIFF="-1", QOHDIFF="0", AQTDIFF="0" inventoryItemId="10002", inventoryItemDetailSeqId="10002", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" InventoryItemStatus:- inventoryItemId="10001" statusId="AVAILABLE" statusEndDateTime="" inventoryItemId="10002" statusId="PROMISED" 2. *Non-serialised*:- At the time of receive non-serialised inventory, Item should be received in Available status. So that status of non-serialised inventory item can be managed further. Status of non-serialised inventory item should be managed at inventory item level not on inventory item detail level i.e. there are limited inventory item status for non-serialised inventory items Ex: 1. If we receive 10 inventory of non-serialised inventory item. The inventory will receive in Available status. InventoryItem:- status="AVAILABLE", ATP="10", QOH="10",AQT="10" InventoryItemDetail:- ATPDIFF="10", QOHDIFF="10",AQTDIFF="10" Now if we place an order 4 quantity and reservation happens then InventoryItem:- status="AVAILABLE", ATP="6", QOH="10",AQT="10" InventoryItemDetail:- ATPDIFF="10", QOHDIFF="10",AQTDIFF="10" ATPDIFF="-4", QOHDIFF="0",AQTDIFF="0" InventoryItemStatus:- status="AVAILABLE" 2. If status of inventory item is changed from Available -> Defective then InventoryItem:- status="DEFECTIVE", ATP="0", QOH="10",AQT="10" InventoryItemDetail:- ATPDIFF="10",
[jira] [Updated] (OFBIZ-9475) Refactor serialize and non-serialize inventory item implementaion
[ https://issues.apache.org/jira/browse/OFBIZ-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-9475: Description: As discussed on dev mailing list [1][2] we need to refactor serialize and non-serialize inventory item design. As per current implementation serialize inventory item work on status and non-serialized inventory item work on inventory item detail. Proposed Design: - Use inventory item detail for both serialize and non-serialize inventory item. Only one additional condition for serialized inventory item that qoh can't be greater then one. - We can maintain inventory item status record for both type [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 As we do a lot of discussion in the respective mail threads. [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 According to this email threads, I conclude that:- There are 2 types of the inventory item in OFBiz. 1. Serialized 2. Non serialized Majorly there are 3 entities to manage the various transaction of serialised and non-serialized inventory items. 1. InventoryItem 2. InventoryItemDetail 3. InventoryItemStatus Following changes need to be done in the workflow of inventory item records:- 1) There is no need to manage a different workflow for serialised and non- serialised inventory items. 2) Transaction of serialised and non-serialised inventory item should be managed in both InventoryItemStatus and InventoryItemDetail entity. a) Transaction of serialised inventory items is managed by inventoryItemstatus entity not managed in inventoryItemDetail entity. While inventoryItemDetail and inventoryItemStatus should be managed for both serialised and non-serialised inventory items. b) As ATP/QOH/AQT are updated on the basis of ATPDIFF/QOHDIFF/AQTDIFF in non-serialised inventory item. We should follow the same pattern for serialised inventory item. c) Change in ATP/QOH/AQT is tracked by inventoryItemDetail entity. d)Status transaction of an inventory item is tracked in InventoryItemStatus entity. 3) No need to manage separate status for serialised and non-serialised inventory item. They are already distinguished on the basis of inventory item type. There are 2 cases for inventory items: 1. Serialised 2. Non-serialised 1. Serialised:- In a serialised inventory item as of now ATP/QOH/AQT are managed on the basis of inventory item status.While ATP/QOH/AQT should be the sum of ATPDIFF/QOHDIFF/AQTDIFF of inventory item detail. Ex: 1. If we receive 2 inventory of serialised inventory item then 2 separate inventory item records are created InventoryItem:- inventoryItemId="10001",status="AVAILABLE", ATP="1", QOH="1",AQT="1" inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" InventoryItemDetail:- inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" inventoryItemId="10002", inventoryItemDetailSeqId="10002", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" InventoryItemStatus:- inventoryItemId="10001" statusId="AVAILABLE" inventoryItemId="10002" statusId="AVAILABLE" 2. If status of inventory item is changed from AVAILABLE -> PROMISED then InventoryItem:- inventoryItemId="10001",status="PROMISED", ATP="1", QOH="1",AQT="1" inventoryItemId="10002",status="AVAILABLE", ATP="1", QOH="1",AQT="1" InventoryItemDetail:- inventoryItemId="10001", inventoryItemDetailSeqId="10001", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" inventoryItemId="10001", inventoryItemDetailSeqId="10002", ATPDIFF="-1", QOHDIFF="0", AQTDIFF="0" inventoryItemId="10002", inventoryItemDetailSeqId="10002", ATPDIFF="1", QOHDIFF="1", AQTDIFF="1" InventoryItemStatus:- inventoryItemId="10001" statusId="AVAILABLE" statusEndDateTime="" inventoryItemId="10002" statusId="PROMISED" 2. Non-serialised:- At the time of receive non-serialised inventory, Item should be received in Available status. So that status of non-serialised inventory item can be managed further. Status of non-serialised inventory item should be managed at inventory item level not on inventory item detail level i.e. there are limited inventory item status for non-serialised inventory items Ex: 1. If we receive 10 inventory of non-serialised inventory item. The inventory will receive in Available status. InventoryItem:- status="AVAILABLE", ATP="10", QOH="10",AQT="10" InventoryItemDetail:- ATPDIFF="10", QOHDIFF="10",AQTDIFF="10" Now if we place an order 4 quantity and reservation happens then InventoryItem:- status="AVAILABLE", ATP="6", QOH="10",AQT="10" InventoryItemDetail:- ATPDIFF="10", QOHDIFF="10",AQTDIFF="10" ATPDIFF="-4", QOHDIFF="0",AQTDIFF="0" InventoryItemStatus:- status="AVAILABLE" 2. If status of inventory item is changed from Available -> Defective then InventoryItem:- status="DEFECTIVE", ATP="0",
[jira] [Assigned] (OFBIZ-9464) Accounting quantity transfer should not be zero while transferring inventory from one facility to another
[ https://issues.apache.org/jira/browse/OFBIZ-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain reassigned OFBIZ-9464: --- Assignee: Vaibhav Jain (was: Divesh Dutta) > Accounting quantity transfer should not be zero while transferring inventory > from one facility to another > - > > Key: OFBIZ-9464 > URL: https://issues.apache.org/jira/browse/OFBIZ-9464 > Project: OFBiz > Issue Type: Bug >Affects Versions: Trunk >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain > Labels: inventory, stock, valuation > Fix For: 16.11.04 > > Attachments: OFBIZ_9464.patch > > > when we transfer inventory, the accountingQuantityTotal field of > _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in > accountingQuantityTotal. > This will create following issues in the system. > # Accounting quantity total will mismatch with the original quantity in the > facility which shows the wrong result when we calculate facility specific > inventory valuation. > # Inventory reservation also throws an error in some specific case like when > AQT of respective product is zero in the specific facility from when > reservation happens. > As we manage 5 different statuses of inventory transfer in OFBiz and > according to my current understanding these processes are associated with the > respective statuses, which are as show below > Requested: As inventory transfer is requested for another facility. > a)ATP, QOH and AQT should decrease from the inventory item of From Facility > and QOH of To Facility should increase. > b)ATP and AQT should be Zero in To Facility as inventory is not transferred > yet. But QOH should increase at To Facility because QOH shows the > xferquantity later. At the time of the completion of the transfer > ATP = ATP + (QOH - ATP) (Adjustment in case of backorder) > AQT = QOH > b)AQT should not decrease because AQT is used for accounting purpose and as > of now quantity is still in From Facility as the transfer is not done yet. > which shows the xferQuantity later > Scheduled: As inventory transfer is Scheduled for another facility. ATP, QOH > and AQT should not affect in both From Facility and To Facility. > En-route: As inventory is routed to reach at To Facility. Even in this case > ATP, QOH and AQT should not affect in both From Facility and To Facility. > Complete: As inventory transfer is completed > a)ATP, QOH and AQT should not affect at From Facility. > b)QOH will be same but ATP and AQT should affect respectively > ATP = ATP + (QOH - ATP) > AQT = QOH > Cancelled: As inventory transfer is cancelled and inventory item record is > already created so > a) ATP, QOH and AQT should decrease from old inventory item and ATP, QOH and > AQT should increase in the newly created inventory item. > Key points: > If the whole ATP and QOH is moved then new inventory item will not create. > Only Facility and location are changed for existing inventory item. > Before Changes:- > As I know there are following processes are associated with respective > statuses > **Note: ATP-> Available to promiseQOH-> Quantity on handAQT-> > Accounting quantity total > 1. Requested:- > ATP =0QOH=Transferred quantity >AQT=0 > 2. Scheduled:- > ATP =0QOH=Transferred quantity >AQT=0 > 3.En-Route:- > ATP =0QOH=Transferred quantity >AQT=0 > 4.Complete:- > If the partial quantity of any inventory item is transferred. > ATP =Transferred quantity QOH=Transferred quantity AQT=0 > If the whole quantity is transferred then only facility id and location > will change no new inventory item record will create. > 5.Cancelled:- > No new inventory item record will create. An inventory transfer record is > created with whole ATP/QOH in cancelled status. > After Changes:- > As shown above, accounting quantity transfer will not affect in transfer > inventory. After the following changes, records will be updated a shown below. > 1. Requested:- > ATP =0QOH=Transferred quantity >AQT=0 > 2. Scheduled:- > ATP =0QOH=Transferred quantity >AQT=0 > 3.En-Route:- > ATP =0QOH=Transferred quantity >AQT=0 > 4.Complete:- > If the partial quantity of any inventory item is transferred. > ATP =Transferred quantity QOH=Transferred quantity > AQT=Transferred quantity > If the whole quantity is transferred then only facility id and location > will change no new inventory item
[jira] [Commented] (OFBIZ-9464) Accounting quantity transfer should not be zero while transferring inventory from one facility to another
[ https://issues.apache.org/jira/browse/OFBIZ-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16100605#comment-16100605 ] Vaibhav Jain commented on OFBIZ-9464: - Hi Paul, Thanks for pointing out this two scenario which will affect due to this changes. I am working on it. > Accounting quantity transfer should not be zero while transferring inventory > from one facility to another > - > > Key: OFBIZ-9464 > URL: https://issues.apache.org/jira/browse/OFBIZ-9464 > Project: OFBiz > Issue Type: Bug >Affects Versions: Trunk >Reporter: Vaibhav Jain >Assignee: Divesh Dutta > Labels: inventory, stock, valuation > Fix For: 16.11.04 > > Attachments: OFBIZ_9464.patch > > > when we transfer inventory, the accountingQuantityTotal field of > _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in > accountingQuantityTotal. > This will create following issues in the system. > # Accounting quantity total will mismatch with the original quantity in the > facility which shows the wrong result when we calculate facility specific > inventory valuation. > # Inventory reservation also throws an error in some specific case like when > AQT of respective product is zero in the specific facility from when > reservation happens. > As we manage 5 different statuses of inventory transfer in OFBiz and > according to my current understanding these processes are associated with the > respective statuses, which are as show below > Requested: As inventory transfer is requested for another facility. > a)ATP, QOH and AQT should decrease from the inventory item of From Facility > and QOH of To Facility should increase. > b)ATP and AQT should be Zero in To Facility as inventory is not transferred > yet. But QOH should increase at To Facility because QOH shows the > xferquantity later. At the time of the completion of the transfer > ATP = ATP + (QOH - ATP) (Adjustment in case of backorder) > AQT = QOH > b)AQT should not decrease because AQT is used for accounting purpose and as > of now quantity is still in From Facility as the transfer is not done yet. > which shows the xferQuantity later > Scheduled: As inventory transfer is Scheduled for another facility. ATP, QOH > and AQT should not affect in both From Facility and To Facility. > En-route: As inventory is routed to reach at To Facility. Even in this case > ATP, QOH and AQT should not affect in both From Facility and To Facility. > Complete: As inventory transfer is completed > a)ATP, QOH and AQT should not affect at From Facility. > b)QOH will be same but ATP and AQT should affect respectively > ATP = ATP + (QOH - ATP) > AQT = QOH > Cancelled: As inventory transfer is cancelled and inventory item record is > already created so > a) ATP, QOH and AQT should decrease from old inventory item and ATP, QOH and > AQT should increase in the newly created inventory item. > Key points: > If the whole ATP and QOH is moved then new inventory item will not create. > Only Facility and location are changed for existing inventory item. > Before Changes:- > As I know there are following processes are associated with respective > statuses > **Note: ATP-> Available to promiseQOH-> Quantity on handAQT-> > Accounting quantity total > 1. Requested:- > ATP =0QOH=Transferred quantity >AQT=0 > 2. Scheduled:- > ATP =0QOH=Transferred quantity >AQT=0 > 3.En-Route:- > ATP =0QOH=Transferred quantity >AQT=0 > 4.Complete:- > If the partial quantity of any inventory item is transferred. > ATP =Transferred quantity QOH=Transferred quantity AQT=0 > If the whole quantity is transferred then only facility id and location > will change no new inventory item record will create. > 5.Cancelled:- > No new inventory item record will create. An inventory transfer record is > created with whole ATP/QOH in cancelled status. > After Changes:- > As shown above, accounting quantity transfer will not affect in transfer > inventory. After the following changes, records will be updated a shown below. > 1. Requested:- > ATP =0QOH=Transferred quantity >AQT=0 > 2. Scheduled:- > ATP =0QOH=Transferred quantity >AQT=0 > 3.En-Route:- > ATP =0QOH=Transferred quantity >AQT=0 > 4.Complete:- > If the partial quantity of any inventory item is transferred. > ATP =Transferred quantity QOH=Transferred quantity > AQT=Transferred quantity > If the
[jira] [Updated] (OFBIZ-9475) Refactor serialize and non-serialize inventory item implementaion
[ https://issues.apache.org/jira/browse/OFBIZ-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-9475: Description: As discussed on dev mailing list [1][2] we need to refactor serialize and non-serialize inventory item design. As per current implementation serialize inventory item work on status and non-serialized inventory item work on inventory item detail. Proposed Design: - Use inventory item detail for both serialize and non-serialize inventory item. Only one additional condition for serialized inventory item that qoh can't be greater then one. - We can maintain inventory item status record for both type [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 As we do a lot of discussion in the respective mail threads. [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 According to this email threads, I conclude that:- There are 2 types of the inventory item in OFBiz. 1. Serialized 2. Non serialized Majorly there are 3 entities to manage the various transaction of serialised and non-serialized inventory items. 1. InventoryItem 2. InventoryItemDetail 3. InventoryItemStatus Following changes need to be done in the workflow of inventory item records:- 1) There is no need to manage a different workflow for serialised and non- serialised inventory items. 2) Transaction of serialised and non-serialised inventory item should be managed in both InventoryItemStatus and InventoryItemDetail entity. a) Transaction of serialised inventory items is managed by inventoryItemstatus entity not managed in inventoryItemDetail entity. While inventoryItemDetail and inventoryItemStatus should be managed for both serialised and non-serialised inventory items. b) As ATP/QOH/AQT are updated on the basis of ATPDIFF/QOHDIFF/AQTDIFF in non-serialised inventory item. We should follow the same pattern for serialised inventory item. 3) No need to manage separate status for serialised and non-serialised inventory item. was: As discussed on dev mailing list [1][2] we need to refactor serialize and non-serialize inventory item design. As per current implementation serialize inventory item work on status and non-serialized inventory item work on inventory item detail. Proposed Design: - Use inventory item detail for both serialize and non-serialize inventory item. Only one additional condition for serialized inventory item that qoh can't be greater then one. - We can maintain inventory item status record for both type [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 As we do a lot of discussion in the respective mail threads. [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 According to this email threads, I conclude that:- There are 2 types of the inventory item in OFBiz. 1. Serialized 2. Non serialized Majorly there are 3 entities to manage the various transaction of serialised and non-serialized inventory items. 1. InventoryItem 2. InventoryItemDetail 3. InventoryItemStatus Following changes need to be done in the workflow of inventory item records:- 1) There is no need to manage a different workflow for serialised and non- serialised inventory items. 2) Transaction of serialised and non-serialised inventory item should be managed in both InventoryItemStatus and InventoryItemDetail entity. a) Transaction of serialised inventory items is managed by inventoryItemstatus entity not managed in inventoryItemDetail entity. While inventoryItemDetail and inventoryItemStatus should be managed for both serialised and non-serialised inventory items. b) As ATP/QOH/AQT are updated on the basis of ATPDIFF/QOHDIFF/AQTDIFF in non-serialised inventory item. We should follow the same pattern for serialised inventory item. > Refactor serialize and non-serialize inventory item implementaion > - > > Key: OFBIZ-9475 > URL: https://issues.apache.org/jira/browse/OFBIZ-9475 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Deepak Dixit >Assignee: Renuka Srishti > > As discussed on dev mailing list [1][2] we need to refactor serialize and > non-serialize inventory item design. > As per current implementation serialize inventory item work on status and > non-serialized inventory item work on inventory item detail. > Proposed Design: > - Use inventory item detail for both serialize and non-serialize inventory > item. Only one additional condition for serialized inventory item that qoh > can't be greater then one. > - We can maintain inventory item status record for both type > [1] http://markmail.org/thread/bd2bpiv6c5wvl7km > [2]
[jira] [Updated] (OFBIZ-9475) Refactor serialize and non-serialize inventory item implementaion
[ https://issues.apache.org/jira/browse/OFBIZ-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-9475: Description: As discussed on dev mailing list [1][2] we need to refactor serialize and non-serialize inventory item design. As per current implementation serialize inventory item work on status and non-serialized inventory item work on inventory item detail. Proposed Design: - Use inventory item detail for both serialize and non-serialize inventory item. Only one additional condition for serialized inventory item that qoh can't be greater then one. - We can maintain inventory item status record for both type [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 As we do a lot of discussion in the respective mail threads. [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 According to this email threads, I conclude that:- There are 2 types of the inventory item in OFBiz. 1. Serialized 2. Non serialized Majorly there are 3 entities to manage the various transaction of serialised and non-serialized inventory items. 1. InventoryItem 2. InventoryItemDetail 3. InventoryItemStatus Following changes need to be done in the workflow of inventory item records:- 1) There is no need to manage a different workflow for serialised and non- serialised inventory items. 2) Transaction of serialised and non-serialised inventory item should be managed in both InventoryItemStatus and InventoryItemDetail entity. a) Transaction of serialised inventory items is managed by inventoryItemstatus entity not managed in inventoryItemDetail entity. While inventoryItemDetail and inventoryItemStatus should be managed for both serialised and non-serialised inventory items. b) As ATP/QOH/AQT are updated on the basis of ATPDIFF/QOHDIFF/AQTDIFF in non-serialised inventory item. We should follow the same pattern for serialised inventory item. was: As discussed on dev mailing list [1][2] we need to refactor serialize and non-serialize inventory item design. As per current implementation serialize inventory item work on status and non-serialized inventory item work on inventory item detail. Proposed Design: - Use inventory item detail for both serialize and non-serialize inventory item. Only one additional condition for serialized inventory item that qoh can't be greater then one. - We can maintain inventory item status record for both type [1] http://markmail.org/thread/bd2bpiv6c5wvl7km [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 > Refactor serialize and non-serialize inventory item implementaion > - > > Key: OFBIZ-9475 > URL: https://issues.apache.org/jira/browse/OFBIZ-9475 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Deepak Dixit >Assignee: Renuka Srishti > > As discussed on dev mailing list [1][2] we need to refactor serialize and > non-serialize inventory item design. > As per current implementation serialize inventory item work on status and > non-serialized inventory item work on inventory item detail. > Proposed Design: > - Use inventory item detail for both serialize and non-serialize inventory > item. Only one additional condition for serialized inventory item that qoh > can't be greater then one. > - We can maintain inventory item status record for both type > [1] http://markmail.org/thread/bd2bpiv6c5wvl7km > [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 > As we do a lot of discussion in the respective mail threads. > [1] http://markmail.org/thread/bd2bpiv6c5wvl7km > [2] http://ofbiz.markmail.org/thread/kro5kcggp4fcose7 > According to this email threads, I conclude that:- > There are 2 types of the inventory item in OFBiz. > 1. Serialized > 2. Non serialized > Majorly there are 3 entities to manage the various transaction of serialised > and non-serialized inventory items. > 1. InventoryItem > 2. InventoryItemDetail > 3. InventoryItemStatus > Following changes need to be done in the workflow of inventory item records:- > 1) There is no need to manage a different workflow for serialised and non- > serialised inventory items. > 2) Transaction of serialised and non-serialised inventory item should be > managed in both InventoryItemStatus and InventoryItemDetail entity. > a) Transaction of serialised inventory items is managed by > inventoryItemstatus entity not managed in inventoryItemDetail entity. While > inventoryItemDetail and inventoryItemStatus should be managed for both > serialised and non-serialised inventory items. > b) As ATP/QOH/AQT are updated on the basis of ATPDIFF/QOHDIFF/AQTDIFF in > non-serialised inventory item. We should follow the same pattern for > serialised inventory item. --
[jira] [Updated] (OFBIZ-9464) Accounting quantity transfer should not be zero while transferring inventory from one facility to another
[ https://issues.apache.org/jira/browse/OFBIZ-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-9464: Attachment: OFBIZ_9464.patch Added accounting quantity total field for creating a new record for inventory item detail at the time inventory transfer. > Accounting quantity transfer should not be zero while transferring inventory > from one facility to another > - > > Key: OFBIZ-9464 > URL: https://issues.apache.org/jira/browse/OFBIZ-9464 > Project: OFBiz > Issue Type: Bug >Affects Versions: Trunk >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain > Fix For: Trunk > > Attachments: OFBIZ_9464.patch > > > when we transfer inventory, the accountingQuantityTotal field of > _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in > accountingQuantityTotal. > This will create following issues in the system. > # Accounting quantity total will mismatch with the original quantity in the > facility which shows the wrong result when we calculate facility specific > inventory valuation. > # Inventory reservation also throws an error in some specific case like when > AQT of respective product is zero in the specific facility from when > reservation happens. > As we manage 5 different statuses of inventory transfer in OFBiz and > according to my current understanding these processes are associated with the > respective statuses, which are as show below > Requested: As inventory transfer is requested for another facility. > a)ATP, QOH and AQT should decrease from the inventory item of From Facility > and QOH of To Facility should increase. > b)ATP and AQT should be Zero in To Facility as inventory is not transferred > yet. But QOH should increase at To Facility because QOH shows the > xferquantity later. At the time of the completion of the transfer > ATP = ATP + (QOH - ATP) (Adjustment in case of backorder) > AQT = QOH > b)AQT should not decrease because AQT is used for accounting purpose and as > of now quantity is still in From Facility as the transfer is not done yet. > which shows the xferQuantity later > Scheduled: As inventory transfer is Scheduled for another facility. ATP, QOH > and AQT should not affect in both From Facility and To Facility. > En-route: As inventory is routed to reach at To Facility. Even in this case > ATP, QOH and AQT should not affect in both From Facility and To Facility. > Complete: As inventory transfer is completed > a)ATP, QOH and AQT should not affect at From Facility. > b)QOH will be same but ATP and AQT should affect respectively > ATP = ATP + (QOH - ATP) > AQT = QOH > Cancelled: As inventory transfer is cancelled and inventory item record is > already created so > a) ATP, QOH and AQT should decrease from old inventory item and ATP, QOH and > AQT should increase in the newly created inventory item. > Key points: > If the whole ATP and QOH is moved then new inventory item will not create. > Only Facility and location are changed for existing inventory item. > Before Changes:- > As I know there are following processes are associated with respective > statuses > **Note: ATP-> Available to promiseQOH-> Quantity on handAQT-> > Accounting quantity total > 1. Requested:- > ATP =0QOH=Transferred quantity >AQT=0 > 2. Scheduled:- > ATP =0QOH=Transferred quantity >AQT=0 > 3.En-Route:- > ATP =0QOH=Transferred quantity >AQT=0 > 4.Complete:- > If the partial quantity of any inventory item is transferred. > ATP =Transferred quantity QOH=Transferred quantity AQT=0 > If the whole quantity is transferred then only facility id and location > will change no new inventory item record will create. > 5.Cancelled:- > No new inventory item record will create. An inventory transfer record is > created with whole ATP/QOH in cancelled status. > After Changes:- > As shown above, accounting quantity transfer will not affect in transfer > inventory. After the following changes, records will be updated a shown below. > 1. Requested:- > ATP =0QOH=Transferred quantity >AQT=0 > 2. Scheduled:- > ATP =0QOH=Transferred quantity >AQT=0 > 3.En-Route:- > ATP =0QOH=Transferred quantity >AQT=0 > 4.Complete:- > If the partial quantity of any inventory item is transferred. > ATP =Transferred quantity QOH=Transferred quantity > AQT=Transferred quantity > If the whole quantity is transferred then only facility id
[jira] [Updated] (OFBIZ-9464) Accounting quantity transfer should not be zero while transferring inventory from one facility to another
[ https://issues.apache.org/jira/browse/OFBIZ-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-9464: Description: when we transfer inventory, the accountingQuantityTotal field of _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in accountingQuantityTotal. This will create following issues in the system. # Accounting quantity total will mismatch with the original quantity in the facility which shows the wrong result when we calculate facility specific inventory valuation. # Inventory reservation also throws an error in some specific case like when AQT of respective product is zero in the specific facility from when reservation happens. As we manage 5 different statuses of inventory transfer in OFBiz and according to my current understanding these processes are associated with the respective statuses, which are as show below Requested: As inventory transfer is requested for another facility. a)ATP, QOH and AQT should decrease from the inventory item of From Facility and QOH of To Facility should increase. b)ATP and AQT should be Zero in To Facility as inventory is not transferred yet. But QOH should increase at To Facility because QOH shows the xferquantity later. At the time of the completion of the transfer ATP = ATP + (QOH - ATP) (Adjustment in case of backorder) AQT = QOH b)AQT should not decrease because AQT is used for accounting purpose and as of now quantity is still in From Facility as the transfer is not done yet. which shows the xferQuantity later Scheduled: As inventory transfer is Scheduled for another facility. ATP, QOH and AQT should not affect in both From Facility and To Facility. En-route: As inventory is routed to reach at To Facility. Even in this case ATP, QOH and AQT should not affect in both From Facility and To Facility. Complete: As inventory transfer is completed a)ATP, QOH and AQT should not affect at From Facility. b)QOH will be same but ATP and AQT should affect respectively ATP = ATP + (QOH - ATP) AQT = QOH Cancelled: As inventory transfer is cancelled and inventory item record is already created so a) ATP, QOH and AQT should decrease from old inventory item and ATP, QOH and AQT should increase in the newly created inventory item. Key points: If the whole ATP and QOH is moved then new inventory item will not create. Only Facility and location are changed for existing inventory item. Before Changes:- As I know there are following processes are associated with respective statuses **Note: ATP-> Available to promiseQOH-> Quantity on handAQT-> Accounting quantity total 1. Requested:- ATP =0QOH=Transferred quantity AQT=0 2. Scheduled:- ATP =0QOH=Transferred quantity AQT=0 3.En-Route:- ATP =0QOH=Transferred quantity AQT=0 4.Complete:- If the partial quantity of any inventory item is transferred. ATP =Transferred quantity QOH=Transferred quantity AQT=0 If the whole quantity is transferred then only facility id and location will change no new inventory item record will create. 5.Cancelled:- No new inventory item record will create. An inventory transfer record is created with whole ATP/QOH in cancelled status. After Changes:- As shown above, accounting quantity transfer will not affect in transfer inventory. After the following changes, records will be updated a shown below. 1. Requested:- ATP =0QOH=Transferred quantity AQT=0 2. Scheduled:- ATP =0QOH=Transferred quantity AQT=0 3.En-Route:- ATP =0QOH=Transferred quantity AQT=0 4.Complete:- If the partial quantity of any inventory item is transferred. ATP =Transferred quantity QOH=Transferred quantity AQT=Transferred quantity If the whole quantity is transferred then only facility id and location will change no new inventory item record will create. 5.Cancelled:- No new inventory item record will create. An inventory transfer record is created with whole ATP/QOH in cancelled status. was: when we transfer inventory, the accountingQuantityTotal field of _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in accountingQuantityTotal. This will create following issues in the system. # Accounting quantity total will mismatch with the original quantity in the facility which shows wrong result when we calculate facility specific inventory valuation. # Inventory reservation also throws an error in some specific case like when AQT of respective product is zero in the specific facility from when reservation happens. As we manage 5 different statuses of inventory transfer in OFBiz and
[jira] [Updated] (OFBIZ-9464) Accounting quantity transfer should not be zero while transferring inventory from one facility to another
[ https://issues.apache.org/jira/browse/OFBIZ-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-9464: Description: when we transfer inventory, the accountingQuantityTotal field of _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in accountingQuantityTotal. This will create following issues in the system. # Accounting quantity total will mismatch with the original quantity in the facility which shows wrong result when we calculate facility specific inventory valuation. # Inventory reservation also throws an error in some specific case like when AQT of respective product is zero in the specific facility from when reservation happens. As we manage 5 different statuses of inventory transfer in OFBiz and according to my current understanding these processes are associated with the respective statuses, which are as show below Requested: As inventory transfer is requested for another facility. a)ATP, QOH and AQT should decrease from the inventory item of From Facility and QOH of To Facility should increase. b)ATP and AQT should be Zero in To Facility as inventory is not transferred yet. But QOH should increase at To Facility because QOH shows the xferquantity later. At the time of the completion of the transfer ATP = ATP + (QOH - ATP) (Adjustment in case of backorder) AQT = QOH b)AQT should not decrease because AQT is used for accounting purpose and as of now quantity is still in From Facility as the transfer is not done yet. which shows the xferQuantity later Scheduled: As inventory transfer is Scheduled for another facility. ATP, QOH and AQT should not affect in both From Facility and To Facility. En-route: As inventory is routed to reach at To Facility. Even in this case ATP, QOH and AQT should not affect in both From Facility and To Facility. Complete: As inventory transfer is completed a)ATP, QOH and AQT should not affect at From Facility. b)QOH will be same but ATP and AQT should affect respectively ATP = ATP + (QOH - ATP) AQT = QOH Cancelled: As inventory transfer is cancelled and inventory item record is already created so a) ATP, QOH and AQT should decrease from old inventory item and ATP, QOH and AQT should increase in the newly created inventory item. Key points: If the whole ATP and QOH is moved then new inventory item will not create. Only Facility and location are changed for existing inventory item. Before Changes:- As I know there are following processes are associated with respective statuses **Note: ATP-> Available to promiseQOH-> Quantity on handAQT-> Accounting quantity total 1. Requested:- ATP =0QOH=Transferred quantity AQT=0 2. Scheduled:- ATP =0QOH=Transferred quantity AQT=0 3.En-Route:- ATP =0QOH=Transferred quantity AQT=0 4.Complete:- If the partial quantity of any inventory item is transferred. ATP =Transferred quantity QOH=Transferred quantity AQT=0 If the whole quantity is transferred then only facility id and location will change no new inventory item record will create. 5.Cancelled:- No new inventory item record will create. An inventory transfer record is created with whole ATP/QOH in cancelled status. After Changes:- As shown above, accounting quantity transfer will not affect in transfer inventory. After the following changes, records will be updated a shown below. 1. Requested:- ATP =0QOH=Transferred quantity AQT=0 2. Scheduled:- ATP =0QOH=Transferred quantity AQT=0 3.En-Route:- ATP =0QOH=Transferred quantity AQT=0 4.Complete:- If the partial quantity of any inventory item is transferred. ATP =Transferred quantity QOH=Transferred quantity AQT=Transferred quantity If the whole quantity is transferred then only facility id and location will change no new inventory item record will create. 5.Cancelled:- No new inventory item record will create. An inventory transfer record is created with whole ATP/QOH in cancelled status. was: when we transfer inventory, the accountingQuantityTotal field of _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in accountingQuantityTotal. This will create following issues in the system. # Accounting quantity total will mismatch with the original quantity in the facility which shows wrong result when we calculate facility specific inventory valuation. # Inventory reservation also throws an error in some specific case like when AQT of respective product is zero in the specific facility from when reservation happens. > Accounting quantity transfer should not be zero while transferring
[jira] [Updated] (OFBIZ-8459) InventoryItemStatus is not updated to INV_PROMISED status while creating sales order for serialized product
[ https://issues.apache.org/jira/browse/OFBIZ-8459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-8459: Attachment: OFBIZ-8459.patch Here is the updated patch > InventoryItemStatus is not updated to INV_PROMISED status while creating > sales order for serialized product > --- > > Key: OFBIZ-8459 > URL: https://issues.apache.org/jira/browse/OFBIZ-8459 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 14.12, Trunk, Release Branch 15.12 >Reporter: Vaibhav Jain >Assignee: Pranay Pandey > Fix For: Release Branch 14.12, Trunk, Release Branch 15.12 > > Attachments: OFBIZ-8459.patch, OFBIZ-8459.patch > > > Steps to regenerate the issue: > # Create a serialized product and receive single inventory item (feed serial > number) of the specific product. > # Check the status of the inventory item in InventoryItem and > InventoryItemStatus entities it should be INV_AVAILABLE. > # Create sales order of this serialized product. > # Status of the inventory item in InventoryItem entity is changed to > 'INV_PROMISED' but InventoryItemStatus entity still shows 'INV_AVAILABLE'. > Expected : > In InventoryItemStatus current status should also be 'INV_PROMISED' as of > InventoryItem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-8459) InventoryItemStatus is not updated to INV_PROMISED status while creating sales order for serialized product
[ https://issues.apache.org/jira/browse/OFBIZ-8459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-8459: Fix Version/s: Release Branch 14.12 Release Branch 15.12 > InventoryItemStatus is not updated to INV_PROMISED status while creating > sales order for serialized product > --- > > Key: OFBIZ-8459 > URL: https://issues.apache.org/jira/browse/OFBIZ-8459 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 14.12, Trunk, Release Branch 15.12 >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain > Fix For: Release Branch 14.12, Trunk, Release Branch 15.12 > > Attachments: OFBIZ-8459.patch > > > Steps to regenerate the issue: > # Create a serialized product and receive single inventory item (feed serial > number) of the specific product. > # Check the status of the inventory item in InventoryItem and > InventoryItemStatus entities it should be INV_AVAILABLE. > # Create sales order of this serialized product. > # Status of the inventory item in InventoryItem entity is changed to > 'INV_PROMISED' but InventoryItemStatus entity still shows 'INV_AVAILABLE'. > Expected : > In InventoryItemStatus current status should also be 'INV_PROMISED' as of > InventoryItem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-8459) InventoryItemStatus is not updated to INV_PROMISED status while creating sales order for serialized product.
[ https://issues.apache.org/jira/browse/OFBIZ-8459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-8459: Attachment: OFBIZ-8459.patch Here is the patch to create inventory item status record for INV_PROMISED status in InventoryItemStatus entity when a sales order is placed for serialized product. > InventoryItemStatus is not updated to INV_PROMISED status while creating > sales order for serialized product. > > > Key: OFBIZ-8459 > URL: https://issues.apache.org/jira/browse/OFBIZ-8459 > Project: OFBiz > Issue Type: Bug > Components: product >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain > Fix For: Trunk > > Attachments: OFBIZ-8459.patch > > > Steps to regenerate the issue: > 1.Create a serialized product and receive single inventory item (please feed > serial number) of the specific product. > 2.Check the status of InventoryItem entity and InventoryItemStatus entity > i.e. status should be INV_AVAILABLE. > 3. Create sales order of serialized product. > 4. Status of inventoryItem entity is changed to 'INV_PROMISED' but the status > of InventoryItemStatus entity still remains 'INV_AVAILABLE'. > Expected : > In InventoryItemStatus entity 'INV_AVAILABLE' status should expire and create > a new record of 'INV_PROMISED' status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-8459) InventoryItemStatus is not updated to INV_PROMISED status while creating sales order for serialized product.
Vaibhav Jain created OFBIZ-8459: --- Summary: InventoryItemStatus is not updated to INV_PROMISED status while creating sales order for serialized product. Key: OFBIZ-8459 URL: https://issues.apache.org/jira/browse/OFBIZ-8459 Project: OFBiz Issue Type: Bug Components: product Reporter: Vaibhav Jain Assignee: Vaibhav Jain Fix For: Trunk Steps to regenerate the issue: 1.Create a serialized product and receive single inventory item (please feed serial number) of the specific product. 2.Check the status of InventoryItem entity and InventoryItemStatus entity i.e. status should be INV_AVAILABLE. 3. Create sales order of serialized product. 4. Status of inventoryItem entity is changed to 'INV_PROMISED' but the status of InventoryItemStatus entity still remains 'INV_AVAILABLE'. Expected : In InventoryItemStatus entity 'INV_AVAILABLE' status should expire and create a new record of 'INV_PROMISED' status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-7644) E-commerce : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain closed OFBIZ-7644. --- Resolution: Duplicate Assignee: Vaibhav Jain Duplicate issue > E-commerce : FTL formatting > --- > > Key: OFBIZ-7644 > URL: https://issues.apache.org/jira/browse/OFBIZ-7644 > Project: OFBiz > Issue Type: Sub-task > Components: specialpurpose/ecommerce >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-7949) E-commerce : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-7949: Attachment: OFBIZ-7949.patch > E-commerce : FTL formatting > --- > > Key: OFBIZ-7949 > URL: https://issues.apache.org/jira/browse/OFBIZ-7949 > Project: OFBiz > Issue Type: Sub-task > Components: specialpurpose/ecommerce >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain > Attachments: OFBIZ-7949.patch, OFBIZ-7949.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-7949) E-commerce : FTL formatting
[ https://issues.apache.org/jira/browse/OFBIZ-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vaibhav Jain updated OFBIZ-7949: Attachment: OFBIZ-7949.patch Here is the patch for the formatted files of e-commerce component > E-commerce : FTL formatting > --- > > Key: OFBIZ-7949 > URL: https://issues.apache.org/jira/browse/OFBIZ-7949 > Project: OFBiz > Issue Type: Sub-task > Components: specialpurpose/ecommerce >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain > Attachments: OFBIZ-7949.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
