GST ਇਨਵੌਇਸ ਡੇਟਾ ਮਾਡਲ: HSN ਅਤੇ ਆਰਡਰਾਂ ਲਈ ਘੱਟੋ-ਘੱਟ ਫੀਲਡ

ਆਮ ਤੌਰ 'ਤੇ GST ਇਨਵੌਇਸਾਂ ਵਿੱਚ ਕੀ ਗਲਤ ਹੁੰਦਾ ਹੈ

ਜ਼ਿਆਦਾਤਰ GST ਇਨਵੌਇਸ ਸਮੱਸਿਆਵਾਂ "ਜਟਿਲ ਟੈਕਸ" ਦੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਗੈਰਮੌਜੂਦਗੀ ਜਾਂ ਅਸੰਖਲਿਤ ਡੇਟਾ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਆਡਿਟ ਫੇਲ ਤਾਂੰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਨਵੌਇਸ ਨੂੰ ਇਹ ਨਹੀਂ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਕਿ ਕੀ ਵੇਚਿਆ ਗਿਆ ਸੀ, ਕਿਸ ਨੂੰ ਵੇਚਿਆ ਗਿਆ ਸੀ, ਕਿੱਥੇ ਸਪਲਾਈ ਹੋਈ, ਅਤੇ ਟੈਕਸ ਕਿਵੇਂ ਲਗਾਇਆ ਗਿਆ।

ਇੱਕ ਆਮ ਕਾਰਨ HSN ਦਾ ਨਾ ਹੋਣਾ, ਪੁਰਾਣਾ ਹੋਣਾ ਜਾਂ ਗਲਤ ਸਤਰ ਤੇ ਲਾਗੂ ਹੋਣਾ ਹੈ। ਟੀਮਾਂ HSN ਨੂੰ ਉਤਪਾਦ 'ਤੇ ਸਟੋਰ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਇਨਵੌਇਸ ਲਾਈਨ ਕਿਸੇ ਹੋਰ SKU ਨਾਮ ਜਾਂ ਵੈਰੀਐਂਟ ਤੋਂ ਬਣਦੀ ਹੈ, ਇਸ ਲਈ HSN ਆਖ਼ਰੀ ਦਸਤਾਵੇਜ਼ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਇਕ ਹੋਰ ਆਮ ਮੁੱਦਾ ਗਲਤ ਟੈਕਸ ਵੰਡ ਹੈ: IGST ਲਾਇਆ ਜਾ ਰਿਹਾ ਹੈ ਜਦੋਂ CGST ਅਤੇ SGST ਲਗਣੇ ਚਾਹੀਦੇ (ਅਥਵਾ ਉਲਟ) ਕਿਉਂਕਿ "place of supply" ਨੂੰ ਸ਼ਿਪਿੰਗ ਐਡਰੈੱਸ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਕੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ, ਪਰ ਦਰਅਸਲ ਉਸ ਨਿਰਣਯ ਲਈ ਵਰਤੇ ਗਏ ਰਾਜ ਕੋਡ ਸਟੋਰ ਨਹੀਂ ਕੀਤੇ ਗਏ।

ਫਾਇਨੈਂਸ ਟੀਮ ਨੂੰ ਇਹ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਰੀਕਨਸੀਲੀਏਸ਼ਨ ਦੈਨੀਕ ਸਫਾਈ ਦਾ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ: ਇਨਵੌਇਸ ਟੋਟਲ ਆਰਡਰ ਨਾਲ ਮਿਲਦੇ ਨਹੀਂ, ਆਰਡਰ ਪੇਮੈਂਟ ਗੇਟਵੇ ਸੈਟਲਮੈਂਟ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਅਤੇ ਰੀਫੰਡ ਮੈਨੂਅਲ ਨੋਟਸ ਦੀ ਲੜੀ ਬਣ ਜਾਂਦੀ ਹੈ। ਇਨਵੌਇਸ PDF, GST ਰਿਪੋਰਟਾਂ ਅਤੇ ਲੈਜਰ ਵਿਚ ਛੋਟੀ ਗੋਲਾਈ ਕਦਰਾਂ ਵੀ ਅਸਮੰਜਸ ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ।

ਇਥੇ ਉਹ ਪੈਟਰਨ ਹਨ ਜੋ ਜ਼ਿਆਦਾਤਰ ਅਸਮੰਜਸ ਪੈਦਾ ਕਰਦੇ ਹਨ:

• ਉਤਪਾਦ ਅਤੇ ਇਨਵੌਇਸ ਲਾਈਨਾਂ ਇਕੋ HSN, GST ਦਰ, ਅਤੇ ਟੈਕਸੇਬਲ ਵੈਲਯੂ ਫੀਲਡ ਸਾਂਝੇ ਨਹੀਂ ਰੱਖਦੇ।
• ਟੈਕਸ ਇਕ ਤੋਂ ਵੱਧ ਜਗ੍ਹਾ ਕੈਲਕ्युਲੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਕਾਰਟ ਵਿਰੁੱਧ ਇਨਵੌਇਸ) ਅਤੇ ਨਤੀਜੇ ਵੱਭਰੇ ਹੁੰਦੇ ਹਨ।
• ਕੁੱਲਾਂ ਸਿਰਫ਼ "ਗ੍ਰੈਂਡ ਟੋਟਲ" ਵਜੋਂ ਸਟੋਰ ਹੁੰਦੇ ਹਨ ਬਿਨਾਂ ਟੈਕਸੇਬਲ ਵੈਲਯੂ ਅਤੇ ਹਰ ਟੈਕਸ ਕੰਪੋਨੈਂਟ ਦੇ ਬ੍ਰੇਕਡਾਊਨ ਦੇ।
• ਇਨਵੌਇਸ ਨੰਬਰਿੰਗ ਸੋਧਯੋਗ ਹੈ ਜਾਂ ਸੀਰੀਜ਼ਾਂ ਵਿੱਚ ਨਕਲ ਹੋ ਰਹੀ ਹੈ।
• ਰੀਫੰਡ ਨੈਗੇਟਿਵ ਆਰਡਰ ਵਜੋਂ ਰਿਕਾਰਡ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਬਜਾਏ ਠੀਕ ਕਰੈਡਿਟ ਨੋਟ ਬਨਾਉਣ ਦੇ।

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

ਤੁਹਾਨੂੰ ਜ਼ਰੂਰੀ ਰਿਕਾਰਡਾਂ ਦਾ ਸਭ ਤੋਂ ਛੋਟਾ ਸੈੱਟ

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

ਇਹਾਂ ਉਹ ਮੁੱਖ ਰਿਕਾਰਡ ਹਨ ਜੋ ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਨੂੰ ਦਿਨ ਇੱਕ 'ਤੇ ਚਾਹੀਦੇ ਹੁੰਦੇ ਹਨ:

• Customer: ਜਿਸ ਨੇ ਖਰੀਦਿਆ (ਨਾਂ, ਫੋਨ/ਈਮੇਲ, GSTIN ਜੇ B2B)
• Address: ਸ਼ਿਪਿੰਗ ਅਤੇ ਬਿੱਲਿੰਗ, ਨਾਲ ਰਾਜ ਅਤੇ place of supply ਸਿਗਨਲ
• Product (ਜਾਂ Service): ਕੀ ਵੇਚਿਆ ਗਿਆ, ਯੂਨਿਟ, ਬੇਸ ਪ੍ਰਾਈਸ, ਅਤੇ ਡਿਫਾਲਟ HSN/SAC
• Order: ਵਪਾਰਕ ਘਟਨਾ (ਕਾਰਟ, ਛੂਟ, ਸ਼ਿਪਿੰਗ ਚਾਰਜ, ਸਥਿਤੀ)
• Payment: ਪੈਸੇ ਕਿਵੇਂ ਲਏ/ਭੁਗਤਾਨ ਹੋਏ (ਗੇਟਵੇ ਰੈਫਰੈਂਸ, ਮੈਥਡ, ਕੈਪਚਰ ਕੀਤੀ ਰਕਮ, ਮਿਤੀ)

ਇੱਕ Invoice ਨੂੰ Order ਤੋਂ ਵੱਖਰਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। Orders ਬਦਲ ਸਕਦੇ ਹਨ (ਏਡਰੈੱਸ ਸੋਧ, ਆਇਟਮ ਰੱਦ ਹੋਣਾ, ਐਸੇ ਭਾਗੀ ਡਿਲਿਵਰੀ)। ਇਨਵੌਇਸਾਂ ਨੂੰ ਨਹੀਂ—ਉਨ੍ਹਾਂ ਨੂੰ ਸਥਿਰ ਨੰਬਰਿੰਗ, ਤਾਰੀਖਾਂ ਅਤੇ ਟੋਟਲ ਚਾਹੀਦੇ ਹਨ ਜੋ ਬਾਅਦ ਵਿੱਚ ਕਿਸੇ ਅਪਡੇਟ ਨਾਲ "ਡ੍ਰਿਫਟ" ਨਾ ਹੋਣ।

ਟੈਕਸ ਸਹੀ ਹੋਣ ਦਾ ਆਧਾਰ Line Items ਹਨ। ਹਰ ਇੱਕ ਆਰਡਰ ਲਾਈਨ ਆਈਟਮ (ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਹਰ ਇਨਵੌਇਸ ਲਾਈਨ) ਨੂੰ ਉਸ ਖਾਸ ਆਈਟਮ ਦੀ ਠੀਕ ਮਾਤਰਾ, ਯੂਨਿਟ ਪ੍ਰਾਈਸ, ਛੂਟ ਅਤੇ ਟੈਕਸ ਬ੍ਰੇਕਡਾਊਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਥੇ ਹੀ HSN/SAC ਅਤੇ GST ਰੇਟ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।

