Stockraken

Stockraken could connect several Shopee stores. One store could return an API error while the others still had ready-to-ship orders that operators needed to process.

I implemented order retrieval per active store. The backend requested ready-to-ship orders, excluded orders already linked to a delivery, and fetched details in groups of 50. When Shopee returned an error for one store, the response retained that store's identifier, name, and provider message before continuing with the remaining stores.

Before the change, a 404 or a 500 from one store stopped the order sync for every store. Afterwards the run skipped the failing store and carried on, and operators were shown which stores had failed and why, so they could retry those or ignore them and work with the orders that did arrive.

A local product variant and a Shopee item were separate records, and Shopee products could have their own variation identifiers. Without an explicit mapping, Stockraken could not show whether the two stock values agreed or know which remote record to update.

I implemented the application workflow for connecting a local variant to a Shopee store, item, and optional variation. The endpoint validated the local records and checked the remote item before storing the mapping. Product responses then exposed Shopee stock and Stockraken stock together.

Local stock changes pushed the current variant stock to each valid linked Shopee store. The synchronization job supported background execution, but this flow invoked it inline during the request rather than through a background worker. A provider error therefore surfaced to the caller. I also added an authenticated manual synchronization endpoint that returned Shopee's error message when an operator-triggered correction failed.

Stockraken had an explicit link between its inventory record and each Shopee listing. The two values drifted in practice: the desktop client called the sync endpoint directly and the push ran inline, so a Shopee rate limit or a failed request could leave local stock updated and the listing stale. The manual synchronization existed for that case, letting operators compare both values and push the local one again when an earlier update had not reached the marketplace.

The quantity calculated from warehouse batches could differ from a physical count. Correcting only the aggregate number would remove the discrepancy without explaining whether stock had entered or left the warehouse.

I worked on the stock-opname flow that snapshots batch quantities per warehouse and records written stock, physical stock, and the difference through draft, processing, and completed states. Its adjustment paths could record an outbound activity and transaction or an inbound activity and new batch, depending on the correction being entered. Both paths used the central variant-stock update, which also invoked the Shopee synchronization job inline.

A physical-count correction became an inventory movement with warehouse context instead of an unexplained overwrite. The corrected local quantity then entered the same marketplace-update path as other stock changes.

The Electron point-of-sale client needed drafts, payouts, completed sales, and print data, but a shop-floor sale still had to affect the same warehouse inventory used by direct sales and Shopee.

I contributed to the Electron client and worked on its Laravel API boundary. Draft carts used the transaction and variant as their update key so lines could be changed or removed before completion. Finishing a sale created an outbound warehouse activity and transaction log, consumed warehouse batches, updated aggregate and sold stock, and marked the transaction complete.

Point-of-sale activity used Stockraken's existing transaction and warehouse records, so the desktop client kept no stock ledger of its own.