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 > [email protected] > 214-720-0700 x 315 > Brainfood, Inc. > http://www.brainfood.com >
