Re: ServiceMcaCondition adding conditionals and multipline conditions.
the mca I am using is in the yahoo directory. so I am not proposing to put yahoo mca in the trunk. I do have a shippers mca that deals with ups, fedex, dhl. BJ Freeman sent the following on 9/30/2008 7:43 PM: > [The point I was trying to make is that the decision of whether or not > an email is a Yahoo email has to be made *somewhere* - so why not keep > Yahoo-related code in one place? Your approach scatters the > Yahoo-related code.] > > to me putting email processing in the yahoo code is squattering the > email processing code. > > guess it is a matter of what should be where. to me it is a email till > it get dispatched. So I treat it as a email. > to me email processing, related to sorting belongs in the MCA. This > philosophy follows in mail servers as well, like james. > > then all the specific code for that email processing should be in the > related code, the email is dispatched to, like the parsing of the email. > > > > > > Adrian Crum sent the following on 9/30/2008 5:44 PM: >> Until someone is willing to to make those changes, you're stuck with the >> tools at hand. That's why I suggested moving your parsing logic to the >> processing logic you already have. >> >> Your example: >> >> If an email has a return path that contains "[EMAIL PROTECTED]" and/or (not >> sure which) the email is from "Yahoo" then it's a Yahoo email - send it to >> ProcessYahooEmailOrders. >> >> My suggestion: >> >> Send incoming email to ProcessYahooEmailOrders. If the email has a return >> path that contains "[EMAIL PROTECTED]" and/or the email is from "Yahoo" then >> it's a Yahoo email - continue processing. Else return. >> >> The point I was trying to make is that the decision of whether or not an >> email is a Yahoo email has to be made *somewhere* - so why not keep >> Yahoo-related code in one place? Your approach scatters the Yahoo-related >> code. >> >> -Adrian >> >> --- On Tue, 9/30/08, BJ Freeman <[EMAIL PROTECTED]> wrote: >> >>> From: BJ Freeman <[EMAIL PROTECTED]> >>> Subject: Re: ServiceMcaCondition adding conditionals and multipline >>> conditions. >>> To: dev@ofbiz.apache.org >>> Date: Tuesday, September 30, 2008, 4:26 PM >>> just to recap my question had to do with modifying the >>> ServiceMcaCondition.java >>> to handle a contians operator and allowing more than one >>> condition for >>> fields and headers. >>> Nothing specific about the type of email like fedex or ups. >>> >>> >>> BJ Freeman sent the following on 9/30/2008 3:39 PM: #1 is to determine were to direct the specific email >> mail-rule-name="EmailOrdersRule"> >> header-name="Return-Path:" >>> operator="matches" >>> value="[EMAIL PROTECTED]"/> >> field-name="subject" >>> operator="not-contains" value="RE:"/> >> field-name="subject" operator="contains" value="Order*"/> >> field-name="from" operator="contains" value="Yahoo"/> >> service="ProcessYahooEmailOrders" >>> mode="sync"/> that is my uncerstainding of mCA. otherwise why not just do a way with it? #2 not sure the function of #2 since that can be >>> filtered by the mca. Why bury the filter algorithms in code. isn't that >>> what MCA are for? #3is done with the MCA dispatch. and is more flexible >>> than burying it in code. Adrian Crum sent the following on 9/30/2008 3:23 PM: > From a design perspective, my preference would be >>> to have a good > separation of concern. Something like: > > 1. MCA triggers service call > 2. Service pre-parses mail - drops obvious rejects > 3. Service forwards mail to a processing chain: > > Pre-Parsed Mail -> Fedex Processor -> UPS >>> Processor -> Import Processor > -> etc. > > The disadvantage to having the parsing done in the >>> MCA XML code is you > end up cross-cutting code (spaghetti code). For >>> example, Fedex-specific > code would be in your Fedex process AND in the MCA >>> XML code. It would be > better to keep all Fedex code in one place. > > -Adrian > > > BJ Freeman wrote: >> if you look at the msg about checking for >>> duplicates in the user ML you >> can see that any thing that will take longer >>> will eventually clogs the >> system. >> Most of my clients have hundreds of emails >>> from shippers >> (fulfillment/dropshippers) and suppliers about >>> status of drop ship >> inventory. >> So I would like to make the process as >>> efficient as possible but having >> the mca get to the correct parsing. >> >> >> >> BJ Freeman sent the following on 9/30/2008 >>> 1:23 PM: >>> routines are in java. and meant to parse >>> the email. they never get put >>> in the communications event. >>> >>> Adrian Crum sent the following on >>> 9/30/2008 1:13 PM: What are the processes written in? Are >>> they services? If yes, then you
Re: ServiceMcaCondition adding conditionals and multipline conditions.
[The point I was trying to make is that the decision of whether or not an email is a Yahoo email has to be made *somewhere* - so why not keep Yahoo-related code in one place? Your approach scatters the Yahoo-related code.] to me putting email processing in the yahoo code is squattering the email processing code. guess it is a matter of what should be where. to me it is a email till it get dispatched. So I treat it as a email. to me email processing, related to sorting belongs in the MCA. This philosophy follows in mail servers as well, like james. then all the specific code for that email processing should be in the related code, the email is dispatched to, like the parsing of the email. Adrian Crum sent the following on 9/30/2008 5:44 PM: > Until someone is willing to to make those changes, you're stuck with the > tools at hand. That's why I suggested moving your parsing logic to the > processing logic you already have. > > Your example: > > If an email has a return path that contains "[EMAIL PROTECTED]" and/or (not > sure which) the email is from "Yahoo" then it's a Yahoo email - send it to > ProcessYahooEmailOrders. > > My suggestion: > > Send incoming email to ProcessYahooEmailOrders. If the email has a return > path that contains "[EMAIL PROTECTED]" and/or the email is from "Yahoo" then > it's a Yahoo email - continue processing. Else return. > > The point I was trying to make is that the decision of whether or not an > email is a Yahoo email has to be made *somewhere* - so why not keep > Yahoo-related code in one place? Your approach scatters the Yahoo-related > code. > > -Adrian > > --- On Tue, 9/30/08, BJ Freeman <[EMAIL PROTECTED]> wrote: > >> From: BJ Freeman <[EMAIL PROTECTED]> >> Subject: Re: ServiceMcaCondition adding conditionals and multipline >> conditions. >> To: dev@ofbiz.apache.org >> Date: Tuesday, September 30, 2008, 4:26 PM >> just to recap my question had to do with modifying the >> ServiceMcaCondition.java >> to handle a contians operator and allowing more than one >> condition for >> fields and headers. >> Nothing specific about the type of email like fedex or ups. >> >> >> BJ Freeman sent the following on 9/30/2008 3:39 PM: >>> #1 is to determine were to direct the specific email >>>> mail-rule-name="EmailOrdersRule"> >>> > header-name="Return-Path:" >> operator="matches" >>> >> value="[EMAIL PROTECTED]"/> >>> > field-name="subject" >> operator="not-contains" >>> value="RE:"/> >>> > field-name="subject" operator="contains" >>> value="Order*"/> >>> > field-name="from" operator="contains" >>> value="Yahoo"/> >>> > service="ProcessYahooEmailOrders" >> mode="sync"/> >>> >>> >>> that is my uncerstainding of mCA. >>> otherwise why not just do a way with it? >>> #2 not sure the function of #2 since that can be >> filtered by the mca. >>> Why bury the filter algorithms in code. isn't that >> what MCA are for? >>> #3is done with the MCA dispatch. and is more flexible >> than burying it in >>> code. >>> >>> Adrian Crum sent the following on 9/30/2008 3:23 PM: From a design perspective, my preference would be >> to have a good separation of concern. Something like: 1. MCA triggers service call 2. Service pre-parses mail - drops obvious rejects 3. Service forwards mail to a processing chain: Pre-Parsed Mail -> Fedex Processor -> UPS >> Processor -> Import Processor -> etc. The disadvantage to having the parsing done in the >> MCA XML code is you end up cross-cutting code (spaghetti code). For >> example, Fedex-specific code would be in your Fedex process AND in the MCA >> XML code. It would be better to keep all Fedex code in one place. -Adrian BJ Freeman wrote: > if you look at the msg about checking for >> duplicates in the user ML you > can see that any thing that will take longer >> will eventually clogs the > system. > Most of my clients have hundreds of emails >> from shippers > (fulfillment/dropshippers) and suppliers about >> status of drop ship > inventory. > So I would like to make the process as >> efficient as possible but having > the mca get to the correct parsing. > > > > BJ Freeman sent the following on 9/30/2008 >> 1:23 PM: >> routines are in java. and meant to parse >> the email. they never get put >> in the communications event. >> >> Adrian Crum sent the following on >> 9/30/2008 1:13 PM: >>> What are the processes written in? Are >> they services? If yes, then you >>> could set up a service group and have >> the email go from service to >>> service - each service acting on the >> email accordingly. >>> -Adrian >>> >>> BJ Freeman wrote: thanks but I have many processes that are >> based on the email subject and or sender. Fedex notification, UPS >> Notifications, Order of differen
Re: ServiceMcaCondition adding conditionals and multipline conditions.
ah, I was asking if there was any opposition to the change. I have it mostly done. thanks. Adrian Crum sent the following on 9/30/2008 5:44 PM: > Until someone is willing to to make those changes, you're stuck with the > tools at hand. That's why I suggested moving your parsing logic to the > processing logic you already have. > > Your example: > > If an email has a return path that contains "[EMAIL PROTECTED]" and/or (not > sure which) the email is from "Yahoo" then it's a Yahoo email - send it to > ProcessYahooEmailOrders. > > My suggestion: > > Send incoming email to ProcessYahooEmailOrders. If the email has a return > path that contains "[EMAIL PROTECTED]" and/or the email is from "Yahoo" then > it's a Yahoo email - continue processing. Else return. > > The point I was trying to make is that the decision of whether or not an > email is a Yahoo email has to be made *somewhere* - so why not keep > Yahoo-related code in one place? Your approach scatters the Yahoo-related > code. > > -Adrian > > --- On Tue, 9/30/08, BJ Freeman <[EMAIL PROTECTED]> wrote: > >> From: BJ Freeman <[EMAIL PROTECTED]> >> Subject: Re: ServiceMcaCondition adding conditionals and multipline >> conditions. >> To: dev@ofbiz.apache.org >> Date: Tuesday, September 30, 2008, 4:26 PM >> just to recap my question had to do with modifying the >> ServiceMcaCondition.java >> to handle a contians operator and allowing more than one >> condition for >> fields and headers. >> Nothing specific about the type of email like fedex or ups. >> >> >> BJ Freeman sent the following on 9/30/2008 3:39 PM: >>> #1 is to determine were to direct the specific email >>>> mail-rule-name="EmailOrdersRule"> >>> > header-name="Return-Path:" >> operator="matches" >>> >> value="[EMAIL PROTECTED]"/> >>> > field-name="subject" >> operator="not-contains" >>> value="RE:"/> >>> > field-name="subject" operator="contains" >>> value="Order*"/> >>> > field-name="from" operator="contains" >>> value="Yahoo"/> >>> > service="ProcessYahooEmailOrders" >> mode="sync"/> >>> >>> >>> that is my uncerstainding of mCA. >>> otherwise why not just do a way with it? >>> #2 not sure the function of #2 since that can be >> filtered by the mca. >>> Why bury the filter algorithms in code. isn't that >> what MCA are for? >>> #3is done with the MCA dispatch. and is more flexible >> than burying it in >>> code. >>> >>> Adrian Crum sent the following on 9/30/2008 3:23 PM: From a design perspective, my preference would be >> to have a good separation of concern. Something like: 1. MCA triggers service call 2. Service pre-parses mail - drops obvious rejects 3. Service forwards mail to a processing chain: Pre-Parsed Mail -> Fedex Processor -> UPS >> Processor -> Import Processor -> etc. The disadvantage to having the parsing done in the >> MCA XML code is you end up cross-cutting code (spaghetti code). For >> example, Fedex-specific code would be in your Fedex process AND in the MCA >> XML code. It would be better to keep all Fedex code in one place. -Adrian BJ Freeman wrote: > if you look at the msg about checking for >> duplicates in the user ML you > can see that any thing that will take longer >> will eventually clogs the > system. > Most of my clients have hundreds of emails >> from shippers > (fulfillment/dropshippers) and suppliers about >> status of drop ship > inventory. > So I would like to make the process as >> efficient as possible but having > the mca get to the correct parsing. > > > > BJ Freeman sent the following on 9/30/2008 >> 1:23 PM: >> routines are in java. and meant to parse >> the email. they never get put >> in the communications event. >> >> Adrian Crum sent the following on >> 9/30/2008 1:13 PM: >>> What are the processes written in? Are >> they services? If yes, then you >>> could set up a service group and have >> the email go from service to >>> service - each service acting on the >> email accordingly. >>> -Adrian >>> >>> BJ Freeman wrote: thanks but I have many processes that are >> based on the email subject and or sender. Fedex notification, UPS >> Notifications, Order of different formats Import routies, etc. would like to do this in the mca >> so I don't have to write this in java code then do the same thing. Adrian Crum sent the following on >> 9/30/2008 12:47 PM: > The way I handled it here was >> to have a simpler condition that > sent the > email into a processor that >> did additional evaluations on the email. > -Adrian > > BJ Freeman wrote: >> if seemed pretty simple to >> add the conditionals. >> but looking a the decision >> tree it looks like is an or'ed
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Until someone is willing to to make those changes, you're stuck with the tools at hand. That's why I suggested moving your parsing logic to the processing logic you already have. Your example: If an email has a return path that contains "[EMAIL PROTECTED]" and/or (not sure which) the email is from "Yahoo" then it's a Yahoo email - send it to ProcessYahooEmailOrders. My suggestion: Send incoming email to ProcessYahooEmailOrders. If the email has a return path that contains "[EMAIL PROTECTED]" and/or the email is from "Yahoo" then it's a Yahoo email - continue processing. Else return. The point I was trying to make is that the decision of whether or not an email is a Yahoo email has to be made *somewhere* - so why not keep Yahoo-related code in one place? Your approach scatters the Yahoo-related code. -Adrian --- On Tue, 9/30/08, BJ Freeman <[EMAIL PROTECTED]> wrote: > From: BJ Freeman <[EMAIL PROTECTED]> > Subject: Re: ServiceMcaCondition adding conditionals and multipline > conditions. > To: dev@ofbiz.apache.org > Date: Tuesday, September 30, 2008, 4:26 PM > just to recap my question had to do with modifying the > ServiceMcaCondition.java > to handle a contians operator and allowing more than one > condition for > fields and headers. > Nothing specific about the type of email like fedex or ups. > > > BJ Freeman sent the following on 9/30/2008 3:39 PM: > > #1 is to determine were to direct the specific email > > mail-rule-name="EmailOrdersRule"> > > header-name="Return-Path:" > operator="matches" > > > value="[EMAIL PROTECTED]"/> > > field-name="subject" > operator="not-contains" > > value="RE:"/> > > field-name="subject" operator="contains" > > value="Order*"/> > > field-name="from" operator="contains" > > value="Yahoo"/> > > service="ProcessYahooEmailOrders" > mode="sync"/> > > > > > > that is my uncerstainding of mCA. > > otherwise why not just do a way with it? > > #2 not sure the function of #2 since that can be > filtered by the mca. > > Why bury the filter algorithms in code. isn't that > what MCA are for? > > > > #3is done with the MCA dispatch. and is more flexible > than burying it in > > code. > > > > Adrian Crum sent the following on 9/30/2008 3:23 PM: > >> From a design perspective, my preference would be > to have a good > >> separation of concern. Something like: > >> > >> 1. MCA triggers service call > >> 2. Service pre-parses mail - drops obvious rejects > >> 3. Service forwards mail to a processing chain: > >> > >> Pre-Parsed Mail -> Fedex Processor -> UPS > Processor -> Import Processor > >> -> etc. > >> > >> The disadvantage to having the parsing done in the > MCA XML code is you > >> end up cross-cutting code (spaghetti code). For > example, Fedex-specific > >> code would be in your Fedex process AND in the MCA > XML code. It would be > >> better to keep all Fedex code in one place. > >> > >> -Adrian > >> > >> > >> BJ Freeman wrote: > >>> if you look at the msg about checking for > duplicates in the user ML you > >>> can see that any thing that will take longer > will eventually clogs the > >>> system. > >>> Most of my clients have hundreds of emails > from shippers > >>> (fulfillment/dropshippers) and suppliers about > status of drop ship > >>> inventory. > >>> So I would like to make the process as > efficient as possible but having > >>> the mca get to the correct parsing. > >>> > >>> > >>> > >>> BJ Freeman sent the following on 9/30/2008 > 1:23 PM: > routines are in java. and meant to parse > the email. they never get put > in the communications event. > > Adrian Crum sent the following on > 9/30/2008 1:13 PM: > > What are the processes written in? Are > they services? If yes, then you > > could set up a service group and have > the email go from service to > > service - each service acting on the > email accordingly. > > > > -Adrian > > > > BJ Freeman wrote: > >> thanks > >> but I have many processes that are > based on the email subject and or > >> sender. Fedex notification, UPS > Notifications, Order of different > >> formats > >> Import routies, etc. > >> would like to do this in the mca > so I don't have to write this in java > >> code then do the same thing. > >> > >> Adrian Crum sent the following on > 9/30/2008 12:47 PM: > >>> The way I handled it here was > to have a simpler condition that > >>> sent the > >>> email into a processor that > did additional evaluations on the email. > >>> > >>> -Adrian > >>> > >>> BJ Freeman wrote: > if seemed pretty simple to > add the conditionals. > but looking a the decision > tree it looks like is an or'ed condition. > if I have two condition > for the same header or field and one of > them is > true then they will all be > true. > > The question is, is > expanding the condition
Re: ServiceMcaCondition adding conditionals and multipline conditions.
just to recap my question had to do with modifying the ServiceMcaCondition.java to handle a contians operator and allowing more than one condition for fields and headers. Nothing specific about the type of email like fedex or ups. BJ Freeman sent the following on 9/30/2008 3:39 PM: > #1 is to determine were to direct the specific email > > value="[EMAIL PROTECTED]"/> > value="RE:"/> > value="Order*"/> > value="Yahoo"/> > > > > that is my uncerstainding of mCA. > otherwise why not just do a way with it? > #2 not sure the function of #2 since that can be filtered by the mca. > Why bury the filter algorithms in code. isn't that what MCA are for? > > #3is done with the MCA dispatch. and is more flexible than burying it in > code. > > Adrian Crum sent the following on 9/30/2008 3:23 PM: >> From a design perspective, my preference would be to have a good >> separation of concern. Something like: >> >> 1. MCA triggers service call >> 2. Service pre-parses mail - drops obvious rejects >> 3. Service forwards mail to a processing chain: >> >> Pre-Parsed Mail -> Fedex Processor -> UPS Processor -> Import Processor >> -> etc. >> >> The disadvantage to having the parsing done in the MCA XML code is you >> end up cross-cutting code (spaghetti code). For example, Fedex-specific >> code would be in your Fedex process AND in the MCA XML code. It would be >> better to keep all Fedex code in one place. >> >> -Adrian >> >> >> BJ Freeman wrote: >>> if you look at the msg about checking for duplicates in the user ML you >>> can see that any thing that will take longer will eventually clogs the >>> system. >>> Most of my clients have hundreds of emails from shippers >>> (fulfillment/dropshippers) and suppliers about status of drop ship >>> inventory. >>> So I would like to make the process as efficient as possible but having >>> the mca get to the correct parsing. >>> >>> >>> >>> BJ Freeman sent the following on 9/30/2008 1:23 PM: routines are in java. and meant to parse the email. they never get put in the communications event. Adrian Crum sent the following on 9/30/2008 1:13 PM: > What are the processes written in? Are they services? If yes, then you > could set up a service group and have the email go from service to > service - each service acting on the email accordingly. > > -Adrian > > BJ Freeman wrote: >> thanks >> but I have many processes that are based on the email subject and or >> sender. Fedex notification, UPS Notifications, Order of different >> formats >> Import routies, etc. >> would like to do this in the mca so I don't have to write this in java >> code then do the same thing. >> >> Adrian Crum sent the following on 9/30/2008 12:47 PM: >>> The way I handled it here was to have a simpler condition that >>> sent the >>> email into a processor that did additional evaluations on the email. >>> >>> -Adrian >>> >>> BJ Freeman wrote: if seemed pretty simple to add the conditionals. but looking a the decision tree it looks like is an or'ed condition. if I have two condition for the same header or field and one of them is true then they will all be true. The question is, is expanding the conditions to accept and and or condition acceptable. this would include a grouping of each condition like in an If statement. rationale: a lot of emails have parts of a field or header that needs to be looked at. for instance subject: order #13950 from yst-1309 to parse you want [contain order and contain yst] or not-contain Re: BTW any hints on how to define a group of condition in the xsd would help. >>> >> >> > > > >
Re: ServiceMcaCondition adding conditionals and multipline conditions.
#1 is to determine were to direct the specific email that is my uncerstainding of mCA. otherwise why not just do a way with it? #2 not sure the function of #2 since that can be filtered by the mca. Why bury the filter algorithms in code. isn't that what MCA are for? #3is done with the MCA dispatch. and is more flexible than burying it in code. Adrian Crum sent the following on 9/30/2008 3:23 PM: > From a design perspective, my preference would be to have a good > separation of concern. Something like: > > 1. MCA triggers service call > 2. Service pre-parses mail - drops obvious rejects > 3. Service forwards mail to a processing chain: > > Pre-Parsed Mail -> Fedex Processor -> UPS Processor -> Import Processor > -> etc. > > The disadvantage to having the parsing done in the MCA XML code is you > end up cross-cutting code (spaghetti code). For example, Fedex-specific > code would be in your Fedex process AND in the MCA XML code. It would be > better to keep all Fedex code in one place. > > -Adrian > > > BJ Freeman wrote: >> if you look at the msg about checking for duplicates in the user ML you >> can see that any thing that will take longer will eventually clogs the >> system. >> Most of my clients have hundreds of emails from shippers >> (fulfillment/dropshippers) and suppliers about status of drop ship >> inventory. >> So I would like to make the process as efficient as possible but having >> the mca get to the correct parsing. >> >> >> >> BJ Freeman sent the following on 9/30/2008 1:23 PM: >>> routines are in java. and meant to parse the email. they never get put >>> in the communications event. >>> >>> Adrian Crum sent the following on 9/30/2008 1:13 PM: What are the processes written in? Are they services? If yes, then you could set up a service group and have the email go from service to service - each service acting on the email accordingly. -Adrian BJ Freeman wrote: > thanks > but I have many processes that are based on the email subject and or > sender. Fedex notification, UPS Notifications, Order of different > formats > Import routies, etc. > would like to do this in the mca so I don't have to write this in java > code then do the same thing. > > Adrian Crum sent the following on 9/30/2008 12:47 PM: >> The way I handled it here was to have a simpler condition that >> sent the >> email into a processor that did additional evaluations on the email. >> >> -Adrian >> >> BJ Freeman wrote: >>> if seemed pretty simple to add the conditionals. >>> but looking a the decision tree it looks like is an or'ed condition. >>> if I have two condition for the same header or field and one of >>> them is >>> true then they will all be true. >>> >>> The question is, is expanding the conditions to accept and and or >>> condition acceptable. this would include a grouping of each >>> condition >>> like in an If statement. >>> >>> rationale: >>> a lot of emails have parts of a field or header that needs to be >>> looked >>> at. for instance >>> subject: order #13950 from yst-1309 >>> to parse you want >>> [contain order >>> and >>> contain yst] >>> or >>> not-contain Re: >>> >>> BTW any hints on how to define a group of condition in the xsd would >>> help. >>> >>> >>> >>> >>> >> >> > > >
Re: ServiceMcaCondition adding conditionals and multipline conditions.
From a design perspective, my preference would be to have a good separation of concern. Something like: 1. MCA triggers service call 2. Service pre-parses mail - drops obvious rejects 3. Service forwards mail to a processing chain: Pre-Parsed Mail -> Fedex Processor -> UPS Processor -> Import Processor -> etc. The disadvantage to having the parsing done in the MCA XML code is you end up cross-cutting code (spaghetti code). For example, Fedex-specific code would be in your Fedex process AND in the MCA XML code. It would be better to keep all Fedex code in one place. -Adrian BJ Freeman wrote: if you look at the msg about checking for duplicates in the user ML you can see that any thing that will take longer will eventually clogs the system. Most of my clients have hundreds of emails from shippers (fulfillment/dropshippers) and suppliers about status of drop ship inventory. So I would like to make the process as efficient as possible but having the mca get to the correct parsing. BJ Freeman sent the following on 9/30/2008 1:23 PM: routines are in java. and meant to parse the email. they never get put in the communications event. Adrian Crum sent the following on 9/30/2008 1:13 PM: What are the processes written in? Are they services? If yes, then you could set up a service group and have the email go from service to service - each service acting on the email accordingly. -Adrian BJ Freeman wrote: thanks but I have many processes that are based on the email subject and or sender. Fedex notification, UPS Notifications, Order of different formats Import routies, etc. would like to do this in the mca so I don't have to write this in java code then do the same thing. Adrian Crum sent the following on 9/30/2008 12:47 PM: The way I handled it here was to have a simpler condition that sent the email into a processor that did additional evaluations on the email. -Adrian BJ Freeman wrote: if seemed pretty simple to add the conditionals. but looking a the decision tree it looks like is an or'ed condition. if I have two condition for the same header or field and one of them is true then they will all be true. The question is, is expanding the conditions to accept and and or condition acceptable. this would include a grouping of each condition like in an If statement. rationale: a lot of emails have parts of a field or header that needs to be looked at. for instance subject: order #13950 from yst-1309 to parse you want [contain order and contain yst] or not-contain Re: BTW any hints on how to define a group of condition in the xsd would help.
Re: ServiceMcaCondition adding conditionals and multipline conditions.
if you look at the msg about checking for duplicates in the user ML you can see that any thing that will take longer will eventually clogs the system. Most of my clients have hundreds of emails from shippers (fulfillment/dropshippers) and suppliers about status of drop ship inventory. So I would like to make the process as efficient as possible but having the mca get to the correct parsing. BJ Freeman sent the following on 9/30/2008 1:23 PM: > routines are in java. and meant to parse the email. they never get put > in the communications event. > > Adrian Crum sent the following on 9/30/2008 1:13 PM: >> What are the processes written in? Are they services? If yes, then you >> could set up a service group and have the email go from service to >> service - each service acting on the email accordingly. >> >> -Adrian >> >> BJ Freeman wrote: >>> thanks >>> but I have many processes that are based on the email subject and or >>> sender. Fedex notification, UPS Notifications, Order of different formats >>> Import routies, etc. >>> would like to do this in the mca so I don't have to write this in java >>> code then do the same thing. >>> >>> Adrian Crum sent the following on 9/30/2008 12:47 PM: The way I handled it here was to have a simpler condition that sent the email into a processor that did additional evaluations on the email. -Adrian BJ Freeman wrote: > if seemed pretty simple to add the conditionals. > but looking a the decision tree it looks like is an or'ed condition. > if I have two condition for the same header or field and one of them is > true then they will all be true. > > The question is, is expanding the conditions to accept and and or > condition acceptable. this would include a grouping of each condition > like in an If statement. > > rationale: > a lot of emails have parts of a field or header that needs to be looked > at. for instance > subject: order #13950 from yst-1309 > to parse you want > [contain order > and > contain yst] > or > not-contain Re: > > BTW any hints on how to define a group of condition in the xsd would > help. > > >>> >> >> > > > >
Re: ServiceMcaCondition adding conditionals and multipline conditions.
routines are in java. and meant to parse the email. they never get put in the communications event. Adrian Crum sent the following on 9/30/2008 1:13 PM: > What are the processes written in? Are they services? If yes, then you > could set up a service group and have the email go from service to > service - each service acting on the email accordingly. > > -Adrian > > BJ Freeman wrote: >> thanks >> but I have many processes that are based on the email subject and or >> sender. Fedex notification, UPS Notifications, Order of different formats >> Import routies, etc. >> would like to do this in the mca so I don't have to write this in java >> code then do the same thing. >> >> Adrian Crum sent the following on 9/30/2008 12:47 PM: >>> The way I handled it here was to have a simpler condition that sent the >>> email into a processor that did additional evaluations on the email. >>> >>> -Adrian >>> >>> BJ Freeman wrote: if seemed pretty simple to add the conditionals. but looking a the decision tree it looks like is an or'ed condition. if I have two condition for the same header or field and one of them is true then they will all be true. The question is, is expanding the conditions to accept and and or condition acceptable. this would include a grouping of each condition like in an If statement. rationale: a lot of emails have parts of a field or header that needs to be looked at. for instance subject: order #13950 from yst-1309 to parse you want [contain order and contain yst] or not-contain Re: BTW any hints on how to define a group of condition in the xsd would help. >>> >>> >> >> > > >
Re: ServiceMcaCondition adding conditionals and multipline conditions.
What are the processes written in? Are they services? If yes, then you could set up a service group and have the email go from service to service - each service acting on the email accordingly. -Adrian BJ Freeman wrote: thanks but I have many processes that are based on the email subject and or sender. Fedex notification, UPS Notifications, Order of different formats Import routies, etc. would like to do this in the mca so I don't have to write this in java code then do the same thing. Adrian Crum sent the following on 9/30/2008 12:47 PM: The way I handled it here was to have a simpler condition that sent the email into a processor that did additional evaluations on the email. -Adrian BJ Freeman wrote: if seemed pretty simple to add the conditionals. but looking a the decision tree it looks like is an or'ed condition. if I have two condition for the same header or field and one of them is true then they will all be true. The question is, is expanding the conditions to accept and and or condition acceptable. this would include a grouping of each condition like in an If statement. rationale: a lot of emails have parts of a field or header that needs to be looked at. for instance subject: order #13950 from yst-1309 to parse you want [contain order and contain yst] or not-contain Re: BTW any hints on how to define a group of condition in the xsd would help.
Re: ServiceMcaCondition adding conditionals and multipline conditions.
thanks but I have many processes that are based on the email subject and or sender. Fedex notification, UPS Notifications, Order of different formats Import routies, etc. would like to do this in the mca so I don't have to write this in java code then do the same thing. Adrian Crum sent the following on 9/30/2008 12:47 PM: > The way I handled it here was to have a simpler condition that sent the > email into a processor that did additional evaluations on the email. > > -Adrian > > BJ Freeman wrote: >> if seemed pretty simple to add the conditionals. >> but looking a the decision tree it looks like is an or'ed condition. >> if I have two condition for the same header or field and one of them is >> true then they will all be true. >> >> The question is, is expanding the conditions to accept and and or >> condition acceptable. this would include a grouping of each condition >> like in an If statement. >> >> rationale: >> a lot of emails have parts of a field or header that needs to be looked >> at. for instance >> subject: order #13950 from yst-1309 >> to parse you want >> [contain order >> and >> contain yst] >> or >> not-contain Re: >> >> BTW any hints on how to define a group of condition in the xsd would >> help. >> >> > > >
Re: ServiceMcaCondition adding conditionals and multipline conditions.
The way I handled it here was to have a simpler condition that sent the email into a processor that did additional evaluations on the email. -Adrian BJ Freeman wrote: if seemed pretty simple to add the conditionals. but looking a the decision tree it looks like is an or'ed condition. if I have two condition for the same header or field and one of them is true then they will all be true. The question is, is expanding the conditions to accept and and or condition acceptable. this would include a grouping of each condition like in an If statement. rationale: a lot of emails have parts of a field or header that needs to be looked at. for instance subject: order #13950 from yst-1309 to parse you want [contain order and contain yst] or not-contain Re: BTW any hints on how to define a group of condition in the xsd would help.
ServiceMcaCondition adding conditionals and multipline conditions.
if seemed pretty simple to add the conditionals. but looking a the decision tree it looks like is an or'ed condition. if I have two condition for the same header or field and one of them is true then they will all be true. The question is, is expanding the conditions to accept and and or condition acceptable. this would include a grouping of each condition like in an If statement. rationale: a lot of emails have parts of a field or header that needs to be looked at. for instance subject: order #13950 from yst-1309 to parse you want [contain order and contain yst] or not-contain Re: BTW any hints on how to define a group of condition in the xsd would help.
Re: findBys and Transactions
Thanks Scott for the pointers. I missed those as the titles didnt look relevant. I think GenericDelegator is being refactored currently - what about adding additional parameter to the findBys or other suitable way which allows callers to specify whether to create a transaction or not? Seems like number of ppl need this for performance reasons. Scott Gray wrote: > > Hi Ritesh > > There are plenty of threads around, here's a couple: > http://www.nabble.com/-Fwd%3A-Re%3A--Fwd%3A-Re%3A-Transaction-related-error-in-log-when-the---to14299071.html#a14300249 > http://www.nabble.com/order-shipped-email-to16101007.html#a16136542 > > Regards > Scott > > 2008/9/30 Ritesh Trivedi <[EMAIL PROTECTED]>: >> >> Hi, >> >> Note:I tried searching for an explanation of why are transactions created >> by >> GenericDelegator even for purely read only operations - but couldnt find >> any >> relevant thread. If its already answered will appreciate if someone can >> provide the link. >> >> I ran a profiler on my application and found significant amount of time >> getting spent >> >> e.g. (GenericDelegator.findCountByCondition() - is spending 90% of the >> time >> in transaction.begin and transaction.commit()) >> >> There are several (if not most) other calls that are similar which is >> adding >> up to the slowness in the response time. >> >> Is there a reason why GenericDelegator is creating transaction for read >> only >> operations - such as findBys and counts? Also there is a flag >> alwaysUseTransaction - but that really "always" - not really very useful >> if >> you think about it (besides its declared final). Is there a way to turn >> off >> the transactions on as needed basis? >> >> >> -- >> View this message in context: >> http://www.nabble.com/findBys-and-Transactions-tp19734296p19734296.html >> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/findBys-and-Transactions-tp19734296p19745961.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Discussion: Recurring Events
David (and others), There is a fundamental difference between the RecurrenceRule/RecurrenceInfo entities and the TemporalExpression entity that needs to be addressed. In the example David gave below, the duration of the recurring event is assumed to be 8 hrs (byHourList="09,10,11,13,14,15,16,17"). Temporal expressions have no duration information. That is intentional - a temporal expression indicates when an event occurs, not how long it will last. So, in the case of WorkEfforts, we need a way of storing the duration of a recurring event. Should we use one of the existing *Millis fields, or do something else? -Adrian David E Jones wrote: On Sep 17, 2008, at 2:15 PM, Adrian Crum wrote: I would like to start working on connecting the temporal expressions code to recurring events. Before I begin, I want to make sure I understand the requirements and where things should land. The WorkEffort entity already has a RecurrenceInfoId field, so adding a temporal expression ID field to that is obvious. Yep, sounds good. What about a personal calendar? Where are those recurring events kept? They aren't related to a work effort or a work schedule. Why would a personal calendar be any different from any other calendar event? Calendar events go in the WorkEffort entity. What about an employee work schedule? I want to assign an employee to work in the roof department from 8am to 5pm, Monday through Friday, with a lunch break from 12:00 to 12:30pm. Where would those recurring events go? Here's what I wrote in Jira OFBIZ-1956: "To push this further, and to answer Jacques' question: the WorkEffort entity is already designed to handle work schedules using the WorkEffortType "Available" (ID: AVAILABLE)." In addition Jacopo added some demo data that I put together for another project that shows how this would look (pretty much exactly, actually) with the old recurrence records (also in that same issue): intervalNumber="1" countNumber="-1" byHourList="09,10,11,13,14,15,16,17" byDayList="MO,TU,WE,TH,FR"/> startDateTime="2008-01-01 00:00:00.000" recurrenceRuleId="SCHED_STD_40HR_WK" recurrenceCount="0"/> workEffortTypeId="AVAILABLE" scopeEnumId="WES_PRIVATE" workEffortName="Work Schedule Full Time (40 hrs/wk)" recurrenceInfoId="SCHED_STD_40HR_WK"/> For the future let's do the same thing except instead of a recurrenceInfoId on the WorkEffort have a temporalExpressionId. Does that make sense, or were you looking for something else? -David
Re: Discussion: Recurring Events
David, Sorry it took so long to reply to this - I've been giving it a lot of thought before answering. I think it would be best to just have the one WorkEffort, and any changes made to recurring instances of it would be made to the original copy. On a side note, the implementation here has some good designs and some bad designs. I'm trying to be careful to port over the good designs and not the bad ones. I came to the conclusion that using the "dummy" WorkEfforts was a bad design. -Adrian --- On Thu, 9/18/08, David E Jones <[EMAIL PROTECTED]> wrote: > From: David E Jones <[EMAIL PROTECTED]> > Subject: Re: Discussion: Recurring Events > To: dev@ofbiz.apache.org > Date: Thursday, September 18, 2008, 5:05 AM > On Sep 18, 2008, at 5:02 AM, Adrian Crum wrote: > > > --- On Wed, 9/17/08, Adrian Crum > <[EMAIL PROTECTED]> wrote: > >> I would like to start working on connecting the > temporal > >> expressions > >> code to recurring events. Before I begin, I want > to make > >> sure I > >> understand the requirements and where things > should land. > >> > >> The WorkEffort entity already has a > RecurrenceInfoId field, > >> so adding a > >> temporal expression ID field to that is obvious. > > > > So, how do we want this to work? On my local copy, I > changed the > > WorkEffortServices.getWorkEffortEventsByPeriod(...) > method so that > > recurring event info is used to create > "dummy" work efforts that are > > added to the results. If a user changes anything in > the "dummy" work > > effort and saves it, then a work effort is created. > > > > How does that sound? Does anyone have any other ideas? > > At what point did you create the new WorkEffort records? > What it when > they viewed the recurring event, or when they change > something based > on a recurring event (probably along with a question of > change just > this event or the entire series)? > > -David
Re: usage of party entity status field
Or modify the performFind service so it accepts an optional EntityCondition parameter that contains additional permissions. -Adrian --- On Tue, 9/30/08, Scott Gray <[EMAIL PROTECTED]> wrote: > From: Scott Gray <[EMAIL PROTECTED]> > Subject: Re: usage of party entity status field > To: dev@ofbiz.apache.org > Date: Tuesday, September 30, 2008, 12:37 AM > Hi Hans > > You could always run the prepareFind service in a groovy > script, add > your extra condition for the null and then run the > executeFind > service. It's not too much coding and you can copy > most of it > straight from the performFind service. > > Regards > Scott > > 2008/9/30 Hans Bakker > <[EMAIL PROTECTED]>: > > but the problem is performFind cannot do that and > adding this to > > performfind is a major undertaking for us... > > > > so be it > > > > > > On Mon, 2008-09-29 at 22:38 -0600, David E Jones > wrote: > >> The more common approach is to design the search > or other > >> functionality to be more flexible, because at the > end of the day there > >> is no way to guarantee a value for many fields, > and really to keep > >> things easy to use and customize in OFBiz we > don't want to require too > >> many fields. Instead the functionality related to > those fields should > >> silently do nothing if the data is not available. > >> > >> In general just treat null/empty like the default > value. In this case > >> that's probably PARTY_ENABLED. > >> > >> -David > >> > >> > >> On Sep 29, 2008, at 10:06 PM, Hans Bakker wrote: > >> > >> > The problem: > >> > currently the status field in party is not > checked in the performFind > >> > service, so all popups for party show > disabled parties. > >> > > >> > The performfind service can only check on > 'and-ed' fields, > >> > so to add the > status="PARTY_ENABLED" condition could be a > solution. > >> > However that means that the party status > field cannot be empty. > >> > > >> > In order to solve this the following is > proposed: > >> > 1. change all demo data to include the party > status field > >> > 2. make sure that by default the create party > service sets this > >> > field to > >> > "PARTY_ENABLED" > >> > 3. provide a conversion service where > existing data can be modified to > >> > fill the empty status field with > "PARTY_ENABLED". > >> > > >> > > >> > any comments or suggestions? > >> > > >> > -- > >> > Antwebsystems.com: Quality OFBiz services for > competitive prices > >> > > >> > > >> > > -- > > Antwebsystems.com: Quality OFBiz services for > competitive prices > > > >
Re: svn commit: r699817 - in /ofbiz/trunk/applications/accounting: config/ script/org/ofbiz/accounting/invoice/ servicedef/ src/org/ofbiz/accounting/invoice/ webapp/accounting/WEB-INF/actions/payment/
Ok Jacopo, i will remove the invoice conversion service and will adapt the payment application screens and programs so it will be possible to apply a payment on another currency...however this 'other' currency should be available on the payment as an 'original' currency. In order to be able to display as much as possible in the home currency the invoices will be shown (not converted) as using the exchange rate table but when available on the payment (original/actual amount) using that exchange rate (better a configurable option?) I will test then the ledger posting programs if i can get this to work. Thanks for your comments on this subject, surely this is a much better solution. Regards, Hans On Tue, 2008-09-30 at 06:51 +0200, Jacopo Cappellato wrote: > On Sep 30, 2008, at 5:28 AM, Hans Bakker wrote: > > > Hi Jacopo, > > > > the point below is very important, does it mean the ledger posting is > > checking the company base currency against the invoices and payments > > and > > convert where required? > > Yes, > > the "company base currency" is set in the PartyAccountingPref (sorry, > I don't remember the name exactly) and you have to enter a record in > the CurrencyUomDated entity. > If this information is available then you'll notice that the > AcctgTransEntry will have two different amounts in the fields: > amount/currencyUomId > and > origAmount/origCurrencyUomId > > You can also test it creating a manual transaction. > > Hope it helps, > > Jacopo > > > > > > > On the payment we have the payment amount/currency fields for both the > > incoming and original payment of which we can extract the exchange > > rate > > used. > > > > In this case no conversion of any document is required, no entry in > > the > > exchange table is required and we keep all amounts in the ledger > > obviously in the companies base currency > > > > let me know if i am right on this. > > > > Regards, > > Hans > > > > > > On Mon, 2008-09-29 at 14:28 +0200, Jacopo Cappellato wrote: > >> . > >> > >> There is already support for this in OFBiz: accounting transactions > >> originated by events in different currencies from the one of GL are > >> automatically converted using the currency exchange rate of the date > >> of the transaction. > > > > -- > > Antwebsystems.com: Quality OFBiz services for competitive prices > > > -- Antwebsystems.com: Quality OFBiz services for competitive prices
Re: svn commit: r699817 - in /ofbiz/trunk/applications/accounting: config/ script/org/ofbiz/accounting/invoice/ servicedef/ src/org/ofbiz/accounting/invoice/ webapp/accounting/WEB-INF/actions/payment/
Thanks Jacopo, I think I will make a FAQ for that... Jacques From: "Jacopo Cappellato" <[EMAIL PROTECTED]> On Sep 30, 2008, at 5:28 AM, Hans Bakker wrote: Hi Jacopo, the point below is very important, does it mean the ledger posting is checking the company base currency against the invoices and payments and convert where required? Yes, the "company base currency" is set in the PartyAccountingPref (sorry, I don't remember the name exactly) and you have to enter a record in the CurrencyUomDated entity. If this information is available then you'll notice that the AcctgTransEntry will have two different amounts in the fields: amount/currencyUomId and origAmount/origCurrencyUomId You can also test it creating a manual transaction. Hope it helps, Jacopo On the payment we have the payment amount/currency fields for both the incoming and original payment of which we can extract the exchange rate used. In this case no conversion of any document is required, no entry in the exchange table is required and we keep all amounts in the ledger obviously in the companies base currency let me know if i am right on this. Regards, Hans On Mon, 2008-09-29 at 14:28 +0200, Jacopo Cappellato wrote: . There is already support for this in OFBiz: accounting transactions originated by events in different currencies from the one of GL are automatically converted using the currency exchange rate of the date of the transaction. -- Antwebsystems.com: Quality OFBiz services for competitive prices
Re: usage of party entity status field
Thanks Scott i will have a look into that however i stiil think that making the status field mandatory and filled as in any other status field, would be much easier for many other programs/views which now have to use this special treatment thanks again for your suggestion... Regards, Hans On Tue, 2008-09-30 at 20:37 +1300, Scott Gray wrote: > Hi Hans > > You could always run the prepareFind service in a groovy script, add > your extra condition for the null and then run the executeFind > service. It's not too much coding and you can copy most of it > straight from the performFind service. > > Regards > Scott > > 2008/9/30 Hans Bakker <[EMAIL PROTECTED]>: > > but the problem is performFind cannot do that and adding this to > > performfind is a major undertaking for us... > > > > so be it > > > > > > On Mon, 2008-09-29 at 22:38 -0600, David E Jones wrote: > >> The more common approach is to design the search or other > >> functionality to be more flexible, because at the end of the day there > >> is no way to guarantee a value for many fields, and really to keep > >> things easy to use and customize in OFBiz we don't want to require too > >> many fields. Instead the functionality related to those fields should > >> silently do nothing if the data is not available. > >> > >> In general just treat null/empty like the default value. In this case > >> that's probably PARTY_ENABLED. > >> > >> -David > >> > >> > >> On Sep 29, 2008, at 10:06 PM, Hans Bakker wrote: > >> > >> > The problem: > >> > currently the status field in party is not checked in the performFind > >> > service, so all popups for party show disabled parties. > >> > > >> > The performfind service can only check on 'and-ed' fields, > >> > so to add the status="PARTY_ENABLED" condition could be a solution. > >> > However that means that the party status field cannot be empty. > >> > > >> > In order to solve this the following is proposed: > >> > 1. change all demo data to include the party status field > >> > 2. make sure that by default the create party service sets this > >> > field to > >> > "PARTY_ENABLED" > >> > 3. provide a conversion service where existing data can be modified to > >> > fill the empty status field with "PARTY_ENABLED". > >> > > >> > > >> > any comments or suggestions? > >> > > >> > -- > >> > Antwebsystems.com: Quality OFBiz services for competitive prices > >> > > >> > > >> > > -- > > Antwebsystems.com: Quality OFBiz services for competitive prices > > > > -- Antwebsystems.com: Quality OFBiz services for competitive prices
[jira] Created: (OFBIZ-1978) createShipment parameters : add a shipmentId in IN parameters
createShipment parameters : add a shipmentId in IN parameters - Key: OFBIZ-1978 URL: https://issues.apache.org/jira/browse/OFBIZ-1978 Project: OFBiz Issue Type: Improvement Components: product Reporter: Charles STELTZLEN Priority: Minor In Shipment services, the service of creation, called *createShipment*, don't accept our own *shipmentId*. It can be a problem in some business, and I think it won't be difficult to add a IN parameter shipmentId. So, I propose to change the service and use a shipmentId given by default, and if there is no shipmentId in parameters, it will get the next sequenced id (as it already done in the createShipment service). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: usage of party entity status field
Hi Hans You could always run the prepareFind service in a groovy script, add your extra condition for the null and then run the executeFind service. It's not too much coding and you can copy most of it straight from the performFind service. Regards Scott 2008/9/30 Hans Bakker <[EMAIL PROTECTED]>: > but the problem is performFind cannot do that and adding this to > performfind is a major undertaking for us... > > so be it > > > On Mon, 2008-09-29 at 22:38 -0600, David E Jones wrote: >> The more common approach is to design the search or other >> functionality to be more flexible, because at the end of the day there >> is no way to guarantee a value for many fields, and really to keep >> things easy to use and customize in OFBiz we don't want to require too >> many fields. Instead the functionality related to those fields should >> silently do nothing if the data is not available. >> >> In general just treat null/empty like the default value. In this case >> that's probably PARTY_ENABLED. >> >> -David >> >> >> On Sep 29, 2008, at 10:06 PM, Hans Bakker wrote: >> >> > The problem: >> > currently the status field in party is not checked in the performFind >> > service, so all popups for party show disabled parties. >> > >> > The performfind service can only check on 'and-ed' fields, >> > so to add the status="PARTY_ENABLED" condition could be a solution. >> > However that means that the party status field cannot be empty. >> > >> > In order to solve this the following is proposed: >> > 1. change all demo data to include the party status field >> > 2. make sure that by default the create party service sets this >> > field to >> > "PARTY_ENABLED" >> > 3. provide a conversion service where existing data can be modified to >> > fill the empty status field with "PARTY_ENABLED". >> > >> > >> > any comments or suggestions? >> > >> > -- >> > Antwebsystems.com: Quality OFBiz services for competitive prices >> > >> > >> > -- > Antwebsystems.com: Quality OFBiz services for competitive prices > >
Re: usage of party entity status field
but the problem is performFind cannot do that and adding this to performfind is a major undertaking for us... so be it On Mon, 2008-09-29 at 22:38 -0600, David E Jones wrote: > The more common approach is to design the search or other > functionality to be more flexible, because at the end of the day there > is no way to guarantee a value for many fields, and really to keep > things easy to use and customize in OFBiz we don't want to require too > many fields. Instead the functionality related to those fields should > silently do nothing if the data is not available. > > In general just treat null/empty like the default value. In this case > that's probably PARTY_ENABLED. > > -David > > > On Sep 29, 2008, at 10:06 PM, Hans Bakker wrote: > > > The problem: > > currently the status field in party is not checked in the performFind > > service, so all popups for party show disabled parties. > > > > The performfind service can only check on 'and-ed' fields, > > so to add the status="PARTY_ENABLED" condition could be a solution. > > However that means that the party status field cannot be empty. > > > > In order to solve this the following is proposed: > > 1. change all demo data to include the party status field > > 2. make sure that by default the create party service sets this > > field to > > "PARTY_ENABLED" > > 3. provide a conversion service where existing data can be modified to > > fill the empty status field with "PARTY_ENABLED". > > > > > > any comments or suggestions? > > > > -- > > Antwebsystems.com: Quality OFBiz services for competitive prices > > > > > -- Antwebsystems.com: Quality OFBiz services for competitive prices
