WP eCommerce stores every purchase in the wp_wpsc_purchase_logs table. Each row carries a processed column with integer values mapped to states like 1 for incomplete, 2 for accepted, 3 for declined, 4 for refunded, 5 for shipped, 6 for closed, plus columns for the customer id, the total price, the gateway, and the date. Line items live in wp_wpsc_cart_contents linked by purchaseid. The native admin shows purchase logs as a flat sortable list, which is fine for archive lookups but blind to the live fulfillment workflow.

SleekView Kanban reads the same wp_wpsc_purchase_logs rows you would query with wpsc_get_purchase_log. Pick the processed column as the group field and every purchase becomes a card slotted under Incomplete, Accepted, Shipped, or Closed. Card fronts show the customer name, the order total in store currency, the gateway, the date, and the line item count from wp_wpsc_cart_contents, so fulfillment sees every purchase's context without opening individual purchase log detail screens for any order.

Dragging a card between columns calls the WP eCommerce helper for updating the processed value, which writes back to wp_wpsc_purchase_logs.processed and fires the matching status change hooks. Stock decrements, customer notification emails, and any extension listening for purchase status changes react, exactly as they would after a manual update from the WP eCommerce purchase log admin screen by a fulfillment team member or manager.

Storefronts running WP eCommerce hit a wall the moment daily order volume passes a few dozen purchases per day. The default purchase log is built around accounting use cases, not the live triage work a fulfillment team does every morning. Staff end up exporting CSVs, building shared Trello boards by hand, or installing a separate project management plugin just to see what is stuck on Incomplete versus moving through Accepted.

None of those shortcuts write back to WP eCommerce, which means the real source of truth and the board the team uses drift apart by lunchtime. Mistakes compound. Purchases get shipped twice, refunds get issued without a status change, and the processed value on the purchase log ends up bearing no relation to its real-world state.

A kanban view that reads and writes the same wp_wpsc_purchase_logs rows the storefront already reads keeps the team and the database honest. Every drag is a real status change, every column count reflects the real fulfillment state, and the cards themselves carry enough context for a new fulfillment hire to start packing on their first day of the job.