ਇੱਕ ਡੀਟੇਲ ਜੋ ਫਾਇਨੈਂਸ ਟੀਮਾਂ ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ: ਸਨੈਪਸ਼ਾਟ ਸਟੋਰ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ ਇਨਵੌਇਸ ਬਣਾਉਂਦੇ ਹੋ, ਉਤਪਾਦ ਵੇਰਵਾ, HSN/SAC, ਟੈਕਸ ਰੇਟ ਅਤੇ ਪ੍ਰਾਈਸਿੰਗ ਨੂੰ ਇਨਵੌਇਸ ਲਾਈਨ ਆਈਟਮਾਂ ਵਿੱਚ ਨਕਲ ਕਰੋ। ਮੌਜੂਦਾ ਉਤਪਾਦ ਮਾਸਟਰ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋ, ਕਿਉਂਕਿ ਰੇਟ ਅਤੇ ਨਾਮ ਬਦਲ ਸਕਦੇ ਹਨ।

ਇੰਨਵੈਲਟ ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂ ਵਿੱਚ ਜੋ ਸ਼ਾਮਲ ਕਰਨ ਲਾਇਕ ਹੁੰਦਾ ਹੈ ਉਹ ਹਨ Returns, Refunds, ਅਤੇ Credit Notes ਨੂੰ ਵੱਖਰੇ ਰਿਕਾਰਡ ਵਜੋਂ ਰੱਖਣਾ। ਉਦਾਹਰਨ: ਜੇ ਗਾਹਕ ਦੋ-ਆਈਟਮ ਆਰਡਰ ਵਿੱਚੋਂ ਇੱਕ ਆਈਟਮ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਕਰੈਡਿਟ ਨੋਟ ਚਾਹੋਗੇ ਜੋ ਮੂਲ ਇਨਵੌਇਸ ਲਾਈਨ ਦਾ ਹਵਾਲਾ ਦੇਵੇ, ਜਦਕਿ ਪੇਮੈਂਟ ਰੀਫੰਡ ਰਿਕਾਰਡ ਗੇਟਵੇ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ। ਇਹਨਾਂ ਨੂੰ ਸੁਪਸ਼ਟ ਆਬਜੈਕਟ ਵਜੋਂ ਰੱਖਣਾ ਮਹੀਨੇ ਦੇ ਅੰਤ 'ਤੇ GST ਰਜਿਸਟਰਾਂ ਵਿੱਚ "ਮੈਨੂਅਲ ਫਿਕਸ" ਨੂੰ ਰੋਕਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਇਹ Koder.ai ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਹਰ ਆਬਜੈਕਟ ਨੂੰ ਪਹਿਲਾਂ ਇੱਕ ਸਧਾਰਨ ਸਕ੍ਰੀਨ (create, view, edit) ਵਜੋਂ ਦੇਖੋ, ਫਿਰ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਲਾਈਨ-ਲੈਵਲ ਫੀਲਡਾਂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਨਵੌਇਸ ਜਨਰੇਸ਼ਨ ਸ਼ਾਮਲ ਕਰੋ।

HSN ਅਤੇ SAC: ਮਾਡਲ ਵਿੱਚ ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦੇ ਹਨ

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

ਇੱਕ ਵਿਵਹਾਰਯੋਗ ਨਿਊਨਤਮ ਡੇਟਾ ਮਾਡਲ ਇਹ ਹੈ:

