ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਸਟਾਕ ਦੀ ਸਹੀ-ਦਾਰੀ: Available, Reserved, Sold

ਕਿਉਂ ਛੋਟੀ ਟੀਮਾਂ ਨੂੰ ਸਟਾਕ ਦੀ ਸਹੀ-ਦਾਰੀ ਵਿੱਚ ਮੁਸ਼ਕਲ ਹੁੰਦੀ ਹੈ

ਜੇ ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਦੁਕਾਨ ਚਲਾਉਂਦੇ ਹੋ ਜਾਂ ਸੀਮਤ ਉਤਪਾਦ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਲੱਗਦਾ ਹੈ ਕਿ ਸਟਾਕ ਸੌਖਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਤੁਸੀਂ ਜਿਹੜਾ ਟਿਕਾਣਾ ਗਿਣਦੇ ਹੋ, ਉਹੀ ਵਿਕਣ ਲਈ ਉਪਲਬਧ ਹੈ। ਫਿਰ ਵੀ ਓਵਰਸੈਲ ਹੋ ਜਾਂਦੇ ਹਨ, ਭਾਵੇਂ ਤੁਹਾਡੀਆਂ ਗਿਣਤੀਆਂ ਸਹੀ ਹੋਣ।

ਮੁੱਖ ਕਾਰਨ ਸਮਾਂ-ਸੰਬੰਧੀ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡਾ "ਗਿਣਤੀ" 10:00:00 'ਤੇ ਠੀਕ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ 10:00:05 'ਤੇ ਗਲਤ ਹੋ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਦੋ ਲੋਕ ਇੱਕੋ ਆਖਰੀ ਇਕਾਈ ਖਰੀਦਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ ਸਕਦੇ ਹਨ, ਪੇਮੈਂਟ ਦੇਰੀ ਨਾਲ ਆਇਆ ਹੋਵੇ, ਜਾਂ ਸਟਾਫ਼ ਨੇ ਚੈੱਕਆਊਟ ਦੌਰਾਨ ਸਟਾਕ ਤਬਦੀਲ ਕੀਤਾ ਹੋਵੇ। ਛੋਟੀ ਟੀਮਾਂ ਵਿੱਚ ਇਹ ਘਟਨਾਵਾਂ ਅਕਸਰ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੀ ਅਪਰੇਸ਼ਨ ਦੀ ਜ਼ਿੰਮੇਵਾਰ ਵਿਅਕਤੀ ਨਹੀਂ ਹੁੰਦੀ ਜੋ ਹਰ ਪਰਿਸਥਿਤੀ ਨੂੰ ਵੇਖੇ।

ਜਦੋਂ ਸਟਾਕ ਗਲਤ ਹੁੰਦਾ ਹੈ, ਗਾਹਕ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ:

• ਉਹ ਆਰਡਰ ਕਰਦੇ ਹਨ, ਫਿਰ ਬਾਅਦ ਵਿੱਚ ਰੱਦਗੀ ਈਮੇਲ ਮਿਲਦੀ ਹੈ।
• ਉਹ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ, ਫਿਰ ਰੀਫੰਡ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ ਭੇਜ ਨਹੀਂ ਸਕਦੇ।
• ਉਹ ਸਹਾਇਤਾ ਨਾਲ ਸੰਪਰਕ ਕਰਦੇ ਹਨ ਪੁੱਛਣ ਲਈ ਕਿ ਕੀ ਹੋਇਆ ਅਤੇ ਪੈਸਾ ਕਦੋਂ ਵਾਪਸ ਮਿਲੇਗਾ।
• ਉਹ ਭਰੋਸਾ ਖੋ ਬੈਠਦੇ ਹਨ ਅਤੇ ਵਾਪਸ ਨਹੀਂ ਆ ਸਕਦੇ।

ਤੁਹਾਡੇ ਪਾਸੇ, ਇਹ ਮੈਨੂੰਅਲ ਕੰਮ ਪੈਦਾ ਕਰਦਾ ਹੈ: ਮਾਫ਼ੀ ਮੰਗਣਾ, ਰੀਫੰਡ ਕਰਨਾ, ਗਿਣਤੀਆਂ ਨੂੰ ਦੁਬਾਰਾ ਚੈੱਕ ਕਰਨਾ, ਅਤੇ ਟਿਕਟਾਂ ਦੇ ਜਵਾਬ ਦੇਣਾ। ਇਸ ਲਈ ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਸਟਾਕ ਦੀ ਸਹੀ-ਦਾਰੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨੰਬਰ ਸਹੀ ਜਾਣੇ ਬਾਰੇ ਨਹੀਂ, ਬਲਕਿ ਇਹ ਸਪਸ਼ਟ ਨਿਯਮਾਂ ਬਾਰੇ ਹੈ ਕਿ ਚੈੱਕਆਊਟ ਦੌਰਾਨ "ਇਨ ਸਟਾਕ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ।

ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਸਟਾਕ ਨੂੰ ਕੁਝ ਸਪਸ਼ਟ ਹਾਲਤਾਂ ਵਜੋਂ ਸਮਝੋ, ਨਾ ਕਿ ਇਕ ਹੀ ਨੰਬਰ। "Available" ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਅੱਜ ਵਾਅਦਾ ਕਰ ਸਕਦੇ ਹੋ। "Reserved" ਉਹ ਹੈ ਜੋ ਕਿਸੇ ਗਾਹਕ ਲਈ ਅੱਛੀ ਗਿਰਹੁੰਦੀ ਹੈ ਪਰ ਭੁਗਤਾਨ ਅਜੇ ਨਹੀਂ ਹੋਇਆ। "Sold" ਉਹ ਹੈ ਜੋ ਭੁਗਤਾਨ ਹੋ ਚੁਕਿਆ ਅਤੇ ਭੇਜਣ ਲਈ ਤਿਆਰ ਹੈ।

ਇਹ ਗਾਈਡ ਸਧਾਰਨ, عملي ਨਿਯਮਾਂ 'ਤੇ ਟਿਕੀ ਹੈ: ਕਿਸ ਤਰ੍ਹਾਂ ਆਈਟਮ ਉਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਮਿਲਦੇ ਹਨ, ਕਦੋਂ ਰਿਜ਼ਰਵ ਕਰਨਾ ਹੈ, ਅਤੇ ਪੇਮੈਂਟ ਟਾਈਮਆਊਟ ਕਿਵੇਂ ਹэндਲ ਕਰਨਾ ਹੈ ਤਾਂ ਕਿ ਸਟਾਕ ਫਸਿਆ ਨਾ ਰਹੇ ਜਾਂ ਦੋ ਵਾਰੀ ਨਾ ਵਿਕ ਜਾਵੇ। ਇਹ ਆਧੁਨਿਕ ਅਨੁਮਾਨ, ਗੋਦਾਮ ਵਿਵਸਥਾ, ਜਾਂ ਮਲਟੀ-ਲੋਕੇਸ਼ਨ ਯੋਜਨਾ ਬਾਰੇ ਨਹੀਂ ਹੈ।

Available vs reserved vs sold: ਸਧਾਰਨ ਪਰਿਭਾਸ਼ਾਵਾਂ

ਇਹ ਤਿੰਨ ਸ਼ਬਦ ਸਧਾਰਨ ਲੱਗਦੇ ਹਨ, ਪਰ ਇਹ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਵਾਅਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਗਾਹਕਾਂ ਨੂੰ ਦਿੰਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਮਿਲਾ-ਝੁਲਾ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਜਾਂ ਤਾਂ ਓਵਰਸੈਲ ਕਰ ਦੇਉਗੇ (ਦੋ ਲੋਕ ਇੱਕ ਹੀ ਆਈਟਮ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ) ਜਾਂ ਅੰਡਰਸੈਲ (ਉਹ ਸਟਾਕ ਲੁਕਾਉਂਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਵੇਚ ਸਕਦੇ ਸੀ)।

Available ਦਾ ਮਤਲਬ ਹੈ "ਇਕ ਗਾਹਕ ਅਜੇ ਵੀ ਇਸ ਆਈਟਮ ਲਈ ਚੈੱਕਆਊਟ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ।" ਇਹ ਤੁਹਾਡੇ ਹੱਥ ਵਿੱਚ ਮੌਜੂਦ ਸਟਾਕ ਦਾ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਹੋਰ ਲਈ ਰਿਜ਼ਰਵ ਨਹੀਂ ਕੀਤਾ ਗਿਆ। ਇਸਨੂੰ ਤੁਹਾਡਾ ਸਾਰਵਜਨਿਕ ਨੰਬਰ ਸਮਝੋ।

Reserved ਦਾ ਮਤਲਬ ਹੈ "ਅਸੀਂ ਇਹ ਆਈਟਮ ਕਿਸੇ ਖਾਸ ਗਾਹਕ ਲਈ ਇੱਕ ਛੋਟੀ ਸਮੇਂ ਲਈ ਰੱਖ ਰਹੇ ਹਾਂ।" ਰਿਜ਼ਰਵੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਵੇਲੇ ਬਣਦੀ ਹੈ ਜਦ ਗ੍ਰਾਹਕ ਨੇ ਖਰੀਦਣ ਦੀ ਨਿੱਜੀ ਨੀਤਿ ਦਿਖਾਈ (ਉਦਾਹਰਣ ਲਈ: ਉਹ ਚੈੱਕਆਊਟ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ)। Reserved ਸਟਾਕ ਅਜੇ ਵਿਕਿਆ ਨਹੀਂ, ਪਰ ਤੁਸੀਂ ਇਸਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਹੋਰਾਂ ਲਈ ਉਪਲਬਧ ਨਹੀਂ ਮੰਨਦੇ ਤਾਂ ਕਿ ਦੂਜਾ ਕੋਈ ਉਸਨੂੰ ਬੁੱਕ ਨਾ ਕਰ ਲਵੇ।

