15 ਨਵੰ 2025·8 ਮਿੰਟ
ਕੂਪਨ ਲਾਜ਼ਿਕ ਦੀਆਂ ਖਾਮੀਆਂ: ਸਟੈਕਿੰਗ ਨਿਯਮ ਜੋ ਕਾਰਟ ਨਹੀਂ ਖਰਾਬ ਕਰਦੇ
ਕੂਪਨ ਲਾਜ਼ਿਕ ਦੀਆਂ ਖਾਮੀਆਂ ਚੈੱਕਆਊਟ ਕੁੱਲਾਂ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਡਬਲ ਛੂਟ, ਨਕਾਰਾਤਮਕ ਟੋਟਲ ਅਤੇ ਹੋਰ ਗਲਤੀਆਂ ਰੋਕਣ ਲਈ ਸਟੈਕਿੰਗ ਨਿਯਮ, ਐਕਸਕਲੂਜ਼ਨ ਅਤੇ ਟੈਸਟ ਕਰਨ ਯੋਗ ਪੈਟਰਨ ਸਿੱਖੋ।
ਪ੍ਰੋਮੋ ਲਾਜ਼ਿਕ ਇਸਤੋਂ ਅਕਸਰ ਕਿਉਂ ਟੁਟਦੀ ਹੈ
ਪ੍ਰੋਮੋ ਆਸਾਨ ਲੱਗਦੇ ਹਨ - ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਅਸਲੀ ਚੈੱਕਆਊਟ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦੇ। ਕਾਰਟ ਹਮੇਸ਼ਾਂ ਬਦਲਦਾ ਹੈ, ਪਰ ਛੂਟ ਅਕਸਰ ਇਕ-ਵਾਰੀ ਨਿਯਮਾਂ ਵਜੋਂ ਲਿਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਇਹੀ ਉਹ ਵਿਰਾਨੀ ਹੈ ਜਿੱਥੇ ਸਾਰੀਆਂ ਕੂਪਨ ਲਾਜ਼ਿਕ ਦੀਆਂ ਖਾਮੀਆਂ ਆਉਂਦੀਆਂ ਹਨ।
ਮੁਸ਼ਕਲ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਕ ਨਵਾਂ ਨਿਯਮ ਹੀ ਹਰ ਥਾਂ ਟੋਟਲ ਬਦਲ ਸਕਦਾ ਹੈ। “10% ਛੂਟ, ਪਰ sale ਆਈਟਮਾਂ 'ਤੇ ਨਹੀਂ” ਜੋੜੋ ਅਤੇ ਤੁਹਾਨੂੰ ਫੈਸਲਾ ਕਰਨਾ ਪਵੇਗਾ ਕਿ “sale” ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਕਦੋਂ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ 10% ਕਿਸ ਰਕਮ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਜੇ ਹੋਰ ਕੋਈ ਪ੍ਰੋਮੋ ਵੀ ਉਹੀ ਆਈਟਮਾਂ ਛੂਹਦਾ ਹੈ ਤਾਂ ਕ੍ਰਮ ਮਤਲਬ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਕ੍ਰਮ ਚੰਗੀ ਕੀਮਤ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਕਈ ਟੀਮਾਂ ਗਣਿਤ ਨੂੰ ਬਿਜਨਸ ਨਿਯਮਾਂ ਨਾਲ ਮਿਕਸ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। "ਛੂਟ ਨੂੰ subtotal 'ਤੇ cap ਕਰੋ" ਵਰਗਾ ਇੱਕ ਚੱਲਦਾ ਫਿਕਸ ਤੀਨ ਥਾਵਾਂ ਤੇ ਕਾਪੀ ਹੋ ਜਾਂਦਾ ਹੈ, ਤੇ ਜਲਦੀ ਹੀ ਤੁਹਾਡੇ ਕੋਲ ਵੱਖ-ਵੱਖ ਜਵਾਬ ਹੋ ਜਾਂਦੇ ਹਨ (ਕਾਰਟ ਪੰਨਾ, ਚੈੱਕਆਊਟ, ਇਨਵੌਇਸ, ਈਮੇਲ)।
ਉੱਚ-ਖਤਰੇ ਦੇ ਸਮੇਂ ਉਹ ਹਨ ਜਦੋਂ ਤੁਹਾਡੀ ਸਿਸਟਮ ਮੁਲਾਂਕਣ ਦੁਬਾਰਾ ਕਰਦੀ ਹੈ:
- ਕਾਰਟ ਅਪਡੇਟ: ਮਾਤਰਾ ਬਦਲਣਾ, ਆਈਟਮ ਹਟਾਉਣਾ, ਸ਼ਿਪਿੰਗ ਮੈਥਡ ਬਦਲਣਾ
- ਭੁਗਤਾਨ ਤੋਂ ਬਾਅਦ ਸੰਪਾਦਨ: ਪਤਾ ਬਦਲਣਾ, ਹਿੱਸੇਵਾਰ ਰੱਦ, ਆਈਟਮ ਦੀ ਥਾਂ ਬਦਲਣਾ
- ਰੀਫੰਡ ਅਤੇ ਰਿਟਰਨ: ਆਈਟਮਾਂ ਵਿੱਚ ਪ੍ਰੋਰੇਟਿੰਗ, ਟੈਕਸ ਅਨੁਕੂਲਣਾ, ਸਟੋਰ ਕ੍ਰੈਡਿਟ
- ਬਹੁ-ਮੁਦਰਾ ਜਾਂ ਟੈਕਸ ਮੋਡ ਬਦਲ: ਨੈੱਟ ਵੱਖਰੇ ਗ੍ਰੋਸ, ਟੈਕਸ-ਇੰਕਲੂਸਿਵ ਟੋਟਲ
ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ: ਖਰੀਦਦਾਰ ਇੱਕ ਬੰਡਲ ਜੋੜਦਾ ਹੈ, ਫਿਰ “$20 off $100” ਕੋਡ ਲਗਾਂਦਾ ਹੈ, ਫਿਰ ਇੱਕ ਆਈਟਮ ਹਟਾਂਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਲੌਜਿਕ ਪੁਰਾਣੇ subtotal ਨੂੰ "ਯਾਦ" ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ $85 ਵਾਲੇ ਕਾਰਟ 'ਤੇ ਵੀ $20 ਛੂਟ ਦੇ ਸਕਦੇ ਹੋ, ਜਾਂ ਆਈਟਮ ਲਾਈਨ ਨੂੰ ਨੈਗੇਟਿਵ ਤੱਕ ਲੈ ਜਾ ਸਕਦੇ ਹੋ।
ਇਸ ਪੋਸਟ ਦੇ ਅੰਤ ਤੱਕ, ਤੁਸੀਂ ਅਕਸਰ ਮਿਲਣ ਵਾਲੀਆਂ ਪ੍ਰੋਮੋ ਫੇਲੀਆਂ ਰੋਕ ਸਕੋਗੇ: ਡਬਲ-ਛੂਟ, ਸਕ੍ਰੀਨਾਂ ਵਿਚੋਂ ਬੇਮਿਲ ਟੋਟਲ, ਨੈਗੇਟਿਵ ਟੋਟਲ, ਐਕਸਕਲੁਡ ਕੀਤੇ ਆਈਟਮਾਂ 'ਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲੀ ਛੂਟ ਅਤੇ ਉਹ ਰਿਫੰਡ ਜੋ ਗਾਹਕ ਨੇ ਅਸਲ ਵਿੱਚ ਭੁਗਤਾਨ ਕੀਤੇ ਦੇ ਸਮਰੂਪ ਨਹੀਂ ਹੁੰਦੇ।
ਸਾਫ਼ ਸਟੈਕਿੰਗ ਅਤੇ ਪ੍ਰਾਥਮਿਕਤਾ ਨਿਯਮਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ
ਜ਼ਿਆਦਾਤਰ ਕੂਪਨ ਲਾਜ਼ਿਕ ਦੀਆਂ ਖਾਮੀਆਂ ਇਕ ਗੁੰਮ ਹੋਈ ਪਰਾਏ ਦਾ ਨਤੀਜਾ ਹੁੰਦੀਆਂ ਹਨ: ਕਿਹੜੀਆਂ ਛੂਟ ਇਕੱਠੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ। ਜੇ ਤੁਸੀਂ ਸਟੈਕਿੰਗ ਨਿਯਮ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ ਤਾਂ ਤੁਹਾਡਾ ਕਾਰਟ ਆਖਿਰਕਾਰ ਹੈਰਾਨ ਕਰਨ ਵਾਲਾ ਕੰਮ ਕਰੇਗਾ।
ਸਟੈਕਿੰਗ ਨੂੰ ਸਧਾਰਨ ਹਾਂ ਜਾਂ ਨਾ ਬਿਆਨਾਂ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਉਦਾਹਰਨ ਲਈ: “ਇਕ ਆਰਡਰ 'ਤੇ ਇੱਕ ਮੈਨੁਅਲ ਕੂਪਨ। ਆਟੋਮੈਟਿਕ ਪ੍ਰੋਮੋ ਜਦ ਤੱਕ ਕੂਪਨ ਖੁਦ ਨਹੀਂ ਕਹਿੰਦਾ, ਲਾਗੂ ਹੋ ਸਕਦੇ ਹਨ।” ਇਹ ਇਕ ਫ੍ਰੇਜ਼ ਰੈਂਡਮ ਮਿਲਾਵਟਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਡਬਲ-ਛੂਟ ਤੱਕ ਲੈ ਜਾਂਦਾ ਹੈ।
ਆਈਟਮ-ਸਤਰ ਛੂਟਾਂ ਨੂੰ ਆਰਡਰ-ਸਤਰ ਛੂਟਾਂ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਵੱਖਰਾ ਕਰੋ। ਆਈਟਮ-ਸਤਰ ਨਿਯਮ ਖਾਸ ਉਤਪਾਦਾਂ ਦੀ ਕੀਮਤ ਬਦਲਦੇ ਹਨ (ਜਿਵੇਂ 20% off ਜੁੱਤਿਆਂ 'ਤੇ)। ਆਰਡਰ-ਸਤਰ ਨਿਯਮ ਕੁੱਲ ਨੂੰ ਬਦਲਦੇ ਹਨ (ਜਿਵੇਂ $10 off ਕਾਰਟ)। ਬਿਨਾਂ ਬਣਤਰ ਦੇ ਮਿਕਸ ਹੋ ਜਾਣ ਨਾਲ ਹੀ ਕੀਮਤਾਂ ਉਤਪਾਦ ਪੰਨਾ, ਕਾਰਟ ਅਤੇ ਚੈੱਕਆਊਟ ਵਿਚ ਦਿਖਾਈ ਦੇ ਰਹੀਆਂ ਕੀਮਤਾਂ ਵਿੱਚ ਦੰਡਯਾਨ ਆ ਜਾਂਦਾ ਹੈ।
"ਬਿਹਤਰ ਡੀਲ" ਦਾ ਮਤਲਬ ਕੋਡਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲ ਕਰ ਲਓ। ਕਈ ਟੀਮਾਂ “ਅਧਿਕਤਮ ਬਚਤ” ਚੁਣਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਕੀਮਤ ਫਲੋਰ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਹਲੇ-ਹਲੇ ਨਿਯਮਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਜਿਵੇਂ “ਕਦੇ ਵੀ ਲਾਗਤ ਤੋਂ ਥੱਲੇ ਛੂਟ ਨਾ ਦਿਓ” ਜਾਂ “ਕਦੇ ਵੀ ਸ਼ਿਪਿੰਗ ਨੈਗੇਟਿਵ ਨਾ ਬਣਾਓ।” ਇਕ ਸਾਫ਼ ਜਿੱਤਣ ਵਾਲਾ ਨਿਯਮ ਚੁਣੋ ਤਾਂ ਕਿ ਇੰਜਣ ਅਨੁਮਾਨ ਨਾ ਲਗਾਏ।
ਇਕ ਸਧਾਰਨ ਪ੍ਰਾਥਮਿਕਤਾ ਕ੍ਰਮ ਟਕਸਾਲੀ ਝਗੜਿਆਂ ਨੂੰ ਅਣਮੁੱਤ ਰੱਖਦਾ ਹੈ:
- ਆਟੋਮੈਟਿਕ ਪ੍ਰੋਮੋ ਪਹਿਲਾਂ (ਕੈਟਾਲੌਗ ਜਾਂ ਸੀਜ਼ਨਲ ਨਿਯਮ)
- ਮੈਨੁਅਲ ਕੂਪਨ ਅੱਗੇ (ਗਾਹਕ ਜੋ ਦਰਜ ਕਰਦਾ)
- ਸਟੋਰ ਕ੍ਰੈਡਿਟ ਜਾਂ ਗਿਫਟ ਕਾਰਡ ਆਖਿਰ
- ਟੈਕਸ ਅਤੇ ਸ਼ਿਪਿੰਗ ਛੂਟਾਂ ਦੇ ਬਾਅਦ ਦੁਬਾਰਾ ਗਣਨਾ
ਉਦਾਹਰਨ: ਇੱਕ ਕਾਰਟ 'ਤੇ ਸਾਰੇ ਆਈਟਮਾਂ 'ਤੇ 10% ਆਟੋਮੈਟਿਕ ਪ੍ਰੋਮੋ ਹੈ, ਨਾਲ ਇੱਕ $15 off $100 ਉਤੇ typed coupon। ਜੇ ਤੁਹਾਡੀ ਪ੍ਰਾਥਮਿਕਤਾ ਆਟੋਮੈਟਿਕ ਨੂੰ ਪਹਿਲਾਂ ਕਹਿੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਪਸ਼ਟ ਤੌਰ ਤੇ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ: $100 ਵਾਲੀ ਮਿਆਦ ਪ੍ਰੀ-ਡਿਸਕਾਉਂਟ subtotal 'ਤੇ ਦੇਖੀ ਜਾਂ ਡਿਸਕਾਉਂਟਡ subtotal 'ਤੇ? ਇਹ ਲਿਖੋ, ਫਿਰ ਹਰ ਥਾਂ ਇਹੀ ਰੀਤੀ ਰੱਖੋ।
ਇਹ ਫੈਸਲੇ ਲਿਖ ਕੇ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਹਾਡੇ ਕੂਪਨ ਸਟੈਕਿੰਗ ਨਿਯਮ ਟੈਸਟ ਕਰਨਯੋਗ ਨਿਯਮ ਬਣ ਜਾਣ। ਇਹ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਭਵਿੱਖ ਦੀਆਂ ਖਾਮੀਆਂ ਰੋਕਣ ਦਾ।
ਛੂਟਾਂ ਨੂੰ ਸਧਾਰਨ, ਸਪਸ਼ਟ ਡੇਟਾ ਵਜੋਂ ਮਾਡਲ ਕਰੋ
ਕਈ ਕੂਪਨ ਲਾਜ਼ਿਕ ਖਾਮੀਆਂ ਉਸ ਵੇਲੇ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਛੂਟਾਂ ਚੈਕਆਊਟ ਕੋਡ ਵਿੱਚ ਵੱਖ-ਵੱਖ if-else ਸ਼ਾਖਾਂ ਵੱਲ ਛਿੜਕੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਠੀਕ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਹਰ ਇੱਕ ਪ੍ਰੋਮੋ ਨੂੰ ਡੇਟਾ ਵਜੋਂ ਰੱਖੋ ਜਿਸ ਵਿੱਚ ਸਪਸ਼ਟ ਕਿਸਮ, ਸਕੋਪ ਅਤੇ ਸੀਮਾਵਾਂ ਹੋਣ। ਫਿਰ ਤੁਹਾਡੀ ਕਾਰਟ ਗਣਿਤ ਇੱਕ ਛੋਟਾ, ਪੇਸ਼ੀਨਾਕ ਅਤੇ ਪੇਸ਼ੀਗੋਏ ਇਵੈਲਯੂਏਟਰ ਬਣ ਜਾਵੇਗੀ।
ਸ਼ੁਰੂਆਤ ਇਸ ਗੱਲ ਨਾਲ ਕਰੋ ਕਿ ਛੂਟ ਦੀ ਕਿਸਮ ਦਾ ਨਾਮ ਲਓ, ਮਾਰਕੀਟਿੰਗ ਦੇ ਆਈਡੀਆ ਦੀ ਨਹੀਂ। ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਮੋ ਕੁਝ ਆਕਾਰਾਂ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੇ ਹਨ: ਪ੍ਰਤੀਸ਼ਤ ਛੂਟ, ਨਿਸ਼ਚਿਤ ਰਕਮ ਦੀ ਛੂਟ, ਮੁਫ਼ਤ ਆਈਟਮ (buy X get Y), ਅਤੇ ਮੁਫ਼ਤ ਸ਼ਿਪਿੰਗ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰੋਮੋ ਨੂੰ ਇਨ੍ਹਾਂ ਕਿਸਮਾਂ ਨਾਲ ਵਿਅਕਤ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਵਿਸ਼ੇਸ਼ ਕੇਸਾਂ ਤੋਂ ਬਚ ਗੇ ਜੋ ਟੈਸਟ ਕਰਨਾ ਮੁਸ਼ਕਿਲ ਹੁੰਦੇ ਹਨ।
ਅਗਲਾ ਕਦਮ: ਸਕੋਪ ਸਪਸ਼ਟ ਬਣਾਓ। ਇੱਕੋ ਪ੍ਰਤੀਸ਼ਤ-ਛੂਟ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਇਹ ਇਸਗੱਲ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਕਿਸ ਨੂੰ ਲੱਗਦਾ ਹੈ। ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਇਹ ਪੂਰੇ ਆਰਡਰ ਨੂੰ ਲਾਗੂ ਹੁੰਦਾ, ਕਿਸੇ ਸ਼੍ਰੇਣੀ ਨੂੰ, ਉਤਪਾਦ ਨੂੰ, ਇਕ ਇਕਾਈ ਲਾਈਨ ਨੂੰ ਜਾਂ ਸ਼ਿਪਿੰਗ ਨੂੰ। ਜੇ ਸਕੋਪ ਅਸਪਸ਼ਟ ਹੈ ਤਾਂ ਤੁਸੀਂ ਗਲਤ subtotal 'ਤੇ ਛੂਟ ਲਾਓਗੇ ਜਾਂ ਦੋ ਵਾਰੀ ਛੂਟ ਹੋ ਜਾਵੇਗੀ।
ਸੀਮਾਵਾਂ ਨੂੰ ਫਾਈਲਡ ਵਜੋਂ ਰੱਖੋ, ਨਾ ਕਿ ਕੋਡ ਕਮੈਂਟ ਵਜੋਂ। ਆਮ ਸੀਮਾਵਾਂ ਹਨ: ਨਿਣਮਾਨਕ ਖਰਚ, ਪਹਿਲਾ ਆਰਡਰ ਹੀ ਲਾਗੂ, ਅਤੇ ਦਿਤੀ ਮਿਆਦ। ਇਹ ਵੀ ਦਰਜ ਕਰੋ ਕਿ ਇਹ ਸੇਲ ਕੀਮਤਾਂ ਨਾਲ ਕਿਵੇਂ ਵਰਤਣਾ: ਉੱਤੇ ਸਟੈਕ ਕਰੇ, ਲਿਸਟ ਕੀਮਤ 'ਤੇ ਲਾਗੂ ਹੋਵੇ, ਜਾਂ ਸੇਲ ਕੀਮਤਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖੇ।
ਇੱਕ ਸੰਕੁਚਿਤ ਨਿਯਮ ਸਕੀਮਾ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ:
- type (percent, fixed, free_item, free_shipping)
- scope (order, category, product, item, shipping)
- constraints (min_spend, first_order, start_at, end_at)
- floors (min_total = 0, min_item_price, optional min_margin)
- rounding policy (per item vs per order)
ਅੰਤ ਵਿੱਚ, ਉਹ ਮੁੱਲ-ਫਲੋਰ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਇੰਜਣ ਹਮੇਸ਼ਾ ਮੰਨੇ: ਟੋਟਲ ਕਦੇ ਵੀ ਜ਼ੀਰੋ ਤੋਂ ਥੱਲੇ ਨਹੀਂ ਜਾਣੇ ਚਾਹੀਦੇ, ਅਤੇ ਜੇ ਤੁਹਾਡੇ ਬਿਜਨਸ ਨੂੰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਆਈਟਮ ਕਦੇ ਵੀ ਲਾਗਤ ਤੋਂ ਥੱਲੇ ਨਹੀਂ ਜਾਣੇ (ਜਾਂ ਪਰਿਭਾਸ਼ਿਤ ਘੱਟੋ-ਘੱਟ ਕੀਮਤ)। ਇਹ ਬਣਾਉਣ ਨਾਲ ਤੁਸੀਂ ਨੈਗੇਟਿਵ ਟੋਟਲ ਅਤੇ ਓਸੇ ਐਜਕੇਸ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ ਕਿ ਅਸੀਂ ਗਾਹਕ ਨੂੰ ਪੈਸਾ ਦੇ ਰਹੇ ਹਾਂ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਇੱਕ ਡਿਸਕਾਉਂਟ ਇੰਜਣ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਆਪਣੇ ਪਲੈਨਿੰਗ ਮੋਡ ਵਿੱਚ ਇਹ ਫੀਲਡ ਦਿਸਪਲੇ करो ਤਾਂ ਕਿ ਜਿਵੇਂ ਤੁਹਾਨੂੰ ਹੋਰ ਪ੍ਰੋਮੋ ਜ਼ੋੜਦਿਆਂ ਇਵੈਲਯੂਏਟਰ ਸਧਾਰਨ ਅਤੇ ਟੈਸਟ ਕਰਨਯੋਗ ਰਹੇ।
ਕਦਮ-ਦਰ-कਦਮ: ਪ੍ਰੋਮੋ ਆਸਾਨੀ ਨਾਲ ਮੁਲਾਂਕਣ ਕਰਨ ਦਾ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ
ਜ਼ਿਆਦਾਤਰ ਕੂਪਨ ਲਾਜ਼ਿਕ ਦੀਆਂ ਖਾਮੀਆਂ ਉਦੋਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਯੋਗਤਾ ਦੀ ਜਾਂਚ ਅਤੇ ਗਣਿਤ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਦੋ-ਫੇਜ਼ ਦਾ ਹੈ: ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਲਾਗੂ ਹੋ ਸਕਦਾ ਹੈ, ਫਿਰ ਰਕਮਾਂ ਦੀ ਗਣਨਾ ਕਰੋ। ਇਹ ਵੱਖ-ਵੱਖਤਾ ਨਿਯਮਾਂ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਰੱਖਦੀ ਹੈ ਅਤੇ ਗਲਤ ਹਾਲਤਾਂ (ਜਿਵੇਂ ਨੈਗੇਟਿਵ ਟੋਟਲ) ਨੂੰ ਰੋਕਣਾ ਆਸਾਨ ਬਣਾ ਦਿੰਦੀ ਹੈ।
ਇੱਕ ਨਿਰਣਾਇਕ ਇਵੈਲਯੂਏਸ਼ਨ ਕ੍ਰਮ
ਹਮੇਸ਼ਾ ਇੱਕੋ ਕ੍ਰਮ ਵਰਤੋ, ਭਾਵੇਂ UI ਜਾਂ API ਵੱਲੋਂ ਪ੍ਰੋਮੋ ਵੱਖ-ਵੱਖ ਕ੍ਰਮ ਵਿੱਚ ਆ ਰਹੇ ਹੋਣ। ਨਿਰਣਾਇਕਤਾ ਇਸ ਲਈ ਜਰੂਰੀ ਹੈ ਕਿ ਇਹ "ਇਹ ਕਾਰਟ ਕਿਉਂ ਬਦਲਿਆ?" ਨੂੰ ਇੱਕ ਜਵਾਬਯੋਗ ਸਵਾਲ ਬਣਾਂਦੀ ਹੈ।
ਇਕ ਸਧਾਰਨ ਫਲੋ ਜੋ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:
- Validate ਇਨਪੁੱਟ: ਪ੍ਰੋਮੋ ਕੋਡ ਫਾਰਮੈਟ, ਮਿਆਦ, ਗਾਹਕ ਸਕੋਪ, ਮੁਦਰਾ, ਅਤੇ ਕੀਮਤਾਂ ਨਾਨ-ਨੇਗੇਟਿਵ ਹਨ।
- Select eligible promos: ਸਿਰਫ ਯੋਗਤਾ ਚਲਾਓ (ਹੋਣ ਵਾਲੀ ਰਕਮ ਨਹੀਂ)। ਉਮੀਦਵਾਰਾਂ ਦੀ ਲਿਸਟ ਬਣਾਓ।
- Resolve stacking and priority: ਆਪਣੇ ਸਟੈਕਿੰਗ ਨਿਯਮ ਲਗਾਓ (ਉਦਾਹਰਣ: "ਇੱਕ ਆਰਡਰ-ਸਤਰ ਪ੍ਰੋਮੋ ਵੱਧ ਤੋਂ ਵੱਧ") ਅਤੇ ਟਾਈ-ਬ੍ਰੇਕਰ (ਪ੍ਰਾਇਰਟੀ, ਫਿਰ ਵਧੀਆ ਮੁੱਲ, ਫਿਰ ਸਥਿਰ ID)।
- Apply calculations: ਇੱਕ ਲਗਾਤਾਰ ਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਛੂਟਾਂ ਦੀ ਗਣਨਾ ਕਰੋ (ਪ੍ਰੀ-ਟੈਕਸ ਵਸ੍ਤੁਂਗਤ ਜਾਂ ਪੋਸਟ-ਟੈਕਸ, ਸ਼ਿਪਿੰਗ ਸ਼ਾਮਿਲ ਹੈ ਜਾਂ ਨਹੀਂ) ਅਤੇ ਰਾਊਂਡਿੰਗ ਨੀਤੀਆਂ ਲਗਾਓ।
- Summarize totals: ਲਾਈਨ ਟੋਟਲ ਤੋਂ ਆਰਡਰ ਟੋਟਲ ਦੁਬਾਰਾ ਗਣਨਾ ਕਰੋ, ਫਿਰ ਜ਼ੀਰੋ ਤੇ ਕੈਪ ਕਰੋ ਅਤੇ ਮੈਕਸ ਛੂਟ ਸੀਮਾਵਾਂ ਠੋਵਾਂ।
ਬ੍ਰੇਕਡਾਊਨ ਅਤੇ ਆਡਿਟ ਟ੍ਰੇਲ ਟਰੈਕ ਕਰੋ
ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰੋਮੋ ਲਾਗੂ ਕਰਦੇ ਹੋ, ਸਿਰਫ ਇਕ ਹੋਰ "ਛੂਟ ਕੁੱਲ" ਨਹੀਂ ਸਟੋਰ ਕਰੋ। ਇੱਕ ਲਾਈਨ ਆਈਟਮ ਅਤੇ ਆਰਡਰ ਪੱਧਰ 'ਤੇ ਬ੍ਰੇਕਡਾਊਨ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਟੋਟਲਾਂ ਨੂੰ ਮਿਲਾ ਸਕੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਿਆਖਿਆ ਕਰ ਸਕੋ।
ਘੱਟੋ-ਘੱਟ ਦਰਜ ਕਰੋ:
- ਕਿਹੜਾ ਨਿਯਮ ਜਾਂ ਪ੍ਰੋਮੋ ਲਾਗੂ ਹੋਇਆ (ID ਅਤੇ ਵਰਜ਼ਨ), ਅਤੇ ਇਸ ਦੀ ਪ੍ਰਾਇਰਟੀ
- ਇਹ ਕਿਉਂ ਲਾਗੂ ਹੋਇਆ (ਯੋਗਤਾ ਤੱਥ ਜਿਵੇਂ "category=shoes", "cart subtotal >= 50")
- ਇਸਨੇ ਕੀ ਬਦਲਿਆ (ਚੋਟੇ ਲਾਈਨ IDs, ਬੇਸ ਰਕਮ, ਛੂਟ ਰਕਮ, ਰਾਊਂਡਿੰਗ)
- ਇਹਨੇ ਕੀ ਰੋਕਿਆ (ਉਦਾਹਰਨ: "blocked by exclusion: already has item-level discount")
ਉਦਾਹਰਨ: ਇੱਕ ਕਾਰਟ ਵਿੱਚ ਦੋ ਆਈਟਮ ਹਨ, ਇੱਕ ਪਹਿਲਾਂ ਹੀ sale 'ਤੇ ਹੈ। ਫੇਜ਼ 1 ਕੋਡ ਨੂੰ ਸਿਰਫ ਫੁੱਲ-ਪ੍ਰਾਈਸ ਆਈਟਮ ਲਈ ਯੋਗ ਮਾਰਕ ਕਰਦਾ ਹੈ। ਫੇਜ਼ 2 ਉਸ ਲਾਈਨ 'ਤੇ 10% ਲਾਗੂ ਕਰਦਾ ਹੈ, sale ਲਾਈਨ ਨੂੰ ਬਦਲਦਾ ਨਹੀਂ, ਫਿਰ ਲਾਈਨ ਬ੍ਰੇਕਡਾਊਨ ਤੋਂ ਆਰਡਰ ਟੋਟਲ ਦੁਬਾਰਾ ਗਣਨਾ ਕਰਦਾ ਤਾਂ ਜੋ ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ ਦੋਹਰਾ-ਛੂਟ ਨਾ ਕਰਵਾਓ।
ਇਕੱਠੇ ਸੰਕਲਨ ਬਿਨਾਂ ਸਪੈਘੇੱਟੀ ਲਾਜ਼ਿਕ ਦੇ ਇਨਕਲੂਡ ਕਰੋ
Keep full source control
Export the source code so your team can review the discount engine and extend it later.
ਜ਼ਿਆਦਾਤਰ ਕੂਪਨ ਲਾਜ਼ਿਕ ਦੀਆਂ ਖਾਮੀਆਂ ਉਦੋਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਬਾਹਰ ਰਹਿਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਖਾਸ-ਕੇਸ ਵਾਲੀਆਂ ਸ਼ਾਖਾਂ ਵਿੱਚ ਛਿਪੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਵੇਂ "if code is X, skip Y." ਇਕ ਪ੍ਰੋਮੋ ਲਈ ਇਹ ਚੱਲ ਜਾਂਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਦੂਜਾ ਪ੍ਰੋਮੋ ਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਟੁਟ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਇਹ ਹੈ: ਇੱਕੋ ਇਵੈਲਯੂਏਸ਼ਨ ਫਲੋ ਰੱਖੋ, ਅਤੇ ਬਾਹਰ-ਰਹਿਣੀਆਂ ਇੱਕ ਤੱਤ ਦੇ ਰੂਪ ਵਿੱਚ ਰੱਖੋ ਜੋ ਪ੍ਰੋਮੋ ਕੰਬੋ ਨੂੰ ਹਿਸਾਬ ਵਿੱਚ ਦੱਸ ਸਕਦਾ ਹੈ, ਫਿਰ ਤੁਸੀਂ ਕਿਸੇ ਪ੍ਰੋਮੋ ਨੂੰ ਅਧ-ਲਾਗੂ ਨਹੀਂ ਦੇਖੋਗੇ।
ਰੋਕਾਂ ਨੂੰ ਡੇਟਾ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ, ਬਰਾਂਚਿੰਗ ਵਜੋਂ ਨਹੀਂ
ਹਰ ਪ੍ਰੋਮੋ ਨੂੰ ਇੱਕ ਛੋਟਾ, ਸਪਸ਼ਟ "compatibility profile" ਦਿਉ: ਉਦਾਹਰਨ ਵਜੋਂ ਪ੍ਰੋਮੋ ਕਿਸਮ (coupon vs automatic sale), ਸਕੋਪ (items, shipping, order), ਅਤੇ ਕੰਬੀਨੇਸ਼ਨ ਨਿਯਮ।
ਦੋਨੋਂ ਸਹਿਯੋਗ ਕਰੋ:
- “Cannot combine with” ਲਿਸਟ (denylist): ਪ੍ਰੋਮੋ A ਪ੍ਰੋਮੋ B ਨੂੰ ਬਲੌਕ ਕਰਦਾ ਹੈ।
- “Only combine with” ਲਿਸਟ (allowlist): ਪ੍ਰੋਮੋ A ਸਿਰਫ ਨਾਂਮੀਤ ਸਮੂਹ ਨਾਲ ਹੀ ਸਟੈਕ ਹੋ ਸਕਦਾ ਹੈ।
- ਨਿਯਮ ਫਲੈਗ ਜਿਵੇਂ "blocks automatic sales" ਜਾਂ "requires no other coupons."
ਕੀਮਤੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇੰਜਣ ਹਰ ਪ੍ਰੋਮੋ ਲਈ ਇਕੋ ਸਵਾਲ ਪੁੱਛੇ, ਫਿਰ ਇਹ ਫੈਸਲਾ ਕਰੇ ਕਿ ਸੈੱਟ ਵੈਧ ਹੈ ਜਾਂ ਨਹੀਂ।
ਟੱਕਰਾਂ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ, ਆਟੋ ਸੇਲਾਂ ਸਮੇਤ
ਆਟੋਮੈਟਿਕ ਸੇਲਾਂ ਅਕਸਰ ਪਹਿਲਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ, ਫਿਰ ਕੋਈ ਕੂਪਨ ਆ ਕੇ ਚੁੱਪਚਾਪ ਉਹਨਾਂ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰ ਦਿੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਹੀ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
- ਕੂਪਨ ਸੇਲ 'ਤੇ ਸਟੈਕ ਕਰੇ
- ਕੂਪਨ ਸੇਲ-ਆਈਟਮਾਂ 'ਤੇ ਹੀ ਲਾਗੂ ਹੋਵੇ
- ਜੇ ਸੇਲ ਮੌਜੂਦ ਹੈ ਤਾਂ ਕੂਪਨ ਰੱਦ ਹੋ ਜਾਵੇ
ਹਰ ਪ੍ਰੋਮੋ ਲਈ ਇੱਕ ਚੋਣ ਚੁਣੋ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਜਾਂਚ ਵਜੋਂ ਇੰਕੋਡ ਕਰੋ, ਨਾ ਕਿ ਵੱਖਰੀ ਗਣਨਾ ਵਾਲੇ ਰਸਤੇ ਵਜੋਂ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਹੈ ਵੈਧਤਾ ਦੀ ਸਮਰੂਪਤਾ ਜਾਂਚਣਾ। ਜੇ "WELCOME10 cannot combine with FREESHIP" ਦੋ-ਪਾਸੇ ਦਾ ਮਤਲਬ ਹੈ, ਤਾਂ ਦੋਹਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਬਲੌਕ ਐਨਕੋਡ ਕਰੋ। ਜੇ ਇਹ ਦੋਹਰਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਨਿਰਧਾਰਿਤ ਅਤੇ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਹੋਵੇ।
ਉਦਾਹਰਨ: ਇੱਕ ਸਾਈਟਵਾਈਡ 15% ਆਟੋਮੈਟਿਕ ਸੇਲ ਚੱਲ ਰਹੀ ਹੈ। ਗਾਹਕ 20% ਕੂਪਨ ਦਰਜ ਕਰਦਾ ਹੈ ਜੋ ਸਿਰਫ ਫੁੱਲ-ਪ੍ਰਾਈਸ ਆਈਟਮਾਂ ਲਈ ਹੈ। ਤੁਹਾਡੀਆਂ ਜਾਂਚਾਂ ਕੂਪਨ ਲਈ ਸੇਲ ਆਈਟਮਾਂ ਨੂੰ ਪਹਿਲਾਂ ਰੱਦ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਬਦਕਿਸਮਤੀ ਨਾਲ ਛੂਟ ਲਗਾਉਣ ਅਤੇ ਫਿਰ ਨੰਬਰ ਠੀਕ ਕਰਨ ਦੀ ਥਾਂ।
ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਨਿਯਮ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਜਾਂਚਾਂ ਇੱਕ ਵੱਖਰੀ, ਟੈਸਟ ਕਰਨਵਾਲੀ ਲੇਅਰ ਵਜੋਂ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਗਣਿਤ ਬਦਲੇ ਬਿਨਾਂ ਨਿਯਮ ਬਦਲ ਸਕੋ।
ਐජ ਕੇਸ ਜੋ ਮਿਲੇ-ਟੋਟਲ ਵਿੱਚ ਫਰਕ ਪੈਦਾ ਕਰਦੇ ਹਨ
ਜਿਆਦਾਤਰ ਕੂਪਨ ਵਿਵਾਦ ਸਿਰਲੇਖ ਛੂਟ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਉਦੋਂ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਇੱਕੋ ਕਾਰਟ ਦੋ ਥੋੜ੍ਹਾ-ਭਿੰਨ ਤਰੀਕਿਆਂ ਨਾਲ ਗਣਨਾ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਗਾਹਕ ਨੂੰ ਕਾਰਟ ਵਿੱਚ ਇੱਕ ਨੰਬਰ ਅਤੇ ਚੈੱਕਆਊਟ ਵਿੱਚ ਦੂਜਾ ਨੰਬਰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
ਆਪਣੇ ਓਪਰੈਸ਼ਨਾਂ ਦੇ ਕ੍ਰਮ ਨੂੰ ਲਾਕ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਦਸਤਾਵੇਜ਼ ਬਣਾਓ ਕਿ ਆਈਟਮ-ਸਤਰ ਛੂਟ ਆਰਡਰ-ਸਤਰ ਛੂਟ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦੇ ਹਨ ਜਾਂ ਉਲਟ — ਅਤੇ ਸ਼ਿਪਿੰਗ ਕਿੱਥੇ ਆਉਂਦੀ ਹੈ। ਇੱਕ ਆਮ ਨਿਯਮ: ਪਹਿਲਾਂ ਆਈਟਮ ਛੂਟ, ਫਿਰ ਬਾਕੀ subtotal 'ਤੇ ਆਰਡਰ ਛੂਟ, ਫਿਰ ਆਖਿਰ 'ਤੇ ਸ਼ਿਪਿੰਗ ਛੂਟ। ਜੋ ਵੀ ਚੋਣ ਕਰੋ, ਹਰ ਥਾਂ ਇੱਕੋ ਕ੍ਰਮ ਵਰਤੋ।
ਟੈਕਸ ਅਗਲਾ ਜਾਲ ਹੈ। ਜੇ ਤੁਹਾਡੀਆਂ ਕੀਮਤਾਂ ਟੈਕਸ-ਇੰਕਲੂਸਿਵ ਹਨ ਤਾਂ ਇੱਕ ਛੂਟ ਟੈਕਸ ਹਿੱਸਾ ਵੀ ਘਟਾਉਂਦੀ ਹੈ। ਜੇ ਕੀਮਤਾਂ ਟੈਕਸ-ਇਕਸਕਲੂਸਿਵ ਹਨ, ਟੈਕਸ ਛੂਟਾਂ ਤੋਂ ਬਾਅਦ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚ ਇਹ ਮਾਡਲ ਮਿਕਸ ਹੋ ਜਾਣਾ ਇੱਕ ਆਮ ਖਾਮੀ ਹੈ ਕਿਉਂਕਿ ਦੋ ਸਹੀ ਗਣਨਾਵਾਂ ਵੀ ਅਣਮਿਲ ਸਕਦੀਆਂ ਹਨ ਜੇ ਉਹ ਭਿੰਨ ਟੈਕਸ ਬੇਸ ਮੰਨ ਲੈਂਦੀਆਂ ਹਨ।
ਰਾਊਂਡਿੰਗ ਦੇ ਮਸਲੇ ਛੋਟੇ ਲੱਗਦੇ ਹਨ ਪਰ ਵੱਡੇ ਸਪੋਰਟ ਟਿਕਟ ਬਣਾਉਂਦੇ ਹਨ। ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਤੁਸੀਂ per-line ਆ ਰਾਊਂਡ ਕਰੋਂਗੇ ਜਾਂ ਸਿਰਫ ਆਰਡਰ-ਲੇਵਲ 'ਤੇ, ਅਤੇ ਆਪਣੀ ਮੁਦਰਾ ਨਿੱਜਤਾ ਰੱਖੋ। ਪ੍ਰਤੀਸ਼ਤ ਕੂਪਨਾਂ ਨਾਲ, ਲਾਈਨ ਰਾਊਂਡਿੰਗ ਕਈਟੁੱਕ ਚੈਂਟਸ ਵਿੱਚ ਆਰਡਰ ਰਾਊਂਡਿੰਗ ਨਾਲ ਬਰਾਬਰ ਨਹੀਂ ਰਹਿੰਦੀ, ਖਾਸ ਤੌਰ 'ਤੇ ਜਦੋਂ ਘੱਟ ਕੀਮਤੀ ਆਈਟਮ ਬਹੁਤ ਹੋਣ।
ਇਹਾਂ ਕੁਝ ਐਜ ਕੇਸ ਹਨ ਜੋ ਖਾਸ ਤੌਰ 'ਤੇ ਹਲ ਕਰਨ ਯੋਗ ਹਨ:
- ਰੀਟਰਨ ਅਤੇ ਹਿੱਸੇਵਾਰ ਰੀਫੰਡ: ਛੂਟਾਂ ਨੂੰ ਆਈਟਮਾਂ ਵਿੱਚ ਪ੍ਰੋਰੇਟ ਕਰੋ ਤਾਂ ਜੋ ਰਿਫੰਡ ਉਹਦੇ ਅਨੁਸਾਰ ਹੋਵੇ ਜੋ ਗਾਹਕ ਨੇ ਭੁਗਤਾਨ ਕੀਤਾ।
- ਕਾਰਟ ਸੋਧਾਂ ਬਾਅਦ ਲਾਗੂ ਕੀਤਾ ਕੂਪਨ: ਆਈਟਮ ਜੋੜੇ ਜਾਂ ਹਟਾਏ ਜਾਣ 'ਤੇ ਯੋਗਤਾ ਅਤੇ ਕੈਪ ਮੁੜ-ਮੁਲਾਂਕਣ ਕਰੋ।
- ਸ਼ਿਪਿੰਗ ਬਦਲ: ਪਤਾ ਜਾਂ ਮੈਥਡ ਬਦਲਣ ਨਾਲ ਟੈਕਸ ਏਰੀਆ ਅਤੇ ਸ਼ਿਪਿੰਗ ਛੂਟ ਯੋਗਤਾ ਬਦਲ ਸਕਦੀ ਹੈ।
- ਮਾਤਰਾ ਬਦਲ: ਇੱਕੋ ਆਈਟਮ ਦੀ ਮਾਤਰਾ ਵੱਧਣ ਨਾਲ ਥਰੈਸ਼ਹੋਲਡਾਂ (ਉਦਾਹਰਨ ਲਈ, min spend ਜਾਂ buy-X-get-Y) ਪਾਰ ਹੋ ਸਕਦੇ ਹਨ।
- ਮਿਲੇ-ਜੁਲੇ ਟੈਕਸੇਬਲ ਆਈਟਮ: ਕੁਝ ਆਈਟਮ non-taxable ਹੋ ਸਕਦੇ ਹਨ ਪਰ ਫਿਰ ਵੀ ਕੂਪਨ ਲਈ ਯੋਗ ਹੋ ਸਕਦੇ ਹਨ।
ਇੱਕ ਠੋਸ ਉਦਾਹਰਨ: 10% ਆਰਡਰ ਕੂਪਨ ਨਾਲ $50 ਤੋਂ ਉੱਤੇ ਮੁਫ਼ਤ ਸ਼ਿਪਿੰਗ। ਜੇ ਕੂਪਨ ਥਰੈਸ਼ਹੋਲਡ ਦੀ ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਲਾਗੂ ਹੁੰਦਾ, ਡਿਸਕਾਉਂਟਡ subtotal $50 ਤੋਂ ਥੱਲੇ ਆ ਸਕਦਾ ਹੈ ਅਤੇ ਸ਼ਿਪਿੰਗ ਮੁਫ਼ਤ ਨਾ ਰਹੇ। ਇਕ ਵਿਆਖਿਆ ਚੁਣੋ, ਨਿਯਮ ਵਜੋਂ ਇਨਕੋਡ ਕਰੋ, ਅਤੇ ਕਾਰਟ, ਚੈੱਕਆਊਟ, ਅਤੇ ਰਿਫੰਡ ਵਿੱਚ ਇਸਨੂੰ ਇੱਕੋ ਜਿਹਾ ਰੱਖੋ।
ਆਮ ਪ੍ਰੋਮੋ ਬੱਗ ਅਤੇ ਉਹ ਕਿਵੇਂ ਹੁੰਦੇ ਹਨ
ਜ਼ਿਆਦਾਤਰ ਕੂਪਨ ਲਾਜ਼ਿਕ ਦੀਆਂ ਖਾਮੀਆਂ ਉਦੋਂ ਉੱਭਰਦੀਆਂ ਹਨ ਜਦੋਂ ਕਾਰਟ ਇਕ ਤੋਂ ਵੱਧ ਪਾਥ ਰਾਹੀਂ ਮੁਲਾਂਕਣ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਪ੍ਰੋਮੋ ਇੱਕ ਥਾਂ ਲਾਈਨ-ਆਈਟਮ ਪੱਧਰ 'ਤੇ ਲਾਗੂ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਦੂਜੀ ਥਾਂ ਆਰਡਰ-ਪੱਧਰ 'ਤੇ ਮੁੜ ਲਾਗੂ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਦੋਹਾਂ ਇਕੱਲੇ ਵਿੱਚ "ਸਹੀ" ਦਿਸਦੇ ਹਨ।
ਸਭ ਤੋਂ ਆਮ ਬੱਗ ਅਤੇ ਹਰ ਇੱਕ ਦੇ ਆਮ ਕਾਰਣ:
- ਇੱਕੋ ਆਈਟਮ ਤੇ ਡਬਲ-ਛੂਟ: ਇੱਕੋ ਪ੍ਰੋਮੋ ਇੱਕ ਵਾਰੀ ਆਈਟਮ ਕੀਮਤ ਵਿੱਚ ਅਤੇ ਫਿਰ ਆਰਡਰ ਟੋਟਲ ਗਣਨਾ ਵਿੱਚ ਫਿਰ ਤੋਂ ਲਾਗੂ ਹੋ ਜਾਂਦੀ ਹੈ—ਅਕਸਰ ਦੋ ਸੇਵਾਵਾਂ ਦੁਆਰਾ।
- ਨੈਗੇਟਿਵ ਟੋਟਲ ਜਾਂ ਨੈਗੇਟਿਵ ਲਾਈਨ ਆਈਟਮ: ਇੱਕ ਨਿਸ਼ਚਿਤ ਰਕਮ ਦੀ ਛੂਟ ਉਸ ਯੋਗ ਰਕਮ ਤੋਂ ਵੱਧ ਲੱਗ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ $20 off ਨੂੰ $12 ਯੋਗ subtotal 'ਤੇ ਲਾਗੂ ਕਰਨਾ) ਬਿਨਾਂ ਜ਼ੀਰੋ ਫਲੋਰ ਦੇ।
- ਪ੍ਰਤੀਸ਼ਤ ਛੂਟ ਗਲਤੀ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਘਟਾਈ ਕੀਤੀ ਕੀਮਤ 'ਤੇ ਲਾਗੂ ਹੋਣਾ: ਇੰਜਣ 10% ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਘਟਾਈ ਕੀਤੀ ਕੀਮਤ 'ਤੇ ਲਗਾਉਂਦਾ ਹੈ ਜਦੋਂ ਨਿਯਮ ਦਾ ਮਤਲਬ "ਲਿਸਟ ਪ੍ਰਾਈਸ ਤੇ 10%" ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੋਡ ਮੌਜੂਦਾ ਕੀਮਤ ਨੂੰ ਬੇਸ ਵਜੋਂ ਵਰਤਦਾ ਹੈ ਨਾ ਕਿ ਬੇਸ ਪ੍ਰਾਈਸ।
- ਗਲਤ subtotal 'ਤੇ min spend ਦੀ ਜਾਂਚ: ਨਿਯਮ ਪ੍ਰੀ-ਡਿਸਕਾਉਂਟ subtotal 'ਤੇ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ ਜਦੋਂ ਕਾਰੋਬਾਰ ਨੇ ਪੋਸਟ-ਡਿਸਕਾਉਂਟ ਉਮੀਦ ਕੀਤੀ ਸੀ (ਜਾਂ ਉਲਟ), ਜਿਸ ਨਾਲ ਪ੍ਰੋਮੋ ਅਣਉਮੀਦ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਜਾਂ ਫੇਲ ਹੁੰਦੀ ਹੈ।
- ਐਕਸਕਲੁਡ ਕੀਤੇ ਆਈਟਮ ਫਿਰ ਵੀ ਕੂਪਨ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦੇ ਹਨ: ਯੋਗਤਾ ਉਤਪਾਦ ਟੈਗਾਂ ਤੇ ਨਿਰਭਰ ਹੈ, ਪਰ ਗੁੰਮ ਟੈਗਿੰਗ ਜਾਂ ਅਸਮਰਥ ਤੈਗਿੰਗ (ਜਾਂ ਫੈਲਬੈਕ) ਅਣਜਾਣ ਆਈਟਮਾਂ ਨੂੰ ਯੋਗ ਮੰਨ ਲੈਂਦਾ ਹੈ।
ਇੱਕ ਠੋਸ ਉਦਾਹਰਨ: ਕਾਰਟ ਵਿੱਚ ਦੋ ਆਈਟਮ ਹਨ, ਇੱਕ ਯੋਗ ਅਤੇ ਇੱਕ ਐਕਸਕਲੁਡ। ਜੇ ਇੰਜਣ ਪ੍ਰਤੀਸ਼ਤ ਪ੍ਰੋਮੋ ਲਈ ਸਹੀ ਤਰੀਕੇ ਨਾਲ "ਯੋਗ subtotal" ਗਣਨਾ ਕਰਦਾ ਹੈ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਫਿਕਸ ਡਿਸਕਾਉਂਟ ਪੂਰੇ ਆਰਡਰ ਟੋਟਲ ਤੋਂ ਕੱਟਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਐਕਸਕਲੁਡ ਆਈਟਮ ਹੋਰ ਵੀ ਛੂਟ ਪਾ ਸਕਦਾ ਹੈ।
ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਹਰ ਪ੍ਰੋਮੋ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ "ਯੋਗ ਰਕਮ" 'ਤੇ ਗਣਨਾ ਕਰਵਾਓ ਅਤੇ ਇੱਕ ਬੰਧਿਤ ਏਡਜਸਟਮੈਂਟ ਵਾਪਸ ਕਰੋ (ਕਦੇ ਵੀ ਜ਼ੀਰੋ ਤੋਂ ਥੱਲੇ ਨਹੀਂ), ਨਾਲ ਹੀ ਇਹ ਦਰਸਾਉ ਕਿ ਇਸਨੇ ਕੀ ਛੂਟ ਕੀਤਾ। ਜੇ ਤੁਸੀਂ ਆਪਣਾ ਡਿਸਕਾਉਂਟ ਇੰਜਣ Koder.ai ਵਰਗੇ ਟੂਲ ਵਿੱਚ ਜਨਰੇਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਟ੍ਰੇਸ ਨੂੰ ਸਧਾਰਨ ਡੇਟਾ ਵਿੱਚ ਆਉਟਪੁੱਟ ਕਰਵਾਓ ਤਾਂ ਤੁਹਾਡੇ ਟੈਸਟਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਪਤਾ ਲੱਗ ਸਕੇ ਕਿ ਕਿਹੜੀਆਂ ਲਾਈਨਾਂ ਯੋਗ ਸਨ ਅਤੇ ਕਿਹੜਾ subtotal ਵਰਤਿਆ ਗਿਆ।
ਸਹੀ ਟੈਸਟ ਸੂਟ ਨਾਲ ਨਿਯਮਾਂ ਨੂੰ ਟੈਸਟ ਕਰਨਯੋਗ ਬਣਾਓ
Test edge cases automatically
Create scenario tests for refunds, thresholds, and rounding so promo bugs fail fast.
ਜ਼ਿਆਦਾਤਰ ਕੂਪਨ ਲਾਜ਼ਿਕ ਦੀਆਂ ਖਾਮੀਆਂ ਇਸ ਕਰਕੇ ਆਉਂਦੀਆਂ ਹਨ ਕਿ ਟੈਸਟਾਂ ਸਿਰਫ ਆਖਿਰਲੇ ਟੋਟਲ ਨੂੰ ਜਾਂਚਦੀਆਂ ਹਨ। ਇਕ ਚੰਗੀ ਸੂਟ ਯੋਗਤਾ (ਕੀ ਇਹ ਪ੍ਰੋਮੋ ਲਾਗੂ ਹੋਣਾ ਚਾਹੀਦਾ?) ਅਤੇ ਗਣਿਤ (ਕਿੰਨੀ ਰਕਮ ਕੱਟਣੀ ਚਾਹੀਦੀ?) ਦੋਹਾਂ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ, ਨਾਲ ਹੀ ਇਕ ਪੜ੍ਹਨਯੋਗ ਬ੍ਰੇਕਡਾਊਨ ਜੋ ਤੁਸੀਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਤੁਲਨਾ ਕਰ ਸਕੋ।
ਛੋਟੇ ਤੋਂ ਵਾਸਤਵਿਕ ਤੱਕ ਟੈਸਟ ਬਣਾਓ
ਸਬ ਤੋਂ ਪਹਿਲਾਂ ਯੂਨਿਟ ਟੈਸਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਇੱਕ ਨਿਯਮ ਨੂੰ ਅਲੱਗ ਕਰਕੇ ਆਈਸੋਲੇਟ ਕਰਦੀਆਂ ਹਨ। ਇਨਪੁੱਟ ਨੂੰ ਛੋਟਾ ਰੱਖੋ, ਫਿਰ ਪੂਰੇ ਕਾਰਟ ਪਰਿਦ੍ਰਸ਼ ਨੂੰ ਵਧਾਓ।
- Eligibility unit tests: ਦਿੱਤੇ ਗਾਹਕ type, ਤਰੀਖਾਂ, ਉਤਪਾਦ ਟੈਗਾਂ, ਅਤੇ min_spend ਦੇ ਨਾਲ ਕੀ ਪ੍ਰੋਮੋ ਲਾਗੂ ਹੁੰਦਾ ਹੈ?
- Math unit tests: ਦਿੱਤੇ ਇੱਕ ਨਿਰਧਾਰਤ ਯੋਗ subtotal ਦੇ ਨਾਲ, ਕੀ ਖਾਤਾ ਰਾਊਂਡਿੰਗ ਅਤੇ ਮੁਦਰਾ ਨਿਯਮਾਂ ਦੇ ਮਿਲਦਾ ਹੈ?
- Scenario tests: ਮਿਸ਼ਰਤ ਆਈਟਮ, ਮਾਤਰਾ, ਸ਼ਿਪਿੰਗ, ਟੈਕਸ, ਅਤੇ ਕੁਝ ਪ੍ਰੋਮੋ ਜੋ ਇਕੱਠੇ ਲਾਗੂ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ।
- “Cart changed” tests: ਮੁਲਾਂਕਣ ਅਤੇ ਚੈੱਕਆਊਟ ਦਰਮਿਆਨ ਕੀਮਤ ਅਪਡੇਟ, ਆਈਟਮ ਹਟਾਏ ਜਾਣ, ਜਾਂ ਮਾਤਰਾ ਬਦਲਣ ਦੀ ਪਰਿਣਾਮ-ਝਲਕ।
- Breakdown snapshot tests: ਉਮੀਦਵਾਰ ਲਾਈਨ-ਦਰ-ਲਾਈਨ ਛੂਟ ਬੰਟਵਾਰੇ ਨੂੰ ਸੰਭਾਲ ਕੇ ਰੱਖੋ, ਨਾ ਕਿ ਸਿਰਫ ਆਖਰੀ ਟੋਟਲ।
ਕਵਰੇਜ ਹੋਣ ਤੋ ਬਾਅਦ, ਕੁਝ "ਹਮੇਸ਼ਾ ਸੱਚ" ਜਾਂਚਾਂ ਜੋੜੋ। ਇਹ ਉਹ ਅਜੀਬ ਮਾਮਲੇ ਪਕੜ ਲੈਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਲਈ ਤੁਸੀਂ ਹੱਥੋਂ ਲਿਖੇ ਟੈਸਟ ਸੋਚ ਨਹੀਂ ਪਾਏ ਹੋਣਗੇ।
- ਟੋਟਲ ਕਦੇ ਵੀ 0.00 ਤੋਂ ਘੱਟ ਨਹੀਂ ਹੁੰਦਾ।
- ਇੱਕ ਛੂਟ ਕਦੇ ਵੀ ਟੋਟਲ ਵਧਾਉਂਦੀ ਨਹੀਂ।
- ਲਾਗੂ ਕੀਤੀ ਛੂਟ ਉਸਦੀ ਯੋਗ ਬੇਸ ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੁੰਦੀ।
- ਇਕ ਅਣਯੋਗ ਆਈਟਮ ਹਟਾਉਂਣ ਨਾਲ ਛੂਟ ਵੱਡੀ ਨਹੀਂ ਹੋ ਸਕਦੀ।
ਇੱਕ ਛੋਟਾ ਕਾਰਟ ਉਦਾਹਰਨ
ਕਲਪਨਾ ਕਰੋ ਕਿ ਇੱਕ ਕਾਰਟ ਵਿੱਚ 2 ਆਈਟਮ ਹਨ: $40 ਦਾ ਸ਼ਰਟ (ਯੋਗ) ਅਤੇ $30 ਦਾ ਗਿਫਟ ਕਾਰਡ (ਇੱਕਸਕਲੂਡ)। ਸ਼ਿਪਿੰਗ $7 ਹੈ। ਇੱਕ ਪ੍ਰੋਮੋ "ਆਪਰੇਲ 'ਤੇ 20% off, ਮੈਕਸ $15" ਹੈ, ਨਾਲ ਦੂਜੀ ਪ੍ਰੋਮੋ "$10 off orders over $50" ਹੈ ਜੋ ਪ੍ਰਤੀਸ਼ਤ ਛੂਟਾਂ ਨਾਲ ਸਟੈਕ ਨਹੀਂ ਹੋ ਸਕਦੀ।
ਤੁਹਾਡੀ ਸਿਨੇਰੀਓ ਟੈਸਟ ਨੂੰ ਪੱਕਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੋਈ ਪ੍ਰੋਮੋ ਜਿੱਤਦਾ ਹੈ (ਪ੍ਰਾਇਰਟੀ), ਗਿਫਟ ਕਾਰਡ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਠੀਕ ਬਟਵਾਰਾ ਪੁਸ਼ਟੀ ਕਰਨਾ: $40 ਦਾ 20% = $8, ਸ਼ਿਪਿੰਗ ਅਚਲ, ਆਖਰੀ ਟੋਟਲ ਸਹੀ। ਉਸ ਬ੍ਰੇਕਡਾਊਨ ਨੂੰ ਸੋਨੇ ਦੀ ਸਨੇਪਸ਼ਾਟ ਵਜੋਂ ਸੰਭਾਲੋ ਤਾਂ ਕਿ ਬਾਅਦ ਦੇ ਰੀਫੈਕਟਰਾਂ ਨਾਲ ਵੀ ਨਹੀਂ ਬਦਲੇ।
ਪ੍ਰੀ-ਲਾਂਚ ਜਾਂਚ-ਸੂਚੀ
ਨਵਾਂ ਪ੍ਰੋਮੋ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਆਖਰੀ ਚੈੱਕ ਲਿਸਟ ਨਾਲ ਇੱਕ ਪਾਸ ਕਰੋ ਜੋ ਗਾਹਕ ਤੁਰੰਤ ਨੋਟਿਸ ਕਰਨ ਵਾਲੀਆਂ ਖਾਮੀਆਂ ਪਕੜਦੀ ਹੈ: ਅਜੀਬ ਟੋਟਲ, ਭੁਲਭੁਲੇ ਸੰਦੇਸ਼, ਅਤੇ ਰਿਫੰਡ ਜੋ ਮਿਲਦੇ-ਜੁਲਦੇ ਨਹੀਂ। ਇਹ ਚੈੱਕ ਨਿਯਮਾਂ ਨੂੰ ਹਰ ਕਾਰਟ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ ਰਵੱਈਆ ਕਰਨ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ।
ਇਹ ਜਾਂਚਾਂ ਛੋਟੇ "ਟ੍ਰਿੱਕੀ" ਕਾਰਟਾਂ 'ਤੇ ਚਲਾਓ (ਇੱਕ ਆਈਟਮ, ਬਹੁਤ ਸਾਰੇ ਆਈਟਮ, ਮਿਕਸਡ ਟੈਕਸ ਰੇਟ, ਸ਼ਿਪਿੰਗ, ਅਤੇ ਇੱਕ ਉੱਚ ਮਾਤਰਾ ਵਾਲੀ ਲਾਈਨ)। ਕਾਰਟਾਂ ਨੂੰ ਸੇਵ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਕੋਈ ਵੀ ਵਾਰ-ਵਾਰ ਇਨ੍ਹਾਂ ਨੂੰ ਚਲਾ ਸਕੋ ਜਦੋਂ ਕੀਮਤ ਕੋਡ ਬਦਲਦੇ ਹੋ।
ਪੰਜ ਜਾਂਚ ਜੋ ਜ਼ਿਆਦਾਤਰ ਫੇਲures ਫੜ ਲੈਂਦੀਆਂ ਹਨ
- Guardrails on totals: ਆਖਰੀ ਆਰਡਰ ਟੋਟਲ ਅਤੇ ਹਰ ਲਾਈਨ ਦੀ ਸਾਫ਼ ਨੈੱਟ ਕੀਮਤ ਕਦੇ ਵੀ 0 ਤੋਂ ਘੱਟ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਜੇ ਕੋਈ ਛੂਟ ਆਪਣੇ ਆਪ ਲਾਗੂ ਹੋ ਕੇ ਵੱਧ ਜਾਵੇ, ਤਾਂ ਇਸਨੂੰ ਕੈਪ ਕਰੋ ਅਤੇ ਕੈਪ ਕੀਤੀ ਰਕਮ ਦਰਜ ਕਰੋ।
- Explainable math: ਗਾਹਕ ਨੂੰ ਦਿਖਾਇਆ ਗਿਆ ਛੂਟ ਬ੍ਰੇਕਡਾਊਨ (ਪ੍ਰੋਮੋ ਵਾਰ, ਲਾਈਨ ਵਾਰ, ਸ਼ਿਪਿੰਗ ਵਾਰ) ਆਖਰੀ ਭੁਗਤਾਨ ਕੀਤੀ ਗਈ ਰਕਮ ਨਾਲ ਬਿਲਕੁਲ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ, ਤਾਂ ਨਿਯਮ ਬਹੁਤ ਧੁੰਦਲੇ ਹਨ।
- One stacking policy, no surprises: ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਸਰਟੀਫਾਈ ਕਰੋ ਕਿ ਕੀ ਸਟੈਕ ਕਰ ਸਕਦਾ (ਕੂਪਨ + ਆਟੋ ਪ੍ਰੋਮੋ, ਪ੍ਰਤੀਸ਼ਤ + ਫਿਕਸਡ, ਸ਼ਿਪਿੰਗ + ਆਈਟਮ ਛੂਟ)। ਪ੍ਰਾਇਰਟੀ ਕ੍ਰਮ ਸਪਸ਼ਟ ਕਰੋ ਅਤੇ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਸਹਾਇਤਾ ਟੀਮ ਵੀ ਏਹੀ ਕਹੇਗੀ।
- Rounding is consistent: ਇੱਕ ਰਾਊਂਡਿੰਗ ਨੀਤੀ (ਪਰ-ਲਾਈਨ ਵਸਤੇ vs ਪਰ-ਆਰਡਰ, half-up vs bankers, ਮੁਦਰਾ-ਖਾਸ ਦਿਸਮਲ) ਚੁਣੋ। ਇਸਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਅਤੇ $0.99 ਜਿਹੀਆਂ ਕੀਮਤਾਂ, 3 ਜਿਹੀਆਂ ਮਾਤਰਾਂ, ਅਤੇ ਮਿਲੇ-ਜੁਲੇ ਪ੍ਰਤੀਸ਼ਤ ਛੂਟਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ।
- Returns and refunds are correct: ਹਿੱਸੇਵਾਰ ਰਿਟਰਨ ਸਹੀ ਹਿੱਸਾ ਵਾਪਸ ਕਰਨ — ਛੂਟ, ਟੈਕਸ ਅਤੇ ਸ਼ਿਪਿੰਗ। "3 ਵਿੱਚੋਂ 1 ਵਾਪਸ", "ਪਹਿਲਾ ਵਾਪਸ ਕੀਤੀ ਗਈ ਛੂਟ ਵਾਲੀ ਆਈਟਮ", ਅਤੇ "ਪ੍ਰੋਮੋ ਮਿਆਦ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਰਿਫੰਡ" ਵਰਗੀਆਂ ਸਥਿਤੀਆਂ ਟੈਸਟ ਕਰੋ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਜਨਰੇਟਰ ਵਿੱਚ ਨਿਯਮ ਬਣਾਉਂਦੇ ਹੋ ਤਾਂ ਇਹ ਕੇਸ ਆਟੋਮੇਟਡ ਟੈਸਟਾਂ ਵਜੋਂ ਨਿਯਮ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨਾਲ ਨਾਲ ਸ਼ਾਮਲ ਕਰੋ। ਉਦੇਸ਼ ਸਧਾਰਨ ਹੈ: ਆਉਣ ਵਾਲਾ ਕੋਈ ਵੀ ਪ੍ਰੋਮੋ ਟੈਸਟਾਂ ਵਿੱਚ ਫੇਲ ਹੋ ਜਾਵੇ ਨਾ ਕਿ ਗਾਹਕ ਦੇ ਕਾਰਟ ਵਿੱਚ।
ਤੁਹਾਡੇ ਨਿਯਮਾਂ ਨੂੰ ਵੈਧ ਕਰਨ ਲਈ ਇੱਕ ਵਾਸਤਵਿਕ ਸਟੈਕਿੰਗ ਸਿਨੇਰੀਓ
Add an audit trail
Generate a clean discount breakdown per line item to prevent mismatched totals across screens.
ਇੱਥੇ ਇੱਕ ਛੋਟਾ ਕਾਰਟ ਦਿੱਤਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਕੂਪਨ ਲਾਜ਼ਿਕ ਦੀਆਂ ਖਾਮੀਆਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਬੇਇੰਤਹਾ ਜਟਿਲਤਾ ਦੇ।
ਇਨ੍ਹਾਂ ਨਿਯਮਾਂ ਨੂੰ ਮੰਨੋ (ਉਨ੍ਹਾਂ ਨੂੰ ਠੀਕ-ਠੀਕ ਇਸੇ ਤਰ੍ਹਾਂ ਆਪਣੇ ਸਿਸਟਮ ਵਿੱਚ ਲਿਖੋ):
- ਆਟੋ ਪ੍ਰੋਮੋ ਪਹਿਲਾਂ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਆਈਟਮ-ਸਤਰ, ਸਿਰਫ ਯੋਗ ਫੁੱਲ-ਪ੍ਰਾਈਸ ਆਈਟਮਾਂ 'ਤੇ
- ਕੂਪਨ ਆਰਡਰ-ਸਤਰ ਹੈ, $15 off, ਘੱਟੋ-ਘੱਟ $100 ਯੋਗ ਮਾਲ ਦੀ ਲੋੜ
- "ਯੋਗ ਮਾਲ" sale ਆਈਟਮਾਂ, ਸ਼ਿਪਿੰਗ, ਅਤੇ ਟੈਕਸ ਨੂੰ ਬਾਹਰ ਰੱਖਦਾ ਹੈ
- ਕੂਪਨ ਛੂਟ ਪਹਿਲਾਂ ਦੇ ਹੋਏ ਪ੍ਰੋਮੋਜ਼ ਤੋਂ ਬਾਅਦ ਉਪਲਬਧ ਯੋਗ subtotal ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੋ ਸਕਦੀ
- ਟੈਕਸ ਛੂਟਾਂ ਤੋਂ ਬਾਅਦ ਗਣਨਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਛੂਟਡ ਮਾਲ + ਸ਼ਿਪਿੰਗ)
ਕਾਰਟ ਅਤੇ ਪ੍ਰੋਮੋ
ਕਾਰਟ:
| Line | Price | Notes |
|---|---|---|
| Item A | $60 | full-price, eligible |
| Item B | $40 | full-price, eligible |
| Item C | $30 | sale item, excluded |
| Shipping | $8 | fee |
ਪ੍ਰੋਮੋਜ਼:
- Promo 1: automatic 10% weekend sale on eligible items
- Promo 2: coupon $15 off, min $100 eligible spend, excludes sale items
ਚਲਣ ਅਤੇ ਅੰਤਿਮ ਬ੍ਰੇਕਡਾਊਨ
-
ਕੂਪਨ ਮਿਨੀਮਮ ਦੀ ਜਾਂਚ: ਛੂਟ ਲਈ ਯੋਗ ਮਾਲ ਪ੍ਰੀ-ਡਿਸਕਾਉਂਟ $60 + $40 = $100 ਹੈ, ਇਸ ਲਈ ਕੂਪਨ ਲਾਗੂ ਹੋ ਸਕਦਾ ਹੈ।
-
Promo 1 ਲਗਾਓ (ਯੋਗ ਆਈਟਮਾਂ 'ਤੇ 10%): $100 x 10% = $10 off. ਯੋਗ subtotal ਹੁੰਦਾ ਹੈ $90।
-
Promo 2 ਲਗਾਓ ($15 off): ਕੈਪ $90 ਹੈ, ਇਸ ਲਈ ਪੂਰਾ $15 ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਨਵਾਂ ਯੋਗ subtotal: $75।
ਟੋਟਲ:
- Merchandise: eligible $75 + sale item $30 = $105
- Shipping: $8
- Tax (8%): (105 + 8) x 0.08 = $9.04
- Final total: $105 + $8 + $9.04 = $122.04
ਹੁਣ ਇਕ ਚੀਜ਼ ਬਦਲੋ: ਗਾਹਕ Item B ($40) ਹਟਾ ਦਿੰਦਾ ਹੈ। ਯੋਗ ਮਾਲ $60 ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ $15 ਕੂਪਨ min spend ਚੈੱਕ ਫੇਲ ਕਰ ਜਾਂਦੀ ਹੈ। ਸਿਰਫ 10% ਆਟੋ ਪ੍ਰੋਮੋ ਰਹਿੰਦਾ ਹੈ: Item A ਹੁੰਦਾ $54, ਮਾਲ $54 + $30 = $84, ਅਤੇ ਆਖਰੀ ਟੋਟਲ $99.36। ਇਹ ਉਹ ਛੋਟੀ ਸੋਧ ਹੈ ਜੋ ਅਕਸਰ ਕਾਰਟਾਂ ਨੂੰ ਟੁੱਟੀ ਹੋਈ ਦਿਖਾਉਂਦੀ ਹੈ ਜੇ ਯੋਗਤਾ ਅਤੇ ਕ੍ਰਮ ਸਪਸ਼ਟ ਨਾ ਹੋਣ।
ਅਗਲੇ ਕਦਮ: ਪ੍ਰੋਮੋਜ਼ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ ਕਰੋ ਅਤੇ ਮੈਨਟੇਨੇਬਲ ਰੱਖੋ
ਕੂਪਨ ਲਾਜ਼ਿਕ ਦੀਆਂ ਖਾਮੀਆਂ ਤੋਂ ਬਚਣ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ: ਪ੍ਰੋਮੋਜ਼ ਨੂੰ ਪ੍ਰੋਡਕਟ ਨਿਯਮ ਵਾਂਗ ਸੰTreat ਕਰੋ, ਨਾ ਕਿ "ਚੈੱਕਆਊਟ ਵਿੱਚ ਕੁਝ ਗਣਿਤ"। ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ ਸਪੈਸ ਲਿਖੋ ਜੋ ਕੌਣ ਵੀ ਟੀਮ ਦੇ ਬੰਦੇ ਪੜ੍ਹ ਸਕਣ ਅਤੇ ਸਹਿਮਤ ਹੋ ਸਕਣ।
ਚਾਰ ਚੀਜ਼ਾਂ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ:
- Stacking rules (ਕਿਹੜੇ ਮਿਲ ਸਕਦੇ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਨਹੀਂ)
- Priority order (ਜਦੋਂ ਦੋ ਛੂਟ ਇਕੋ ਆਈਟਮ ਨੂੰ ਲਕੜਦੇ ਹਨ ਤਾਂ ਕਿਹੜਾ ਜਿੱਤਦਾ)
- Exclusions (ਸ਼੍ਰੇਣੀ, ਬ੍ਰਾਂਡ, sale ਆਈਟਮ, ਸਬਸਕ੍ਰਿਪਸ਼ਨ, ਗਿਫਟ ਕਾਰਡ)
- Floors and caps (min subtotal, max discount, ਅਤੇ "ਕਦੇ ਵੀ $0 ਤੋਂ ਥੱਲੇ ਨਹੀਂ")
ਰਿਲੀਜ਼ ਦੇ ਬਾਅਦ, ਟੋਟਲਾਂ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਵੇਖੋ ਜਿਵੇਂ ਤੁਸੀਂ ਐਰਰਾਂ ਨੂੰ ਵੇਖਦੇ ਹੋ। ਇਕ ਛੂਟ ਬੱਗ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਵੈਧ ਆਰਡਰ ਵਾਂਗ ਦਿਸਦਾ ਹੈ ਜਦ ਤੱਕ ਫ਼ਾਇਨੈਂਸ ਉਸਨੂੰ ਨੋਟਿਸ ਨਾ ਕਰੇ।
ऐਸੇ ਆਰਡਰਾਂ ਨੂੰ ਫਲੈਗ ਕਰਨ ਲਈ ਮਾਨੀਟਰਿੰਗ ਸੈੱਟ ਕਰੋ ਜਿਵੇਂ near-zero totals, negative totals, discounts larger than subtotal, ਜਾਂ ਅਚਾਨਕ "100% off" ਕਾਰਟਾਂ ਵਿੱਚ spike. ਅਲਰਟਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਥਾਵਾਂ 'ਤੇ ਰੂਟ ਕਰੋ ਜਿੱਥੇ ਤੁਹਾਡੇ ਚੈੱਕਆਊਟ ਐਰਰ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਪਲੇਬੁੱਕ ਰੱਖੋ ਕਿ ਕਿਸ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰੋਮੋ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ disable ਕਰਨਾ ਹੈ।
ਨਵੇਂ ਪ੍ਰੋਮੋਜ਼ ਨੂੰ ਰੀਗਰੈਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਸ਼ਾਮਿਲ ਕਰਨ ਲਈ, ਇਕ ਦੁਹਰਾਓਯੋਗ ਵਰਕਫਲੋ ਵਰਤੋ: ਪਹਿਲਾਂ ਸਪੈਸ ਅਪਡੇਟ ਕਰੋ, ਫਿਰ ਨਿਯਮ ਨੂੰ ਡੇਟਾ ਵਜੋਂ ਇਨਕੋਡ ਕਰੋ (ਬਿਲਕੁਲ branching code ਨਹੀਂ), ਕੁਝ "ਨਾਰਮਲ" ਕਾਰਟਾਂ ਅਤੇ ਇੱਕ-ਦੋ ਨਾਸਟੀ ਐਜ-ਕੇਸਾਂ ਲਈ ਟੈਸਟ ਜੋੜੋ, ਫਿਰ ਪੂਰੀ ਡਿਸਕਾਉਂਟ ਟੈਸਟ ਸੂਟ ਚਲਾਓ ਪਹਿਲਾਂ merge ਕਰਨ ਤੋਂ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇੰਪਲੀਮੈਂਟ ਅਤੇ ਇਟਰੇਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਵਿੱਚ planning mode ਵਿੱਚ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ, ਫਿਰ snapshots ਅਤੇ rollback ਨਾਲ ਆਪਣੇ ਟੈਸਟ ਬਰਕਡਾਊਨ ਨੂੰ ਰਿਫਾਈਨ ਕਰੋ। ਇਹ ਤੁਹਾਨੂੰ ਨਿਯਮ ਬਦਲਦੇ ਸਮੇਂ ਇੱਕ ਜਾਣਿਆ-ਪਹਚਾਣਿਆ ਵਰਜਨ ਰੱਖਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ।