Multi-Channel Inventory in Türkiye: Sync, Reordering and Stock Counts

سفير تركيا · 2026-10-12T00:02:32+0300

One reliable stock quantity behind several sales channels
Synchronization, reservations, reordering and stock counts without overselling

The inventory source of truth starts with a physical count and documented movements.

Displaying ten units in three stores does not mean you own thirty units. Channels sharing inventory need an authoritative record, clear reservations, verifiable synchronization and a fallback when integration fails. An integration plugin alone cannot guarantee correct displayed quantities.

This guide is for sellers using their own website and Turkish marketplaces. It explains what to request from staff, developers and suppliers without assuming platforms share the same statuses. All quantities and durations are hypothetical; integration-interface updates must be checked against current platform documentation when implemented.

Standardize the code for every sellable item

Create a record for each independently sold variant: size, color, capacity or pack quantity. Give it a stable internal code linked to marketplace identifiers, barcode and website product. A table containing only translated names that change between channels is insufficient.

Distinguish single items from multipacks. A three-unit bundle consumes three component units unless it is already prepared as separate bundle stock. Prevent two systems from counting it twice, and do not let a product-name change alter its inventory reference.

Test mapping on similar items before adding the entire catalog. Ask staff to pick by code and verify attributes, and developers to expose codes in error reports. When suppliers or packaging change, decide whether the goods retain their identity or need a new code. Standardization makes discrepancies investigable instead of losing them among three names for one item.

Distinguish physical, saleable, reserved and available stock

Physical stock is what exists in counted locations, including units not ready for sale. Separate damage and returns awaiting inspection, then deduct appropriate reservations and a synchronization buffer to determine displayable availability. Available quantity must reflect a clear decision rather than simply the last plugin’s number.

The hypothetical example has one hundred and thirty-five physical units, five awaiting inspection, leaving one hundred and thirty saleable. With fifteen reserved and a buffer of ten, available quantity is one hundred and five. The buffer is an operational risk-control decision, rather than a missing unit or accounting expense.

Keep status definitions beside the report and state whether expected receipts enter displayed availability. Goods in transit from a supplier are not on the shelf merely because an invoice was accepted.

Example status	Quantity	Meaning
Physical stock in the warehouse	135	Before separating statuses
Awaiting inspection	5	Do not offer for sale
Saleable	130	135−5
Reserved for orders	15	Saleable units linked to an existing order
Synchronization buffer	10	Hypothetical safety decision
Available for display	105	130−15−10

Choose an authoritative record and its owner

Decide where quantity is authoritative: an inventory system, management software or store database according to scale. Establish who determines balances and receives movements. Do not allow two employees to independently edit final quantities in two channels and leave the system to select a last update arbitrarily.

Document synchronization direction. You may receive orders from every channel while sending available quantities from the central record. If marketplace adjustments are needed, define how they are recorded and accepted and when they override recorded quantities. A temporary manual change must not become permanent inventory truth.

Assign an owner who reviews daily differences and can stop offering an item when uncertain, with a backup, limited permissions and an adjustment log. Developers own integration operation within scope, warehouses own movement accuracy and the business owner owns display rules. Undefined roles leave each team assuming another corrected the quantity.

Connect reservations and cancellations to the correct signal

Define which event reserves a unit, which releases it on cancellation or payment timeout, and which converts the reservation into physical dispatch. Do not deduct stock twice at payment and shipment handover if reservation already accounts for the deduction in your design.

In WooCommerce, hold-stock settings for orders awaiting payment differ from orders in other on-hold states; the timer does not necessarily cover every case. Review local settings, payment plugins and integrations, then test unpaid orders, cancellation and late-arriving payment.

Release only canceled quantities for partial cancellations. After dispatch, do not restore availability when cancellation is requested; the goods must return and be classified. Link every movement to an order reference and time, with a visible reason. This separates refunded money from returned goods, which may occur on different days.

Each independently sold size or color needs clear mapping.

Handle two orders for the last unit

With one unit and two near-simultaneous orders from different channels, both may read the old quantity before an update arrives. This is more than a counting issue: it needs reservation rules preventing double allocation, suitable integration speed and an exception plan.

Do not expose the full shared stock everywhere without assessing synchronization lag. Allocate quantities to channels, use a buffer or stop selling at low stock according to volume and integration. These reduce risk but do not make it impossible; monitor actual cases.

If overselling occurs, do not buy a different substitute without customer agreement. Collect references, timestamps and the pre-event balance, and escalate the fulfillment or appropriate-remedy decision. Fix the duplicate reservation cause and retest. Keep the test result instead of manually changing quantity and considering the issue closed.

Test event	Required behavior	Failure signal
Two orders for one unit	One reservation and clear handling of the second order	One item allocated to two orders
Duplicate order notification	No new movement for the same transaction	Repeated deduction
Cancellation of a reserved order	Release only its linked quantity	Increasing the item’s entire stock
Late payment after reservation expiry	Recheck fulfillment availability	Preparation without stock
Return awaiting inspection	No automatic availability increase	Offering an unclassified item

Review integration versions and results, beyond submission

Ask the developer which service versions are used and when last tested, then compare platform notices. At this guide’s preparation, Trendyol’s portal instructions specify the fifteenth of October 2026 for migration to new product and order services. Check your integration before that date rather than relying on last month’s operation.

This does not mean every service changed identically: Trendyol documentation distinguishes services shared between versions from new services. Review every function—products, quantity, price, orders and invoices—and test the result actually appearing on the marketplace.

Successful technical submission does not always prove every row was applied. Retain the operation reference, result and item errors, and read quantities afterward where reconciliation requires it. Do not resend an old update over newer results without a prevention rule. Apply the principle to Hepsiburada and others using their actual documentation rather than copying service names or procedures between platforms.

