Re: Serialized Inventory issue with backorder item
Hi Deepak, Issue Renuka: “when we create an order for product with serialized inventory with quantity more than ATP then a negative ATP Inventory Item record is created, which is of type Non-Serialized.” Pro for using Non-Serialized type 1. As the placeholder record in Inventory Item is of type Non-Serialized, it can be used to store any number of negative ATP quantity. 2. If the sales order is cancelled, we only need to update that one record. Con for using Non-Serialized type = 1. The placeholder record in Inventory Item cannot be reused when the actual Inventory Item is received. Yes we can further discuss / refine on the serialised inventory item support in the JIRA. I also concur with you that InventoryItemDetail should also be used for serialised item, and the logics for ATP/QOH of a serialised inventory item. Thank you. Regards, James Deepak Dixit-3 wrote > Hi James, > > System create new inventory item each time, it does not use single > InventoryItem for all backorder. So it create incorrect inventory item(s) > data for serialized inventory item. > I think we can refine serialized inventory item support under > https://issues.apache.org/jira/browse/OFBIZ-7762 > > As per current implementation serialized inventory logic implemented on > status, and non-serialized inventory logic implemented on > InventoryItemDetail. > > Ideally both should use IID and if item is serialized than qoh can't be > greater then one, if we go with this route than we can implement status > base check on both type of inventory item. > Like if inventory item is defective than we can set its ATP to zero for > both cases etc > > > > > > > > Thanks & Regards > -- > Deepak Dixit > www.hotwaxsystems.com > > On Sat, Dec 17, 2016 at 8:42 PM, james yong < > i_yongbl@.com > > wrote: > >> Hi Renuka, >> >> In this case, the non-serialized inventory acts as a placeholder to >> ensure >> the final ATP is correct. >> This is correct behaviour, and not a bug. >> >> Regards, >> James >> >> >> Renuka Srishti-2 wrote >> > Hello All, >> > >> > In OFBiz, when we create an order for product with serialized inventory >> > with quantity more than ATP then a negative ATP Inventory Item record >> is >> > created, which is of type Non-Serialized. >> > It should be of type serialized . >> > >> > If we resolve this issue, we need to check all scenarios related to >> this >> > process. Please let me know your thoughts. If it looks good I will open >> a >> > ticket for the same. >> > >> > Thanks >> > >> > -- >> > Regards, >> > Renuka Srishti >> >> >> >> >> >> -- >> View this message in context: http://ofbiz.135035.n4.nabble. >> com/Serialized-Inventory-issue-with-backorder-item-tp4700367p4700409.html >> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >> -- View this message in context: http://ofbiz.135035.n4.nabble.com/Serialized-Inventory-issue-with-backorder-item-tp4700367p4700614.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Suggestion for Use Cases of Product Search in Ofbiz Ecommerce
- Rendering of products through the keyword passed in search context. - Advance search feature should run on the other parameters. - Product with basic informations. - Pagination. - Also on how we can validate if a product is searchable on specific keyword then how can be we sure that those products should come in a particular category. Some links like product link, other search pages related links etc should be there in the test case. Rishi Solanki Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com On Sat, Dec 17, 2016 at 5:38 PM, Shubham Agrawal < shubham.agra...@hotwaxsystems.com> wrote: > Hello All, > > I am writing use cases of Product Search in OFBiz ecommerce, I would need > help of the community to find out all the possible scenarios those should > be taken in consideration. > > So please suggest me the use cases for the same. > > > *Thanks and Regards,* > *Shubham Agrawal* >
Clarification about Jira version named "16.11.02"
Hi all, whenever a Jira ticket is resolved and the fix is back-ported to the 16.11 branch, please add the version "16.11.02" to the "Fix Version/s" field: in fact 16.11.02 is the first release of the 16.11 branch in which the fix will be published. As a side note, when you report a bug that affects the 16.11 branch you can set: "Affects Version/s" = "Release Branch 16.11" However it would be nice to know if the same bug affects also the release 16.11.01; if this is the case then please set: "Affects Version/s" = "16.11.01" In this case it is not necessary to specify "Release Branch 16.11" because it is implied that if the bug affects the "16.11.01" release then it also affected the 16.11 branch. In short: "Release Branch 16.11" should only be used when the bug was introduced in the branch after the 16.11.01 (and doesn't affect 16.11.01) or if you don't know if the bug affects the 16.11.01 release. Regards, Jacopo
Re: Use Cases for POC
Hi Olivier, I began to read, really began only read the 1st 3 pages :) Much easier to read directly at https://olivier-heintz.gitbooks.io/use-cases-for-poc/content/ than the copy in email It seems this proposition is not related to the efforts recently announced by Anuj Jain, Shubham Agrawal, Aayushi Gupta and Renuka Srishti. Just saying because maybe a common effort would help? BTW it's not quite clear to me because on page 1 you say <"applications/component" in ofbiz terminology.>> but on the other hand on page 3 you refer to 1. n HR application, simple employee management 2. in CRM B2C application, simple customer (person) management 3. in eCommerce, simple profile page 4. in HR application, simple organization/place (group) management 5. in CRM B2B application, simple customer (company) management 6. in Facility application, simple worker management which are not all specialpurpose/components. And what correspond to "CRM B2C/B2B" in OFBiz parlance? I guess it's related with the SFA webapp? Jacques Le 15/12/2016 à 11:09, Olivier Heintz a écrit : The goal of this mail is only two questions : 1. Is this form of use case like in this mail is usable for new UI POC ? (and new Doc POC and Selenium-Webdriver POC) 2. Is these use cases seem to be the correct to have correct POC ? If answer to these two question seem to be yes, I will created a wiki confluence page with these use case and we can start to discuss on each detail it's necessary to have a correct release of this document, usable for the POCs. Because, I'm testing some documentation tools, these use cases are also readable on https://olivier-heintz.gitbooks.io/use-cases-for-poc/content/ --- # Use cases for POC Theses use cases are to be used for new UI POC, documentation associated and selenium unit task test. All these use cases should be done with existing entities and services, if it's necessary to develop one, simplify the use case, the goal is UI, not service or entity. These use case description are done in a agile philosophy, only main point is present and during realization details choices will be discuss and done. Preliminary remarks : - 1. In this document, the term "application" corresponding to "specialpurpose/component" in the ofbiz terminology which is not same as a "applications/component" in ofbiz terminology. An application is dedicated for a business purpose for a user type, it's build by assembling piece of ofbiz components, sometimes without any specifics entities, services and screen (ex: CRM-B2C, CRM-B2B, SFA are 3 applications uses by sales men) 1. Each use case is on an "application" and is part of one of the menu of this application. Of course, this document describe only menu-option needed by the use-case. As it's difficult to do a clear definition of "web-page" because it's depending of theme/template, use case is for me at two level : 1. screen, which can be well define 2. page, which depend on default theme Of course, some of use case (screen or page) will be done by a previous one (ex : sometime edit is done by the same screen as add). It's even, one of the re-usable important point (UI, Doc and Selenium) 1. Each time a line (or point) start by a "?" the question is "is this point is needed ?" ## Release and goal Goal is the POC realization, not doing multiple super applications. POC realization should generate discussion and decision, each time be careful to mainly discuss on UI, Doc or Selenium and not on use case business justification. Use case are to be realistic but mainly as a support for a specifics UI, Doc or Selenium needed. ### V1 **Main Goal is to proof the technical points**. Of course UI re-organization is the driver for this phase, documentation start to work in parallel but will wait first realization to test integration for help. For selenium unit task, it will be a simple usage of the new UI with the default theme, the sole purpose being to check that test with default theme is simple. So never mind if all cases is not done, the list exist to give different classic case what we will need to know how to process it. Some case which seem to be duplicate from other can be use for beginner who want to help and check if the concept is understanding. During V1 realization, UseCase list will be updated ### V2 **Main Goal is to check if** the solution is **useful for the different type of contributors** * experiment developer * beginner developer * functional consultant for parameters * functional consultant for personalization * ? end user - for parameters ? (if it's still possible with the new architecture) Use Case list will be use as a deployment plan. The list contains similar case to these which are realize in V1, so those on V2 can be achieve by all types of contributors. ### Documentation Goal - Apache OFBiz web site wiki - OFBiz Help - PDF ? ### Selenium test 1. demo data for
Re: Call to action: fixing defects reported by code analysis tools
Le 14/12/2016 à 07:32, Jacopo Cappellato a écrit : On Tue, Dec 13, 2016 at 7:57 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Just as a note I find very useful to run these tools in Eclipse (the FindBug plugin for instance is conveniently integrated). But I rarely find the time to work on the reported issues :/ Jacques Thank you Jacques. Of course leveraging any similar IDE plugin will serve the same purpose, there are plenty of options! I use IntelliJ and it has a very good integrated code inspection tool (which analyzes everything) but it is not a viable option when used to bulk process all the files in OFBiz in one shot: it takes hours. Jacopo This is weird, FindBug in Eclipse takes only 3 mins to run. It currently finds 289 bugs. Jacques
Re: Test cases for Category Navigation
I think you can include the number of products should display under one category, number of subcategories display under category. In case list of products have multiple pages then it should work properly. Also on how we can validate if a product/category is under specific category then how can be we sure that those products or catgories should come under the browsed category. Some links like product link, other category swithing links, catgory tree should be working etc should be there in the test case. I could recall only these, may be others from community could help more. -- Rishi Rishi Solanki Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com On Sat, Dec 17, 2016 at 4:59 PM, Ayushi Gupta < ayushi.gu...@hotwaxsystems.com> wrote: > Hello All, > > I want to write test cases for category navigation functionality of OFBiz. > I have listed out some test cases as follows: > > - Rendering of categories/sub-categories > - Rendering of products through categories/sub-categories > - Product with basic informations > > Please suggest any other possible test cases related to category navigation > in OFBiz. > > -- > > Thanks with regards, > > Aayushi Gupta >