• Product: id, name, SKU, unit (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (ਹੱਥੇ-ਦਿੱਤੇ ਲਾਈਨਾਂ ਲਈ ਵਿਕਲਪਿਕ), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

Product 'ਤੇ HSN/SAC ਰੱਖਣ ਨਾਲ ਤੁਹਾਡੀ ਐਡਮਿਨ ਟੀਮ ਨੂੰ ਇੱਕ ਥਾਂ ਤੇ ਇਹ ਰੱਖਣ ਵਿੱਚ ਆਸਾਨੀ ਹੁੰਦੀ ਹੈ। ਇਨਵੌਇਸ ਲਾਈਨ 'ਤੇ ਇਸ ਦੀ ਨਕਲ ਹੀ ਪਿਛਲੇ ਇਨਵੌਇਸਾਂ ਨੂੰ ਸਥਿਰ ਬਣਾਉਂਦੀ ਹੈ। ਭਾਵੇਂ ਉਤਪਾਦ ਬਾਅਦ ਵਿੱਚ ਬਦਲੇ, ਇਨਵੌਇਸ ਅਜੇ ਵੀ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਵੇਲੇ ਵਿਕਰੀ 'ਤੇ ਕੀ ਸੱਚ ਸੀ। ਇਹ reconciliation ਦੌਰਾਨ ਟੁੱਟਣ ਤੋਂ ਬਚਾਉਣ ਦਾ ਮੂਲ ਹੈ।

HSN ਸਟੋਰੇਜ ਲਈ, ਇਸਨੂੰ ਸਧਾਰਾ ਰੱਖੋ: code ਲਾਜ਼ਮੀ, description ਵਿਕਲਪਿਕ, ਅਤੇ effective_from date ਵਿਕਲਪਿਕ ਜੇ ਤੁਸੀਂ ਬਦਲਾਅ ਇਤਿਹਾਸ ਟਰੈਕ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਨੂੰ ਹਰ ਲਾਈਨ ਆਈਟਮ 'ਤੇ description ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ, ਪਰ ਇਹ ਐਕਸੈਪਸ਼ਨ ਜਾਂਚ ਵੇਲੇ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ।

ਮਿਕਸਡ ਕਾਰਟ ਆਮ ਹਨ: ਇੱਕ ਇਨਵੌਇਸ ਵਿੱਚ ਕਈ ਲਾਈਨ ਆਈਟਮ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਇਸ ਲਈ ਕਈ HSN/SAC ਕੋਡ ਹੋ ਸਕਦੇ ਹਨ। ਇੱਕ ਕੋਡ ਪਰੇ ਇਨਵੌਇਸ 'ਤੇ ਲੱਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ। ਕੁੱਲ ਇਨਵੌਇਸ ਪੱਧਰ 'ਤੇ ਜੋੜੇ ਜਾਂਦੇ ਹਨ, ਜਦਕਿ ਵਰਗੀਕਰਨ ਲਾਈਨ ਪੱਧਰ 'ਤੇ ਰਹਿੰਦੀ ਹੈ।

ਚੇੰਜ ਮੈਨੇਜਮੈਂਟ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਲੋਕ ਮੁਸ਼ਕਲਾਂ ਵਿੱਚ ਪੈਂਦੇ ਹਨ। ਇੱਕ ਛੋਟਾ ਨਿਯਮ ਸੈਟ ਵਰਤੋ:

• ਜਾਰੀ ਕੀਤੀਆਂ ਇਨਵੌਇਸ ਲਾਈਨਾਂ 'ਤੇ HSN/SAC ਨੂੰ ਕਦੇ ਓਵਰਰਾਈਟ ਨਾ ਕਰੋ।
• ਜੇ ਉਤਪਾਦ ਦਾ HSN/SAC ਬਦਲਦਾ ਹੈ, ਤਾਂ ਭਵਿੱਖੀ ਆਰਡਰਾਂ ਲਈ Product ਅਪਡੇਟ ਕਰੋ ਸਿਰਫ।
• ਜੇ ਤੁਸੀਂ ਇਤਿਹਾਸ ਟਰੈਕ ਕਰਦੇ ਹੋ, ਤਾਂ ਪੁਰਾਣੀ ਰਿਕਾਰਡ ਨੂੰ ਸੋਧਣ ਦੀ ਬਜਾਏ ਇੱਕ ਨਵਾਂ effective_from ਰਿਕਾਰਡ ਜੋੜੋ।

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

ਪਾਰਟੀ ਵੇਰਵੇ: GSTIN, ਐਡਰੈੱਸ ਅਤੇ place of supply

GST ਇਨਵੌਇਸ ਡੇਟਾ ਮਾਡਲ ਅਕਸਰ ਪਾਰਟੀ ਵੇਰਿਆਂ 'ਤੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਜੇ ਖਰੀਦਦਾਰ ਜਾਂ ਵਿਕਰੇਤਾ ਦੀ ਪਛਾਣ ਥੋੜ੍ਹੀ ਵੀ ਗਲਤ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਇਨਵੌਇਸ ਕਾਗਜ਼ 'ਤੇ ਬਿਲਕੁਲ ਠੀਕ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਰਿਟਰਨ ਅਤੇ ਰੀਕਨਸੀਲੀਏਸ਼ਨ ਵਿਚ ਦੁਖਦਾਈ ਹੋ ਸਕਦੀ ਹੈ।

ਸ਼ੁਰੂਆਤ ਵਿੱਚ "seller", "buyer" ਅਤੇ "ship-to" ਨੂੰ ਵੱਖ-ਵੱਖ ਪਾਰਟੀਆਂ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ, ਭਾਵੇਂ ਉਹ ਇਕੋ ਵਿਅਕਤੀ ਹੀ ਕਿਉਂ ਨਾ ਹੋਣ। ਇਹ ਗਲਤ ਰੋਕਦਾ ਹੈ ਜਦੋਂ ਗਾਹਕ ਵੱਖਰਾ ਸ਼ਿਪਿੰਗ ਐਡਰੈੱਸ ਜੋੜਦਾ ਹੈ ਜਾਂ ਜਦੋਂ ਤੁਸੀਂ ਇਕ ਤੋਂ ਵੱਧ GST ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਤੋਂ ਵੇਚਦੇ ਹੋ।

ਘੱਟੋ-ਘੱਟ ਫੀਲਡ ਜੋ ਸਟੋਰ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ (buyer ਅਤੇ seller)

ਫੀਲਡਾਂ ਨੂੰ ਸਧਾਰਨ ਅਤੇ ਸਪਸ਼ਟ ਰੱਖੋ। ਇਹ ਉਹ ਹਨ ਜਿਹੜੇ ਆਮ ਤੌਰ 'ਤੇ ਇਨਵੌਇਸ ਅਤੇ ਰਿਪੋਰਟਾਂ 'ਚ ਲੋੜ ਪੈਂਦੇ ਹਨ:

• ਕਾਨੂੰਨੀ ਨਾਂ (ਜਿਵੇਂ ਇਨਵੌਇਸ 'ਤੇ ਦਿਖਣਾ ਚਾਹੀਦਾ)
• ਟਰੇਡ ਨਾਂ (ਵਿਕਲਪਿਕ, ਪਰ ਲਾਭਦਾਇਕ)
• GSTIN (seller ਲਈ ਲਾਜ਼ਮੀ; buyer ਲਈ ਨੱਲੇਬਲ)
• ਫੋਨ/ਈਮੇਲ (ਹਮੇਸ਼ਾਂ ਜ਼ਰੂਰੀ ਨਹੀਂ, ਪਰ ਸਹਾਇਕ)
• ਐਡਰੈੱਸ ਲਾਈਨਾਂ, ਸਿਟੀ, ਰਾਜ, ਦੇਸ਼, PIN/ਪੋਸਟਲ ਕੋਡ

ਰਾਜ ਨੂੰ ਦੋਹਾਂ ਮਨੁੱਖ-ਪੜ੍ਹਨਯੋਗ ਨਾਂ ਅਤੇ ਸਟੇਟ ਕੋਡ ਵਜੋਂ ਸਟੋਰ ਕਰੋ, ਕਿਉਂਕਿ ਰਿਪੋਰਟਿੰਗ ਅਤੇ place-of-supply ਨਿਯਮ ਅਕਸਰ ਕੋਡ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ।

ਬਿੱਲਿੰਗ vs ਸ਼ਿਪਿੰਗ ਅਤੇ place of supply

ਆਰਡਰ 'ਤੇ ਬਿਲਿੰਗ ਅਤੇ ਸ਼ਿਪਿੰਗ ਦੋਹਾਂ ਐਡਰੈੱਸ ਕੈਪਚਰ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਗਾਹਕ ਪ੍ਰੋਫਾਇਲ 'ਤੇ। ਪ੍ਰੋਫਾਇਲ ਬਦਲਦੇ ਹਨ; ਇਨਵੌਇਸ ਨਹੀਂ।

place of supply ਨੂੰ ਇਨਵੌਇਸ 'ਤੇ ਇੱਕ ਨਿਰਧਾਰਤ ਰਾਜ ਕੋਡ ਵਜੋਂ ਸਟੋਰ ਕਰੋ (ਆਰਡਰ ਤੋਂ ਇਨਵੌਾਇਸ ਬਣਾਉਣ ਸਮੇਂ ਨਕਲ ਕੀਤਾ ਗਿਆ)। ਇਸਨੂੰ ਬਾਅਦ 'ਚ "ਰਿਕੈਲਕੁਲੇਟ" ਨਾ ਕਰੋ। ਜੇ ਤੁਹਾਡਾ ਨਿਯਮ "ship-to state" ਹੈ, ਤਾਂ ਉਸ ਨਤੀਜੇ ਨੂੰ ਸਟੋਰ ਕਰੋ, ਨਾਲ ਹੀ ਉਹ ਰਾਜ ਵੀ ਜੋ ਇਸ ਨਿਰਣਾ ਲਈ ਵਰਤੀ ਗਈ। ਇਹ ਆਡਿਟ ਅਤੇ ਵਿਵਾਦਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।

B2B vs B2C: ਕਦੋਂ GSTIN ਲਾਜ਼ਮੀ ਹੈ

B2B ਲਈ ਆਮ ਤੌਰ 'ਤੇ buyer GSTIN ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ ਅਤੇ ਐਨਟਰੀ ਸਮੇਂ ਲੰਬਾਈ ਅਤੇ ਫਾਰਮੈਟ ਲਈ ਵੈਧਤਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। B2C ਲਈ GSTIN ਖਾਲੀ ਰਹਿ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ CGST/SGST ਜਾਂ IGST ਫੈਸਲਾ ਕਰਨ ਲਈ ਪੂਰਾ ਐਡਰੈੱਸ ਅਤੇ ਰਾਜ ਚਾਹੀਦਾ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਜੋ ਬਹੁਤ ਸਿਸਟਮਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ: ਜੇ buyer GSTIN ਮੌਜੂਦ ਹੈ, ਤਾਂ B2B ਮੰਨੋ; ਜੇ ਨਹੀਂ, ਤਾਂ B2C ਮੰਨੋ। ਜੇ ਤੁਹਾਨੂੰ ਛੋਟੀਆਂ ਛੁਟ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇੱਕ explicit customer_type ਫੀਲਡ ਰੱਖੋ।

ਬਹੁ-ਇਕਾਈ ਵਿਕਰੇਤਾ (multiple GSTINs)

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਵਿਭਾਗਾਂ ਜਾਂ ਬਿਜਨਸ ਯੂਨਿਟ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਵੱਖ-ਵੱਖ GST ਰਜਿਸਟ੍ਰੇਸ਼ਨਾਂ ਹਨ, ਤਾਂ "Seller Entity" ਨੂੰ ਇੱਕ ਆਪਣਾ ਰਿਕਾਰਡ ਮਾਡਲ ਕਰੋ ਜਿਸਦਾ ਆਪਣਾ GSTIN ਅਤੇ ਐਡਰੈੱਸ ਹੋਵੇ। ਹਰ ਆਰਡਰ ਨੂੰ ਇੱਕ ਨਿਰਧਾਰਿਤ seller entity ਦਾ ਹਵਾਲਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਹਰ ਇਨਵੌਇਸ ਨੂੰ ਉਹ ਵੇਰਵੇ ਨਕਲ ਕਰਨੇ ਚਾਹੀਦੇ ਤਾਂ ਕਿ ਪੁਰਾਣੇ ਇਨਵੌਇਸ ਭਵਿੱਖ ਵਿੱਚ seller ਐਡਰੈੱਸ ਬਦਲਣ 'ਤੇ ਵੀ ਸਹੀ ਰਹਿਣ।

Koder.ai ਵਰਗੇ ਟੂਲ ਤੇਜ਼ੀ ਨਾਲ ਇਹ ਰਿਕਾਰਡ ਲਈ ਐਡਮਿਨ ਫਾਰਮ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਕੁੰਜੀ ਢਾਂਚਾ ਹੈ: ਵੱਖਰਾ seller entity, ਆਰਡਰ-ਟਾਈਮ ਸਨੈਪਸ਼ਾਟ, ਅਤੇ explicit place-of-supply ਰਾਜ ਕੋਡ।

ਟੈਕਸ ਕੈਲਕੁਲੇਸ਼ਨ ਫੀਲਡ ਜਿਹੜੇ ਤੁਸੀਂ ਸਟੋਰ ਕਰਨੇ ਲਾਜ਼ਮੀ ਹਨ

ਸਭ ਤੋਂ ਆਮ ਵੰਡ ਸਧਾਰਨ ਹੈ: ਜੇ supplier ਦਾ place of supply ਇੱਕੋ ਰਾਜ ਵਿੱਚ ਹੈ ਤਾਂ ਟੈਕਸ CGST + SGST ਹੁੰਦਾ ਹੈ। ਜੇ ਵੱਖਰਾ ਰਾਜ ਹੈ, ਤਾਂ IGST ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੀ ਸਿਸਟਮ ਨੂੰ ਬਾਅਦ 'ਚ "ਟੋਟਲ ਤੋਂ ਦੁਬਾਰਾ ਗਣਨਾ" ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ ਕਿਉਂਕਿ ਛੋਟੀ ਗੋਲਾਈ, ਛੂਟ, ਸ਼ਿਪਿੰਗ ਵਗੈਰਾ ਦੇ ਨਜ਼ਦੀਕੀ ਅੰਤਰ ਹੀ ਉਹੀ ਹਨ ਜੋ ਅਸਮੰਜਸ ਪੈਦਾ ਕਰਦੇ ਹਨ।

ਕਮ ਤੋਂ ਕਮ, ਟੈਕਸ ਨੰਬਰ ਇਨਵੌਇਸ ਲਾਈਨ ਪੱਧਰ 'ਤੇ ਸਟੋਰ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਨਵੌਇਸ ਹੈਡਰ 'ਤੇ। ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਇਨਵੌਇਸ 'ਤੇ ਹਰ ਰੁਪਏ ਦੀ ਵਿਆਖਿਆ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਹ ਨੂੰ ਉਤਪਾਦ, HSN ਅਤੇ ਰੈਵਿਨਿਊ ਨਾਲ ਮੇਲ ਕਰ ਸਕਦੇ ਹੋ।

ਤੁਹਾਡੇ GST ਇਨਵੌਇਸ ਡੇਟਾ ਮਾਡਲ ਲਈ ਇੱਕ ਵਿਵਹਾਰਯੋਗ ਨਿਊਨਤਮ ਇਨਵੌਇਸ ਲਾਈਨ ਇਹ ਹੇਠਾਂ ਲੱਗਦੀ ਹੈ:

• taxable_value (ਲਾਈਨ-ਲੈਵਲ ਛੂਟ ਅਲੋਕੇਸ਼ਨ ਤੋਂ ਬਾਅਦ)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (ਵਰਤੀਆਂ ਗਈ ਵੰਡ ਸਟੋਰ ਕਰੋ)
• cgst_amount, sgst_amount, igst_amount (ਗਣਿਤ ਕੀਤੀਆਂ ਰਕਮਾਂ ਸਟੋਰ ਕਰੋ)
• line_total (taxable_value + ਟੈਕਸ ਰਕਮਾਂ)

ਛੂਟਾਂ ਉਹ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ ਸਿਸਟਮ ਗੜਬੜ ਕਰਦੇ ਹਨ। ਇੱਕ ਨਿਯਮ ਫੈਸਲਾ ਕਰੋ ਅਤੇ ਉਸਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕਰੋ। ਜੇ ਛੂਟ ਕਰੀਟਮ ਟੈਕਸ ਤੋਂ ਪਹਿਲਾਂ ਘਟਾਉਂਦੀ ਹੈ (ਆਈਟਮ ਛੂਟ ਅਤੇ ਕੂਪਨ ਲਈ ਆਮ), ਤਾਂ ਮੂਲ ਗ੍ਰੋਸ ਰਕਮ, ਛੂਟ ਰਕਮ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ taxable value ਸਟੋਰ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਆਰਡਰ-ਲੈਵਲ ਕੂਪਨ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਲਾਈਨਾਂ 'ਤੇ ਅਲੋਕੇਟ ਕਰੋ (ਆਮ ਤੌਰ 'ਤੇ ਹਰ ਲਾਈਨ ਦੇ ਪ੍ਰੀ-ਡਿਸਕਾਊਂਟ taxable value ਦੇ ਅਨੁਪਾਤ ਵਿੱਚ) ਅਤੇ ਹਰ ਲਾਈਨ ਦੀ ਅਲੋਕੇਟ ਕੀਤੀ ਛੂਟ ਸਟੋਰ ਕਰੋ ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਟੈਕਸ ਗਣਿਤ ਸਮਝਾਏ ਜਾ ਸਕੇ।

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

ਸ਼ਿਪਿੰਗ ਅਤੇ ਹੈਂਡਲਿੰਗ ਨੂੰ ਛੁਪੇ ਹੋਏ ਐਡ-ਆਨ ਨਾ ਮੰਨੋ। ਇਸਨੂੰ ਇੱਕ ਅਲੱਗ ਇਨਵੌਇਸ ਲਾਈਨ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ ਜਿਸਦਾ ਆਪਣਾ HSN/ਸੇਵਾ ਕੋਡ এবং ਟੈਕਸ ਰੇਟ ਨਿਯਮ ਹੋਣ। ਉਦਾਹਰਨ ਵਜੋਂ, ਦੋ ਉਤਪਾਦਾਂ ਅਤੇ ਇੱਕ ਸ਼ਿਪਿੰਗ ਫੀਸ ਵਾਲੇ ਆਰਡਰ ਵਿਚ ਤਿੰਨ ਲਾਈਨਾਂ ਬਣਦੀਆਂ ਹਨ, ਹਰ ਇੱਕ ਸਟੋਰ ਕੀਤੀ taxable value ਅਤੇ ਟੈਕਸ ਕੰਪੋਨੈਂਟ ਰਕਮਾਂ ਨਾਲ, ਜਿਸ ਨਾਲ ਫਾਇਨੈਂਸ ਰੀਕਨਸੀਲੀਏਸ਼ਨ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ।

ਇਨਵੌਇਸ ਦਸਤਾਵੇਜ਼ ਡੇਟਾ: ਨੰਬਰਿੰਗ, ਤਰੀਖਾਂ, ਟੋਟਲ, ਸਥਿਤੀ

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

ਹੈਡਰ ਬੇਸਿਕਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਇਨਵੌਇਸ ਨੰਬਰ, ਜਾਰੀ ਕਰਨ ਦੀ ਤਰੀਖ (ਇਨਵੌਇਸ 'ਤੇ ਲਿਖੀ ਗਈ ਤਰੀਖ), ਇਨਵੌਇਸ ਕਿਸਮ (ਟੈਕਸ ਇਨਵੌਇਸ, ਐਕਸਪੋਰਟ, B2B, B2C ਆਦਿ), ਅਤੇ ਕਰੰਸੀ। ਯਦਿ ਤੁਹਾਡੀ ਮੁੱਖਤਾਂ INR ਹਨ, ਫਿਰ ਵੀ ਕਰੰਸੀ ਸਟੋਰ ਕਰਨ ਨਾਲ ਐਕਸਪੋਰਟ ਜਾਂ ਮਲਟੀ-ਕਰੰਸੀ ਮਾਰਕੀਟਪਲੇਸ ਲਈ ਗਲਤੀਆਂ ਘਟਦੀਆਂ ਹਨ।

ਨੰਬਰਿੰਗ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਟੀਮਾਂ ਜਲਦੀ ਖਰਾਬ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ ਸੀਰੀਜ਼ ਜਾਂ ਪ੍ਰੀਫਿਕਸ ਰੱਖੋ (ਉਦਾਹਰਨ ਲਈ "FY25-INV-"), ਆਰਥਿਕ ਸਾਲ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਡੇਟਾਬੇਸ ਪੱਧਰ 'ਤੇ ਅਨੋਖਾਪਨ ਨੂੰ ਲਾਜ਼ਮੀ ਬਣਾਓ। ਐਡਮਿਨ ਵਿੱਚ ਪ੍ਰਤੀ ਸੀਰੀਜ਼ "ਅਗਲਾ ਨੰਬਰ" ਕੰਟਰੋਲ ਸਟੋਰ ਕਰੋ ਤਾਂ ਕਿ ਦੋ ਐਡਮਿਨ ਇੱਕੋ ਨੰਬਰ ਨੂੰ ਇੱਕ ਸਮੇਂ ਜਾਰੀ ਨਾ ਕਰ ਸਕਣ।

ਟੋਟਲਾਂ ਨੂੰ ਖੁੱਝਿਆ ਨਾ ਰੱਖੋ; ਹਮੇਸ਼ਾਂ ਵੱਖ-ਵੱਖ ਸਟੋਰ करो, ਨਾ ਕਿ ਕੇਵਲ ਨਿਕਲੇ ਹੋਏ। ਸਬਟੋਟਲ (ਟੈਕਸੇਬਲ ਵੈਲਯੂ), ਕੁੱਲ ਟੈਕਸ, ਗ੍ਰੈਂਡ ਟੋਟਲ, ਅਤੇ ਇੱਕ ਵੱਖਰਾ ਰਾਊਂਡ-ਆਫ਼ ਐਮਾਊਂਟ ਸਟੋਰ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਲਾਈਨ ਆਈਟਮਾਂ ਤੋਂ ਦੁਬਾਰਾ ਗਣਨਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਛੋਟਾ ਨਿਯਮ ਬਦਲਣ ਪੁਰਾਣੇ ਇਨਵੌਇਸਾਂ ਨੂੰ ਫਾਇਲ ਕੀਤੇ ਗਏ ਰਿਟਰਨ ਨਾਲ ਮਿਲਣਾ ਬੰਦ ਕਰ ਸਕਦਾ ਹੈ।

ਸਥਿਤੀਆਂ ਨੂੰ ਅਸਲੀ ਜੀਵਨਚੱਕਰ ਦਰਸਾਉਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਜ਼ਰੂਰਤ 'ਤੇ ਰਿਕਾਰਡ ਨੂੰ ਲੌਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

• Draft (ਸੋਧਯੋਗ)
• Issued (ਨੰਬਰ ਨਿਰਧਾਰਤ, PDF ਜਨਰੇਟ ਕੀਤੀ ਗਈ)
• Cancelled (ਆਡਿਟ ਲਈ ਰੱਖੀ ਗਈ, ਮਿਟਾਈ ਨਾ ਕੀਤੀ ਜਾਵੇ)
• Refunded (ਪੇਮੈਂਟ ਵਾਪਸ ਕੀਤਾ ਗਿਆ, ਸੰਭਵ ਤੌਰ 'ਤੇ ਕਰੈਡਿਟ ਨੋਟ ਲੋੜੀ)
• Credit noted (ਲਿੰਕ ਕੀਤੀ ਕਰੈਡਿਟ ਨੋਟ ਜਾਰੀ ਕੀਤੀ ਗਈ)

ਆਖ਼ਰਕਾਰ, ਜਨਰੇਟ ਕੀਤੇ ਆਰਟੀਫੈਕਟ ਮੈਟਾਡੇਟਾ ਸਟੋਰ ਕਰੋ: PDF ਟੈਮਪਲੇਟ ਵਰਜ਼ਨ, ਜਨਰੇਸ਼ਨ ਟਾਈਮਸਟੈਂਪ, ਅਤੇ ਫਾਈਲ ਆਈਡੈਂਟੀਫਾਇਰ। ਹੈਸ਼ ਵਿਅਕਲਪਿਕ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਪ੍ਰੂਵ ਕਰਨੇ ਚਾਹੁੰਦੇ ਹੋ ਕਿ PDF ਸੋਧਿਆ ਨਹੀਂ ਗਿਆ ਤਾਂ ਲਾਭਦਾਇਕ।

ਉਦਾਹਰਨ: ਜੇ ਸਪੋਰਟ ਏਜੰਟ ਟੈਮਪਲੇਟ ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ PDF ਨੂੰ ਦੁਬਾਰਾ ਜਨਰੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਨਵੌਇਸ ਟੋਟਲ ਅਤੇ ਨੰਬਰ ਇੱਕੋ ਹੀ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ, ਪਰ ਸਟੋਰ ਕੀਤਾ ਟੈਮਪਲੇਟ ਵਰਜ਼ਨ ਦੱਸਦਾ ਹੈ ਕਿ PDF ਲੇਆਉਟ ਕਿਉਂ ਵੱਖਰਾ ਲੱਗ ਰਿਹਾ ਹੈ।

ਉਤਪਾਦ, ਟੈਕਸ ਅਤੇ ਗਾਹਕ ਵੇਰਿਆਂ ਲਈ ਐਡਮਿਨ ਸਕ੍ਰੀਨ

ਜੇ ਤੁਸੀਂ ਸਾਫ਼ GST ਇਨਵੌਇਸ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਨਵੌਇਸ ਸਕ੍ਰੀਨ ਵਿਚੋਂ ਸ਼ੁਰੂਆਤ ਨਾ ਕਰੋ। ਜਾਂਚਣ ਵਾਲੇ ਉਹ ਐਡਮਿਨ ਪੰਨੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਇਹ ਭਰਦੇ ਹਨ। ਇੱਕ ਚੰਗਾ GST ਇਨਵੌਇਸ ਡੇਟਾ ਮਾਡਲ ਛੋਟਾ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਇਨਪੁਟ ਕੰਟਰੋਲਡ ਅਤੇ ਸਥਿਰ ਹੁੰਦੇ ਹਨ।

Product master (SKU ਤੋਂ HSN/SAC)

Product master ਵਹੁੱਧਭਵਿੱਖੀ ਅਸਮੰਜਸ ਉੱਥੇ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਕਠੋਰ ਰੱਖੋ। ਹਰ SKU ਨੂੰ ਸਹੀ ਕੇਵਲ ਇੱਕ ਡਿਫਾਲਟ HSN (ਜਾਂ ਸੇਵਾਵਾਂ ਲਈ SAC) ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾਲ ਹੀ ਇੱਕ ਡਿਫਾਲਟ GST ਰੇਟ ਅਤੇ ਕੋਈ ਵੀ ਐਕਸਪਸ਼ਨ ਜੋ ਸਿਰਫ਼ ਨਿਰਧਾਰਤ ਮਿਤੀਆਂ ਲਈ ਲਾਗੂ ਹੋ।

ਇੱਕ ਵਰਤੋ ਭੋਗੀ ਉਤਪਾਦ ਸਕ੍ਰੀਨ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਚਾਹੀਦੀ ਹੈ:

• SKU ਅਤੇ ਉਤਪਾਦ ਨਾਂ (ਜਿਵੇਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਪ੍ਰਿੰਟ ਹੋਵੇ)
• HSN/SAC ਕੋਡ, GST ਰੇਟ, ਅਤੇ ਟੈਕਸ ਕੈਟੇਗਰੀ (ਜੇ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ)
• Active from/to ਮਿਤੀਆਂ (ਤਾਂ ਜੋ ਬਦਲਾਅ ਪੁਰਾਣੇ ਇਨਵੌਇਸ ਨੂੰ ਦੁਬਾਰਾ ਨਾ ਲਿਖ ਸਕਣ)
• ਕੀਮਤ ਓਵਰਰੇਡ (ਖਾਸ MRPs ਜਾਂ ਚੈਨਲ-ਨਿਰਧਾਰਤ ਪ੍ਰਾਈਸਿੰਗ ਲਈ)
• ਸਥਿਤੀ (active/inactive) ਇੱਕ ਸਪਸ਼ਟ ਕਾਰਨ ਦੇ ਨਾਲ

ਟੈਕਸ ਸੈੱਟਅਪ (ਰੇਟ ਅਤੇ ਅੰਦਰੂਨੀ-ਵਿਰੁੱਧ ਇੰਟਰ-ਸਟੇਟ ਇਨਪੁਟ)

ਇੱਕ "ਕੈਲਕੁਲੇਟਰ" UI ਤੋਂ ਬਚੋ। ਇਸ ਦੀ ਬਜਾਏ, ਉਹ ਇਨਪੁਟ ਸਟੋਰ ਕਰੋ ਜੋ ਤੁਹਾਡੀ ਸਿਸਟਮ ਲਗਾਤਾਰ ਲਾਗੂ ਕਰ ਸਕੇ: ਰੇਟ ਟੇਬਲ, place of supply ਨਿਯਮ ਜੋ ਤੁਸੀਂ ਫਾਲੋ ਕਰਦੇ ਹੋ, ਅਤੇ ਤੁਸੀਂ ਅੰਦਰੂਨੀ-ਵਿਰੁੱਧ ਅੰਤਰ-ਰਾਜ ਕਿਵੇਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ (ਆਮ ਤੌਰ 'ਤੇ supplier state ਅਤੇ ship-to state ਦੀ ਤੁਲਨਾ ਕਰ ਕੇ)।

ਟੈਕਸ ਸਕ੍ਰੀਨ ਨੂੰ ਕੇਵਲ ਫੋਕਸ ਰੱਖੋ: ਕੈਟੇਗਰੀ/HSN ਗਰੁੱਪ ਦੇ ਅਨੁਸਾਰ ਟੈਕਸ ਰੇਟ, ਪ੍ਰਭਾਵੀ ਮਿਤੀਆਂ, ਅਤੇ ਜੇ ਖਰੀਦਦਾਰ ਵੈਧ GSTIN ਦਿੰਦਾ ਹੈ ਤਾਂ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ।

ਗਾਹਕ ਅਤੇ ਕੰਪਨੀ ਪ੍ਰੋਫਾਇਲ (ਇਹ ਕਿੜੇ ਇਨਵੌਇਸ 'ਤੇ ਹਨ)

ਗਾਹਕ ਸਕ੍ਰੀਨ ਨੂੰ GSTIN ਅਤੇ ਉਸਦੀ ਵੈਧਤਾ ਸਥਿਤੀ ਸਮੇਤ ਡਿਫਾਲਟ ਬਿਲਿੰਗ ਅਤੇ ਸ਼ਿਪਿੰਗ ਐਡਰੈੱਸ ਕੈਪਚਰ ਕਰਨੇ ਚਾਹੀਦੇ। ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਫ੍ਰੀਫ਼ਾਰਮ ਰਾਜ ਟਾਈਪ ਕਰਨ ਦੀ ਆਗਿਆ ਨਾ ਦਿਓ; ਇਕ ਕੰਟਰੋਲ ਕੀਤੀ ਸੂਚੀ ਵਰਤੋ ਤਾਂ ਕਿ "KA" ਅਤੇ "Karnataka" ਦੋ ਵੱਖਰੇ ਮੁੱਲ ਨਾ ਬਣ ਜਾਣ।

ਤੁਹਾਡੀ ਕੰਪਨੀ ਪ੍ਰੋਫਾਇਲ ਸਕ੍ਰੀਨ ਵੀ ਬਰਾਬਰ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਕਾਨੂੰਨੀ ਨਾਂ, GSTIN, ਰਜਿਸਟਰਡ ਐਡਰੈੱਸ, ਅਤੇ ਇਨਵੌਇਸ ਸੀਰੀਜ਼ ਸੈਟਿੰਗਜ਼ (ਪ੍ਰੀਫਿਕਸ, ਅਗਲਾ ਨੰਬਰ, ਅਤੇ ਆਰਥਿਕ ਸਾਲ ਦੀਆਂ ਸੀਮਾਵਾਂ)। ਇਸਨੂੰ ਪਰਮਿਸ਼ਨਾਂ ਨਾਲ ਲਾਕ ਕਰੋ ਕਿਉਂਕਿ ਬਦਲਾਅ ਹਰ ਭਵਿੱਖੀ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।

ਆਡਿਟ ਲੋਗ ਬੇਸਿਕਸ (ਭਰੋਸਾ ਅਤੇ ਟ੍ਰੇਸਬਿਲਿਟੀ)

ਤੁਹਾਨੂੰ ਕੋਈ ਜਟਿਲ ਸਿਸਟਮ ਨਹੀਂ ਚਾਹੀਦਾ, ਪਰ ਤੁਹਾਨੂੰ ਇੱਕ ਟ੍ਰੇਲ ਦੀ ਲੋੜ ਹੈ। کون HSN/SAC, GST ਦਰਾਂ, ਇਨਵੌਇਸ ਸੀਰੀਜ਼ ਸੈਟਿੰਗਜ਼ ਜਾਂ ਕੰਪਨੀ GSTIN ਬਦਲਣ ਵਾਲੇ ਨੂੰ ਲੌਗ ਕਰੋ, ਪੁਰਾਣਾ ਮੁੱਲ, ਨਵਾਂ ਮੁੱਲ, ਟਾਈਮਸਟੈਂਪ, ਅਤੇ ਕਾਰਨ ਸਮੇਤ।

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

ਕਦਮ-ਦਰ-ਕਦਮ: ਆਰਡਰ ਤੋਂ ਕਮਪਲਾਇੰਟ ਇਨਵੌਇਸ ਤੱਕ

ਇੱਕ ਕਮਪਲਾਇੰਟ ਇਨਵੌਇਸ ਫਾਰਮੇਟਿੰਗ ਤੋਂ ਵੱਧ ਤੱਥ 'ਤੇ ਸਥਿਰ ਕਰਨ ਦਾ ਕੰਮ ਹੈ—ਸਹੀ ਤੱਥਾਂ ਨੂੰ ਸਹੀ ਸਮੇਂ ਫ੍ਰੀਜ਼ ਕਰਨਾ। ਜੇ ਤੁਸੀਂ ਆਪਣਾ GST ਇਨਵੌਇਸ ਡੇਟਾ ਮਾਡਲ ਇਸ ਫਲੋ ਦੇ ਆਧਾਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਕਰੋ گے, ਤਾਂ ਫਾਇਨੈਂਸ ਕੰਮ ਸਧਾਰਨ ਮੈਚ ਬਣ ਜਾਵੇਗਾ, ਹਫ਼ਤੇਵਾਰ ਜਾਂਚ ਨਹੀਂ।

1) ਗਾਹਕ ਨੇ ਅਸਲ ਵਿੱਚ ਜੋ ਖਰੀਦਿਆ ਉਹ ਫ੍ਰੀਜ਼ ਕਰੋ

ਟੈਕਸ ਕੈਲਕੁਲੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਰਡਰ ਸਨੈਪਸ਼ਾਟ ਲਾਕ ਕਰੋ: ਆਈਟਮ, ਮਾਤਰਾ, ਯੂਨਿਟ ਪ੍ਰਾਈਸ, ਛੂਟ, ਸ਼ਿਪਿੰਗ/ਹੈਂਡਲਿੰਗ ਚਾਰਜ, ਗਾਹਕ GSTIN (ਜੇ ਕੋਈ), ਬਿਲਿੰਗ ਅਤੇ ਸ਼ਿਪਿੰਗ ਐਡਰੈੱਸ, ਅਤੇ place of supply ਸਿਗਨਲ। ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਬਦਲਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, ਚਾਹੇ ਉਤਪਾਦ ਕੀਮਤ ਜਾਂ HSN ਮੈਪਿੰਗ ਬਾਅਦ ਵਿੱਚ ਬਦਲੇ।

2) ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਇਨਵੌਇਸ ਲਾਈਨਾਂ ਵਿੱਚ ਬਦਲੋ (ਨਕਲ ਕੀਤੀਆਂ ਟੈਕਸ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ)

ਸਨੈਪਸ਼ਾਟ ਤੋਂ ਟੈਕਸ ਦੀ ਗਣਨਾ ਕਰੋ ਅਤੇ ਇਨਵੌਇਸ ਲਾਈਨਾਂ ਬਣਾਓ। ਹਰ ਇਨਵੌਇਸ ਲਾਈਨ ਨੂੰ ਸਨੈਪਸ਼ਾਟ 'ਚੋਂ HSN/SAC, ਟੈਕਸ ਦਰ(ਆਂ), ਟੈਕਸੇਬਲ ਵੈਲਯੂ, ਅਤੇ ਉਸ ਵੇਲੇ ਵਰਤੀ ਗਈ ਟੈਕਸ ਰਕਮਾਂ ਨਕਲ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਬਾਅਦ ਵਿੱਚ ਲਾਈਵ ਲੁੱਕਅੱਪ ਕਰਨੀ ਚਾਹੀਦੀ।

3) ਇਨਵੌਇਸ ਜਾਰੀ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਅਟੂਟ ਬਣਾਓ

ਇਨਵੌਇਸ ਨੰਬਰ ਅਤੇ ਜਾਰੀ ਕਰਨ ਦੀ ਤਰੀਖ ਨਿਰਧਾਰਤ ਕਰੋ, ਫਿਰ ਇਨਵੌਇਸ ਨੂੰ issued ਮਾਰਕ ਕਰੋ। ਇਸ ਤੋਂ ਬਾਅਦ ਇਨਵੌਇਸ ਰਿਕਾਰਡ 'ਤੇ ਕੀਮਤ, ਟੈਕਸ ਦਰਾਂ, HSN ਕੋਡ ਅਤੇ ਐਡਰੈੱਸ ਸੋਧਾਂ ਨੂੰ ਲਾਕ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਕੁਝ ਆਗਿਆ ਦੇਣੀ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਗੈਰ-ਵਿੱਤੀ ਨੋਟਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਟੈਗਸ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ।

4) ਅੰਤਿਮ ਦਸਤਾਵੇਜ਼ ਤਿਆਰ ਕਰੋ ਅਤੇ ਕੁੱਲ ਸਟੋਰ ਕਰੋ

ਜਾਰੀ ਕੀਤੀ ਇਨਵੌਇਸ ਤੋਂ PDF/ਪਰਿੰਟ ਵਿਊ ਜਨਰੇਟ ਕਰੋ, ਫਿਰ ਉਹ ਅੰਤਿਮ ਕੁੱਲ ਸਟੋਰ ਕਰੋ ਜੋ ਤੁਸੀਂ ਰਿਪੋਰਟ ਕਰੋਗੇ: ਟੈਕਸੇਬਲ ਟੋਟਲ, CGST/SGST/IGST ਟੋਟਲ, ਰਾਊਂਡਿੰਗ, ਅਤੇ ਗ੍ਰੈਂਡ ਟੋਟਲ। ਜੇ ਤੁਸੀਂ ਚਾਹੋ ਤਾਂ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਵਰਜ਼ਨ ਜਾਂ ਚੈਕਸਮ ਵੀ ਸਟੋਰ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਸਕੋ ਕਿ ਪ੍ਰਿੰਟਆਉਟ ਸਟੋਰਡ ਨੰਬਰਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।

5) ਬਦਲਾਅ ਨੂੰ ਕਾਨੂੰਨੀ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲੋ

