Re: finding a variant with the required standard features can take long
Yes, exactly, and that is what including the same entity multiple times as different member-entities with different aliases in a view- entity is all about. For some nice complex examples of this (hopefully more complex than you'll need) check out the ProductSearch.java stuff. The code there is split around, but search for "ProductKeyword" and you'll see that entity linked in multiple times so that multiple keyword records for a single product can be considered. -David On Apr 24, 2008, at 11:54 PM, Hans Bakker wrote: David, thanks for your help, i would understand that if they were different fields...but these are the same fields with different values on different records. regards, Hans On Thu, 2008-04-24 at 22:44 -0600, David E Jones wrote: You would need to join the ProductFeatureAppl entity into the view multiple times (once for each feature selected). -David On Apr 24, 2008, at 10:29 PM, Hans Bakker wrote: the problem is that the actual variants are stored in productAssoc and the standard features in different records of productFeatureAppl any idea how this view would look like? so i want a variant from product assoc which has all the selected features on the screen as standard features in productFeatureAppl On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: Why not just use a view-entity to reduce round-trips to the database and select by the productId and the relevant feature ids? -David On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: The new feature explosion is now most implemented and shows , in speed as a big improvement. However Part of the problem to select the respective variant is now done after the features are selected. Because of the datamodel it takes a long time to find the applicable variant if there are many. this what i do now: for every 'variant' in the ProductAssoc entity i check if the related variant product has all the selected features as 'standard' in the ProductFeatureAppl entity. this however can take a long time How can we improve this? If we could add a field to the ProductAssoc entity called 'standardFeatures' and we copy in here all the standard productFeatureId's of a related variant separated with a '|' sign when the features are updated, then we could find the related variant with one read.. This copy can be done with an eca... what is the opinion of the community? regards, Hans Bakker -- AntWebsystems.com: Quality OFBiz services for competitive rates. -- AntWebsystems.com: Quality OFBiz services for competitive rates. -- AntWebsystems.com: Quality OFBiz services for competitive rates.
Re: finding a variant with the required standard features can take long
David, thanks for your help, i would understand that if they were different fields...but these are the same fields with different values on different records. regards, Hans On Thu, 2008-04-24 at 22:44 -0600, David E Jones wrote: > You would need to join the ProductFeatureAppl entity into the view > multiple times (once for each feature selected). > > -David > > > On Apr 24, 2008, at 10:29 PM, Hans Bakker wrote: > > the problem is that the actual variants are stored in productAssoc and > > the standard features in different records of productFeatureAppl > > > > any idea how this view would look like? > > > > so i want a variant from product assoc which has all the selected > > features on the screen as standard features in productFeatureAppl > > > > > > On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: > >> Why not just use a view-entity to reduce round-trips to the database > >> and select by the productId and the relevant feature ids? > >> > >> -David > >> > >> > >> On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: > >>> The new feature explosion is now most implemented and shows , in > >>> speed > >>> as a big improvement. However > >>> Part of the problem to select the respective variant is now done > >>> after > >>> the features are selected. Because of the datamodel it takes a long > >>> time > >>> to find the applicable variant if there are many. > >>> > >>> this what i do now: > >>> for every 'variant' in the ProductAssoc entity i check if the > >>> related > >>> variant product has all the selected features as 'standard' in the > >>> ProductFeatureAppl entity. > >>> > >>> this however can take a long time > >>> > >>> How can we improve this? > >>> > >>> If we could add a field to the ProductAssoc entity called > >>> 'standardFeatures' and we copy in here all the standard > >>> productFeatureId's of a related variant separated with a '|' sign > >>> when > >>> the features are updated, then we could find the related variant > >>> with > >>> one read.. > >>> This copy can be done with an eca... > >>> > >>> what is the opinion of the community? > >>> > >>> regards, > >>> Hans Bakker > >>> -- > >>> AntWebsystems.com: Quality OFBiz services for competitive rates. > >>> > >> > >> > > -- > > AntWebsystems.com: Quality OFBiz services for competitive rates. > > > > -- AntWebsystems.com: Quality OFBiz services for competitive rates.
Re: finding a variant with the required standard features can take long
You would need to join the ProductFeatureAppl entity into the view multiple times (once for each feature selected). -David On Apr 24, 2008, at 10:29 PM, Hans Bakker wrote: the problem is that the actual variants are stored in productAssoc and the standard features in different records of productFeatureAppl any idea how this view would look like? so i want a variant from product assoc which has all the selected features on the screen as standard features in productFeatureAppl On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: Why not just use a view-entity to reduce round-trips to the database and select by the productId and the relevant feature ids? -David On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: The new feature explosion is now most implemented and shows , in speed as a big improvement. However Part of the problem to select the respective variant is now done after the features are selected. Because of the datamodel it takes a long time to find the applicable variant if there are many. this what i do now: for every 'variant' in the ProductAssoc entity i check if the related variant product has all the selected features as 'standard' in the ProductFeatureAppl entity. this however can take a long time How can we improve this? If we could add a field to the ProductAssoc entity called 'standardFeatures' and we copy in here all the standard productFeatureId's of a related variant separated with a '|' sign when the features are updated, then we could find the related variant with one read.. This copy can be done with an eca... what is the opinion of the community? regards, Hans Bakker -- AntWebsystems.com: Quality OFBiz services for competitive rates. -- AntWebsystems.com: Quality OFBiz services for competitive rates.
Re: finding a variant with the required standard features can take long
the problem is that the actual variants are stored in productAssoc and the standard features in different records of productFeatureAppl any idea how this view would look like? so i want a variant from product assoc which has all the selected features on the screen as standard features in productFeatureAppl On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: > Why not just use a view-entity to reduce round-trips to the database > and select by the productId and the relevant feature ids? > > -David > > > On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: > > The new feature explosion is now most implemented and shows , in speed > > as a big improvement. However > > Part of the problem to select the respective variant is now done after > > the features are selected. Because of the datamodel it takes a long > > time > > to find the applicable variant if there are many. > > > > this what i do now: > > for every 'variant' in the ProductAssoc entity i check if the related > > variant product has all the selected features as 'standard' in the > > ProductFeatureAppl entity. > > > > this however can take a long time > > > > How can we improve this? > > > > If we could add a field to the ProductAssoc entity called > > 'standardFeatures' and we copy in here all the standard > > productFeatureId's of a related variant separated with a '|' sign when > > the features are updated, then we could find the related variant with > > one read.. > > This copy can be done with an eca... > > > > what is the opinion of the community? > > > > regards, > > Hans Bakker > > -- > > AntWebsystems.com: Quality OFBiz services for competitive rates. > > > > -- AntWebsystems.com: Quality OFBiz services for competitive rates.
Re: finding a variant with the required standard features can take long
Why not just use a view-entity to reduce round-trips to the database and select by the productId and the relevant feature ids? -David On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: The new feature explosion is now most implemented and shows , in speed as a big improvement. However Part of the problem to select the respective variant is now done after the features are selected. Because of the datamodel it takes a long time to find the applicable variant if there are many. this what i do now: for every 'variant' in the ProductAssoc entity i check if the related variant product has all the selected features as 'standard' in the ProductFeatureAppl entity. this however can take a long time How can we improve this? If we could add a field to the ProductAssoc entity called 'standardFeatures' and we copy in here all the standard productFeatureId's of a related variant separated with a '|' sign when the features are updated, then we could find the related variant with one read.. This copy can be done with an eca... what is the opinion of the community? regards, Hans Bakker -- AntWebsystems.com: Quality OFBiz services for competitive rates.
finding a variant with the required standard features can take long
The new feature explosion is now most implemented and shows , in speed as a big improvement. However Part of the problem to select the respective variant is now done after the features are selected. Because of the datamodel it takes a long time to find the applicable variant if there are many. this what i do now: for every 'variant' in the ProductAssoc entity i check if the related variant product has all the selected features as 'standard' in the ProductFeatureAppl entity. this however can take a long time How can we improve this? If we could add a field to the ProductAssoc entity called 'standardFeatures' and we copy in here all the standard productFeatureId's of a related variant separated with a '|' sign when the features are updated, then we could find the related variant with one read.. This copy can be done with an eca... what is the opinion of the community? regards, Hans Bakker -- AntWebsystems.com: Quality OFBiz services for competitive rates.
[jira] Commented: (OFBIZ-1757) I can not open the xml files of ofbiz application
[ https://issues.apache.org/jira/browse/OFBIZ-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592174#action_12592174 ] Jacques Le Roux commented on OFBIZ-1757: http://docs.ofbiz.org/display/OFBIZ/Plugins#Plugins-XMLMarkupLanguage(.xml,.xsd) > I can not open the xml files of ofbiz application > - > > Key: OFBIZ-1757 > URL: https://issues.apache.org/jira/browse/OFBIZ-1757 > Project: OFBiz > Issue Type: Bug > Components: ecommerce > Environment: windows XP and eclipse3.3 >Reporter: Lisa Wu > > We have an application which is made by ofbiz. today, I try to import the > application to my ide (eclipse3.3). I can open the java files, but I can't > open the xml files. hope you can help me. Thanks a lot! Lisa -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-1757) I can not open the xml files of ofbiz application
[ https://issues.apache.org/jira/browse/OFBIZ-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-1757. - Resolution: Invalid I doubt this has anything to do with OFBiz and everything to do with your IDE. Try right-clicking on an xml file and selecting Open With > XML Editor > I can not open the xml files of ofbiz application > - > > Key: OFBIZ-1757 > URL: https://issues.apache.org/jira/browse/OFBIZ-1757 > Project: OFBiz > Issue Type: Bug > Components: ecommerce > Environment: windows XP and eclipse3.3 >Reporter: Lisa Wu > > We have an application which is made by ofbiz. today, I try to import the > application to my ide (eclipse3.3). I can open the java files, but I can't > open the xml files. hope you can help me. Thanks a lot! Lisa -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-1757) I can not open the xml files of ofbiz application
I can not open the xml files of ofbiz application - Key: OFBIZ-1757 URL: https://issues.apache.org/jira/browse/OFBIZ-1757 Project: OFBiz Issue Type: Bug Components: ecommerce Environment: windows XP and eclipse3.3 Reporter: Lisa Wu We have an application which is made by ofbiz. today, I try to import the application to my ide (eclipse3.3). I can open the java files, but I can't open the xml files. hope you can help me. Thanks a lot! Lisa -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: What is the meaning of the SettlementTerm entity?
On Apr 24, 2008, at 1:45 AM, Jacopo Cappellato wrote: What is the meaning of the SettlementTerm entity? Is it an old entity or something created during the very initial GL design and never implemented. By looking at its seed data it seems to me a duplication of the payment terms as already implemented in the OrderTerm and InvoiceTerm entities. That sounds like it's probably true. The SerrltementTerm entity was probably just around from the beginning and overlooked when the time came to work on the OrderTerm and InvoiceTerm build outs. -David
Is there any OFBiz component on OpenSign?
Hi list, Just in case someone may have developed an OFBiz-OpenSign component but I don't know, is there any OFBiz component on opensign? TIA, Shi Yusen/Beijing Langhua Ltd.
Re: Question regarding deletePartyRelationship service.
Usually for "join" entities with effective dates (from/thru dates) (like PartyRelationship) the delete service does actually delete the record. If you want to expire the record, just use the update service. -David On Apr 24, 2008, at 12:08 AM, Sumit Pandit wrote: Hello all, I saw the implementation of service deletePartyRelationship In the service it use remove-value which deletes the record form the database. But here i think It should expire. Please make me correct if i am wrong. Thanks Sumit Pandit
Re: Shared labels between Order and Ecommerce applications
Looking forward to the big labels cleanup... -Bruno 2008/4/24, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Hi Jacques, > > I would like to translate missing labels in Italian but without any urgency > also because I'm very busy with other projects. > > Thanks a lot > Marco > > > I should have say that I have currently 4 files pending. As soons as I > will validate and commit this files, I will look on Jira > > issue. Of course any reviews of Bruno's work in the meantime is welcome. > > > > Sorry to call upon your patience > > > > Jacques > > > > From: "Jacques Le Roux" <[EMAIL PROTECTED]> > > > Bruno, Marco, > > > > > > I'm currently working with a person who help me to add and fix french > labels. I have to check translations because, as you know, > > > it's very specific, and this takes time. So I'd like to finish as much > as possible this work before working on > > > https://issues.apache.org/jira/browse/OFBIZ-1698. I suspect that > commiting this changes after will be harder (merging issues). So > > > I ask you to wait a bit before doing anything about it. I'm making my > best to not delay it too much. > > > > > > Thanks > > > > > > Jacques > > > > > > - Original Message - > > > From: "Jacques Le Roux" <[EMAIL PROTECTED]> > > > To: > > > Sent: Tuesday, April 22, 2008 12:39 AM > > > Subject: Re: Shared labels between Order and Ecommerce applications > > > > > > > > >>I should look at it this week. I have got some time. > > >> > > >> Jacques > > >> > > >> From: "Bruno Busco" <[EMAIL PROTECTED]> > > >> Great! > > >> > > >> 2008/4/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > >>> > > >>> Thanks Bruno, also I will take a look at this issue if I get the time. > > >>> > > >>> Marco > > >>> > > >>> > > >>> Marco, > > >>> there is an ongoing work on this issue. > > >>> Please read https://issues.apache.org/jira/browse/OFBIZ-1698 > > >>> Jacques is supposed to integrate my contribution in these days. > > >>> > > >>> -Bruno > > >>> > > >>> 2008/4/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > >>> > > >>> Hi to All, > > >>> > > >>> I'm trying to translate some labels to Italian but I have seen a > little > > >>> bit of confusion on the shared labels between Order and Ecommerce > > >>> applications. > > >>> For example the label EcommerceAddtoCart (Add to Cart) is present on > both > > >>> files: > > >>> > > >>> in OrderUiLabels.xml > > >>> > > >>>In den Warenkorb legen > > >>>Add to Cart > > >>>Añadir al carro > > >>>Ajouter au panier > > >>>Aggiungi al Carrello > > >>>Bestel > > >>>Adicionar ao Cesto > > >>>Adauga in Cos > > >>> > > >>>?? > > >>>? > > >>> > > >>> > > >>> in EcommerceUiLabels.xml > > >>> > > >>>pridat do kosíku > > >>>Add to Cart > > >>>Ajouter au panier > > >>>Add to basket > > >>>? ??? ?? > > >>>? > > >>>??? > > >>> > > >>> > > >>> In this case that label is not translated in Italian into the > Ecommerce > > >>> application but only into the Order application > > >>> So my idea was to move those duplicated labels to the > OrderUiLabel.xml. > > >>> > > >>> What did you think of it ? Did you have different ideas ? > > >>> > > >>> Thanks > > >>> Marco > > >>> > > >>> > > >>> > > >>> > > >> > > > > > > > > >
Re: Shared labels between Order and Ecommerce applications
Hi Jacques, I would like to translate missing labels in Italian but without any urgency also because I'm very busy with other projects. Thanks a lot Marco > I should have say that I have currently 4 files pending. As soons as I will > validate and commit this files, I will look on Jira > issue. Of course any reviews of Bruno's work in the meantime is welcome. > > Sorry to call upon your patience > > Jacques > > From: "Jacques Le Roux" <[EMAIL PROTECTED]> > > Bruno, Marco, > > > > I'm currently working with a person who help me to add and fix french > > labels. I have to check translations because, as you know, > > it's very specific, and this takes time. So I'd like to finish as much as > > possible this work before working on > > https://issues.apache.org/jira/browse/OFBIZ-1698. I suspect that commiting > > this changes after will be harder (merging issues). So > > I ask you to wait a bit before doing anything about it. I'm making my best > > to not delay it too much. > > > > Thanks > > > > Jacques > > > > - Original Message - > > From: "Jacques Le Roux" <[EMAIL PROTECTED]> > > To: > > Sent: Tuesday, April 22, 2008 12:39 AM > > Subject: Re: Shared labels between Order and Ecommerce applications > > > > > >>I should look at it this week. I have got some time. > >> > >> Jacques > >> > >> From: "Bruno Busco" <[EMAIL PROTECTED]> > >> Great! > >> > >> 2008/4/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > >>> > >>> Thanks Bruno, also I will take a look at this issue if I get the time. > >>> > >>> Marco > >>> > >>> > >>> Marco, > >>> there is an ongoing work on this issue. > >>> Please read https://issues.apache.org/jira/browse/OFBIZ-1698 > >>> Jacques is supposed to integrate my contribution in these days. > >>> > >>> -Bruno > >>> > >>> 2008/4/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > >>> > >>> Hi to All, > >>> > >>> I'm trying to translate some labels to Italian but I have seen a little > >>> bit of confusion on the shared labels between Order and Ecommerce > >>> applications. > >>> For example the label EcommerceAddtoCart (Add to Cart) is present on both > >>> files: > >>> > >>> in OrderUiLabels.xml > >>> > >>>In den Warenkorb legen > >>>Add to Cart > >>>Añadir al carro > >>>Ajouter au panier > >>>Aggiungi al Carrello > >>>Bestel > >>>Adicionar ao Cesto > >>>Adauga in Cos > >>> > >>>?? > >>>? > >>> > >>> > >>> in EcommerceUiLabels.xml > >>> > >>>pridat do kosíku > >>>Add to Cart > >>>Ajouter au panier > >>>Add to basket > >>>? ??? ?? > >>>? > >>>??? > >>> > >>> > >>> In this case that label is not translated in Italian into the Ecommerce > >>> application but only into the Order application > >>> So my idea was to move those duplicated labels to the OrderUiLabel.xml. > >>> > >>> What did you think of it ? Did you have different ideas ? > >>> > >>> Thanks > >>> Marco > >>> > >>> > >>> > >>> > >> > > > >
Re: Shared labels between Order and Ecommerce applications
I should have say that I have currently 4 files pending. As soons as I will validate and commit this files, I will look on Jira issue. Of course any reviews of Bruno's work in the meantime is welcome. Sorry to call upon your patience Jacques From: "Jacques Le Roux" <[EMAIL PROTECTED]> Bruno, Marco, I'm currently working with a person who help me to add and fix french labels. I have to check translations because, as you know, it's very specific, and this takes time. So I'd like to finish as much as possible this work before working on https://issues.apache.org/jira/browse/OFBIZ-1698. I suspect that commiting this changes after will be harder (merging issues). So I ask you to wait a bit before doing anything about it. I'm making my best to not delay it too much. Thanks Jacques - Original Message - From: "Jacques Le Roux" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 22, 2008 12:39 AM Subject: Re: Shared labels between Order and Ecommerce applications I should look at it this week. I have got some time. Jacques From: "Bruno Busco" <[EMAIL PROTECTED]> Great! 2008/4/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Thanks Bruno, also I will take a look at this issue if I get the time. Marco Marco, there is an ongoing work on this issue. Please read https://issues.apache.org/jira/browse/OFBIZ-1698 Jacques is supposed to integrate my contribution in these days. -Bruno 2008/4/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Hi to All, I'm trying to translate some labels to Italian but I have seen a little bit of confusion on the shared labels between Order and Ecommerce applications. For example the label EcommerceAddtoCart (Add to Cart) is present on both files: in OrderUiLabels.xml In den Warenkorb legen Add to Cart Añadir al carro Ajouter au panier Aggiungi al Carrello Bestel Adicionar ao Cesto Adauga in Cos ?? ? in EcommerceUiLabels.xml pridat do košíku Add to Cart Ajouter au panier Add to basket ? ??? ?? ? ??? In this case that label is not translated in Italian into the Ecommerce application but only into the Order application So my idea was to move those duplicated labels to the OrderUiLabel.xml. What did you think of it ? Did you have different ideas ? Thanks Marco
Re: Shared labels between Order and Ecommerce applications
Bruno, Marco, I'm currently working with a person who help me to add and fix french labels. I have to check translations because, as you know, it's very specific, and this takes time. So I'd like to finish as much as possible this work before working on https://issues.apache.org/jira/browse/OFBIZ-1698. I suspect that commiting this changes after will be harder (merging issues). So I ask you to wait a bit before doing anything about it. I'm making my best to not delay it too much. Thanks Jacques - Original Message - From: "Jacques Le Roux" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 22, 2008 12:39 AM Subject: Re: Shared labels between Order and Ecommerce applications I should look at it this week. I have got some time. Jacques From: "Bruno Busco" <[EMAIL PROTECTED]> Great! 2008/4/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Thanks Bruno, also I will take a look at this issue if I get the time. Marco Marco, there is an ongoing work on this issue. Please read https://issues.apache.org/jira/browse/OFBIZ-1698 Jacques is supposed to integrate my contribution in these days. -Bruno 2008/4/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Hi to All, I'm trying to translate some labels to Italian but I have seen a little bit of confusion on the shared labels between Order and Ecommerce applications. For example the label EcommerceAddtoCart (Add to Cart) is present on both files: in OrderUiLabels.xml In den Warenkorb legen Add to Cart Añadir al carro Ajouter au panier Aggiungi al Carrello Bestel Adicionar ao Cesto Adauga in Cos ?? ? in EcommerceUiLabels.xml pridat do košíku Add to Cart Ajouter au panier Add to basket ? ??? ?? ? ??? In this case that label is not translated in Italian into the Ecommerce application but only into the Order application So my idea was to move those duplicated labels to the OrderUiLabel.xml. What did you think of it ? Did you have different ideas ? Thanks Marco
Re: Happy hour promotions
Thanks for answering everyone.
David, thanks for the advice.
I checked the entities you mentioned WorkEffort, RecurrenceInfo, and
RecurrenceRule, but cannot figure it our how to achieve the same
functionality.
It is possible to store the promotion hours in WorkEffort entity
(actualStartDate - actualCompletionDate), and assign a recurrenceInfoId
to it. Then the hours could be active for example every day, or every
7th day (like every Sunday), but how can I choose only the weekdays, or
how to set up different time range for every day of the week?
I think this will be needed also by manufacturing application(when
deprecating TechDataCalendarWeek), which is the only one place where
TechDataCalendarWeek entity is used.
Can someone answer to this question:
Looking at RecurrenceInfo and RecurrenceRule entities I got confused.
RecurrenceInfo entity has exceptionRuleId, recurrenceRuleId fields, so
it can have ONLY ONE recurrenceRule and ONLY ONE exception
recurrenceRule.
But in RecurrenceInfo.java there are lists for storing exceptionRules
and recurrenceRules:
// Get the recurrence rules objects
rRulesList = new ArrayList();
for (GenericValue value: info.getRelated("RecurrenceRule")){
rRulesList.add(new RecurrenceRule(value));
}
// Get the exception rules objects
eRulesList = new ArrayList();
for (GenericValue value:
info.getRelated("ExceptionRecurrenceRule")){
eRulesList.add(new RecurrenceRule(value));
}
Is it possible one RecurrenceInfo to have many RecurrenceRules and many
exception RecurrenceRules? May be something is wrong with the entity
definitions?
Thanks,
Bilgin
Re: svn commit: r646132 - /ofbiz/trunk/applications/order/servicedef/services_cart.xml
This is finally reverted in rev. 651193 Jacopo On Apr 14, 2008, at 7:05 AM, David E Jones wrote: +1 from me on the revert as well (making it clear as it is only implied in my initial reply). -David On Apr 12, 2008, at 11:04 PM, Jacopo Cappellato wrote: No feedback on this? However, a committer should always be around to explain and provide further details if there are concerns or questions on his commits. Should we revert this commit? Jacopo On Apr 9, 2008, at 4:29 AM, David E Jones wrote: Actually, transactions ARE important for reading as well as writing, and should pretty much always be used. What was the problem you had that this change is supposed to solve? -David On Apr 8, 2008, at 5:21 PM, [EMAIL PROTECTED] wrote: Author: sichen Date: Tue Apr 8 16:21:14 2008 New Revision: 646132 URL: http://svn.apache.org/viewvc?rev=646132&view=rev Log: turning off transactions for loading of cart from quote, since there does not seem to be any data being stored, and having a transaction consumes resources unnecessarily and could cause it to fail if there are many items on a quote Modified: ofbiz/trunk/applications/order/servicedef/services_cart.xml Modified: ofbiz/trunk/applications/order/servicedef/ services_cart.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/servicedef/services_cart.xml?rev=646132&r1=646131&r2=646132&view=diff = = = = = = = = = = = === --- ofbiz/trunk/applications/order/servicedef/services_cart.xml (original) +++ ofbiz/trunk/applications/order/servicedef/services_cart.xml Tue Apr 8 16:21:14 2008 @@ -103,7 +103,7 @@ - location="org.ofbiz.order.shoppingcart.ShoppingCartServices" invoke="loadCartFromQuote"> + location="org.ofbiz.order.shoppingcart.ShoppingCartServices" invoke="loadCartFromQuote" use-transaction="false"> Create a ShoppingCart Object based on an existing quote. If applyQuoteAdjustments is set to false then standard cart adjustments are generated. optional="false"/> mode="IN" optional="true"/>
What is the meaning of the SettlementTerm entity?
What is the meaning of the SettlementTerm entity? Is it an old entity or something created during the very initial GL design and never implemented. By looking at its seed data it seems to me a duplication of the payment terms as already implemented in the OrderTerm and InvoiceTerm entities. Jacopo
