That does sound like a good solution Ean.
Currently the only way to refund against an order is to choose an OrderItem (through ReturnItem) or OrderAdjustment (through ReturnAdjustment) and attach the refund to that.
I was thinking you could use ReturnItem for this, but it has a FK to OrderItem (ie you can't populate the orderId and leave the orderItemSeqId null), and while I haven't looked into it I think the code for returns depends on a productId being present for a ReturnItem and such.
On the other hand, it might be easier to change the return code to allow a ReturnItem to not have a orderItemSeqId than it would be to add the orderId and related functionality to the ReturnAdjustment.
-David
On Dec 23, 2009, at 5:01 PM, Ean Schuessler wrote:
> Manual adjustments on orders (ie. giving a customer an overall discount
> on an already paid order because of bad customer service or some other
> misunderstanding) is currently complicated by the fact that there is no
> way to trace a value-only refund back to the order it was created
> against. Tracing the order is required in order to insure that the
> refund is sent to the payment method that was used to generate the order.
>
> I suggest adding an "orderId" field to the ReturnAdjustment entity. This
> would be analogous to the orderId/orderItemSeqId fields in the
> ReturnItem entity. Does anyone object to that change? I need to analyze
> what services would be impacted by this change. I think as long as it is
> an optional field it should not be disruptive.
>
> --
> Ean Schuessler, CTO
>
[hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
>
http://www.brainfood.com>
Locked