ਜਾਰੀ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਬਦਲਾਅ ਨਿਯਮਾਂ ਰਾਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ, ਸੋਧਾਂ ਰਾਹੀਂ ਨਹੀਂ:

• ਗਾਹਕ ਚਾਹੁੰਦਾ ਹੈ ਕੀਮਤ ਸਹੀ ਕਰਨੀ: ਮੂਲ ਇਨਵੌਇਸ ਦਾ ਹਵਾਲਾ ਦੇਂਦੇ ਹੋਏ ਕਰੈਡਿਟ ਨੋਟ (ਜਾਂ ਡੇਬਿਟ ਨੋਟ) ਜਾਰੀ ਕਰੋ।
• ਆਰਡਰ ਜਾਰੀ ਤੋਂ ਬਾਅਦ ਰੱਦ ਹੋ ਗਿਆ: ਜੇ ਆਗਿਆ ਹੈ ਤਾਂ ਇਨਵੌਇਸ ਨੂੰ ਕੈਂਸਲ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਕਰੈਡਿਟ ਨੋਟ ਜਾਰੀ ਕਰੋ।
• ਗਾਹਕ ਜਾਰੀ ਤੋਂ ਬਾਅਦ ਐਡਰੈੱਸ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ: ਇਨਵੌਇਸ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੋ ਨਾ; ਠੀਕ ਦਸਤਾਵੇਜ਼ ਰਾਹੀਂ ਠੀਕ ਕਰੋ ਅਤੇ ਆਡਿਟ ਟ੍ਰੇਲ ਰੱਖੋ।
• ਅੰਸ਼ਿਕ ਰੀਫੰਡ: ਸਿਰਫ ਰੀਫੰਡ ਕੀਤੀਆਂ ਲਾਈਨਾਂ/ਰਕਮ ਲਈ ਕਰੈਡਿਟ ਨੋਟ ਜਾਰੀ ਕਰੋ।
• ਬਦਲੀ ਸ਼ਿਪਮੈਂਟ: ਨਵਾਂ ਆਰਡਰ/ਇਨਵੌਇਸ, ਬਿਨਾਂ ਖਾਮੋਸ਼ੀ ਨਾਲ ਸੋਧ ਕਰਨ ਦੇ।

