On Feb 13, 2007, at 10:35 AM, Al Byers wrote:

I do see that updateShoppingList has a check that there is recurring info before it allows "isActive" to be set to "Y". That is a good reason to leave
things as they are.

That leaves my remaining question as how to mark subscriptions/ account that are dead - do I change the order status or use the isActive field of the
shoppingList or am I missing the right approach all together.

The recurring order code looks ONLY at the ShoppingList and related entities, it does not look at the Order* ones.

The service that creates orders based on a ShoppingList only does so if isActive=Y. So, to turn off the recurring orders just set isActive=N.

-David



On 2/13/07, Al Byers <[EMAIL PROTECTED]> wrote:

It is for managing subscriptions. I need to periodically bill using the ShoppingList services. I can have several subscriptions tied to an order. If they are too far in arrears the subscriptions need to be cancelled. I am planning on setting the thruDates of the subscription at a certain point, but I do not want to deactivate the "account" using that method because the authorization may go thru within a prescribed timeframe and I can turn the subscriptions back on. So I am looking for away to know if a subscription is
"dead" - no longer trying to get payment.

I thought the way to deactivate an account would be to set the initial OrderHeader's associated ShoppingList.isActive to "N", but it is "N" to start. I guess I could just activate the ShoppingList as soon as it is created, but why should I have to do that? Why can't I just activate the
ShoppingList when i create it? It is one of the input parameters to
createShoppingList, but "makeListFromOrder" does not allow me to set it.

I hesitated to set the OrderHeader.statusId to ORDER_CANCELLED once it is set to ORDER_COMPLETED, but is that the best way to do that or create a
special StatusItem for "deactivated".

Thanks,

-Al

On 2/13/07, David E. Jones <[EMAIL PROTECTED]> wrote:
>
>
> Because of what isActive is used for this default generally makes
> sense. Any hints on why this isn't working for you or why the
> approach used elsewhere for this isn't sufficient?
>
> -David
>
>
> On Feb 12, 2007, at 11:48 PM, Al Byers wrote:
>
> > It can be set by an input parameter in
> > ShoppingListServices.xml:createShoppingList, but the most likely
> > place to
> > call "createShoppingList", ShoppingListServices.java -
> > makeListFromOrder
> > does not allow the createShoppingList parameters to be set from a
> > "makeValid" call and that is what I think should be done.
> >
> > -Al
>
>
>


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to