Prepare for synchronization failure

Define detection through the last successful movement, queued-message count and stock discrepancies. ‘The service is running’ does not prove all item quantities arrived. Tie alerts to interpretable events, such as the defined operational period passing without new updates being applied.

Set a clear temporary procedure. The owner may stop sales of low-stock items, reduce displayed availability or manually review one channel’s orders. Do not let several staff repair quantities simultaneously without a log, creating more differences when service resumes.

On recovery, reconcile orders, reservations and inventory before a full update. Classify failed messages, retry transient failures and seek intervention for incorrect codes or settings. Rapid unlimited retries are not a universal fix; they can consume service capacity and replay old movements. Test short outages, backlog and recovery before launch.

Failure	Team check	Action
Unknown code	Mapping table and variant	Correct the code before submission
Duplicate order	Channel reference and event	Prevent an additional movement
Delayed update	Message queue and last success	Restrict availability where needed
Authorization rejection	Account and authorization	Restore access without exposing keys
Old update	Balance timestamp and version	Prevent overwriting newer data

Calculate reorder point and inventory position

Reorder points compare demand during supplier lead time with stock, reservations and confirmed receipts under your definition. A simple model assumes daily demand of eight units, lead time of twelve days and safety stock of twenty-four. Lead-time demand is ninety-six and the reorder point one hundred and twenty.

Do not compare that point only with one marketplace’s displayed availability. Calculate inventory position: saleable minus reserved stock plus confirmed inbound quantities expected to meet the requirement, without double counting. Show unconfirmed supplier quantities separately rather than as guaranteed arrivals.

Update daily demand and lead time as they change. Old averages can hide seasons, promotions or supplier stoppages; buffers cannot resolve unpredictable delivery indefinitely. These educational assumptions need your own data.

Hypothetical calculation	Value	Result
Daily demand 8 × lead time 12	96 units	Lead-time demand
Demand 96 + safety stock 24	120 units	Reorder point
Saleable 110 − reserved 30 + inbound 20	100 units	Inventory position
Target 220 − position 100	120 units	Illustrative purchase quantity
Pack of 24 units	5 packs	120 units after pack-size alignment
If lead time becomes 20 days	8×20+24	Reorder point 184 units

Result: reaching the reorder point does not alone determine order quantity; check cash, pack sizes, minimums, space and shelf life.

Reservations, damage and returns change availability even while units remain in the warehouse.

Do not let supplier minimums consume cash

After calculating demand, review pack sizes, minimum orders, payment budget and space. If the supplier requires two hundred when you need one hundred and twenty, do not accept solely for a lower unit price. Calculate excess-stock selling time, design-change or expiry risk and storage cost.

Request written dates, quantities and specifications and define full or phased delivery. For partial receipt, book only accepted goods into stock and keep the remainder inbound with its revised date. Do not increase store stock to the full invoice quantity before receipt.

Separate inventory from payment. A supplier deposit does not establish available sellable units, and recorded receipt does not mean the invoice is fully paid. Link reports to understand cash needs while keeping definitions clear. Monitor slow-moving items and reduce purchasing or improve offers based on demand and profit rather than generalized stockout fear.

⁦⁩ Count regularly and investigate discrepancies

Perform a full count when establishing the record, then recurring counts for high-movement or error-prone items. Choose a time when continuing movements can be identified, or pause movements for the item being counted if necessary. Count without seeing expected quantities where this reduces staff bias.

Investigate receipts, dispatches, cancellations, transfers, returns and damage. Do not repeatedly enter ‘stock adjustment’ without explanation or approval. One missing size may correspond to one extra neighboring size, indicating picking error rather than a general loss.

Retain initial and repeat counts, cause, adjustment and approver. Fix recurring shelf-location, barcode, reservation or duplicate-notification issues. Counts are not cosmetic system corrections; they reveal unrecorded operations. Check secondary locations too, including packing tables, quarantine and orders not yet collected by the carrier.

⁦⁩ Organize returns, transfers and manual adjustments

Record a separate movement on return receipt, then approve its status before availability. A refund reference does not put a unit on the shelf, and a returned box does not prove the item and accessories are complete. Record only returned portions of partial orders.

Warehouse transfers need dispatch, receipt and an in-transit location. Units must not appear in both warehouses throughout the journey. Assign each transfer a reference, quantity and receipt, then resolve differences before enabling sales from the destination.

Limit direct balance-editing rights and require reasons when used. Protect integration keys and customer data with need-based access. Changing developers or providers should not mean losing records or export rights; agree handover, termination and access. Before major updates, test a settings copy and order scenarios without unnecessary personal data.

⁦⁩ Specific questions and inventory operating checklist

Should I send the same full quantity to every marketplace?
Channels can share a balance, but this needs reservations, synchronization and a delay plan. Assess simultaneous-order risk and use suitable buffers or allocations rather than treating repeated numbers as additional stock.

Is a successful response sufficient?
Check application results for items, then reconcile displayed balances. Acceptance of an update request may differ from completed processing or success of every row.

Should I purchase whenever a stockout alert appears?
Alerts help, but purchasing uses demand, lead time, safety stock, reservations, receipts and cash. Slow-moving items may need less purchasing even when reaching an old alert threshold.

Stable codes and mappings for every variant.
Defined physical, saleable, reserved and safety quantities.
One authoritative record and identified decision owner.
Duplicate notifications create no second movement.
Cancellations and returns do not restore incorrect quantities.
Tested integration version and outage plan.
Reordering based on documented lead times and receipts.
Every count discrepancy has a cause and approved adjustment.

Start with a small item sample and test ordering, cancellation, return and outage across all channels. One successful sale does not establish correct reservation or retry behavior. Expand integration when the team can explain discrepancies without guessing.