ਜੇ ਤੁਸੀਂ ਇਹ ਫਲੋ ਆਪਣੇ ਐਡਮਿਨ ਸਕ੍ਰੀਨਾਂ ਵਿੱਚ ਬਿਲਟ ਕਰ ਲਓ (Koder.ai-ਸਟਾਈਲ ਪਲੈਨਿੰਗ ਮੋਡ ਨਕਸ਼ਾ ਬਣਾਉਣ ਲਈ ਮਦਦਗਾਰ), ਤਾਂ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਇਨਵੌਇਸ ਜਨਰੇਟ ਕਰ ਸਕੇਗੀ ਬਿਨਾਂ ਰੀਕਨਸੀਲੀਏਸ਼ਨ ਨੂੰ ਤੋੜੇ।

ਰੀਕਨਸੀਲੀਏਸ਼ਨ ਨੂੰ ਆਸਾਨ ਬਣਾਓ: ਭੁਗਤਾਨ, ਰੀਫੰਡ ਅਤੇ ਰਜਿਸਟਰ

ਰੀਕਨਸੀਲੀਏਸ਼ਨ ਉੱਧਰਨ 'ਤੇ ਤਬਾਹ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਭੁਗਤਾਨ ਆਰਡਰ ਤੇ ਸਿਰਫ਼ "paid/unpaid" ਫਲੈਗ ਵਜੋਂ ਟ੍ਰੀਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਭੁਗਤਾਨ ਅਤੇ ਰੀਫੰਡ ਨੂੰ ਵੱਖ-ਵੱਖ ਰਿਕਾਰਡ ਰੱਖੋ ਜੋ ਆਰਡਰ ਅਤੇ ਇਨਵੌਇਸ ਨੂੰ ਪੌਇੰਟ ਕਰਦੇ ਹਨ, ਤਾਂ ਕਿ ਫਾਇਨੈਂਸ ਬੈਂਕ ਸੈਟਲਮੈਂਟ ਮਿਲਾਉਣ ਦੇ ਬਿਨਾਂ ਇਤਿਹਾਸ ਲਿਖਣ ਨੂੰ ਨਹੀਂ ਕਰਨਾ ਪਵੇ।

