Problems with shipping ahead & backorders

earlyimp wrote: Why do you "zero" the prices? Could you provide more information on what you believe is missing from the system?

First, I should mention that we process credit card payments through PayFlow PRO using the "capture" method NOT the "sale" method. For those reading at home, that means we capture an authorization from PFP to charge the card for a specific amount that's valid for a specific amount of time. This is also sometimes referred to as a "preauth".

Moving on...we specifically use this method because with ProductCart, if you have items that are both in stock and backordered and the payment method is set to "sale", PC charges the customer for the entire order (i.e. both in stock AND out of stock) items.

Since we all know it's illegal to charge customers for items that are not physically able to ship at the time of billing, we use the "capture" method. Hence, we have to zero out the cost of the backordered items so we're not charging customers for things we can't send them.

As a result, when the item a customer backordered is in stock; we then have to zero out the price of the previously shipped items and re-enter the price of the backordered item and reset the order status to "pending" to be able to batch process the order and a.) get our money and b.) ship the customer their goods.

The problem (from our perspective) is that backordering/partial shipping wasn't fully developed before it was released as a feature in PC. I say this because:

1. Product Cart does not differentiate between in stock and out of stock items when capturing funds when using sale method (thereby charging the ENTIRE order total at the point of sale)

2. You cannot choose which items to charge/ship in mixed orders when using authorization method

Yes, PC allows you to ship partial orders; but it pre-supposes that you're either a.) breaking the law in charging the customer for them upfront or b.) don't want to be able to charge them later when you ship their order.

IMHO, what should happen is either one of the following (depending on how the store is configured):

1. If you're using the "sale" method (card charged at the time of the sale), then PC should be able to differentiate between in stock and backordered items and NOT charge the customer for the BO. Later, when the item is available and stock has been filled, that order should be filled and you should be alerted to the fact that those orders need to ship/be processed and then allow you to batch process.

2. If you're using the "capture" method (card charged after the sale), then PC should allow you to choose at the SKU level - BEFORE batch processing - which items will be charged/shipped and which items will be left on backorder.

Hopefully I've explained the problem correctly and accurately. If I have presented erroneous information I welcome Early Impact to correct me and I'll gladly apologize. I really enjoy ProductCart and think, for the price, it's a wonderful tool. However, this is one area that I think a little more planning might have been beneficial.

Ultimately, I hope I've missed something completely and this isn't really an issue; just operator error!

Thanks!

Hi Andi, could you elaborate? This is a long thread, where different points of view were discussed, so it's unclear to us what you see as a "major issue".

In ProductCart you can certainly authorize a transaction (assuming your payment gateway supports the "authorization only" method), process the order and ship it in the Control Panel, then capture the transaction when everything has shipped. Typically transactions can remain authorized (but not captured and therefore not settled) for many days (I believe it's 30 days with Authorize.Net, for example).