Sold ਦਾ ਮਤਲਬ ਹੈ "ਖਰੀਦ ਪੁਸ਼ਟੀ ਹੋ ਗਈ।" ਇਹ ਉਹ ਸਮਾਂ ਹੈ ਜਦ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਆਈਟਮ ਨੂੰ ਹੋਰਾਂ ਲਈ ਵਿਕਣ ਯੋਗ ਨਹੀਂ ਮੰਨ ਸਕਦੇ। ਬਹੁਤ ਸਾਰੀਆਂ ਦੁਕਾਨਾਂ ਵਿੱਚ, "sold" ਭੁਗਤਾਨ ਦੀ ਸਫਲਤਾ (ਜਾਂ ਭਰੋਸੇਯੋਗ pay-later ਵਿਧੀ 'ਤੇ ਆਰਡਰ ਰੱਖਣ) ਤੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਜਦ ਤੱਕ ਭੇਜਿਆ ਨਹੀਂ ਜਾਂਦਾ ਬੰਦ ਰਹਿੰਦਾ ਹੈ।

ਇੱਕ ਮੁੱਖ ਨੁਕਤਾ: available ਅਤੇ on hand ਇਕੋ ਜਿਹਾ ਨਹੀਂ। On hand ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਭੌਤਿਕ ਤੌਰ 'ਤੇ ਰੱਖਦੇ ਹੋ। Available ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਨਵੇਂ ਖਰੀਦਦਾਰਾਂ ਨੂੰ ਵਾਅਦਾ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ।

ਇੱਕ ਛੋਟੀ ਉਦਾਹਰਣ, ਜਿੱਥੇ 5 ਯੂਨਿਟ on hand ਹਨ:

• On hand: 5
• Reserved: 2 (ਦੋ ਗਾਹਕ ਚੈੱਕਆਊਟ ਵਿਚ ਹਨ)
• Sold: 1 (ਇੱਕ ਭੁਗਤਾਨ ਆਰਡਰ)
• Available: 2 (5 minus 2 minus 1)

ਨੋਟ ਕਰੋ ਕਿ ਇਹ ਤਿੰਨ ਨੰਬਰ ਇਕੱਠੇ ਸਹੀ ਹੋ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ "on hand" ਟਰੈਕ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੀ ਸਾਈਟ 5 ਦਿਖਾ ਸਕਦੀ ਹੈ ਅਤੇ 5 ਲੋਕ ਖਰੀਦਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਲੈਂਗੇ, ਭਾਵੇਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਹੋਰ 2 ਹੀ ਮੰਨ ਕੇ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ।

ਸਟਾਕ ਕਿਵੇਂ ਹਿਲਦਾ ਹੈ: ਬੁਨਿਆਦੀ ਲਾਇਫਸਾਇਕਲ

ਸਟਾਕ ਗਲਤ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦ "ਗਿਣਤੀ" ਨੂੰ ਇਕ ਹੀ ਨੰਬਰ ਵਜੋਂ ਦੇਖਿਆ ਜਾਂਦਾ ਹੈ। ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਸਟਾਕ ਦੀ ਸਹੀ-ਦਾਰੀ ਨੂੰ ਰਾਜ਼ ਰੱਖਣ ਲਈ ਹਾਲਤਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸੋਚੋ ਜੋ ਇੱਕ ਸਧਾਰਨ ਰਸਤਾ ਫੋਲੋ ਕਰਨ। ਹਰ ਹਾਲਤ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਕੀ ਕੋਈ ਵੀ ਇਸਨੂੰ ਅਜੇ ਵੀ ਖਰੀਦ ਸਕਦਾ ਹੈ, ਕੀ ਇਹ ਚੈੱਕਆਊਟ ਲਈ ਰੱਖਿਆ ਗਿਆ ਹੈ, ਜਾਂ ਕੀ ਵਿਕਰੀ ਅੰਤਿਮ ਹੈ।

ਆਮ ਲਾਇਫਸਾਇਕਲ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ:

• Available -> Reserved: ਜਦ ਗਾਹਕ ਚੈੱਕਆਊਟ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ (ਜਾਂ "Pay" 'ਤੇ ਕਲਿਕ ਕਰਦਾ ਹੈ) ਅਤੇ ਤੁਸੀਂ ਆਈਟਮ ਉਹਦੇ ਲਈ ਰੱਖਣ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹੋ।
• Reserved -> Sold: ਸਿਰਫ਼ ਭੁਗਤਾਨ ਪੁਸ਼ਟੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੁੰਦਾ ਹੈ (ਜਾਂ ਜਦ ਤੁਸੀਂ ਆਫਲਾਈਨ ਭੁਗਤਾਨ ਮਨਜ਼ੂਰ ਕਰਦੇ ਹੋ)।
• Reserved -> Available: ਜਦ ਚੈੱਕਆਊਟ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਭੁਗਤਾਨ ਟਾਈਮਆਊਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਗਾਹਕ ਭੁਗਤਾਨ ਤੋਂ ਪਹਿਲਾਂ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ।

"Sold" ਉਹ ਮੋੜ ਹੈ ਜਦ ਤੁਸੀਂ ਅਸਲ ਵਾਅਦਾ ਕਰਦੇ ਹੋ। ਕਈ ਸੈਟਅੱਪ ਵਿੱਚ ਇਹ ਉਹੀ ਸਮਾਂ ਹੁੰਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਭੌਤਿਕ ਸਟਾਕ ਗਿਣਤੀ ਘਟਾਉਂਦੇ ਹੋ, ਕਿਉਂਕਿ ਆਈਟਮ ਹੁਣ ਹੋਰ ਤੁਹਾਡਾ ਨਹੀਂ ਰਹਿੰਦਾ। ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਸ਼ਿੱਪ ਕਰਦੇ ਹੋ (ਛੋਟੀ ਟੀਮਾਂ ਵਿੱਚ ਆਮ), ਤਾਂ ਤੁਸੀਂ ਫਿਰ ਵੀ "sold" ਨੂੰ ਅੰਤਿਮ ਮੰਨ ਕੇ ਭੇਜਣ ਨੂੰ ਅਲੱਗ ਰੱਖ ਸਕਦੇ ਹੋ। ਮੁੱਖ ਗੱਲ: ਕਿਸੇ ਨੂੰ sold ਨਾ ਮੰਨੋ ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿ ਉਹ ਭੁਗਤਾਨ ਪੇਜ 'ਤੇ ਆ ਗਿਆ।

ਇਹ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਸਖ਼ਤੀ ਰੱਖੋ ਕਿ ਕਿਹੜਾ ਸਿਸਟਮ ਹਰ ਹਾਲਤ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ:

• Checkout ਸਿਸਟਮ ਰਿਜ਼ਰਵੇਸ਼ਨ ਬਣਾ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਵਧਾ ਸਕਦਾ ਹੈ (ਹੱਦਾਂ ਦੇ ਅੰਦਰ)।
• Payment confirmation reserved ਨੂੰ sold ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ।
• Admin ਰਿਜ਼ਰਵੇਸ਼ਨ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ, ਰੀਫੰਡ (ਜੋ ਸ਼ਾਇਦ sold -> available ਬਣਾਏ ਜੇ ਤੁਸੀਂ ਵਾਕਈ رੈਸਟੋਕ ਕਰੋ), ਜਾਂ ਜਦ ਨਵੇਂ ਯੂਨਿਟ ਮਿਲਣ ਤੇ ਗਿਣਤੀ ਠੀਕ ਕਰ ਸਕਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਹਰੇਕ ਸਥਿਤੀ ਬਦਲਾਵ ਹਰ ਜਗਾ ਇੱਕੋ ਜਿਹਾ ਦਿਸਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਡਾ ਸਟੋਰਫਰੰਟ, ਐਡਮਿਨ ਪੈਨਲ, ਅਤੇ ਕਿਸੇ ਵੀ ਗਾਹਕ ਸਹਾਇਤਾ ਵਿਊ ਨੂੰ ਇੱਕੋ ਜਿਹੀਆਂ ਇਨਵੈਂਟਰੀ ਨਿਯਮਾਂ ਤੋਂ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਥਾਂ ਤੇ ਓਵਰਸੈਲ ਠੀਕ ਕਰਕੇ ਹੋਰ ਥਾਂ ਤੇ ਵਾਪਸ ਲਿਆ ਸਕਦੇ ਹੋ।

ਚੈੱਕਆਊਟ ਦੌਰਾਨ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਦੋਂ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ

ਤੁਸੀਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਦੋਂ ਬਣਾਉਂਦੇ ਹੋ, ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿੰਨੀ ਵਾਰੀ ਓਵਰਸੈਲ ਕਰੋਂਗੇ ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਕਿੰਨਾ ਤਕਲੀਫ਼ ਹੋਵੇਗੀ। ਬਹੁਤ ਜਲਦੀ ਰੱਖਿਆ ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਲਈ ਆਈਟਮ ਰੱਖ ਲੈਂਦੇ ਜੋ ਸਿਰਫ਼ ਬਰਾਊਜ਼ ਕਰ ਰਹੇ ਸੀ। ਬਹੁਤ ਦੇਰ ਨਾਲ ਰੱਖਿਆ ਤਾਂ ਤੁਸੀਂ ਇੱਕੋ ਆਈਟਮ ਦੋ ਵਾਰੀ ਵੇਚ ਸਕਦੇ ਹੋ।

ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਜੋ ਅਕਸਰ ਕੰਮ ਕਰਦਾ ਹੈ: ਗਾਹਕ ਜਦ ਚੈੱਕਆਊਟ ਕਰਨ ਦਾ ਵਚਨ ਦੇਵੇ ਤਾਂ ਰਿਜ਼ਰਵ ਕਰੋ, ਨਾਂ ਕਿ ਜਦ ਉਹ ਪ੍ਰੋਡਕਟ ਪੇਜ ਖੋਲ੍ਹੇ।

ਇੱਥੇ ਆਮ ਵਿਕਲਪ ਹਨ, ਸਭ ਤੋਂ ਜਲਦੀ ਤੋਂ ਸਭ ਤੋਂ ਦੇਰ ਤੱਕ:

• ਚੈੱਕਆਊਟ ਸ਼ੁਰੂ 'ਤੇ (ਜਦ ਉਹ "Checkout" 'ਤੇ ਕਲਿਕ ਕਰਦਾ ਹੈ): ਤੇਜ਼-ਬਿਕਣ ਵਾਲੀਆਂ ਆਈਟਮਾਂ ਲਈ ਵਧੀਆ, ਪਰ ਤੁਹਾਨੂੰ ਛੋਟੀਆਂ ਮਿਆਦਾਂ ਦੀ ਲੋੜ ਹੋਏਗੀ।
• ਐਡਰੈੱਸ ਸਟੈਪ ਮਗਰੋਂ: ਨਕਲੀ ਹੋਲਡ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਭੁਗਤਾਨ ਤੋਂ ਪਹਿਲਾਂ ਰੱਖ-ਰੱਖਾਅ ਕਰਦਾ ਹੈ।
• ਪੇਮੈਂਟ ਸ਼ੁਰੂ 'ਤੇ (ਜਦ ਤੁਸੀਂ ਪੇਮੈਂਟ ਇੰਟੈਂਟ ਬਣਾਉਂਦੇ ਹੋ ਜਾਂ ਪ੍ਰੋਵਾਇਡਰ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰਦੇ ਹੋ): ਅਕਸਰ ਸਭ ਤੋਂ ਸਾਫ਼-ਸੁਥਰਾ ਬਿੰਦੂ ਕਿਉਂਕਿ "ਭੁگਤਾਨ ਚੱਲ ਰਿਹਾ ਹੈ" ਇੱਕ ਅਸਲੀ ਵਚਨ ਹੈ।
• ਪੇਮੈਂਟ ਸਫਲਤਾ ਤੋਂ ਬਾਅਦ: ਗਾਹਕ ਅਨੁਭਵ ਲਈ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ, ਪਰ ਓਵਰਸੈਲ ਦਾ ਸਬ ਤੋਂ ਵਧੀਆ ਖਤਰਾ ਹੈ।

ਜਿੰਨਾ ਵੀ ਚੁਣੋ, ਹਰ ਰਿਜ਼ਰਵੇਸ਼ਨ ਵਿੱਚ ਸਿਰਫ਼ ਉਹੀ ਜਾਣਕਾਰੀ ਰੱਖੋ ਜਿਸਦੀ ਲੋੜ enforcement ਲਈ ਹੈ: ਆਈਟਮ (SKU), ਮਾਤਰਾ, ਕਾਰਟ ਜਾਂ ਆਰਡਰ ID, ਜਿਸਨੇ ਇਹ ਰੱਖਿਆ (ਸੈਸ਼ਨ/ਉਪਭੋਗਤਾ), ਅਤੇ ਇਕ expiry ਸਮਾਂ। ਸਹਾਇਤਾ ਲਈ ਕਾਰਨ ਜਾਂ ਸਟੇਜ (ਚੈੱਕਆਊਟ, ਪੇਮੈਂਟ) ਵੀ ਸਟੋਰ ਕਰੋ ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਸਮਝ ਆ ਸਕੇ ਕਿ ਕੀ ਹੋਇਆ।

ਮਲਟੀ-ਆਈਟਮ ਕਾਰਟਾਂ ਲਈ ਇੱਕ ਵਾਧੂ ਫੈਸਲਾ ਲੋ: ਕੀ ਤੁਸੀਂ ਸਾਰੀ ਕਾਰਟ ਦੇ ਆਈਟਮ ਇਕੱਠੇ ਰਿਜ਼ਰਵ ਕਰੋਗੇ ਜਾਂ ਪ੍ਰਤੀ ਆਈਟਮ। ਪ੍ਰਤੀ ਆਈਟਮ ਰਿਜ਼ਰਵ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ। ਜੇ ਇੱਕ ਆਈਟਮ ਆਉਟ ਆਫ਼ ਸਟਾਕ ਹੋ ਜਾਵੇ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਉਸ ਆਈਟਮ ਦੀ ਰਿਜ਼ਰਵ ਛੱਡ ਸਕਦੇ ਹੋ ਨਾ ਕਿ ਪੂਰੀ ਕਾਰਟ ਨੂੰ ਰੋਕਨਾ।

ਹੋਲਡ ਨੂੰ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿਚ ਦਿਖਾਓ। ਇੱਕ ਛੋਟਾ ਨੋਟ "ਅਸੀਂ ਇਹਨਾਂ ਆਈਟਮਾਂ ਨੂੰ 10 ਮਿੰਟ ਲਈ ਰੱਖ ਰਹੇ ਹਾਂ ਜਦ ਤਕ ਤੁਸੀਂ ਚੈੱਕਆਊਟ ਪੂਰਾ ਕਰੋ" ਕਾਫ਼ੀ ਹੈ। ਆਖਰੀ-ਆਈਟਮ ਦੇ ਮਾਮਲੇ ਵਿਚ ਸਿੱਧਾ ਕਹੋ: "ਸਿਰਫ਼ 1 ਬਚਾ ਹੈ। ਇਹ 3:42 PM ਤੱਕ ਤੁਹਾਡੇ ਲਈ ਰੱਖਿਆ ਗਿਆ ਹੈ।" ਟਾਈਮਰ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਤੁਹਾਡਾ ਸੁਨੇਹਾ ਸਪਸ਼ਟ ਹੈ ਤਾਂ ਉਹ ਜ਼ਰੂਰੀ ਨਹੀਂ।

ਜੇ ਤੁਸੀਂ ਫਲੋ Koder.ai ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ "reserve" ਨੂੰ ਪਹਿਲੀ-ਕਲਾਸ ਕਦਮ ਵਜੋਂ ਲਓ (API ਕਾਲ + ਡੇਟਾਬੇਸ ਰਿਕਾਰਡ) ਤਾਂ ਕਿ UI ਅਤੇ ਬੈਕਐਂਡ ਹਮੇਸ਼ਾ ਇਹ ਤੈਅ ਕਰੋ ਕਿ ਇਸ ਵੇਲੇ ਕੀ ਰੱਖਿਆ ਗਿਆ ਹੈ।

ਕ੍ਰਮ-ਬਾਈ-ਕ੍ਰਮ: ਸਟਾਕ ਰਿਜ਼ਰਵ ਕਰਨਾ ਅਤੇ ਓਵਰਸੈਲ ਰੋਕਣਾ

ਜੇ ਤੁਸੀਂ ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਸਟਾਕ ਦੀ ਸਹੀ-ਦਾਰੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਿਸਟਮ ਨੂੰ ਬੋਰਿੰਗ ਅਤੇ ਪੂਰੇ ਤੌਰ 'ਤੇ ਪੇਸ਼ਣਯੋਗ ਬਣਾਓ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਹਰ ਨੰਬਰ ਦਾ ਮਤਲਬ ਨਿਰਧਾਰਿਤ ਕਰੋ, ਅਤੇ ਇਸਨੂੰ ਸਿਰਫ਼ ਇਕ ਥਾਂ ਤੇ ਹੀ ਬਦਲੋ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਇੱਕਲ ਸੱਚਾਈ ਸੋਰਸ ਚੁਣੋ। ਇਹ ਇਕ ਡੇਟਾਬੇਸ ਟੇਬਲ ਹੋ ਸਕਦੀ ਹੈ, ਜਾਂ ਇੱਕ ਸੇਵਾ ਜੋ ਸਾਰੇ ਚੈੱਕਆਊਟਾਂ ਨੂੰ ਕਾਲ ਕਰਨੀ ਪਵੇ। ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ, ਐਡਮਿਨ ਟੈੱਬਸ, ਅਤੇ "ਕੁਇਕ ਫਿਕਸ" ਦੋ ਸਿਸਟਮਾਂ ਵਿੱਚ ਓਵਰਸੈਲ ਦੇ ਜਨਮ ਪੰਕਤੀਆਂ ਹਨ।

ਇੱਥੇ ਇੱਕ ਸਧਾਰਨ ਫਲੋ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਦੁਕਾਨਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ:

1. ਗਿਣਤੀਆਂ ਲਈ ਆਪਣੀ ਸੱਚਾਈ ਚੁਣੋ। "On hand" ਨੂੰ ਅਸਲ ਭੌਤਿਕ ਸਟਾਕ ਵਜੋਂ ਟਰੈਕ ਕਰੋ। ਫਿਰ "available" ਨੂੰ ਜਾਂ ਤਾਂ ਸਟੋਰ ਕੀਤਾ ਨੰਬਰ ਬਣਾਓ ਜਾਂ ਕੈਲਕੁਲੇਟ ਕੀਤਾ ਨੰਬਰ: on hand minus reserved।
2. ਜਦ ਗਾਹਕ ਵਚਨ ਦੇਵੇ ਤਾਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਬਣਾਓ। ਇਸਨੂੰ ਉਸ ਸਮੇਂ ਬਣਾਓ ਜਦ ਉਹ "Pay" 'ਤੇ ਕਲਿਕ ਕਰੇ (ਜਾਂ ਜਦ ਤੁਸੀਂ payment intent ਬਣਾਉਂਦੇ ਹੋ), ਨਾ ਕਿ ਜਦ ਉਹ ਕਾਰਟ ਵੇਖਦਾ ਹੈ। ਜ਼ਲਦੀ ਬਣਾਈਆਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਉਹਨਾਂ ਲਈ ਰੋਕਾ ਪੈਦਾ ਕਰਦੀਆਂ ਜੋ ਕਦੇ ਖਰੀਦਦੇ ਹੀ ਨਹੀਂ।
3. ਰਿਜ਼ਰਵੇਸ਼ਨ ਬਣਾਉਣ ਨਾਲ Availability ਨੂੰ ਘੱਟ ਕਰੋ। ਜੇ ਤੁਸੀਂ "available" ਸੰਭਾਲਦੇ ਹੋ, ਤਾਂ ਉਸਨੂੰ ਘਟਾਓ ਉਸੇ ਕਾਰਵਾਈ ਵਿੱਚ ਜੋ ਰਿਜ਼ਰਵੇਸ਼ਨ ਬਣਾਉਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ "available" ਕੈਲਕੁਲੇਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ reserved ਰਿਕਾਰਡ ਜੋੜੋ ਅਤੇ ਗਣਿਤ ਆਪਣਾ ਕੰਮ ਕਰੇਗਾ।
4. ਪੇਮੈਂਟ ਪੁਸ਼ਟੀ 'ਤੇ reserved ਨੂੰ sold ਵਿੱਚ ਬਦਲੋ। ਰਿਜ਼ਰਵੇਸ਼ਨ ਨੂੰ "sold" ਮਾਰਕ ਕਰੋ (ਜਾਂ ਇੱਕ ਆਰਡਰ ਲਾਈਨ ਬਣਾਓ) ਅਤੇ on hand ਨੂੰ ਘਟਾਓ। ਇਹੀ ਉਹ ਮੋੜ ਹੈ ਜਦ ਤੁਸੀਂ ਆਈਟਮ ਨੂੰ ਵਾਪਸ ਨਹੀਂ ਮੰਨਦੇ।
5. ਅਸਫਲਤਾ ਜਾਂ ਟਾਈਮਆਊਟ 'ਤੇ ਰਿਜ਼ਰਵੇਸ਼ਨ ਛੱਡੋ। ਜੇ ਪੇਮੈਂਟ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਮਿਆਦ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਗਾਹਕ ਪੇਜ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਨੂੰ "released" ਕਰ ਦਿਓ ਅਤੇ ਯੂਨਿਟ ਮੁੜ available ਕਰ ਦਿਓ।

ਅੰਤ ਵਿੱਚ, ਹਰ ਹਾਲਤ ਦੀ ਲੋਨ-ਇਤਿਹਾਸ ਲਿਖੋ: ਸਮਾਂ, ਕਾਰਨ, ਅਤੇ IDs (ਕਾਰਟ, ਪੇਮੈਂਟ, ਆਰਡਰ)। ਜਦ ਗਾਹਕ ਪੁੱਛਦਾ ਹੈ "ਕਿਉਂ ਆਊਟ ਆਫ਼ ਸਟਾਕ ਸੀ?" ਤਾਂ ਸਹਾਇਤਾ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਟਾਈਮਲਾਈਨ ਚਾਹੀਦੀ ਹੈ, ਅਨੁਮਾਨ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ ਇਹ ਫਲੋ ਕਿਸੇ ਐਪ ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ (ਉਦਾਹਰਣ ਲਈ Koder.ai ਨਾਲ), ਤਾਂ ਇਨ੍ਹਾਂ ਹਾਲਤਾਂ ਅਤੇ ਲੋਗਜ਼ ਨੂੰ ਪਹਿਲੀ-ਕਲਾਸ ਡੇਟਾ ਸਮਝੋ, ਨਾ ਕਿ ਸਿਰਫ਼ UI ਲੇਬਲ।

ਪੇਮੈਂਟ ਟਾਈਮਆਊਟਾਂ ਨੂੰ ਸਾਫ਼-ਸੁਥਰਾ ਹેન્ડਲ ਕਰਨਾ

ਪੇਮੈਂਟ ਟਾਈਮਆਊਟ ਉਸ ਬਿੰਦੂ ਨੂੰ ਕਹਿੰਦੇ ਹਨ ਜਦ ਤੁਸੀਂ ਚੈੱਕਆਊਟ ਪੂਰਾ ਹੋਣ ਦੀ ਉਮੀਦ ਛੱਡ ਦਿੰਦੇ ਹੋ ਅਤੇ Reserved ਸਟਾਕ ਨੂੰ ਮੁੜ Available ਨੂੰ ਰੀਲੀਜ਼ ਕਰ ਦਿੰਦੇ ਹੋ। ਤੁਹਾਨੂੰ ਇਹ ਲੋੜੀਦਾ ਹੈ ਕਿਉਂਕਿ ਕੁਝ ਗਾਹਕ ਭੁਗਤਾਨ ਕਦੇ ਪੂਰਾ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਬਿਨਾਂ ਟਾਈਮਆਊਟ ਦੇ ਤੁਹਾਡਾ "reserved" ਢੇਰ ਵਧਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਅਸਲੀ ਖਰੀਦਦਾਰਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਾਂ ਮੈਨੂਅਲ ਫਿਕਸ ਕਰਨ ਪੈਂਦੇ ਹਨ।

ਉਹ ਟਾਈਮਆਊਟ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਪੇਮੈਂਟ ਪ੍ਰੋਵਾਇਡਰ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ। ਕਾਰਡ ਭੁਗਤਾਨ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਪੁਸ਼ਟੀ ਹੋ ਜਾਂਦੇ ਹਨ, ਪਰ 3D Secure, ਬੈਂਕ ਰੀਡਾਇਰੈਕਟ, ਅਤੇ ਵੌਲੇਟ ਫਲੋ ਵੱਧ ਸਮਾਂ ਲੈ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਟਾਈਮਆਊਟ ਬਹੁਤ ਛੋਟੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਹ ਸਟਾਕ ਛੱਡ ਦਿਓਗੇ ਜਦ ਗਾਹਕ ਅਜੇ ਭੁਗਤਾਨ ਕਰ ਰਿਹਾ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਇਹ ਬਹੁਤ ਲੰਮੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਲਈ ਸਟਾਕ ਰੱਖ ਕੇ ਰੱਖੋਗੇ ਜੋ ਪਹਿਲਾਂ ਹੀ ਛੱਡ ਚੁੱਕੇ ਹਨ। ਕਈ ਛੋਟੀ ਦੁਕਾਨਾਂ ਲਈ 10 ਤੋਂ 20 ਮਿੰਟ ਇੱਕ ਵਾਜਬ ਸ਼ੁਰੂਆਤ ਹੈ, ਫਿਰ ਲੋਗਜ਼ ਦੇ ਆਧਾਰ ਤੇ ਸਮਾਂ ਠੀਕ ਕਰੋ।

ਜਦ ਗਾਹਕ ਟੈਬ ਬੰਦ ਕਰ ਦੇਂਦਾ ਜਾਂ ਕਨੈਕਸ਼ਨ ਗੁਆ ਦੇਂਦਾ ਹੈ, ਕੁਝ ਵੀ ਧਾਰਨਾ ਨਾ ਕਰੋ। ਪੇਮੈਂਟ ਪਿਛੇਲੇ ਫਲ ਵਿੱਚ ਵੀ ਸਫਲ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਕਦੇ ਸ਼ੁਰੂ ਹੀ ਨਾ ਹੋਇਆ। ਇਸੀ ਲਈ ਇਨਵੈਂਟਰੀ ਸਿਸਟਮ ਨੂੰ ਬਰਾਉਜ਼ਰ 'ਤੇ ਆਧਾਰ ਨਾ ਰੱਖੋ ਕਿ "ਉਸਨੇ ਤੁਹਾਨੂੰ ਦੱਸਿਆ"।

ਸਾਫ਼-ਸੁਥਰਾ ਕਲੀਨਅਪ ਆਟੋਮੈਟਿਕ ਬਣਾਓ ਤਾਂ ਕਿ ਤੁਸੀਂ ਆਰਡਰਾਂ ਦੀ ਦੇਖਭਾਲ ਨਾਹ ਕਰੋ। ਇੱਕ ਸਧਾਰਣ ਤਰੀਕਾ ਹੈ ਇੱਕ ਨਿਯਮਤ ਸਵੀਪ ਜੋ ਪੁਰਾਣੀਆਂ ਰਿਜ਼ਰਵ ਐਸ਼ਨਾਂ ਨੂੰ ਖਤਮ ਕਰ ਦੇਵੇ ਅਤੇ ਕਾਰਨ ਨੋਟ ਕਰੇ।

• ਰਿਜ਼ਰਵੇਸ਼ਨ ਨੂੰ ਇੱਕ explicit expires_at ਟਾਈਮਸਟੈਂਪ ਨਾਲ ਸਟੋਰ ਕਰੋ
• ਹਰ 1 ਤੋਂ 5 ਮਿੰਟ 'ਤੇ ਇੱਕ ਸ਼ੈਡਿਊਲਡ ਜੌਬ ਚਲਾਓ ਜੋ ਖਤਮ ਹੋਈਆਂ ਰਿਜ਼ਰਵੇਸ਼ਨਾਂ ਲੱਭੇ
• ਰਿਜ਼ਰਵ ਤੋਂ quantity ਨੂੰ "reserved" -> "available" ਵੱਲ ਵਾਪਸ ਕਰੋ
• ਚੈੱਕਆਊਟ/ਆਰਡਰ ਨੂੰ "expired" ਮਾਰਕ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਗਾਹਕ ਦੀ ਸਹਾਇਤਾ ਕਰ ਸਕੋ
• expiration ਦੀ ਗਿਣਤੀ ਲੋଗ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਟਾਈਮਆਊਟ ਟਿਊਨ ਕਰ ਸਕੋ

ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਕਰੋ ਕਿ ਜੇ ਭੁਗਤਾਨ ਦੇਰ ਨਾਲ ਆਏ (ਟਾਈਮਆਊਟ ਤੋਂ ਬਾਅਦ), ਤਾਂ ਤੁਸੀਂ ਕੀ ਕਰੋਗੇ। ਕੋਈ ਪੂਰਾ-ਪਰਫੈਕਟ ਜਵਾਬ ਨਹੀਂ, ਪਰ ਇਕ ਲਗਾਤਾਰ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ। ਆਮ ਵਿਕਲਪ ਹਨ: ਜੇ ਸਟਾਕ ਅਜੇ ਵੀ ਉਪਲਬਧ ਹੈ ਤਾਂ ਭੁਗਤਾਨ ਮੰਨਣਾ (ਨਹੀਂ ਤਾਂ ਆਟੋ-ਰੀਫੰਡ), ਜਾਂ ਜੇ ਤੁਹਾਡੇ ਪ੍ਰੋਵਾਇਡਰ ਨੇ ਇਹ ਸਾਬਤ ਕੀਤਾ ਕਿ ਭੁगਤਾਨ ਚੱਲ ਰਿਹਾ ਹੈ ਤਾਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਲੰਬਾ ਕਰਨਾ।

ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਟਾਈਮਆਊਟ ਪੇਸ਼ਗੀਯੋਗ, ਆਟੋਮੈਟਿਕ, ਅਤੇ ਦਿਖਾਈ ਦੇਣਯੋਗ ਹੋਣ, ਤਾਂ ਕਿ "reserved" ਕਦੇ ਕਾਲੇ ਸੁਰ ਖਾਂ ਨਾ ਬਣੇ।

ਪੇਮੈਂਟ ਅਤੇ ਇਨਵੈਂਟਰੀ ਨੂੰ ਸਿੰਕ ਰੱਖਣਾ

ਪੇਮੈਂਟ ਸਿਸਟਮ ਹਮੇਸ਼ਾ ਇੱਕ ਸਾਫ਼ "paid" ਸੁਨੇਹਾ ਨਹੀਂ ਭੇਜਦੇ। ਤੁਸੀਂ ਇੱਕੋ ਪੁਸ਼ਟੀ ਜ਼ਿਆਦਾ ਵਾਰੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ, ਡਿਲੇਡ webhook ਆ ਸਕਦਾ ਹੈ, ਜਾਂ ਇੱਕ capture ਜੋ ਗਾਹਕ ਸਮਝਦਾ ਹੈ ਕਿ ਮੁਕੰਮਲ ਹੋਣ ਤੋਂ ਮਿੰਟਾਂ ਬਾਅਦ ਆ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਇਨਵੈਂਟਰੀ ਅੱਪਡੇਟ ਉਹਨਾਂ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਇੱਕੋ ਯੂਨਿਟ ਦੋ ਵਾਰ ਵੇਚ ਸਕਦੇ ਹੋ।

ਸਭ ਤੋਂ ਸਧਾਰਨ ਐਂਕੋਰ ਇੱਕ order id ਹੈ ਜੋ ਸਾਰੀ ਕਹਾਣੀ ਨੂੰ ਫੋਲੋ ਕਰਦੀ ਹੈ: ਰਿਜ਼ਰਵੇਸ਼ਨ, ਹਰ ਪੇਮੈਂਟ ਕੋਸ਼ਿਸ਼, ਅਤੇ ਆਖਰੀ ਵਿਕਰੀ। ਜਦ ਕੁਝ ਵੀ ਹੁੰਦਾ ਹੈ, ਪਹਿਲਾਂ order id ਲੱਭੋ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇ।

ਕੁਝ ਨਿਯਮ ਜੋ ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਇਨਵੈਂਟਰੀ ਸਹੀ-ਦਾਰੀ ਰੱਖਣਗੇ ਬਿਨਾਂ ਜਟਿਲਤਾ ਵੱਧਾਉਂਦੇ:

• ਇਨਵੈਂਟਰੀ ਅੱਪਡੇਟ(idempotent) ਬਣਾਓ: ਜੇ ਉਹੀ "payment confirmed" ਘਟਨਾ ਦੋ ਵਾਰੀ ਪ੍ਰੋਸੈਸ ਹੋਵੇ, ਦੂਜੀ ਵਾਰੀ ਕੁਝ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ।
• ਰਿਜ਼ਰਵੇਸ਼ਨ ਨੂੰ ਇੱਕ ਵਾਰੀ ਹੀ "converted to sale" ਮਾਰਕ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਇੱਕ ਵਾਰੀ, ਉਸ order id ਲਈ।
• ਹਰ ਪੇਮੈਂਟ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਉਸੇ order id ਹੇਠ ਰਿਕਾਰਡ ਕਰੋ, ਭਾਵੇਂ ਗਾਹਕ ਨਵੀਂ ਕਾਰਡ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੇ।
• ਸਿਰਫ਼ ਉਹਦੋਂ reserved -> sold ਕਰੋ ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਪੱਠ, ਆਖਰੀ ਪੇਮੈਂਟ ਨਤੀਜਾ ਹੋਵੇ (authorised ਅਤੇ captured, ਜਾਂ ਜੋ ਵੀ "final" ਤੁਹਾਡੇ ਵਪਾਰ ਲਈ ਮਤਲਬ ਰੱਖਦਾ ਹੈ)।

Idempotent ਇੱਕ ਵੱਡਾ ਸ਼ਬਦ ਹੈ ਜੋ "ਦੋਹਰਾਉਣ ਯੋਗ ਬਿਨਾ ਨੁਕਸਾਨ" ਦਾ ਮਤਲਬ ਰੱਖਦਾ ਹੈ। ਇਹਨੂੰ ਟਿਕਟ 'ਤੇ ਸਥਾਨ ਕਰਨ ਵਾਂਗ ਸੋਚੋ: ਪਹਿਲਾ ਸਟੈਂਪ ਮਹੱਤਵਪੂਰਨ, ਦੂਜਾ ਸਟੈਂਪ ਕੋਈ ਨਵੀਂ ਚੀਜ਼ ਨਹੀਂ ਕਰਦਾ।

ਰੀਫੰਡ ਅਤੇ ਚਾਰ্জਬੈਕ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਆਈਟਮ ਨੂੰ ਮੁੜ available ਵਿੱਚ ਨਹੀਂ ਰੱਖਣਾ ਚਾਹੀਦਾ। ਜੇ ਆਈਟਮ ਪਹਿਲਾਂ ਹੀ ਭੇਜ ਦਿੱਤਾ ਗਿਆ, ਤਾਂ ਇਨਵੈਂਟਰੀ sold ਰਹੇ, ਜਦਕਿ ਤੁਹਾਡੀ ਬੁੱਕਕਿਪਿੰਗ ਰਿਫੰਡ ਦਿਖਾਵੇ। ਸਿਰਫ਼ ਤਾਂ ਹੀ ਦੁਬਾਰਾ ਸਟਾਕ ਕਰੋ ਜਦ ਆਈਟਮ ਵਾਪਸ ਆਏ ਅਤੇ ਜਾਂਚ ਹੋਵੇ।

ਪਾਰਸ਼ੀਅਲ captures ਅਤੇ ਸਪਲਿਟ ਪੇਮੈਂਟ ਲਈ ਇੱਕ ਸਧਾਰਨ ਨੀਤੀ ਰੱਖੋ। ਉਦਾਹਰਣ ਲਈ: ਆਈਟਮ ਨੂੰ ਰੱਖੋ ਜਦ ਤਕ ਕਿ ਕੁੱਲ captured ਰਕਮ ਆਰਡਰ ਟੋਟਲ ਦੇ ਬਰਾਬਰ ਨਾ ਹੋ ਜਾਵੇ, ਫਿਰ sold ਮਾਰਕ ਕਰੋ। ਜੇ ਗਾਹਕ ਸਿਰਫ਼ ਹਿੱਸਾ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਟਾਈਮਆਊਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਨੂੰ ਕਿਸੇ ਵੀ ਹੋਰ ਨਾਕਾਮ ਚੈੱਕਆਊਟ ਵਾਂਗ ਹੀ ਛੱਡ ਦਿਓ।

ਓਵਰਸੈਲ ਹੋਣ ਦੇ ਆਮ ਗਲਤੀਆਂ

ਬਹੁਤ ਸਾਰੇ ਓਵਰਸੈਲਾਂ ਗਲਤ ਗਣਿਤ ਕਰਕੇ ਨਹੀਂ ਹੋਂਦੇ। ਉਹ ਉਸ ਸਮੇਂ ਹੁੰਦੇ ਹਨ ਜਦ ਟੀਮ ਇਕੋ ਸ਼ਬਦਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਮਤਲਬ ਦੇ ਰਿਹਾ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਜਦ ਚੈੱਕਆਊਟ ਦੇ ਇੱਕ ਹਿਸੇ ਤੋਂ ਇਨਵੈਂਟਰੀ ਨੂੰ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਛੋਟੀ ਟੀਮ ਲਈ ਸਟਾਕ ਦੀ ਸਹੀ-ਦਾਰੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਧਾਰਨ ਫਿਕਸ ਆਮ ਤੌਰ 'ਤੇ ਹੌਂਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਲਗਾਤਾਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ਇੱਕ ਆਮ ਗਲਤੀ ਬਹੁਤ ਜਲਦੀ ਰਿਜ਼ਰਵ ਕਰਨਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਉਤਪਾਦ ਪੇਜ ਖੋਲ੍ਹਦੇ ਹੀ ਜਾਂਕਾਰਟ ਵਿੱਚ ਰੱਖਦੇ ਹੀ ਰਿਜ਼ਰਵ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਸਲ ਖਰੀਦਦਾਰਾਂ ਲਈ ਸਟਾਕ ਬਲਾਕ ਕਰ ਦੇਂਦੇ ਹੋ ਜੋ ਸਿਰਫ਼ ਬਰਾਊਜ਼ ਕਰ ਰਹੇ ਹੋ ਸਕਦੇ ਹਨ। ਰਿਜ਼ਰਵੇਸ਼ਨ ਨੂੰ ਸਪਸ਼ਟ ਇਰਾਦੇ ਨਾਲ ਜੋੜਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਚੈੱਕਆਊਟ ਸ਼ੁਰੂ ਕਰਨਾ ਜਾਂ payment session ਬਣਾਉਣਾ।

ਇਕ ਹੋਰ ਅੜਿੱਕ ਹੈ ਰਿਜ਼ਰਵ ਜੋ ਕਦੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਹਰ ਰੋਜ਼ ਕੁਝ ਛੱਡੇ ਹੋਏ ਚੈੱਕਆਊਟ ਤੁਹਾਡਾ ਵਿਕਣਯੋਗ ਸਟਾਕ ਖਾਂ ਸਕਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਸਮਾਂ ਸੀਮਾ ਅਤੇ ਆਟੋਮੈਟਿਕ ਰੀਲੀਜ਼ ਦੀ ਲੋੜ ਹੈ।

ਇਹ ਉਹ ਗਲਤੀਆਂ ਹਨ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਮਿਲਦੀਆਂ ਹਨ:

• ਚੈੱਕਆਊਟ ਤੋਂ ਪਹਿਲਾਂ ਸਟਾਕ ਰਿਜ਼ਰਵ ਕਰਨਾ, ਇਸ ਲਈ ਬਰਾਊਜ਼ਰਜ਼ ਦੁਆਰਾ ਸਟਾਕ ਲੌਕ ਹੋ ਜਾਂਦਾ ਹੈ, ਖਰੀਦਦਾਰਾਂ ਦੁਆਰਾ ਨਹੀਂ।
• expiry ਛੱਡ ਦੇਣਾ, ਤਾਂ ਪੁਰਾਣੀਆਂ ਰਿਜ਼ਰਵੇਸ਼ਨਾਂ ਦਾ ਢੇਰ ਬਣ ਜਾਂਦਾ ਹੈ ਅਤੇ availability ਘਟਦੀ ਰਹਿੰਦੀ ਹੈ।
• ਬਹੁਤ ਸਾਰੇ ਸਿਸਟਮ ਗਿਣਤੀਆਂ ਬਦਲਦੇ ਹਨ (ਐਡਮਿਨ ਐਡਿਟ, ਬਲਕ ਇੰਪੋਰਟ, ਰੀਟਰਨ) ਬਿਨਾਂ ਇੱਕ ਨਿਯਮ ਦੇ ਕਿ ਸਥਿਤੀਆਂ ਕਿਵੇਂ ਹਿਲਦੀਆਂ ਹਨ।
• ਅਰਥ ਮਿਲਾਉਣਾ: ਕਿਸੇ ਥਾਂ "sold" ਨੂੰ "paid" ਮੰਨਣਾ ਅਤੇ ਕਿਸੇ ਹੋਰ ਥਾਂ "shipped" ਸਮਝਣਾ।
• ਰਿਜ਼ਰਵੇਸ਼ਨ ਨੂੰ RELEASE ਕਰਨਾ ਬਿਨਾਂ ਕਾਰਨ ਦਰਜ਼ ਕੀਤੇ, ਜੋ ਸਪੋਰਟ ਮੁੱਦਿਆਂ ਨੂੰ ਔਖਾ ਬਣਾਉਂਦਾ ਹੈ।

ਆਖਰੀ ਨੁਕਤਾ ਉਹਨਾ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜਦ ਇੱਕ ਗਾਹਕ ਕਹਿੰਦਾ ਹੈ, "ਮੈਂ ਭੁਗਤਾਨ ਕੀਤਾ ਪਰ ਇਹ ਆਊਟ ਆਫ਼ ਸਟਾਕ ਦਿਖਾ ਰਿਹਾ ਹੈ," ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਇੱਕ ਆਡਿਟ ਟਰੇਲ ਚਾਹੀਦੀ ਹੈ ਜੋ ਜਵਾਬ ਦੇਵੇ: ਕਦੋਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਬਣੀ, ਕਦੋਂ ਛੱਡੀ ਗਈ, ਅਤੇ ਕੀ ਕਾਰਨ ਸੀ—ਟਾਈਮਆਊਟ, ਮੈਨੁਅਲ ਕੈਂਸਲ, ਜਾਂ ਰੀਫੰਡ।

ਇੱਕ ਸਧਾਰਨ ਆਦਤ ਮਦਦ ਕਰਦੀ ਹੈ: ਜਦ ਵੀ ਇਨਵੈਂਟਰੀ ਬਦਲੇ, ਕਾਰਨ ਅਤੇ ਸਰੋਤ ਦਰਜ਼ ਕਰੋ (checkout, admin, import, support)। ਜੇ ਤੁਸੀਂ Koder.ai 'ਚ ਇਹ ਫਲੋ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਕਾਰਨ ਆਪਣੇ ਡੇਟਾ ਮਾਡਲ ਵਿੱਚ ਬਣਾ ਦੇਵੋ ਅਤੇ ਇੱਕ ਥਾਂ ਤੇ ਲਾਗੂ ਕਰੋ ਤਾਂ ਹਰ ਫੀਚਰ ਇੱਕੋ ਨਿਯਮ ਮੰਨੇ।

ਤੁਰੰਤ ਚੈਕਲਿਸਟ ਜਦ ਤੁਸੀਂ ਬਦਲਾਅ ਲਾਂਚ ਕਰਦੇ ਹੋ

ਨਵੇਂ ਚੈੱਕਆਊਟ ਜਾਂ ਇਨਵੈਂਟਰੀ ਲਾਜਿਕ ਪੈਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਹਰ ਕੋਈ ਟੀਮ ਵਿੱਚ ਇਹ ਦੱਸ ਸਕੇ ਕਿ ਹਰ ਸਥਿਤੀ ਦਾ ਕੀ ਮਤਲਬ ਹੈ ਬਿਨਾਂ ਵਾਧੂ ਨਿਯਮਾਂ ਦੇ। "Available" ਉਹ ਹੈ ਜੋ ਅਜੇ ਰਿਜ਼ਰਵ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, "reserved" ਉਹ ਹੈ ਜੋ ਨਿਰਧਾਰਤ ਚੈੱਕਆਊਟ ਲਈ ਰੱਖਿਆ ਗਿਆ ਹੈ ਜਦ ਤਕ ਇਹ ਖਤਮ ਨਾ ਹੋਵੇ, ਅਤੇ "sold" ਭੁਗਤਾਨ ਹੋ ਕੇ ਅੰਤਿਮ ਹੈ।

ਇੱਕ ਸਧਾਰਨ ਸਟਾਕ ਰਿਜ਼ਰਵ ਸਿਸਟਮ ਸਮਾਂ ਅਤੇ ਕਲੀਨਅਪ 'ਤੇ ਟਿਕਦਾ ਹੈ। ਰਿਜ਼ਰਵੇਸ਼ਨਾਂ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ expiry ਸਮਾਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ 10-15 ਮਿੰਟ), ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਜੌਬ ਜਾਂ ਟ੍ਰਿਗਰ ਚਾਹੀਦਾ ਹੈ ਜੋ ਖਤਮ ਹੋਏ ਹੋਲਡ ਨੂੰ ਰਿਲੀਜ਼ ਕਰੇ ਤਾਂ ਕਿ ਸਟਾਕ ਮੁੜ available ਹੋ ਜਾਵੇ।

ਇਹ ਪ੍ਰੀ-ਸ਼ਿਪ ਚੈੱਕਲਿਸਟ ਚਲਾਉ:

• ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਚੈੱਕਆਊਟ ਸਿਰਫ਼ ਉਹ ਆਈਟਮ ਪ੍ਰੋਮੀਸ ਕਰਦਾ ਹੈ ਜੋ reserved ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ ਕਾਰਟ ਵਿੱਚ ਬੈਠੇ ਹੋਏ।
• ਯਕੀਨ ਬਣਾਓ ਕਿ ਰਿਜ਼ਰਵੇਸ਼ਨ ਬਣਾਉਣਾ ਐਟੌਮਿਕ ਹੈ (ਦੋ ਲੋਕ ਇਕੋ ਸਮੇਂ ਆਖਰੀ ਆਈਟਮ reserve ਨਹੀਂ ਕਰ ਸਕਦੇ)।
• ਜਾਂਚੋ ਕਿ ਪੇਮੈਂਟ ਪੁਸ਼ਟੀ reserved ਨੂੰ sold ਵਿੱਚ ਬਦਲਦੀ ਹੈ ਇੱਕ ਵਾਰੀ ਹੀ (retries ਅਤੇ webhooks ਲਈ idempotent ਹੈਂਡਲਿੰਗ)।
• ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਜੇ ਭੁਗਤਾਨ ਰਿਜ਼ਰਵੇਸ਼ਨ expiry ਤੋਂ ਬਾਅਦ ਦੇਰ ਨਾਲ ਆਏ ਤਾਂ ਕੀ ਹੋਵੇ: ਇਸਨੂੰ ਮੰਨਣਾ, ਰੱਦ ਕਰਨਾ, ਜਾਂ backorder ਦੇ ਰੂਪ ਵਿੱਚ ਮਾਰਕ ਕਰਨਾ। ਇੱਕ ਨਿਯਮ ਚੁਣੋ ਅਤੇ ਹਰ ਵਾਰੀ ਲਾਗੂ ਕਰੋ।
• timeout ਰਾਹ ਨੂੰ end-to-end ਟੈਸਟ ਕਰੋ: ਰਿਜ਼ਰਵੇਸ਼ਨ expire ਹੋਏ, ਇਨਵੈਂਟਰੀ ਮੁੜ available ਹੋਈ, ਅਤੇ ਗਾਹਕ ਨੂੰ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦਿੱਤਾ ਗਿਆ।

ਸਪੋਰਟ ਨੂੰ ਅਨੁਮਾਨ ਨਹੀਂ, ਦਿੱਖਾਈ ਚਾਹੀਦੀ ਹੈ। ਕਿਸੇ ਵੀ ਆਰਡਰ ਲਈ, ਤੁਸੀਂ ਇੱਕ ਟਾਈਮਲਾਈਨ ਦੇਖ ਸਕੋ ਜਿਸ ਵਿੱਚ ਸਥਿਤੀ ਬਦਲਾਅ ਦੇ ਟਾਈਮਸਟੈਂਪ ਹੁਣ ਤਾਂ ਢੰਗ ਨਾਲ বিত---

ਸਪੋਰਟ ਟਾਈਮਲਾਈਨ ਨੂੰ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ

• ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਦੋਂ ਬਣੀ ਅਤੇ ਕਦੋਂ expire ਹੋਈ?
• ਭੁਗਤਾਨ ਕਦੋਂ ਸਫਲ ਯਾ ਅਸਫਲ ਹੋਇਆ, ਅਤੇ ਕੀ ਇਹ expiry ਤੋਂ ਪਹਿਲਾਂ ਜਾਂ ਬਾਅਦ ਸੀ?
• ਸਟਾਕ ਕਦੋਂ ਰਿਲੀਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਜਾਂ sold ਵਿੱਚ ਬਦਲਿਆ ਗਿਆ, ਅਤੇ ਕਿਸ ਸਿਸਟਮ ਇਵੈਂਟ ਵੱਲੋਂ?

ਜੇ ਤੁਸੀਂ ਇਹ ਲਾਜਿਕ ਕਿਸੇ ਕੋਡ ਜਨਰੇਟਰ ਜਾਂ vibe-coding ਪਲੇਟਫਾਰਮ (ਉਦਾਹਰਣ: Koder.ai) ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ ਇਹ ਨਿਯਮ ਲਿਖੋ, ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਖੁੱਲ੍ਹਾ ਰੂਪ ਵਿੱਚ states ਅਤੇ events ਵਜੋਂ ਨਿਰਮਾਣ ਕਰੋ। ਇਹ ਐੱਡਜ ਕੇਸਜ਼ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਘੁਸਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਉਦਾਹਰਣ: ਦੋ ਗਾਹਕ, ਇੱਕ ਆਖਰੀ ਆਈਟਮ

ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਲੋਕਪ੍ਰਿਯ ਆਈਟਮ ਦੀ 1 ਯੂਨਿਟ ਬਚੀ ਹੈ। ਦੋ ਖਰੀਦਦਾਰ ਲਗਭਗ ਇੱਕੋ ਸਮੇਂ ਚੈੱਕਆਊਟ 'ਤੇ ਪਹੁੰਚਦੇ ਹਨ।

12:00:00 - ਸਟੋਰ ਦਿਖਾਉਂਦਾ ਹੈ Available: 1, Reserved: 0, Sold: 0।

12:00:05 - ਖਰੀਦਦਾਰ A "Pay" 'ਤੇ ਕਲਿਕ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੀ ਸਿਸਟਮ A ਲਈ 1 ਯੂਨਿਟ ਦੀ ਇੱਕ 10 ਮਿੰਟ ਦੀ ਰਿਜ਼ਰਵੇਸ਼ਨ ਬਣਾਉਂਦੀ ਹੈ। ਪ੍ਰੋਡਕਟ ਪੇਜ ਹੁਣ ਪ੍ਰਭਾਵਤ ਤੌਰ 'ਤੇ ਦਿਖਾਉਂਦਾ ਹੈ Available: 0 (ਕਿਉਂਕਿ ਆਖਰੀ ਯੂਨਿਟ ਰੱਖਿਆ ਗਿਆ ਹੈ), ਜਦਕਿ ਬੈਕ ਆਫਿਸ 'Reserved: 1' ਦਿਖਾਉਂਦਾ ਹੈ।

12:00:20 - ਖਰੀਦਦਾਰ B ਉਹੀ ਆਈਟਮ ਕਾਰਟ ਵਿੱਚ ਪਾਈਦਾ ਹੈ ਅਤੇ ਚੈੱਕਆਊਟ ਤੇ ਜਾਂਦਾ ਹੈ।

• ਖਰੀਦਦਾਰ B ਨੂੰ ਜੋ ਦਿਖਾਈ ਦੇਵੇਗਾ: "Out of stock" ਜਾਂ "Not available right now."
• ਸਹਾਇਤਾ/ਐਡਮਿਨ ਜੋ ਵੇਖਦੇ ਹਨ: Available 0, Reserved 1 (A ਲਈ ਰੱਖਿਆ), Sold 0।

12:03:10 - ਖਰੀਦਦਾਰ A ਦਾ ਭੁਗਤਾਨ ਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਤੁਸੀਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਨੂੰ ਵਿਕਰੀ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹੋ:

• Sold 1 ਹੋ ਜਾਂਦਾ ਹੈ।
• Reserved 0 ਹੋ ਜਾਂਦਾ ਹੈ।
• Available 0 ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਕੋਈ ਭੌਤਿਕ ਸਟਾਕ ਨਹੀਂ ਬਚਿਆ।

ਹੁਣ ਗਿਣਤੀਆਂ ਹਨ Available: 0, Reserved: 0, Sold: 1। ਖਰੀਦਦਾਰ A ਨੂੰ ਆਰਡਰ ਪੁਸ਼ਟੀ ਮਿਲਦੀ ਹੈ। ਖਰੀਦਦਾਰ B ਹਜੇ ਵੀ ਖਰੀਦ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਵਿਕਲਪ ਸਮਾਪਤੀ: ਪੇਮੈਂਟ ਟਾਈਮਆਊਟ

ਉਹੀ ਸ਼ੁਰੂਆਤ, ਪਰ ਖਰੀਦਦਾਰ A ਭੁਗਤਾਨ ਕਦੇ ਪੂਰਾ ਨਹੀਂ ਕਰਦਾ।

12:10:05 - ਰਿਜ਼ਰਵੇਸ਼ਨ expire ਹੋ ਜਾਂਦੀ ਹੈ (ਟਾਈਮਆਊਟ)। ਤੁਸੀਂ ਸਟਾਕ ਰਿਲੀਜ਼ ਕਰ ਦਿੰਦੇ ਹੋ।

• ਗਿਣਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ Available: 1, Reserved: 0, Sold: 0।
• ਖਰੀਦਦਾਰ B ਹੁਣ ਚੈੱਕਆਊਟ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ B ਲਈ ਨਵੀਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਬਣਾਉਣਗੇ।

ਵੈਰੀਅੰਟ: ਪੇਮੈਂਟ ਟਾਈਮਆਊਟ ਤੋਂ ਬਾਅਦ ਸਫਲ

ਕਈ ਵਾਰੀ ਪੇਮੈਂਟ ਪ੍ਰੋਵਾਇਡਰ ਦੇਰੀ ਨਾਲ ਸਫਲ ਦੱਸਦੇ ਹਨ (ਨੈੱਟਵਰਕ ਲੈਗ, ਡਿਲੇਡ ਪੁਸ਼ਟੀ)।

ਤੁਹਾਡਾ ਨਿਯਮ ਸਧਾਰਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਜਦ ਇੱਕ ਰਿਜ਼ਰਵੇਸ਼ਨ expire ਹੋ ਚੁੱਕੀ ਹੈ, ਉਸਨੂੰ ਮੁੜ ਜਿਉਂਦਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਤਾਂ ਜਦ A ਲਈ ਦੇਰ ਨਾਲ "success" ਆਵੇ, ਤੁਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਕਰੋਗੇ:

• ਜੇ ਰਿਜ਼ਰਵੇਸ਼ਨ expire ਹੋ ਚੁੱਕੀ ਹੈ, ਆਈਟਮ ਨੂੰ sold ਨਾ ਮਾਰਕ ਕਰੋ। ਆਰਡਰ ਨੂੰ "needs review" ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਗਾਹਕ ਨੂੰ ਰੀਫੰਡ ਕਰੋ ਜਾਂ ਪੁੱਛੋ ਕਿ ਉਹ ਦੁਬਾਰਾ ਆਰਡਰ ਕਰੇ।
• ਜੇ ਨਵੀਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਖਰੀਦਦਾਰ B ਲਈ ਬਣ ਚੁੱਕੀ ਹੈ, ਤਾਂ B ਨੂੰ ਪਹਿਲ ਦਿਓ ਕਿਉਂਕਿ B ਕੋਲ ਸਰਗਰਮ ਹੋਲਡ ਹੈ।

ਇਹ ਇੱਕ ਨਿਯਮ ਓਵਰਸੈਲ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਸਪੋਰਟ ਨਤੀਜਿਆਂ ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।

ਅੱਗੇ ਦੇ ਕਦਮ: ਨਿਯਮਾਂ ਨੂੰ ਇਕ ਸਧਾਰਨ ਸਿਸਟਮ ਵਿੱਚ ਬਦਲੋ

ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਸਟਾਕ ਦੀ ਸਹੀ-ਦਾਰੀ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦ ਹਰ ਕੋਈ ਇਕੋ ਜਿਹੀਆਂ ਭਾਸ਼ਾ ਇਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤੇ। ਇਕ ਥਾਂ ਤੇ ਆਪਣੇ definitions ਲਿਖੋ: available, reserved, sold — ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਉਹੀ ਹਨ ਜੋ ਤੁਹਾਡੀ ਦੁਕਾਨ ਗਾਹਕਾਂ ਨੂੰ ਦਿਖਾਉਂਦੀ, ਸਹਾਇਤਾ ਗਾਹਕਾਂ ਨੂੰ ਦੱਸਦੀ, ਅਤੇ ਟੀਮ ਐਡਮਿਨ ਵਿੱਚ ਵੇਖਦੀ ਹੈ।

ਆਪਣੀ ਨੀਤੀ ਛੋਟੀ ਰੱਖੋ: ਸਹੀ-ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਦੋਂ ਬਣਦੀ ਹੈ (ਉਦਾਹਰਣ: ਚੈੱਕਆਊਟ ਸ਼ੁਰੂ 'ਤੇ ਜਾਂ ਜਦ ਪੇਮੈਂਟ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ) ਅਤੇ ਇਹ ਕਿੰਨਾ ਸਮਾਂ ਰੱਖ ਸਕਦੀ ਹੈ ਪਹਿਲਾਂ ਖਤਮ ਹੋਣ ਤੋਂ। ਟਾਈਮਆਊਟ ਨਿਯਮ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਰੱਖੋ, ਜਿਸ ਵਿੱਚ ਇਹ ਵੀ ਲਿਖੋ ਕਿ ਜੇ ਗਾਹਕ expiry ਤੋਂ ਬਾਅਦ ਆਵੇ ਤਾਂ ਕੀ ਹੋਵੇ।

ਚੈੱਕਆਊਟ ਵਿੱਚ ਕੋਈ ਵੀ ਤਬਦੀਲੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਪਹਿਲਾਂ states ਅਤੇ transitions ਦਾ ਸਕੈਚ ਬਣਾਓ। ਤੁਸੀਂ ਹਰ ਇਵੈਂਟ ਨੂੰ ਦਿਸ ਕੇ ਕਹਿ ਸਕੋ ਕਿ ਇਹ ਸਟਾਕ 'ਤੇ ਕੀ ਕਰੇਗਾ।

ਇੱਕ ਸਧਾਰਨ, عملي ਬੇਸਲਾਈਨ

ਜਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ ਇਹ ਪੰਜ ਕਾਰਵਾਈਆਂ ਠੀਕ ਰਹਿੰਦੀਆਂ ਹਨ:

• Reserve: ਇੱਕ ਨਿਰਧਾਰਤ ਕਾਰਟ ਜਾਂ ਆਰਡਰ ਲਈ ਰੱਖ ਬਣਾਉ
• Release: ਜਦ ਗਾਹਕ ਰੱਦ ਕਰੇ ਜਾਂ timeout ਆਏ ਤਾਂ ਹੋਲਡ ਹਟਾ ਦੇ
• Convert to sold: ਜਦ ਭੁਗਤਾਨ ਪੁਸ਼ਟੀ ਹੋਵੇ ਤਾਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਨੂੰ ਫਾਈਨਲ ਕਰੋ
• Fail safely: ਜੇ ਤੁਸੀਂ ਯਕੀਨੀ ਨਹੀਂ ਹੋ, ਤਾਂ sold ਨਾ ਮਾਰਕ ਕਰੋ
• Reconcile: ਅੱਕ-ਚੱਕ ਮਿਲਾਪਾਂ ਨੂੰ ਮੈਨੁਅਲ ਜਾਂ ਨਿਯਮਤ ਜਾਂਚ ਨਾਲ ਠੀਕ ਕਰੋ

ਮੂਢੀ ਨਿਗਰਾਨੀ ਜੋੜੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਅਣਹੋਣੇ ਏਜਕੇਸ ਨੂੰ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇਖ ਸਕੋ। ਹਰ reserve, release, ਅਤੇ convert-to-sold ਇਵੈਂਟ ਨੂੰ order ID, ਕਾਰਨ (timeout, cancel, payment success), ਟਾਈਮਸਟੈਂਪ, ਅਤੇ ਪਹਿਲਾਂ-ਅਤੇ-ਬਾਅਦ ਦੀ ਮਾਤਰਾ ਨਾਲ ਲੌਗ ਕਰੋ।

ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਓ, ਫਿਰ ਕਠੋਰ ਕਰੋ

ਜੇ ਤੁਹਾਨੂੰ ਇਹ ਫਲੋ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ Koder.ai ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ states ਨੂੰ ਚੈਟ 'ਚ ਮੈਪ ਕਰੋ, ਰਿਜ਼ਰਵੇਸ਼ਨ ਅਤੇ timeout ਲਾਜਿਕ ਜਨਰੇਟ ਕਰੋ, ਅਤੇ ਫਿਰ ਡਿਪਲੌਇਮੈਂਟ ਲਈ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰੋ। ਮੁੱਖ ਗੱਲ ਕੋਈ ਸ਼ਾਨਦਾਰ ਟੂਲ ਨਹੀਂ, ਬਲਕਿ ਨਿਯਮਾਂ ਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਲਗਾਤਾਰ ਰੱਖਣਾ ਅਤੇ ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਹਰ ਜਗ੍ਹਾ ਲਾਗੂ ਕਰਨਾ ਹੈ ਜਿੱਥੇ ਚੈੱਕਆਊਟ ਇਨਵੈਂਟਰੀ ਨੂੰ ਛੁਹਦਾ ਹੈ।