ਪੇਮੈਂਟ ਅਤੇ ਰੀਫੰਡ ਰਿਕਾਰਡ ਵੱਖਰੇ (ਇਨਵੌਇਸ ਸੋਧੋ ਨਹੀਂ)

ਇੱਕ ਕਮਪਲਾਇੰਟ ਇਨਵੌਇਸ ਜਾਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸਥਿਰ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਗਾਹਕ ਹਿੱਸਿਆਂ ਵਿੱਚ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ, ਜਾਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਰੀਫੰਡ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਸ ਹਰਕਤ ਨੂੰ ਇੱਕ ਪੇਮੈਂਟ ਜਾਂ ਰੀਫੰਡ ਐਂਟਰੀ ਵਜੋਂ ਦਰਜ ਕਰੋ, ਨਾ ਕਿ ਇਨਵੌਇਸ ਟੋਟਲ ਨੂੰ ਸੋਧੋ।

ਕਮ ਤੋਂ ਕਮ ਫੀਲਡ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਰੀਕਨਸੀਲੀਏਸ਼ਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ:

• Payment: payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Settlement (ਵਿਕਲਪਿਕ ਪਰ ਮਦਦਗਾਰ): settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• Refund: refund_id, order_id, invoice_id, payment_id, credit_note_id (ਜੇ ਜਾਰੀ), gateway_refund_id, amount, reason, refunded_at, status
• Reconciliation keys ਜੋ ਤੁਸੀਂ ਕਦੇ ਮੁੜ-ਵਰਤੋਂ ਨਹੀਂ ਕਰਨੇ: order_id, invoice_id, payment_id, refund_id, credit_note_id

