For anyone following this thread, the answer, as usual, is in David's previous reply - I just did not see it. I believe the key is to use the ShoppingList entity in place of where I was trying to use an OrderHeader as the key off of which to run everything. The ShoppingList's ShoppingListItems have all the same info as the OrderItems. So when I want to see what subscriptions a party has, I do not look at the subscriptions, not at the initial orderHeader, but at the shoppingList, as I can see all the payment history and credit card status from there.
-Al On 2/14/07, Al Byers <[EMAIL PROTECTED]> wrote:
David, Could you tell how to distinguish the initial order from all the other orders that the shoppingList creates? Anything other than date? Thanks, -Al On 2/13/07, David E. Jones <[EMAIL PROTECTED]> wrote: > > > 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 > >> > > >> > > >> > > >> > > >
