why is resetGrandTotal a SECA on createOrderAdjustment?

[Si Chen <si...@opensourcestrategies.com>]

Hi.

Why is resetGrandTotal a SECA on createOrderAdjustment?  Would  
anybody have a problem if I just made it a service call inside  
createOrderAdjustment?

Best Regards,

Si
sichen@opensourcestrategies.com

Re: why is resetGrandTotal a SECA on createOrderAdjustment?

[David E Jones <jo...@undersunconsulting.com>]

Si,

Yes, that is what the EECA alternative would look like. There are  
various other SECAs that trigger the resetGrandTotal service, and  
that is why I mentioned potentially having a series of EECA rules  
that would replace them.

Putting it inside the service implementation is okay too, and in a  
way may be more efficient. The reason I say this is the current  
storeOrder service does direct entity engine calls (mostly one call I  
guess) rather than calling the services. Of course, they really  
should be service calls to lower level services instead of direct  
entity engine calls and fixing that would put the two approaches on  
par in terms of performance.

I guess I'm saying unless someone else sees issues with this, the  
EECA approach is probably easier to write and maintain (and keep  
track of).

-David


On Oct 13, 2006, at 5:39 PM, Si Chen wrote:

> David,
>
> Sorry, but you've lost me there.  Right now, there's an SECA on  
> createorderAdjustment which then calls resetGrandTotal.  Are you  
> saying to implement an EECA on OrderAdjustment?
>
> On Oct 13, 2006, at 3:20 AM, David E Jones wrote:
>
>>
>> Good question... probably because it was originally implemented  
>> that way and hasn't really been reviewed... ;)
>>
>> In a way this should probably be an EECA because the grandTotal  
>> field is really a derived/redundant field used for easy display,  
>> etc, and not really an "original source" field, and EECAs are good  
>> for that. I think at the time this was implemented the EECAs were  
>> not yet implemented.
>>
>> It could be a call within the service itself too. I'm not sure  
>> long term which would be the better practice. In a way I think a  
>> set of EECA rules would be easier to maintain over time as there  
>> are various entities that have an effect on this field and the  
>> "rules" for maintaining it could all site in one place. However,  
>> this also may lead to more redundant calls to the grand total  
>> service as during the whole storeOrder service it would be called  
>> a bunch of times.
>>
>> -David
>>
>>
>> On Oct 13, 2006, at 12:54 AM, Si Chen wrote:
>>
>>> Hi.
>>>
>>> Why is resetGrandTotal a SECA on createOrderAdjustment?  Would  
>>> anybody have a problem if I just made it a service call inside  
>>> createOrderAdjustment?
>>>
>>> Best Regards,
>>>
>>> Si
>>> sichen@opensourcestrategies.com
>>>
>>>
>>>
>
> Best Regards,
>
> Si
> sichen@opensourcestrategies.com
>
>
>

Re: why is resetGrandTotal a SECA on createOrderAdjustment?

[Si Chen <si...@opensourcestrategies.com>]

David,

Sorry, but you've lost me there.  Right now, there's an SECA on  
createorderAdjustment which then calls resetGrandTotal.  Are you  
saying to implement an EECA on OrderAdjustment?

On Oct 13, 2006, at 3:20 AM, David E Jones wrote:

>
> Good question... probably because it was originally implemented  
> that way and hasn't really been reviewed... ;)
>
> In a way this should probably be an EECA because the grandTotal  
> field is really a derived/redundant field used for easy display,  
> etc, and not really an "original source" field, and EECAs are good  
> for that. I think at the time this was implemented the EECAs were  
> not yet implemented.
>
> It could be a call within the service itself too. I'm not sure long  
> term which would be the better practice. In a way I think a set of  
> EECA rules would be easier to maintain over time as there are  
> various entities that have an effect on this field and the "rules"  
> for maintaining it could all site in one place. However, this also  
> may lead to more redundant calls to the grand total service as  
> during the whole storeOrder service it would be called a bunch of  
> times.
>
> -David
>
>
> On Oct 13, 2006, at 12:54 AM, Si Chen wrote:
>
>> Hi.
>>
>> Why is resetGrandTotal a SECA on createOrderAdjustment?  Would  
>> anybody have a problem if I just made it a service call inside  
>> createOrderAdjustment?
>>
>> Best Regards,
>>
>> Si
>> sichen@opensourcestrategies.com
>>
>>
>>

Best Regards,

Si
sichen@opensourcestrategies.com

Re: why is resetGrandTotal a SECA on createOrderAdjustment?

[David E Jones <jo...@undersunconsulting.com>]

Good question... probably because it was originally implemented that  
way and hasn't really been reviewed... ;)

In a way this should probably be an EECA because the grandTotal field  
is really a derived/redundant field used for easy display, etc, and  
not really an "original source" field, and EECAs are good for that. I  
think at the time this was implemented the EECAs were not yet  
implemented.

It could be a call within the service itself too. I'm not sure long  
term which would be the better practice. In a way I think a set of  
EECA rules would be easier to maintain over time as there are various  
entities that have an effect on this field and the "rules" for  
maintaining it could all site in one place. However, this also may  
lead to more redundant calls to the grand total service as during the  
whole storeOrder service it would be called a bunch of times.

-David


On Oct 13, 2006, at 12:54 AM, Si Chen wrote:

> Hi.
>
> Why is resetGrandTotal a SECA on createOrderAdjustment?  Would  
> anybody have a problem if I just made it a service call inside  
> createOrderAdjustment?
>
> Best Regards,
>
> Si
> sichen@opensourcestrategies.com
>
>
>