ਜੇ ਗਾਹਕ ਇੱਕ ਆਈਟਮ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਨਵੌਇਸ ਘਟਾਉਣਾ ਨਾ ਕਰੋ। ਮੂਲ ਇਨਵੌਇਸ ਨੂੰ ਲਿੰਕ ਕਰਦਿਆਂ ਕਰੈਡਿਟ ਨੋਟ ਜਾਰੀ ਕਰੋ। ਇਨਵੌਇਸ ਰਜਿਸਟਰ ਸਾਫ਼ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਰੀਫੰਡ ਕਰੈਡਿਟ ਨੋਟ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ।

ਫਾਇਨੈਂਸ ਵਿਊ ਅਤੇ ਐਕਸਪੋਰਟ ਜੋ ਘੰਟੇ ਬਚਾਉਂਦੇ ਹਨ

ਫਾਇਨੈਂਸ ਨੂੰ ਇੱਕ ਐਸੀ ਸਕ੍ਰੀਨ ਦਿਓ ਜੋ ਇਹ ਜਵਾਬ ਦੇਵੇ: ਕੀ ਜਾਰੀ ਕੀਤਾ ਗਿਆ, ਕੀ ਭੁਗਤਾਨ ਹੋਇਆ, ਕੀ ਖੁੱਲ੍ਹਾ ਹੈ, ਅਤੇ ਕੀ ਵਾਪਸ ਕੀਤਾ ਗਿਆ। ਵਰਗੀਜ ਉਮਰ (0-7, 8-30, 31-60, 60+ ਦਿਨ) ਅਤੇ ਸੰਬੰਧਤ ਪੇਮੈਂਟ ਅਤੇ ਰੀਫੰਡ ਐਂਟਰੀਜ਼ ਨੂੰ ਡ੍ਰਿੱਲ-ਡਾਊਨ ਸ਼ਾਮਲ ਕਰੋ।

ਮਹੀਨੇ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਐਕਸਪੋਰਟ:

• ਇਨਵੌਇਸ ਰਜਿਸਟਰ (ਜਾਰੀ, ਰੱਦ ਕੀਤੇ, ਕਰੈਡਿਟ-ਨੋਟ ਕੀਤੇ)
• ਰੇਟ ਅਤੇ HSN/SAC ਅਨੁਸਾਰ ਟੈਕਸ ਸੰਖੇਪ (ਤੁਹਾਡੀ GST ਇਨਵੌਇਸ ਡੇਟਾ ਮਾਡਲ ਨੂੰ ਸਮਰਥਨ)
• ਪੇਮੈਂਟ ਵਿ. ਇਨਵੌਇਸ ਰੀਕਨਸੀਲੀਏਸ਼ਨ (invoice_id, payment totals, balance)
• ਰੀਫੰਡ ਅਤੇ ਕਰੈਡਿਟ ਨੋਟ ਰਜਿਸਟਰ
• ਗੇਟਵੇ ਸੈਟਲਮੈਂਟ ਰਿਪੋਰਟ (payout_id ਤੋਂ invoice/payment ਮੈਪਿੰਗ)

ਉਦਾਹਰਨ: ਇੱਕ ਆਰਡਰ Rs 10,000 ਹੈ, ਅੱਜ Rs 6,000 ਭੁਗਤਾਨ ਹੋਇਆ ਅਤੇ ਅਗਲੇ ਹਫ਼ਤੇ Rs 4,000। ਇਨਵੌਇਸ Rs 10,000 ਹੀ ਰਹਿੰਦੀ। ਤੁਹਾਡੀ ਫਾਇਨੈਂਸ ਵਿਊ ਬਕਾਇਆ Rs 4,000 ਦਿਖਾਏਗੀ ਜਦ ਤੱਕ ਦੂਜਾ ਸੈਟਲਮੈਂਟ ਨਹੀਂ ਆਉਂਦਾ, ਫਿਰ ਬਿਨਾਂ ਜਾਰੀ ਦਸਤਾਵੇਜ਼ ਬਦਲੇ ਪੁਰੀ ਤਰ੍ਹਾਂ ਪੇਡ ਦਰਜ ਕਰਨਗੇ।

ਆਮ ਜਾਲ (traps) ਜੋ ਅਨੁਕੂਲਤਾ ਅਤੇ ਅਸਮੰਜਸ ਮੁੱਦੇ ਪੈਦਾ ਕਰਦੇ ਹਨ

ਜ਼ਿਆਦਾਤਰ GST ਇਨਵੌਇਸ ਸਮੱਸਿਆਵਾਂ "ਟੈਕਸ ਲੌਜਿਕ" ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਰਿਕਾਰਡ ਰੱਖਣ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ: PDF 'ਤੇ ਦੀਆਂ ਗਿਣਤੀਆਂ ਫਾਇਨੈਂਸ ਐਕਸਪੋਰਟਾਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀਆਂ, ਜਾਂ ਇਨਵੌਇਸ ਮਹੀਨਿਆਂ ਬਾਅਦ ਸਮਝਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ।

ਪਹਿਲਾ ਜਾਲ è ਹੈ ਕਿ GST ਸਿਰਫ ਵਿਊ ਸਮੇਂ ਕੈਲਕੁਲੇਟ ਕੀਤਾ ਜਾਵੇ। ਜੇ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਇਨਵੌਇਸ ਖੋਲ੍ਹਣ 'ਤੇ CGST/SGST/IGST ਦੁਬਾਰਾ ਕੈਲਕੁਲੇਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਦਿਨ ਕਿਸੇ ਦਰ-ਬਦਲ, ਗੋਲਾਈ ਨਿਯਮ ਬਦਲ ਜਾਂ ਬੱਗ ਫਿਕਸ ਤੋਂ ਬਾਅਦ ਨਤੀਜੇ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ। ਗਣਿਤ ਕੀਤਾ ਟੈਕਸ ਬ੍ਰੇਕਡਾਊਨ ਉਸ ਵੇਲੇ ਜਦੋਂ ਇਨਵੌਇਸ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਸੀ, ਉਹ ਸਟੋਰ ਕਰੋ, ਭਾਵੇਂ ਤੁਸੀਂ ਇਨਪੁਟ ਵੀ ਸਟੋਰ ਕਰੋ।

ਦੂਜਾ ਜਾਲ è ਹੈ ਜਾਰੀ ਕੀਤੀ ਇਨਵੌਇਸ ਨੂੰ ਸੋਧਣ ਦੀ ਆਗਿਆ ਦੇਣਾ। ਇੱਕ ਵਾਰੀ ਇਨਵੌਇਸ ਫਾਈਨਲ ਹੋਵੇ, ਸੋਧਾਂ ਕਰੈਡਿਟ ਨੋਟ ਜਾਂ ਬਦਲੀ ਫਲੋ ਰਾਹੀਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਵੇਖੋਗੇ "ਗਾਹਕ PDF ਕਿਉਂ ਕਿਤਾਬਾਂ ਨਾਲ ਵੱਖਰਾ ਹੈ?" ਵਾਲੇ ਤਰਕ।

ਇੱਥੇ ਉਹ ਅਸਮੰਜਸ ਪੈਟਰਨ ਹਨ ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਵਾਰ GST ਇਨਵੌਇਸ ਡੇਟਾ ਮਾਡਲ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:

• place of supply ਗੈਰਹਾਜ਼ਰ ਹੈ ਜਾਂ ਰਾਜ ਕੋਡ ਗਲਤ ਹੈ, ਇਸ ਕਰਕੇ IGST ਲੱਗਿਆ ਜਦੋਂ CGST+SGST ਲਗਣੇ ਚਾਹੀਦੇ (ਜਾਂ ਉਲਟ)।
• ਉਤਪਾਦ HSN/SAC ਜਾਂ ਟੈਕਸ ਰੇਟ ਅਪਡੇਟ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਪੁਰਾਣੇ ਆਰਡਰ ਨਵੀਂ ਵੈਲਯੂ ਨਾਲ ਦੁਬਾਰਾ ਗਣਨਾ ਹੋ ਗਏ।
• ਟੈਕਸ ਸਟੋਰ ਕੀਤਾ ਗਿਆ, ਪਰ ਗੋਲਾਈ ਨਿਯਮ UI, PDF ਬਣਾਉਣ ਅਤੇ CSV ਐਕਸਪੋਰਟਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਹਨ।
• ਕਿਸੇ ਜਗ੍ਹਾ ਛੂਟ ਟੈਕਸ ਤੋਂ ਬਾਅਦ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਦੂਜੇ ਜਗ੍ਹਾ ਤੋਂ ਪਹਿਲਾਂ।
• ਰੀਫੰਡ ਮੂਲ ਇਨਵੌਇਸ ਨਾਲ ਸਪਸ਼ਟ ਲਿੰਕ ਦੇ ਬਗੈਰ ਨੈਗੇਟਿਵ ਲਾਈਨ ਆਈਟਮ ਵਜੋਂ ਦਰਜ ਹੋਂਦੇ ਹਨ।

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ: ਤੁਸੀਂ Karnataka ਵਿੱਚ ਇਕ ਗਾਹਕ ਨੂੰ ਵੇਚਦੇ ਹੋ, ਪਰ ਸ਼ਿਪਿੰਗ ਐਡਰੈੱਸ Maharashtra ਵਿੱਚ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਸਿਸਟਮ ਗਲਤੀ ਨਾਲ place of supply ਲਈ ਬਿਲਿੰਗ ਰਾਜ ਚੁਣ ਲੈਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ CGST+SGST ਚਾਰਜ ਕਰ ਸਕਦੇ ਹੋ ਬਜਾਏ IGST ਦੇ। ਜੇ ਤੁਸੀਂ ਫਿਰ ਵੀ ਟੈਕਸ ਨੂੰ ਲਾਈਵ ਦੌਰਾਨ ਦੁਬਾਰਾ ਗਣਨਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਗਲਤੀ ਚੁੱਪਚਾਪ ਬਾਅਦ ਵਿੱਚ "ਠੀਕ" ਵੀ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਫਾਇਨੈਂਸ ਕੋਲ ਜਾਰੀ ਕੀਤੇ ਦਸਤਾਵੇਜ਼ ਨਾਲ ਮੇਲ ਨਾ ਖਾਣ ਵਾਲੀਆਂ ਗਿਣਤੀਆਂ ਰਹਿ ਜਾਣ।

ਜਦੋਂ ਤੁਸੀਂ ਐਡਮਿਨ ਸਕ੍ਰੀਨਾਂ ਬਨਾਉਂਦੇ ਹੋ (ਚਾਹੇ ਕਸਟਮ ਹੋਣ ਜਾਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਦੁਆਰਾ), ਛੋਟੇ ਗਾਰਡਰੇਲ ਜੋੜੋ: ਜਾਰੀ ਇਨਵੌਇਸਾਂ ਨੂੰ ਲਾਕ ਕਰੋ, place-of-supply ਇਨਪੁਟ ਨੂੰ ਕੈਲਕੁਲੇਟ ਕੀਤੇ ਟੈਕਸ ਕਿਸਮ ਦੇ ਕੋਲ ਦਿਖਾਓ, ਅਤੇ ਜਾਰੀ ਸਮੇਂ ਵਰਤੀ HSN, ਦਰ ਅਤੇ ਗੋਲਾਈ ਦਾ ਅਟੂਟ ਸਨੈਪਸ਼ਾਟ ਰੱਖੋ।

ਤੇਜ਼ ਚੈੱਕਲਿਸਟ ਅਤੇ ਅਗਲੇ ਕਦਮ

ਗਾਹਕ ਨੂੰ ਇਨਵੌਇਸ ਭੇਜਣ ਜਾਂ ਇਸਨੂੰ "ਜਾਰੀ" ਮਾਰਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਕੁਝ ਚੈੱਕ ਚਲਾਓ। ਇੱਥੇ ਹੀ ਬਹੁਤ ਛੋਟੀ ਗਲਤੀਆਂ ਬਾਅਦ ਵਿੱਚ ਵੱਡੇ ਰੀਕਨਸੀਲੀਏਸ਼ਨ ਸਿਰਦਰਦ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ GST ਇਨਵੌਇਸ ਡੇਟਾ ਮਾਡਲ ਬਣਾਉ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਚੈੱਕ validation ਨਿਯਮਾਂ ਅਤੇ ਤੁਹਾਡੇ ਐਡਮਿਨ UI ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨਾ ਲਾਭਦਾਇਕ ਹੈ।

ਪ੍ਰਤੀ-ਇਨਵੌਇਸ ਚੈੱਕ (ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ)

• ਹਰੇਕ ਲਾਈਨ ਆਈਟਮ 'ਤੇ HSN/SAC ਮੌਜੂਦ ਹੈ ਅਤੇ ਉਹ ਉਸ ਉਤਪਾਦ ਜਾਂ ਸੇਵਾ ਨਾਲ ਮਿਲਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਵੇਚੀ।
• GSTIN ਨਿਯਮ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਹੋ ਰਹੇ ਹਨ (B2B vs B2C), ਅਤੇ ਬਿਲਿੰਗ ਅਤੇ ਸ਼ਿਪਿੰਗ ਵੇਰਵੇ ਇਕ-ਦੂਜੇ ਦਾ ਵਿਰੋਧ ਨਾ ਕਰਦੇ ਹੋਣ।
• place of supply ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਟੈਕਸ ਸਪਲਿਟ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਸਮਝ ਵਿੱਚ ਆਉਂਦਾ (CGST/SGST vs IGST) ।
• ਕੁੱਲ ਸਹੀ ਮਿਲਦੇ ਹਨ: ਟੈਕਸੇਬਲ ਵੈਲਯੂ, ਹਰੇਕ ਟੈਕਸ ਕੰਪੋਨੈਂਟ, ਰਾਊਂਡਿੰਗ, ਅਤੇ ਗ੍ਰੈਂਡ ਟੋਟਲ।
• ਇੱਕ ਵਾਰੀ ਜਾਰੀ ਹੋਣ 'ਤੇ, ਇਨਵੌਇਸ ਲਾਕ ਹੋ ਜਾਂਦਾ ਹੈ (ਕੋਈ ਖਾਮੋਸ਼ ਸੋਧ ਨਹੀਂ)। ਠੀਕ ਕਰਨ ਲਈ ਕਰੈਡਿਟ ਨੋਟ ਜਾਂ ਰੱਦ ਫਲੋ ਵਰਤੋ, ਇਤਿਹਾਸ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੋ ਨਹੀਂ।

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

ਡੇਟਾ + ਵਰਕਫਲੋ ਚੈੱਕ (ਫਾਇਨੈਂਸ ਨੂੰ ਸਾਫ਼ ਰੱਖਣ ਲਈ)

• ਇਨਵੌਇਸ ਨੰਬਰਿੰਗ ਅਨੋਖੀ, ਨੀਤੀ ਅਨੁਸਾਰ ਕ੍ਰਮਿਕ ਅਤੇ ਕੇਵਲ "issue" ਸਮੇਂ ਬਣਾਈ ਜਾਂਦੀ ਹੈ।
• ਵਰਤੀ ਗਈ ਗਣਿਤੀ ਟੈਕਸ ਰਕਮਾਂ ਨੂੰ ਸਟੋਰ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ ਦਰਾਂ, ਤਾਂ ਕਿ ਰੇਟ ਬਾਅਦ ਵਿੱਚ ਬਦਲਣ 'ਤੇ ਰਿਪੋਰਟ ਸਥਿਰ ਰਹਿਣ।
• ਸਪਸ਼ਟ ਸਥਿਤੀ ਕਦਮ ਮੌਜੂਦ ਹਨ: draft -> issued -> cancelled (ਅਤੇ ਵੱਖਰੇ ਕਰੈਡਿਟ ਨੋਟ ਦਸਤਾਵੇਜ਼)।
• ਰਿਪੋਰਟ ਪੀਰੀਅਡ ਅਨੁਸਾਰ ਮਿਲਦੇ ਹੋਣ: ਇਨਵੌਇਸ ਰਜਿਸਟਰ ਟੋਟਲ ਨੂੰ ਕੈਪਚਰ ਕੀਤੀਆਂ ਭੁਗਤਾਨਾਂ, ਪ੍ਰੋਸੈੱਸ ਕੀਤੇ ਰੀफੰਡਾਂ, ਅਤੇ ਬਕਾਇਆ ਰਸੀਵਏਬਲਸ ਨਾਲ ਜੋੜਨਾ ਚਾਹੀਦਾ ਹੈ।
• ਆਡਿਟ ਫੀਲਡ ਹਮੇਸ਼ਾਂ ਮੌਜੂਦ: created by, issued at, ਅਤੇ ਰੱਦ ਜਾਂ ਕਰੈਡਿਟ ਨੋਟ ਲਈ ਕਾਰਨ ਨੋਟ।

ਅਗਲੇ ਕਦਮ: ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਵੈਲਿਡੇਸ਼ਨ ਲਾਗੂ ਕਰੋ, ਫਿਰ ਕੁਝ ਇਟਰੈਸ਼ਨ ਕਰੋ। Koder.ai ਵਿੱਚ, Planning Mode ਨਾਲ ਰਿਕਾਰਡ ਅਤੇ ਐਡਮਿਨ ਸਕ੍ਰੀਨਾਂ (HSN/SAC ਮੈਪਿੰਗ ਵਾਲੇ ਉਤਪਾਦ, ਗਾਹਕ/GSTIN ਵੇਰਵੇ, ਟੈਕਸ ਨਿਯਮ ਅਤੇ ਇਨਵੌਇਸ) ਨੂੰ ਸਕੈਚ ਕਰੋ। ਐਪ ਜਨਰੇਟ ਕਰੋ, ਕੁਝ ਅਸਲ ਆਰਡਰਾਂ ਨੂੰ ਏਂਡ-ਟੂ-ਏਂਡ ਟੈਸਟ ਕਰੋ, ਫਿਰ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਮਕੈਨਿਜ਼ਮ ਵਰਤ ਕੇ ਵਰਕਫਲੋ ਨੂੰ ਸੰਭਾਲਦੇ ਹੋਏ ਸੁਧਾਰ ਕਰੋ। ਜਦੋਂ deeper customization ਜਾਂ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਹੋਵੇ, ਸੋਅਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰੋ ਅਤੇ ਆਪਣੀ ਆਮ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਅੱਗੇ ਵਧੋ।