1C - ਚੰਗਾ ਅਤੇ ਬੁਰਾ। 1C ਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੋਲੀਵਰਾਂ ਵਿੱਚ ਬਿੰਦੂਆਂ ਦਾ ਪ੍ਰਬੰਧ

ਦੋਸਤੋ ਅਤੇ ਸਹਿਕਰਮੀਓ, ਹਾਲ ਹੀ ਵਿੱਚ ਇੱਕ ਵਿਕਾਸ ਪਲੇਟਫਾਰਮ ਵਜੋਂ 1C ਪ੍ਰਤੀ ਨਫ਼ਰਤ ਦੇ ਨਾਲ Habré 'ਤੇ ਵਧੇਰੇ ਵਾਰ-ਵਾਰ ਲੇਖ ਅਤੇ ਇਸਦੇ ਬਚਾਅ ਕਰਨ ਵਾਲਿਆਂ ਦੁਆਰਾ ਭਾਸ਼ਣ ਦਿੱਤੇ ਗਏ ਹਨ। ਇਹਨਾਂ ਲੇਖਾਂ ਨੇ ਇੱਕ ਗੰਭੀਰ ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ ਕੀਤੀ: ਅਕਸਰ, 1C ਦੇ ਆਲੋਚਕ "ਇਸ ਵਿੱਚ ਮੁਹਾਰਤ ਨਾ ਹਾਸਲ ਕਰਨ" ਦੀ ਸਥਿਤੀ ਤੋਂ ਇਸਦੀ ਆਲੋਚਨਾ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਝਿੜਕਦੇ ਹਨ ਜੋ ਅਸਲ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਹੱਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ, ਇਸਦੇ ਉਲਟ, ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਛੂਹਣਾ ਨਹੀਂ ਜੋ ਅਸਲ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਮਹੱਤਵਪੂਰਣ ਹਨ। ਚਰਚਾ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਵਿਕਰੇਤਾ ਦੁਆਰਾ ਹੱਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ। ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ 1C ਪਲੇਟਫਾਰਮ ਦੀ ਇੱਕ ਸੰਜੀਦਾ ਅਤੇ ਸੰਤੁਲਿਤ ਸਮੀਖਿਆ ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ. ਇਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਇਹ ਕੀ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇਸ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਪਰ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ, ਮਿਠਆਈ ਲਈ, ਇਹ ਇੱਕ ਧਮਾਕੇ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ, ਅਤੇ %technology_name% 'ਤੇ ਤੁਹਾਡੇ ਡਿਵੈਲਪਰ ਇਸ ਨੂੰ ਸੁੱਟ ਕੇ ਸੌ ਸਾਲ ਕਰਨਗੇ। ਇੱਕ ਤੋਂ ਵੱਧ ਸਾਲਾਨਾ ਬਜਟ.

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

ਕੱਟ ਦੇ ਹੇਠਾਂ 1C 'ਤੇ, 1C ਦੇ ਆਲੋਚਕਾਂ 'ਤੇ, Java, .NET ਅਤੇ ਆਮ ਤੌਰ' ਤੇ ਬਹੁਤ ਸਾਰੇ ਮੋਟੇ ਹਮਲੇ ਹਨ... ਪੱਖਾ ਭਰਿਆ ਹੋਇਆ ਹੈ, ਸੁਆਗਤ ਹੈ!

ਮੇਰੇ ਬਾਰੇ

ਮੈਂ ਲਗਭਗ 2004 ਤੋਂ ਗੱਲਬਾਤ ਦੇ ਵਿਸ਼ੇ ਤੋਂ ਜਾਣੂ ਹਾਂ। ਮੈਂ ਸ਼ਾਇਦ ਉਦੋਂ ਤੋਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਕਰ ਰਿਹਾ ਹਾਂ ਜਦੋਂ ਮੈਂ 6 ਸਾਲ ਦਾ ਸੀ, ਉਸੇ ਪਲ ਤੋਂ ਜਦੋਂ ਮੈਨੂੰ ਪ੍ਰੋਫੈਸਰ ਫੋਰਟਰਨ ਬਾਰੇ ਇੱਕ ਬਿੱਲੀ, ਇੱਕ ਚਿੜੀ ਅਤੇ ਇੱਕ ਕੈਟਰਪਿਲਰ ਬਾਰੇ ਕਾਮਿਕਸ ਦੇ ਨਾਲ ਇੱਕ ਕਿਤਾਬ ਮਿਲੀ। ਮੈਂ ਉਹਨਾਂ ਪ੍ਰੋਗਰਾਮਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਜੋ ਬਿੱਲੀ ਨੇ ਕਿਤਾਬ ਵਿੱਚ ਤਸਵੀਰਾਂ ਤੋਂ ਲਿਖੀਆਂ ਅਤੇ ਪਤਾ ਲਗਾਇਆ ਕਿ ਉਹਨਾਂ ਨੇ ਕੀ ਕੀਤਾ. ਅਤੇ ਹਾਂ, ਮੇਰੇ ਕੋਲ ਉਸ ਸਮੇਂ ਅਸਲ ਕੰਪਿਊਟਰ ਨਹੀਂ ਸੀ, ਪਰ ਕਿਤਾਬ ਦੇ ਫੈਲਣ 'ਤੇ ਇੱਕ ਡਰਾਇੰਗ ਸੀ ਅਤੇ ਮੈਂ ਇਮਾਨਦਾਰੀ ਨਾਲ ਕਾਗਜ਼ ਦੇ ਬਟਨਾਂ ਨੂੰ ਦਬਾਇਆ, ਉਹਨਾਂ ਕਮਾਂਡਾਂ ਨੂੰ ਦਾਖਲ ਕੀਤਾ ਜੋ ਮੈਂ ਬਿੱਲੀ X 'ਤੇ ਜਾਸੂਸੀ ਕੀਤੀ ਸੀ।

ਫਿਰ ਸਕੂਲ ਵਿੱਚ BK0011 ਅਤੇ ਬੇਸਿਕ, ਯੂਨੀਵਰਸਿਟੀ ਵਿੱਚ C++ ਅਤੇ ਅਸੈਂਬਲਰ, ਫਿਰ 1C, ਅਤੇ ਫਿਰ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਸਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਯਾਦ ਕਰਨ ਵਿੱਚ ਮੈਂ ਬਹੁਤ ਆਲਸੀ ਹਾਂ। ਪਿਛਲੇ 15 ਸਾਲਾਂ ਤੋਂ, ਮੈਂ ਮੁੱਖ ਤੌਰ 'ਤੇ 1C ਵਿੱਚ ਸ਼ਾਮਲ ਰਿਹਾ ਹਾਂ, ਨਾ ਸਿਰਫ ਕੋਡਿੰਗ ਦੇ ਰੂਪ ਵਿੱਚ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ 1C ਵਿੱਚ. ਇੱਥੇ ਕੰਮ, ਪ੍ਰਸ਼ਾਸਨ ਅਤੇ ਡਿਵੋਪਸ ਸੈੱਟ ਕਰਨਾ। ਪਿਛਲੇ 5 ਸਾਲਾਂ ਤੋਂ ਮੈਂ ਹੋਰ 1C ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਵਿਕਾਸ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਟੂਲ ਬਣਾਉਣ, ਲੇਖ ਅਤੇ ਕਿਤਾਬਾਂ ਲਿਖਣ ਦੇ ਰੂਪ ਵਿੱਚ ਸਮਾਜਿਕ ਤੌਰ 'ਤੇ ਉਪਯੋਗੀ ਗਤੀਵਿਧੀਆਂ ਵਿੱਚ ਰੁੱਝਿਆ ਹੋਇਆ ਹਾਂ।

ਆਓ ਚਰਚਾ ਦੇ ਵਿਸ਼ੇ 'ਤੇ ਫੈਸਲਾ ਕਰੀਏ

ਪਹਿਲਾਂ, ਆਓ ਪਰਿਭਾਸ਼ਿਤ ਕਰੀਏ ਕਿ ਅਸੀਂ ਕਿਸ ਬਾਰੇ ਗੱਲ ਕਰਨ ਜਾ ਰਹੇ ਹਾਂ, ਕਿਉਂਕਿ ਅੱਖਰਾਂ "1C" ਦਾ ਮਤਲਬ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, "1C" ਅੱਖਰਾਂ ਦੁਆਰਾ ਸਾਡਾ ਅਰਥ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਆਧੁਨਿਕ, ਅੱਠਵੇਂ ਸੰਸਕਰਣ ਦਾ ਵਿਕਾਸ ਫਰੇਮਵਰਕ "1C: Enterprise" ਹੋਵੇਗਾ। ਅਸੀਂ ਨਿਰਮਾਤਾ ਅਤੇ ਇਸ ਦੀਆਂ ਨੀਤੀਆਂ ਬਾਰੇ ਜ਼ਿਆਦਾ ਗੱਲ ਨਹੀਂ ਕਰਾਂਗੇ (ਪਰ ਸਾਨੂੰ ਥੋੜਾ ਜਿਹਾ ਕਰਨਾ ਪਵੇਗਾ) ਅਸੀਂ ਇਸ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਲਿਖੇ ਗਏ ਖਾਸ ਐਪਲੀਕੇਸ਼ਨਾਂ 'ਤੇ ਚਰਚਾ ਨਹੀਂ ਕਰਾਂਗੇ। ਤਕਨਾਲੋਜੀ ਵੱਖਰੀ ਹੈ, ਐਪਲੀਕੇਸ਼ਨ ਉਰਫ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵੱਖਰੀਆਂ ਹਨ।

ਉੱਚ-ਪੱਧਰੀ ਆਰਕੀਟੈਕਚਰ 1C: ਐਂਟਰਪ੍ਰਾਈਜ਼

ਇਹ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ ਕਿ ਮੈਂ "ਫ੍ਰੇਮਵਰਕ" ਸ਼ਬਦ ਦਾ ਜ਼ਿਕਰ ਕਰਦਾ ਹਾਂ. ਇੱਕ ਡਿਵੈਲਪਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, 1C ਪਲੇਟਫਾਰਮ ਇੱਕ ਫਰੇਮਵਰਕ ਹੈ. ਅਤੇ ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਬਿਲਕੁਲ ਇੱਕ ਫਰੇਮਵਰਕ ਵਾਂਗ ਇਲਾਜ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਇਸ ਨੂੰ ਸਪਰਿੰਗ ਜਾਂ ASP.NET ਦੇ ਰੂਪ ਵਿੱਚ ਸੋਚੋ, ਕੁਝ ਰਨਟਾਈਮ (ਕ੍ਰਮਵਾਰ JVM ਜਾਂ CLR) ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਕਿ ਰਵਾਇਤੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ("ਨਹੀਂ 1C") ਦੀ ਦੁਨੀਆ ਵਿੱਚ, ਫਰੇਮਵਰਕ, ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਅਤੇ ਖਾਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਵੰਡ ਕੁਦਰਤੀ ਹੈ, ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਇਹ ਹਿੱਸੇ ਆਮ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਨਿਰਮਾਤਾਵਾਂ ਦੁਆਰਾ ਵਿਕਸਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। 1C ਸੰਸਾਰ ਵਿੱਚ, ਵਿਕਾਸ ਫਰੇਮਵਰਕ ਅਤੇ ਰਨਟਾਈਮ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵੱਖਰਾ ਕਰਨ ਦਾ ਰਿਵਾਜ ਨਹੀਂ ਹੈ, ਇਸਦੇ ਇਲਾਵਾ, ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਿਖੀਆਂ ਗਈਆਂ ਖਾਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵੀ ਮੁੱਖ ਤੌਰ 'ਤੇ 1C ਦੁਆਰਾ ਵਿਕਸਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਕੁਝ ਉਲਝਣ ਪੈਦਾ ਹੁੰਦਾ ਹੈ. ਇਸ ਲਈ, ਲੇਖ ਦੇ ਫਰੇਮਵਰਕ ਦੇ ਅੰਦਰ, ਸਾਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਪਾਸਿਆਂ ਤੋਂ 1C ਨੂੰ ਵਿਚਾਰਨਾ ਹੋਵੇਗਾ ਅਤੇ ਇਸਨੂੰ ਕਈ ਕੋਆਰਡੀਨੇਟ ਧੁਰਿਆਂ ਦੇ ਨਾਲ ਵਰਗੀਕ੍ਰਿਤ ਕਰਨਾ ਹੋਵੇਗਾ। ਅਤੇ ਹਰੇਕ ਕੋਆਰਡੀਨੇਟ ਧੁਰੇ ਵਿੱਚ ਅਸੀਂ ਭੂਰੇ ਪਦਾਰਥ ਦਾ ਇੱਕ ਬੇਲਚਾ ਪਾਵਾਂਗੇ ਅਤੇ ਮੌਜੂਦਾ ਘੋਲ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਫਾਇਦਿਆਂ ਅਤੇ ਨੁਕਸਾਨਾਂ ਨੂੰ ਵੇਖਾਂਗੇ।

1C 'ਤੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ

ਖਰੀਦਦਾਰ ਲਈ 1 ਸੀ

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

1C ਖਰੀਦਦਾਰ ਲਈ ਇਹ ਮਾਰਕੀਟ ਲਈ ਇੱਕ ਤੇਜ਼ ਸਮਾਂ ਹੈ। ਤੇਜ਼। Java, C# ਜਾਂ JS ਨਾਲੋਂ ਤੇਜ਼। ਔਸਤ। ਹਸਪਤਾਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ. ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਰੀਐਕਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀ ਇੱਕ ਬਿਜ਼ਨਸ ਕਾਰਡ ਵੈਬਸਾਈਟ ਬਿਹਤਰ ਹੋਵੇਗੀ, ਪਰ ਇੱਕ WMS ਸਿਸਟਮ ਦਾ ਬੈਕਐਂਡ 1C 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਲਾਂਚ ਹੋਵੇਗਾ।

ਇੱਕ ਸੰਦ ਵਜੋਂ 1 ਸੀ

ਹਰੇਕ ਤਕਨੀਕੀ ਹੱਲ ਵਿੱਚ ਲਾਗੂ ਹੋਣ ਦੀਆਂ ਸੀਮਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ। 1C ਇੱਕ ਆਮ-ਉਦੇਸ਼ ਵਾਲੀ ਭਾਸ਼ਾ ਨਹੀਂ ਹੈ; ਇਹ ਇਸਦੇ ਢਾਂਚੇ ਤੋਂ ਵੱਖ ਨਹੀਂ ਰਹਿੰਦੀ ਹੈ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਲੋੜ ਹੋਵੇ ਤਾਂ 1C ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ:

• ਸਰਵਰ ਐਪਲੀਕੇਸ਼ਨ
• ਐਪਲੀਕੇਸ਼ਨ ਜਿੱਥੇ ਵਿੱਤ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ
• ਤਿਆਰ UI, ORM, ਰਿਪੋਰਟਿੰਗ, XML/JSON/COM/PDF/YourDataTransferingFormat ਦੇ ਨਾਲ
• ਪਿਛੋਕੜ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਨੌਕਰੀਆਂ ਲਈ ਸਮਰਥਨ ਦੇ ਨਾਲ
• ਭੂਮਿਕਾ-ਅਧਾਰਿਤ ਸੁਰੱਖਿਆ ਦੇ ਨਾਲ
• ਸਕ੍ਰਿਪਟਯੋਗ ਵਪਾਰਕ ਤਰਕ ਦੇ ਨਾਲ
• ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਉਣ ਦੀ ਸਮਰੱਥਾ ਅਤੇ ਘੱਟ ਸਮੇਂ-ਬਜ਼ਾਰ ਲਈ

ਜੇਕਰ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ 1C ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ:

• ਮਸ਼ੀਨ ਸਿਖਲਾਈ
• GPU ਗਣਨਾਵਾਂ
• ਕੰਪਿਊਟਰ ਗਰਾਫਿਕਸ
• ਗਣਿਤਿਕ ਗਣਨਾਵਾਂ
• CAD ਸਿਸਟਮ
• ਸਿਗਨਲ ਪ੍ਰੋਸੈਸਿੰਗ (ਆਵਾਜ਼, ਵੀਡੀਓ)
• ਹਜ਼ਾਰਾਂ ਆਰਪੀਐਸ ਦੇ ਨਾਲ http ਕਾਲਾਂ ਨੂੰ ਹਾਈਲੋਡ ਕਰੋ

ਇੱਕ ਨਿਰਮਾਣ ਕੰਪਨੀ ਵਜੋਂ 1 ਸੀ

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

• ਵਿੱਤੀ ਲੇਖਾ
• ਕਾਰੋਬਾਰੀ ਤਰਕ ਦੀ ਆਸਾਨ ਅਨੁਕੂਲਤਾ
• ਵਿਭਿੰਨ IT ਲੈਂਡਸਕੇਪਾਂ ਵਿੱਚ ਵਿਆਪਕ ਏਕੀਕਰਣ ਸੰਭਾਵਨਾਵਾਂ

ਇੱਕ ਨਿਰਮਾਤਾ ਦੇ ਰੂਪ ਵਿੱਚ, 1C ਦਾ ਮੰਨਣਾ ਹੈ ਕਿ ਇਹ ਉਹ ਰਣਨੀਤੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਇੱਕ ਜਿੱਤ-ਜਿੱਤ ਮੋਡ ਵਿੱਚ ਭਾਈਵਾਲਾਂ ਅਤੇ ਗਾਹਕਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ। ਤੁਸੀਂ ਇਸ ਨਾਲ ਬਹਿਸ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਲਗਭਗ ਇਸ ਤਰ੍ਹਾਂ ਹੈ ਕਿ ਕੰਪਨੀ ਆਪਣੇ ਆਪ ਨੂੰ ਕਿਵੇਂ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ: ਕਾਰੋਬਾਰੀ ਸਮੱਸਿਆਵਾਂ ਦੇ ਤਿਆਰ-ਕੀਤੇ ਹੱਲ ਜੋ ਭਾਈਵਾਲਾਂ ਦੁਆਰਾ ਤੇਜ਼ੀ ਨਾਲ ਅਨੁਕੂਲਿਤ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਅਤੇ ਕਿਸੇ ਵੀ IT ਲੈਂਡਸਕੇਪ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਹੋ ਸਕਦੇ ਹਨ।

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

- ਹੇ, ਕਾਰੋਬਾਰ, ਕੀ ਤੁਸੀਂ ਆਪਣੇ 1C ਵਿੱਚ OOP ਚਾਹੁੰਦੇ ਹੋ?
- ਕੀ ਇਹ ਮੇਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ?
- ਕੌਣ ਜਾਣਦਾ ਹੈ...
- ਫਿਰ ਕੋਈ ਲੋੜ ਨਹੀਂ

ਇਹ ਪਹੁੰਚ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਕੌਣ ਇਸ ਨੂੰ ਦੇਖ ਰਿਹਾ ਹੈ, ਚੰਗਾ ਜਾਂ ਮਾੜਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ। ਇਸ ਤੱਥ ਬਾਰੇ ਬੋਲਦੇ ਹੋਏ ਕਿ 1C ਵਿੱਚ ਕੋਈ ਵਿਸ਼ੇਸ਼ਤਾ X ਨਹੀਂ ਹੈ, ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਇਹ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਨਹੀਂ ਹੈ, ਪਰ "ਲਾਗੂ ਕਰਨ ਦੀ ਲਾਗਤ ਬਨਾਮ ਲਾਭ ਦੀ ਰਕਮ" ਵਿਕਲਪ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਹੈ।

ਤਕਨੀਕੀ ਵਰਗੀਕਰਨ

"ਵਾਸਤਵ ਵਿੱਚ, Odinesniks ਸਭ ਤੋਂ ਵਧੀਆ ਪੈਟਰਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਆਪਣੀ ਪੂਰੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਦੇਖਭਾਲ ਕਰਨ ਵਾਲੇ ਵਿਧੀ ਵਿਗਿਆਨੀਆਂ ਅਤੇ 1C ਪਲੇਟਫਾਰਮ ਦੇ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਧਿਆਨ ਨਾਲ ਚੁਣੇ ਗਏ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਪ੍ਰਬੰਧਿਤ ਫਾਰਮ ਲਈ ਆਪਣਾ ਮੂਰਖ ਕੋਡ ਲਿਖਦੇ ਹੋ, ਅਸਲ ਵਿੱਚ ਤੁਸੀਂ ਵਰਤ ਰਹੇ ਹੋ ਮਾਡਲ-ਦ੍ਰਿਸ਼-ਕੰਟਰੋਲਰ с ਡਬਲ-ਵੇਅ ਡਾਟਾ ਬਾਈਡਿੰਗ в ਤਿੰਨ-ਲੇਅਰਡ-ਡਾਟਾ-ਐਪ-ਇੰਜਣ, ਸੁਆਦਲਾ ਉੱਚ ਪੱਧਰੀ ਵਸਤੂ-ਸੰਬੰਧ-ਮੈਪਿੰਗ ਅਧਾਰ 'ਤੇ ਘੋਸ਼ਣਾਤਮਕ ਮੈਟਾਡੇਟਾ ਵਰਣਨਇਸ ਦੇ ਆਪਣੇ ਹੋਣ ਪਲੇਟਫਾਰਮ-ਸੁਤੰਤਰ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾ, C ਘੋਸ਼ਣਾਤਮਕ ਡੇਟਾ-ਸੰਚਾਲਿਤ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ, ਸੰਪੂਰਨ ਪਾਰਦਰਸ਼ੀ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਡੋਮੇਨ-ਅਧਾਰਿਤ ਪ੍ਰੋਗਰਾਮ ਭਾਸ਼ਾ.

ਜਿੱਥੇ 1C ਡਿਵੈਲਪਰ ਆਪਣੇ ਪੱਛਮੀ ਸਹਿਯੋਗੀਆਂ ਤੋਂ ਵੱਖਰੇ ਹਨ, ਉਹ PR ਵਿੱਚ ਹੈ। ਉਹ ਕਿਸੇ ਵੀ ਬਕਵਾਸ ਨੂੰ ਵੱਡਾ ਨਾਮ ਦੇਣਾ ਅਤੇ ਗੰਦੇ ਥੈਲੇ ਦੀ ਤਰ੍ਹਾਂ ਇਸ ਦੇ ਨਾਲ ਭੱਜਣਾ ਪਸੰਦ ਕਰਦੇ ਹਨ।
A. Orefkov

1C ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਇੱਕ ਕਲਾਸਿਕ 3-ਟੀਅਰ ਆਰਕੀਟੈਕਚਰ ਹੈ, ਜਿਸ ਦੇ ਕੇਂਦਰ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਹੈ (ਜਾਂ ਛੋਟੇ ਦੁਕਾਨਦਾਰਾਂ ਲਈ ਥੋੜ੍ਹੇ ਪੈਸੇ ਲਈ ਇਸਦਾ ਇਮੂਲੇਸ਼ਨ)। ਜਾਂ ਤਾਂ MS SQL ਜਾਂ Postgres ਨੂੰ DBMS ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਓਰੇਕਲ ਅਤੇ IBM DB2 ਲਈ ਵੀ ਸਮਰਥਨ ਹੈ, ਪਰ ਇਹ ਕੋਈ ਵੀ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਕੀ ਹੋਵੇਗਾ ਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਡੇਟਾਬੇਸ 'ਤੇ ਮੱਧਮ ਅਤੇ ਉੱਚ ਲੋਡ ਦੇ ਅਧੀਨ 1C ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹੋ। ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ 1C ਖੁਦ ਇਹ ਨਹੀਂ ਜਾਣਦਾ.

ਕਲਾਇੰਟ ਦਾ ਹਿੱਸਾ ਜਾਂ ਤਾਂ ਉਪਭੋਗਤਾ ਦੀ ਮਸ਼ੀਨ ਜਾਂ ਵੈਬ ਕਲਾਇੰਟ 'ਤੇ ਸਥਾਪਤ ਇੱਕ ਪਤਲਾ ਕਲਾਇੰਟ ਹੁੰਦਾ ਹੈ। ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮਰ 2 ਵੱਖ-ਵੱਖ ਕੋਡ ਨਹੀਂ ਲਿਖਦੇ ਹਨ, ਉਹ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ, ਇੱਕ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ ਜੇਕਰ ਕੋਈ ਇੱਛਾ ਜਾਂ ਲੋੜ ਹੋਵੇ। ਉੱਥੇ ਕੌਣ ਅੱਗੇ ਅਤੇ ਬੈਕਐਂਡ, node.js ਲਈ ਇੱਕ ਸੱਚਾ ਪੂਰਾ ਸਟੈਕ ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਭਾਸ਼ਾ ਚਾਹੁੰਦਾ ਸੀ? ਉਹ ਅੰਤ ਤੱਕ ਬਿਲਕੁਲ ਉਹੀ ਕੰਮ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਨਹੀਂ ਹੋਏ। ਇੱਕ ਅਸਲੀ ਪੂਰਾ ਸਟੈਕ ਮੌਜੂਦ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਇਸਨੂੰ 1C ਵਿੱਚ ਲਿਖਣਾ ਪਵੇਗਾ। ਕਿਸਮਤ ਦੀ ਵਿਡੰਬਨਾ, ਅਜਿਹੀਆਂ ਗੱਲਾਂ :)

ਕਲਾਉਡ SaaS ਹੱਲ 1C: Fresh ਬ੍ਰਾਊਜ਼ਰ ਮੋਡ ਵਿੱਚ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ 1C ਨਹੀਂ ਖਰੀਦ ਸਕਦੇ ਹੋ, ਪਰ ਇੱਕ ਛੋਟਾ ਡਾਟਾਬੇਸ ਕਿਰਾਏ 'ਤੇ ਲੈ ਸਕਦੇ ਹੋ ਅਤੇ ਉੱਥੇ ਸ਼ਵਰਮਾ ਦੀ ਵਿਕਰੀ 'ਤੇ ਨਜ਼ਰ ਰੱਖ ਸਕਦੇ ਹੋ। ਸਿਰਫ਼ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ, ਕੁਝ ਵੀ ਸਥਾਪਿਤ ਜਾਂ ਸੰਰਚਿਤ ਕੀਤੇ ਬਿਨਾਂ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇੱਥੇ ਇੱਕ ਵਿਰਾਸਤੀ ਕਲਾਇੰਟ ਹੈ, ਜਿਸ ਨੂੰ 1C ਵਿੱਚ "ਨਿਯਮਿਤ ਐਪਲੀਕੇਸ਼ਨ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਵਿਰਾਸਤ ਵਿਰਾਸਤ ਹੈ, 2002 ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ, ਪਰ ਅਸੀਂ ਅਜੇ ਵੀ ਈਕੋਸਿਸਟਮ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ।

1C ਸਰਵਰ ਭਾਗ ਕਲੱਸਟਰ ਵਿੱਚ ਨਵੀਆਂ ਮਸ਼ੀਨਾਂ ਜੋੜ ਕੇ ਕਲੱਸਟਰਿੰਗ ਅਤੇ ਸਕੇਲਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਕਾਪੀਆਂ ਤੋੜ ਦਿੱਤੀਆਂ ਗਈਆਂ ਹਨ ਅਤੇ ਇਸ ਬਾਰੇ ਲੇਖ ਵਿੱਚ ਇੱਕ ਵੱਖਰਾ ਭਾਗ ਹੋਵੇਗਾ। ਸੰਖੇਪ ਵਿੱਚ, ਇਹ HAProxy ਦੇ ਪਿੱਛੇ ਬਿਲਕੁਲ ਇੱਕੋ ਜਿਹੀਆਂ ਉਦਾਹਰਣਾਂ ਨੂੰ ਜੋੜਨ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ।

ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਮੈਂਟ ਫਰੇਮਵਰਕ ਆਪਣੀ ਖੁਦ ਦੀ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਰੂਸੀ ਵਿੱਚ ਅਨੁਵਾਦ ਕੀਤੇ ਗਏ ਇੱਕ ਥੋੜ੍ਹਾ ਸੁਧਾਰਿਆ VB6 ਵਰਗਾ ਹੈ। ਉਹਨਾਂ ਲੋਕਾਂ ਲਈ ਜੋ ਰੂਸੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਨਫ਼ਰਤ ਕਰਦੇ ਹਨ, ਜੋ ਇਹ ਨਹੀਂ ਮੰਨਦੇ ਕਿ “ਜੇ” ਦਾ ਅਨੁਵਾਦ “ਜੇਕਰ” ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਦੂਜਾ ਸੰਟੈਕਸ ਵਿਕਲਪ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ। ਉਹ. ਜੇ ਤੁਸੀਂ ਚਾਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ 1C ਵਿੱਚ ਇਸ ਤਰੀਕੇ ਨਾਲ ਲਿਖ ਸਕਦੇ ਹੋ ਕਿ ਇਹ VB ਤੋਂ ਵੱਖਰਾ ਨਹੀਂ ਹੈ।

ਇਹ ਬਹੁਤ ਹੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਉਹਨਾਂ ਦੇ ਪਲੇਟਫਾਰਮ ਪ੍ਰਤੀ 1C ਉਪਨਾਮਾਂ ਦੀ ਨਫ਼ਰਤ ਦਾ ਮੁੱਖ ਕਾਰਨ ਹੈ। ਆਓ ਇਸਦਾ ਸਾਹਮਣਾ ਕਰੀਏ, ਬਿਨਾਂ ਕਾਰਨ ਨਹੀਂ. ਭਾਸ਼ਾ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸਰਲ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਘੱਟੋ ਘੱਟ CIS ਵਿੱਚ ਇੱਕ ਪੈਮਾਨੇ 'ਤੇ "ਵਿਕਾਸਕਾਰ, ਵਿਕਾਸਕਾਰ" ਮੰਤਰ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਅਜਿਹੇ ਹੱਲ ਦਾ ਵਪਾਰਕ ਤੱਤ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ: ਵਧੇਰੇ ਡਿਵੈਲਪਰ, ਵੱਧ ਮਾਰਕੀਟ ਕਵਰੇਜ. ਇਹ 45% ਤੋਂ 95% ਤੱਕ ਦੇ ਵੱਖ-ਵੱਖ ਅਨੁਮਾਨਾਂ ਅਨੁਸਾਰ ਸੱਚ ਹੋਇਆ। ਮੈਂ ਤੁਰੰਤ ਕਹਾਂਗਾ ਕਿ ਜਿਸ ਭਾਸ਼ਾ ਵਿੱਚ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਉਸ ਵਿੱਚ ਲਿਖਣਾ ਅਸਲ ਵਿੱਚ ਆਸਾਨ ਹੈ। ਅਤੇ ਮੈਂ ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਜਾਣਦਾ ਹਾਂ।

ਆਓ ਭਾਸ਼ਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ।

1C ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ

ਉਸੇ ਸਮੇਂ ਸਿਸਟਮ ਦੇ ਮਜ਼ਬੂਤ ​​​​ਅਤੇ ਕਮਜ਼ੋਰ ਬਿੰਦੂ. ਆਸਾਨ ਦਾਖਲਾ ਅਤੇ ਪੜ੍ਹਨਯੋਗਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ. ਦੂਜੇ ਪਾਸੇ, 8 ਵਿੱਚ ਸੰਸਕਰਣ 2002 ਦੇ ਜਾਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਅਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਹ ਨੈਤਿਕ ਤੌਰ 'ਤੇ ਪੁਰਾਣਾ ਹੈ। ਕੋਈ ਕਹੇਗਾ "ਮੁੱਖ ਕਮਜ਼ੋਰੀ ਇਹ ਹੈ ਕਿ ਕੋਈ ਓਓਪੀ ਨਹੀਂ ਹੈ" ਅਤੇ ਉਹ ਗਲਤ ਹੋਣਗੇ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਪੀਐਲਓ ਨਾ ਸਿਰਫ ਨੂਰਾਲੀਵ ਨੂੰ ਪਸੰਦ ਕਰਦਾ ਹੈ, ਸਗੋਂ ਟੋਰਵਾਲਡਜ਼ ਨੂੰ ਵੀ ਪਸੰਦ ਕਰਦਾ ਹੈ. ਅਤੇ ਦੂਜਾ, ਓਓਪੀ ਅਜੇ ਵੀ ਮੌਜੂਦ ਹੈ.

ਡਿਵੈਲਪਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਉਸ ਕੋਲ DBMS 'ਤੇ ਪ੍ਰਦਰਸ਼ਿਤ ਬੇਸ ਕਲਾਸਾਂ ਦੇ ਨਾਲ ਇੱਕ ਫਰੇਮਵਰਕ ਹੈ। ਡਿਵੈਲਪਰ ਬੇਸ ਕਲਾਸ "ਡਾਇਰੈਕਟਰੀ" ਲੈ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸ ਤੋਂ "ਕਲਾਇੰਟਸ" ਡਾਇਰੈਕਟਰੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਇਸ ਵਿੱਚ ਨਵੇਂ ਕਲਾਸ ਫੀਲਡਾਂ ਨੂੰ ਜੋੜ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, INN ਅਤੇ ਪਤਾ, ਅਤੇ ਨਾਲ ਹੀ, ਜੇਕਰ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਇਹ ਬੇਸ ਕਲਾਸ ਦੇ ਢੰਗਾਂ ਨੂੰ ਓਵਰਰਾਈਡ (ਓਵਰਰਾਈਡ) ਕਰ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, OnWrite/AtRecord ਵਿਧੀ।

ਫਰੇਮਵਰਕ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਡੂੰਘੀ ਵਿਰਾਸਤ ਦੀ ਬਹੁਤ ਘੱਟ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ OOP ਵਿੱਚ ਪਾਬੰਦੀ, ਮੇਰੇ ਵਿਚਾਰ ਵਿੱਚ, ਅਰਥ ਰੱਖਦਾ ਹੈ. 1C ਡੋਮੇਨ ਸੰਚਾਲਿਤ ਵਿਕਾਸ 'ਤੇ ਕੇਂਦ੍ਰਤ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਵਿਕਸਤ ਕੀਤੇ ਜਾ ਰਹੇ ਹੱਲ ਦੇ ਵਿਸ਼ਾ ਖੇਤਰ ਬਾਰੇ ਸੋਚਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਚੰਗਾ ਹੈ। ਇੱਥੇ ਨਾ ਸਿਰਫ਼ ਕੋਈ ਪਰਤਾਵਾ ਹੈ, ਸਗੋਂ ਡੋਮੇਨ ਤੋਂ ਕੁਝ ਡੇਟਾ ਦਿਖਾਉਣ ਲਈ 10 ਵੱਖ-ਵੱਖ ਡੀਟੀਓ ਅਤੇ ਵਿਊ ਮਾਡਲ ਲਿਖਣ ਦੀ ਵੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ। 1C ਡਿਵੈਲਪਰ ਹਮੇਸ਼ਾ ਇੱਕ ਇਕਾਈ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਸਮਾਨ ਨਾਮਾਂ ਵਾਲੀਆਂ ਦਰਜਨ ਸ਼੍ਰੇਣੀਆਂ ਦੇ ਨਾਲ ਧਾਰਨਾ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਗੜਬੜ ਕੀਤੇ ਬਿਨਾਂ, ਇੱਕੋ ਇਕਾਈ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਪਰ ਇੱਕ ਵੱਖਰੇ ਪਾਸੇ ਤੋਂ। ਕੋਈ ਵੀ .NET ਐਪਲੀਕੇਸ਼ਨ, ਉਦਾਹਰਨ ਲਈ, JSON ਵਿੱਚ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਕਲਾਇੰਟ ਤੋਂ ਸਰਵਰ ਤੱਕ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਲਈ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਪੰਜ ਜਾਂ ਦੋ ਵਿਊ ਮਾਡਲ ਅਤੇ ਡੀਟੀਓ ਸ਼ਾਮਲ ਹੋਣਗੇ। ਅਤੇ ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਦਾ ਲਗਭਗ 10-15% ਪੈਨ ਜਾਂ ਬੈਸਾਖੀਆਂ ਜਿਵੇਂ ਆਟੋਮੈਪਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਕਲਾਸ ਤੋਂ ਦੂਜੀ ਕਲਾਸ ਵਿੱਚ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਵਿੱਚ ਖਰਚ ਕੀਤਾ ਜਾਵੇਗਾ। ਇਹ ਕੋਡ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਲਿਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਬਣਾਉਣ ਅਤੇ ਸਾਂਭਣ ਲਈ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਭੁਗਤਾਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

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

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

• ਪੱਧਰ 'ਤੇ ਟਾਈਪ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ, ਉਦਾਹਰਨ ਲਈ, ਟਾਈਪਸਕ੍ਰਿਪਟ (ਨਤੀਜੇ ਵਜੋਂ, IDE ਵਿੱਚ ਵਧੇਰੇ ਵਿਕਸਤ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲ, ਰੀਫੈਕਟਰਿੰਗ, ਘੱਟ ਅਪਮਾਨਜਨਕ ਜਾਮ)
  ਫੰਕਸ਼ਨਾਂ ਦੀ ਪਹਿਲੀ ਸ਼੍ਰੇਣੀ ਦੀਆਂ ਵਸਤੂਆਂ ਦੇ ਰੂਪ ਵਿੱਚ ਉਪਲਬਧਤਾ। ਇੱਕ ਥੋੜ੍ਹਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਸੰਕਲਪ, ਪਰ ਆਮ ਬਾਇਲਰਪਲੇਟ-ਕੋਡ ਦੀ ਮਾਤਰਾ ਨੂੰ ਬਹੁਤ ਘੱਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਵਿਦਿਆਰਥੀ ਦੀ ਕੋਡ ਦੀ ਸਮਝ, IMHO, ਵਾਲੀਅਮ ਵਿੱਚ ਕਮੀ ਦੇ ਕਾਰਨ ਹੋਰ ਵੀ ਵਧੇਗੀ
• ਯੂਨੀਵਰਸਲ ਕਲੈਕਸ਼ਨ ਲਿਟਰਲ, ਸ਼ੁਰੂਆਤੀ। ਉਹੀ ਚੀਜ਼ - ਕੋਡ ਦੀ ਮਾਤਰਾ ਨੂੰ ਘਟਾਉਣਾ ਜਿਸ ਨੂੰ ਲਿਖਣ ਅਤੇ/ਜਾਂ ਤੁਹਾਡੀਆਂ ਅੱਖਾਂ ਨਾਲ ਵੇਖਣ ਦੀ ਲੋੜ ਹੈ। ਸੰਗ੍ਰਹਿ ਨੂੰ ਭਰਨ ਵਿੱਚ 9000C ਪ੍ਰੋਗਰਾਮਿੰਗ ਸਮੇਂ ਦਾ 1% ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਸਿੰਟੈਟਿਕ ਸ਼ੂਗਰ ਦੇ ਬਿਨਾਂ ਇਸ ਨੂੰ ਲਿਖਣਾ ਲੰਬਾ, ਮਹਿੰਗਾ ਅਤੇ ਗਲਤੀ-ਪ੍ਰਵਾਨ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, 1C ਹੱਲਾਂ ਵਿੱਚ LOC ਦੀ ਮਾਤਰਾ ਉਪਲਬਧ ਓਪਨ ਫਰੇਮਵਰਕ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਸਾਰੀਆਂ ਕਲਪਨਾਯੋਗ ਸੀਮਾਵਾਂ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ ਅਤੇ, ਆਮ ਤੌਰ 'ਤੇ, ਤੁਹਾਡੇ ਸਾਰੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ Javas ਨੂੰ ਮਿਲਾ ਕੇ। ਭਾਸ਼ਾ ਵਰਬੋਜ਼ ਹੈ, ਅਤੇ ਇਹ ਡੇਟਾ, ਮੈਮੋਰੀ, IDE ਬ੍ਰੇਕ, ਸਮਾਂ, ਪੈਸੇ ਦੀ ਮਾਤਰਾ ਵਿੱਚ ਵਿਗੜਦੀ ਹੈ ...
• ਅੰਤ ਵਿੱਚ ਉਸਾਰੀ ਮੇਰੇ ਕੋਲ ਇੱਕ ਅਨੁਮਾਨ ਹੈ ਕਿ ਇਹ ਉਸਾਰੀ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਗਾਇਬ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਰੂਸੀ ਵਿੱਚ ਇਸਦਾ ਸਫਲ ਅਨੁਵਾਦ ਨਹੀਂ ਮਿਲਿਆ :)
• ਆਪਣੇ ਡੇਟਾ ਕਿਸਮਾਂ (OOP ਤੋਂ ਬਿਨਾਂ), VB6 ਤੋਂ ਕਿਸਮ ਦੇ ਐਨਾਲਾਗ। ਇਹ ਤੁਹਾਨੂੰ ਬਸਪਾ ਵਿੱਚ ਟਿੱਪਣੀਆਂ ਅਤੇ ਜਾਦੂ ਤਰੀਕਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਢਾਂਚਿਆਂ ਨੂੰ ਟਾਈਪ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦੇਵੇਗਾ ਜੋ ਇਹਨਾਂ ਢਾਂਚੇ ਨੂੰ ਬਣਾਉਂਦੇ ਹਨ। ਸਾਨੂੰ ਮਿਲਦਾ ਹੈ: ਘੱਟ ਕੋਡ, ਇੱਕ ਬਿੰਦੀ ਦੁਆਰਾ ਇੱਕ ਸੰਕੇਤ, ਸਮੱਸਿਆ ਦਾ ਤੇਜ਼ ਹੱਲ, ਟਾਈਪੋਜ਼ ਦੇ ਕਾਰਨ ਘੱਟ ਗਲਤੀਆਂ ਅਤੇ ਢਾਂਚਿਆਂ ਦੀਆਂ ਗੁੰਮ ਹੋਈਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ। ਹੁਣ ਉਪਭੋਗਤਾ ਢਾਂਚੇ ਦੀ ਟਾਈਪਿੰਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਟੈਂਡਰਡ ਸਬਸਿਸਟਮ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਿਕਾਸ ਟੀਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਜੋ ਇਸਦੇ ਕ੍ਰੈਡਿਟ ਲਈ, ਪਾਸ ਕੀਤੇ ਪੈਰਾਮੀਟਰ ਢਾਂਚੇ ਦੀਆਂ ਸੰਭਾਵਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਧਿਆਨ ਨਾਲ ਟਿੱਪਣੀਆਂ ਲਿਖਦੀ ਹੈ।
• ਵੈਬ ਕਲਾਇੰਟ 'ਤੇ ਅਸਿੰਕ੍ਰੋਨਸ ਕਾਲਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਕੋਈ ਸ਼ੂਗਰ ਨਹੀਂ। ProcessingNotifications ਦੇ ਰੂਪ ਵਿੱਚ ਕਾਲਬੈਕ-ਨਰਕ ਮੁੱਖ ਬ੍ਰਾਉਜ਼ਰਾਂ ਦੇ API ਵਿੱਚ ਅਚਾਨਕ ਤਬਦੀਲੀ ਕਾਰਨ ਹੁੰਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਹਰ ਸਮੇਂ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਰਹਿ ਸਕਦੇ ਹੋ, ਅਸਿੰਕ੍ਰੋਨਸ ਕੋਡ ਦੀ "ਵਿਦਿਆਰਥੀ ਸਮਝ" ਦਾ ਫਾਇਦਾ ਗੁਆਇਆ ਜਾ ਰਿਹਾ ਹੈ; ਹੋਰ ਅਤੇ ਹੋਰ ਜਿਆਦਾ. ਮੁੱਖ IDE ਵਿੱਚ ਇਸ ਪੈਰਾਡਾਈਮ ਲਈ ਕੋਈ ਸਮਰਥਨ ਸ਼ਾਮਲ ਨਾ ਕਰੋ ਅਤੇ ਚੀਜ਼ਾਂ ਹੋਰ ਵੀ ਵਿਗੜ ਜਾਂਦੀਆਂ ਹਨ।

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

ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ ਜਿਸਨੇ ਪਹਿਲਾਂ ਹੀ ਇਸ ਭਾਸ਼ਾ ਨਾਲ ਬਹੁਤ ਕੰਮ ਕੀਤਾ ਹੈ, js ਜਾਂ c# ਵਿੱਚ ਵੇਖਦਾ ਹੈ, ਇਸ ਭਾਸ਼ਾ ਦੇ ਢਾਂਚੇ ਵਿੱਚ ਬੋਰ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਤੱਥ ਹੈ। ਉਸਨੂੰ ਵਿਕਾਸ ਦੀ ਲੋੜ ਹੈ। ਵਿਕਰੇਤਾ ਲਈ ਪੈਮਾਨੇ ਦੇ ਦੂਜੇ ਪਾਸੇ ਵਿਸ਼ੇਸ਼ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲਾਗਤ ਬਨਾਮ ਉਹਨਾਂ ਦੇ ਲਾਗੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਆਮਦਨ ਵਿੱਚ ਵਾਧਾ ਹੈ। ਇੱਥੇ ਮੈਨੂੰ ਇਸ ਬਾਰੇ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੈ ਕਿ ਕੰਪਨੀ ਦੀਆਂ ਨਜ਼ਰਾਂ ਵਿੱਚ ਮੌਜੂਦਾ ਸਮੇਂ ਵਿੱਚ ਕੀ ਹੈ.

ਵਿਕਾਸ ਵਾਤਾਵਰਣ

ਇੱਥੇ ਵੀ ਚੀਜ਼ਾਂ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਨਹੀਂ ਚੱਲ ਰਹੀਆਂ। ਵਿਕਾਸ ਦੇ ਦੋ ਵਾਤਾਵਰਣ ਹਨ। ਪਹਿਲਾਂ ਡਿਲੀਵਰੀ ਵਿੱਚ ਸ਼ਾਮਲ ਸੰਰਚਨਾਕਾਰ ਹੈ। ਦੂਸਰਾ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਸ ਐਨਵਾਇਰਮੈਂਟ ਹੈ, ਜਾਂ ਸੰਖੇਪ ਵਿੱਚ EDT, Eclipse ਦੇ ਅਧਾਰ ਤੇ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਕੌਂਫਿਗਰੇਟਰ ਵਿਕਾਸ ਕਾਰਜਾਂ ਦੀ ਇੱਕ ਪੂਰੀ ਸ਼੍ਰੇਣੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਅਤੇ ਮਾਰਕੀਟ ਵਿੱਚ ਮੁੱਖ ਵਾਤਾਵਰਣ ਹੈ। ਇਹ ਨੈਤਿਕ ਤੌਰ 'ਤੇ ਵੀ ਅਪ੍ਰਚਲਿਤ ਹੈ, ਵਿਕਾਸ ਨਹੀਂ ਕਰ ਰਿਹਾ, ਅਫਵਾਹਾਂ ਦੇ ਅਨੁਸਾਰ - ਆਪਣੇ ਅੰਦਰ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਦੀ ਮਾਤਰਾ ਦੇ ਕਾਰਨ. ਇੱਕ ਅੰਦਰੂਨੀ API (ਨਾਲ ਦੋਸਤੀ ਦੇ ਰੂਪ ਵਿੱਚ) ਖੋਲ੍ਹ ਕੇ ਸਥਿਤੀ ਨੂੰ ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ ਸਨੋਮੈਨ ਏ. ਓਰੇਫਕੋਵਾ ਜਾਂ ਸੁਤੰਤਰ ਆਧਾਰ 'ਤੇ), ਪਰ ਅਜਿਹਾ ਨਹੀਂ ਹੈ। ਅਭਿਆਸ ਨੇ ਦਿਖਾਇਆ ਹੈ ਕਿ ਕਮਿਊਨਿਟੀ IDE ਵਿੱਚ ਆਪਣੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਿਖ ਦੇਵੇਗੀ, ਜਦੋਂ ਤੱਕ ਵਿਕਰੇਤਾ ਦਖਲ ਨਹੀਂ ਦਿੰਦਾ. ਪਰ ਸਾਡੇ ਕੋਲ ਉਹ ਹੈ ਜੋ ਸਾਡੇ ਕੋਲ ਹੈ। ਸੰਰਚਨਾਕਾਰ 2004-2005 ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਸੀ, ਉਹਨਾਂ ਸਮਿਆਂ ਦੇ ਵਿਜ਼ੂਅਲ ਸਟੂਡੀਓ ਦੀ ਬਹੁਤ ਯਾਦ ਦਿਵਾਉਂਦਾ ਸੀ, ਕੁਝ ਥਾਵਾਂ ਤੇ ਇਹ ਠੰਡਾ ਵੀ ਸੀ, ਪਰ ਇਹ ਉਹਨਾਂ ਸਮਿਆਂ ਵਿੱਚ ਫਸਿਆ ਹੋਇਆ ਸੀ।

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

ਇੱਕ ਵਿਕਲਪ ਦੇ ਤੌਰ 'ਤੇ, ਸਕ੍ਰੈਚ ਤੋਂ ਲਿਖਿਆ ਇੱਕ IDE, Eclipse 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਦੀ ਪੇਸ਼ਕਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਉੱਥੇ, ਸਰੋਤ, ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਹੋਰ ਸੌਫਟਵੇਅਰ ਵਿੱਚ, ਟੈਕਸਟ ਫਾਈਲਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਜੀਆਈਟੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਬੇਨਤੀ ਸ਼ਾਖਾਵਾਂ, ਇਹ ਸਭ ਕੁਝ. ਨਨੁਕਸਾਨ 'ਤੇ, ਇਸਨੇ ਹੁਣ ਕਈ ਸਾਲਾਂ ਤੋਂ ਬੀਟਾ ਸਥਿਤੀ ਨਹੀਂ ਛੱਡੀ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ ਹਰ ਰੀਲੀਜ਼ ਦੇ ਨਾਲ ਬਿਹਤਰ ਹੋ ਰਿਹਾ ਹੈ। ਮੈਂ EDT ਦੇ ਨੁਕਸਾਨਾਂ ਬਾਰੇ ਨਹੀਂ ਲਿਖਾਂਗਾ, ਅੱਜ ਇਹ ਘਟਾਓ ਹੈ, ਕੱਲ੍ਹ ਇਹ ਇੱਕ ਸਥਿਰ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ. ਅਜਿਹੇ ਵਰਣਨ ਦੀ ਸਾਰਥਕਤਾ ਜਲਦੀ ਖਤਮ ਹੋ ਜਾਵੇਗੀ। ਅੱਜ EDT ਵਿੱਚ ਵਿਕਾਸ ਕਰਨਾ ਸੰਭਵ ਹੈ, ਪਰ ਇਹ ਅਸਾਧਾਰਨ ਹੈ, ਤੁਹਾਨੂੰ IDE ਬੱਗਾਂ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਗਿਣਤੀ ਲਈ ਤਿਆਰ ਰਹਿਣ ਦੀ ਲੋੜ ਹੈ

ਜੇ ਤੁਸੀਂ ਉਪਰੋਕਤ "1C ਪ੍ਰਿਜ਼ਮ" ਦੁਆਰਾ ਸਥਿਤੀ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਮਿਲਦਾ ਹੈ: ਨਵੇਂ IDE ਦੇ ਜਾਰੀ ਹੋਣ ਨਾਲ ਬਕਸੇ ਦੀ ਵਿਕਰੀ ਨਹੀਂ ਵਧਦੀ, ਪਰ ਡਿਵੈਲਪਰਾਂ ਦਾ ਆਊਟਫਲੋ ਘੱਟ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਕਹਿਣਾ ਮੁਸ਼ਕਲ ਹੈ ਕਿ ਡਿਵੈਲਪਰ ਆਰਾਮ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਈਕੋਸਿਸਟਮ ਦਾ ਕੀ ਇੰਤਜ਼ਾਰ ਹੈ, ਪਰ ਮਾਈਕ੍ਰੋਸਾੱਫਟ ਨੇ ਪਹਿਲਾਂ ਹੀ ਮੋਬਾਈਲ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਬਹੁਤ ਦੇਰ ਨਾਲ ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਕੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪਰੇਸ਼ਾਨ ਕਰ ਦਿੱਤਾ ਹੈ।

ਵਿਕਾਸ ਪ੍ਰਬੰਧਨ

ਕੋਡ ਲਿਖਣ ਨਾਲੋਂ ਇੱਥੇ ਸਭ ਕੁਝ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਹਾਲ ਹੀ ਵਿੱਚ, ਜਦੋਂ ਕਮਿਊਨਿਟੀ ਦੇ ਯਤਨਾਂ ਨੇ ਪ੍ਰਸ਼ਾਸਨ ਆਟੋਮੇਸ਼ਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਇਆ, 1C ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਰੱਦੀ ਦੇ ਢੇਰ ਵਿੱਚ ਸੁੱਟਣ ਅਤੇ ਗਿੱਟ, ਤੇਜ਼ ਦੋਸ਼, ਕੋਡ-ਸਮੀਖਿਆ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਪ੍ਰੋਟੋਟਾਈਪ ਲਾਂਚ ਕੀਤੇ। , ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ, ਆਟੋ-ਡਿਪਲਾਇ ਅਤੇ ਆਦਿ। ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ ਜੋ ਵਿਕਾਸ ਕਾਰਜਾਂ ਦੇ ਆਟੋਮੇਸ਼ਨ ਦੇ ਪੱਧਰ ਨੂੰ ਵਧਾਉਂਦੀਆਂ ਹਨ. ਹਾਲਾਂਕਿ, ਇਹ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸਿਰਫ਼ ਅਤੇ ਸਿਰਫ਼ ਸਾਡੇ ਆਪਣੇ ਵੱਡੇ ਉਤਪਾਦਾਂ ਦੇ ਵਿਕਾਸ ਲਈ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ, ਜਦੋਂ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਅਸੀਂ ਸਵੈਚਾਲਨ ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਕਰ ਸਕਦੇ. ਉੱਥੇ ਆਟੋ-ਅਭੇਦ ਸਨ, KDiff ਨਾਲ ਤਿੰਨ-ਪੱਖੀ ਤੁਲਨਾ ਅਤੇ ਇਹ ਸਭ। Github 'ਤੇ ਲਾਂਚ ਕੀਤਾ ਗਿਆ gitconverter, ਜੋ, ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਵਿਚਾਰਧਾਰਕ ਤੌਰ 'ਤੇ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਦੂਰ ਖਿੱਚਿਆ ਗਿਆ ਸੀ gitsync, ਪਰ ਵਿਕਰੇਤਾ ਕੰਪਨੀ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਅਨੁਕੂਲ ਹੋਣ ਲਈ ਸੋਧਿਆ ਗਿਆ ਹੈ। ਓਪਨ-ਸੋਰਸ ਤੋਂ ਜ਼ਿੱਦੀ ਮੁੰਡਿਆਂ ਦਾ ਧੰਨਵਾਦ, 1C ਵਿੱਚ ਵਿਕਾਸ ਆਟੋਮੇਸ਼ਨ ਜ਼ਮੀਨ ਤੋਂ ਬਾਹਰ ਹੋ ਗਿਆ। ਸੰਰਚਨਾਕਾਰ ਲਈ ਇੱਕ ਖੁੱਲਾ API, IMHO, ਮੁੱਖ IDE ਦੇ ਨੈਤਿਕ ਪਛੜੇਪਣ ਨੂੰ ਵੀ ਬਦਲ ਦੇਵੇਗਾ।

ਅੱਜ, ਜੀਰਾ ਵਿੱਚ ਮੁੱਦਿਆਂ ਨਾਲ ਜੁੜੇ ਕਮਿਟਾਂ ਦੇ ਨਾਲ ਗਿੱਟ ਵਿੱਚ 1C ਸਰੋਤਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ, ਕਰੂਸੀਬਲ ਵਿੱਚ ਸਮੀਖਿਆਵਾਂ, ਜੇਨਕਿਨਸ ਤੋਂ ਪੁਸ਼ ਬਟਨ ਅਤੇ 1C ਵਿੱਚ ਕੋਡ ਟੈਸਟਿੰਗ 'ਤੇ ਐਲੂਰ ਰਿਪੋਰਟਾਂ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ SonarQube ਵਿੱਚ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ - ਇਹ ਖ਼ਬਰਾਂ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹੈ, ਸਗੋਂ ਉਹਨਾਂ ਕੰਪਨੀਆਂ ਵਿੱਚ ਮੁੱਖ ਧਾਰਾ ਹੈ ਜਿੱਥੇ ਬਹੁਤ ਸਾਰਾ 1C ਵਿਕਾਸ ਹੈ.

ਪ੍ਰਸ਼ਾਸਨ

ਇੱਥੇ ਕਹਿਣ ਲਈ ਬਹੁਤ ਕੁਝ ਹੈ। ਪਹਿਲਾਂ, ਇਹ, ਬੇਸ਼ਕ, ਇੱਕ ਸਰਵਰ (1C ਸਰਵਰ ਕਲੱਸਟਰ) ਹੈ। ਇੱਕ ਸ਼ਾਨਦਾਰ ਚੀਜ਼, ਪਰ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਇਹ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਲੈਕ ਬਾਕਸ ਹੈ, ਕਾਫ਼ੀ ਵੇਰਵੇ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ੀ ਤੌਰ 'ਤੇ, ਪਰ ਇੱਕ ਖਾਸ ਤਰੀਕੇ ਨਾਲ - ਕਈ ਸਰਵਰਾਂ 'ਤੇ ਹਾਈਲੋਡ ਮੋਡ ਵਿੱਚ ਨਿਰਵਿਘਨ ਕਾਰਵਾਈ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਮੁਹਾਰਤ ਹਾਸਲ ਕਰਨਾ ਬਹੁਤ ਸਾਰੇ ਚੁਣੇ ਹੋਏ ਲੋਕਾਂ ਲਈ ਹੈ ਜੋ "ਤਕਨੀਕੀ ਮੁੱਦਿਆਂ 'ਤੇ ਮਾਹਰ" ਸ਼ਿਲਾਲੇਖ ਦੇ ਨਾਲ ਮੈਡਲ। ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ, ਸਿਧਾਂਤ ਵਿੱਚ, ਇੱਕ 1C ਸਰਵਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਕਿਸੇ ਹੋਰ ਸਰਵਰ ਦੇ ਪ੍ਰਬੰਧਨ ਨਾਲੋਂ ਵੱਖਰਾ ਨਹੀਂ ਹੈ. ਇਹ ਇੱਕ ਨੈੱਟਵਰਕ-ਅਧਾਰਿਤ, ਮਲਟੀ-ਥ੍ਰੈਡਡ ਐਪਲੀਕੇਸ਼ਨ ਹੈ ਜੋ ਮੈਮੋਰੀ, CPU, ਅਤੇ ਡਿਸਕ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਦੀ ਹੈ। ਟੈਲੀਮੈਟਰੀ ਕਲੈਕਸ਼ਨ ਅਤੇ ਡਾਇਗਨੌਸਟਿਕਸ ਲਈ ਕਾਫੀ ਮੌਕੇ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਇੱਥੇ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਵਿਕਰੇਤਾ ਇਸ ਬਹੁਤ ਹੀ ਡਾਇਗਨੌਸਟਿਕ ਲਈ ਤਿਆਰ ਕੀਤੇ ਹੱਲਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਕੁਝ ਖਾਸ ਪੇਸ਼ ਨਹੀਂ ਕਰਦਾ ਹੈ. ਹਾਂ, ਇੱਥੇ 1C ਹੈ: ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਅਤੇ ਕੰਟਰੋਲ ਸੈਂਟਰ, ਉਹ ਵੀ ਕਾਫ਼ੀ ਚੰਗੇ ਹਨ, ਪਰ ਉਹ ਬਹੁਤ ਮਹਿੰਗੇ ਹਨ ਅਤੇ ਹਰ ਕਿਸੇ ਕੋਲ ਨਹੀਂ ਹੈ। ਸਟੈਂਡਰਡ ਐਡਮਿਨ ਸੈਟ ਤੋਂ ਗ੍ਰਾਫਾਨਾ, ਜ਼ੈਬਿਕਸ, ਈਐਲਕੇ ਅਤੇ ਹੋਰ ਚੀਜ਼ਾਂ ਨੂੰ ਜੋੜਨ ਲਈ ਕਮਿਊਨਿਟੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਵਿਕਾਸ ਹਨ, ਪਰ ਇੱਥੇ ਕੋਈ ਇੱਕ ਹੱਲ ਨਹੀਂ ਹੈ ਜੋ ਬਹੁਮਤ ਦੇ ਅਨੁਕੂਲ ਹੋਵੇਗਾ। ਕੰਮ ਆਪਣੇ ਹੀਰੋ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ. ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਅਜਿਹਾ ਕਾਰੋਬਾਰ ਹੋ ਜੋ 1C ਕਲੱਸਟਰ 'ਤੇ ਲਾਂਚ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਮਾਹਰ ਦੀ ਲੋੜ ਹੈ। ਆਪਣੇ ਅੰਦਰੋਂ ਜਾਂ ਬਾਹਰੋਂ, ਪਰ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ। ਇਹ ਆਮ ਗੱਲ ਹੈ ਕਿ ਸਰਵਰ ਸੰਚਾਲਨ ਲਈ ਯੋਗਤਾਵਾਂ ਦੇ ਨਾਲ ਇੱਕ ਵੱਖਰੀ ਭੂਮਿਕਾ ਹੈ, ਹਰ 1C ਉਪਭੋਗਤਾ ਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਅਜਿਹੀ ਭੂਮਿਕਾ ਦੀ ਲੋੜ ਹੈ. ਆਓ ਉਦਾਹਰਨ ਲਈ SAP ਨੂੰ ਲੈਂਦੇ ਹਾਂ। ਉੱਥੇ, ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ, ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ, ਆਪਣੀ ਕੁਰਸੀ ਤੋਂ ਵੀ ਨਹੀਂ ਉੱਠੇਗਾ ਜੇਕਰ ਉਸਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ 'ਤੇ ਕੁਝ ਕੌਂਫਿਗਰ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਉਹ ਸਿਰਫ਼ ਮੂਰਖ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹ ਸ਼ਰਮਿੰਦਾ ਨਹੀਂ ਹੋਵੇਗਾ। SAP ਵਿਧੀ ਵਿੱਚ ਇਸਦੇ ਲਈ ਇੱਕ ਵੱਖਰੀ ਕਰਮਚਾਰੀ ਦੀ ਭੂਮਿਕਾ ਹੈ। ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ, 1C ਉਦਯੋਗ ਵਿੱਚ ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਇਸ ਨੂੰ ਇੱਕੋ ਤਨਖਾਹ ਲਈ ਇੱਕ ਕਰਮਚਾਰੀ ਵਿੱਚ ਜੋੜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਹ ਇੱਕ ਭੁਲੇਖਾ ਹੈ।

1C ਸਰਵਰ ਦੇ ਨੁਕਸਾਨ

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

ਨਹੀਂ ਤਾਂ, 1C ਸਰਵਰ ਉਹੀ ਐਪਲੀਕੇਸ਼ਨ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਹੋਰ ਵਾਂਗ ਹੈ ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਪੜ੍ਹ ਕੇ ਅਤੇ ਟੈਂਬੋਰੀਨ 'ਤੇ ਦਸਤਕ ਦੇ ਕੇ, ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਡੌਕਰ

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

ਵਪਾਰਕ ਭਾਗ

ਨਿਵੇਸ਼ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, 1C ਤੁਹਾਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਕਲਾਸਾਂ ਦੀਆਂ ਵਿਸ਼ਾਲ ਸਮਰੱਥਾਵਾਂ ਦੇ ਕਾਰਨ ਵਪਾਰਕ ਵਿਚਾਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਬਾਕਸ ਦੇ ਬਾਹਰ 1C ਬਹੁਤ ਵਧੀਆ ਰਿਪੋਰਟਿੰਗ, ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨਾਲ ਏਕੀਕਰਣ, ਵੈੱਬ ਕਲਾਇੰਟ, ਮੋਬਾਈਲ ਕਲਾਇੰਟ, ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ, ਵੱਖ-ਵੱਖ DBMS ਲਈ ਸਹਾਇਤਾ, ਸਮੇਤ। ਮੁਫਤ, ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਸਰਵਰ ਅਤੇ ਸਥਾਪਿਤ ਕਲਾਇੰਟ ਪਾਰਟਸ ਦੋਵੇਂ। ਹਾਂ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਦਾ UI ਪੀਲਾ ਹੋਵੇਗਾ, ਕਈ ਵਾਰ ਇਹ ਮਾਇਨਸ ਹੁੰਦਾ ਹੈ, ਪਰ ਹਮੇਸ਼ਾ ਨਹੀਂ ਹੁੰਦਾ।
1C ਦੀ ਚੋਣ ਕਰਕੇ, ਇੱਕ ਕਾਰੋਬਾਰ ਨੂੰ ਸੌਫਟਵੇਅਰ ਹੱਲਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਮਿਲਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਇੱਕ ਬਹੁਤ ਵਿਸ਼ਾਲ ਸ਼੍ਰੇਣੀ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਨਾਲ ਹੀ ਮਾਰਕੀਟ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ ਜੋ Javaists ਨਾਲੋਂ ਘੱਟ ਪੈਸੇ ਚਾਹੁੰਦੇ ਹਨ ਅਤੇ ਉਸੇ ਸਮੇਂ ਤੇਜ਼ੀ ਨਾਲ ਨਤੀਜੇ ਦਿੰਦੇ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ PDF ਇਨਵੌਇਸ ਭੇਜਣ ਦਾ ਕੰਮ ਵਿਦਿਆਰਥੀ ਦੇ ਕੰਮ ਦੇ ਇੱਕ ਘੰਟੇ ਵਿੱਚ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। .NET ਵਿੱਚ ਇਹੀ ਸਮੱਸਿਆ ਇੱਕ ਮਲਕੀਅਤ ਲਾਇਬ੍ਰੇਰੀ ਖਰੀਦ ਕੇ, ਜਾਂ ਇੱਕ ਸਖਤ, ਦਾੜ੍ਹੀ ਵਾਲੇ ਡਿਵੈਲਪਰ ਦੁਆਰਾ ਕੋਡਿੰਗ ਦੇ ਦੋ ਦਿਨਾਂ ਜਾਂ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਹੱਲ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਕਦੇ-ਕਦੇ, ਦੋਵੇਂ ਇੱਕੋ ਸਮੇਂ। ਅਤੇ ਹਾਂ, ਮੈਂ ਸਿਰਫ ਪੀਡੀਐਫ ਪੀੜ੍ਹੀ ਬਾਰੇ ਗੱਲ ਕਰ ਰਿਹਾ ਸੀ. ਅਸੀਂ ਇਹ ਨਹੀਂ ਕਿਹਾ ਕਿ ਇਹ ਬਿੱਲ ਕਿੱਥੋਂ ਆਵੇਗਾ। ਵੈੱਬ ਫਰੰਟੈਂਡਰ ਨੂੰ ਇੱਕ ਫਾਰਮ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਆਪਰੇਟਰ ਡੇਟਾ ਦਾਖਲ ਕਰੇਗਾ, ਬੈਕੈਂਡਰ ਨੂੰ JSON ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਲਈ dto ਮਾਡਲ ਬਣਾਉਣਾ ਹੋਵੇਗਾ, ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰਨ ਲਈ ਮਾਡਲ, ਡੇਟਾਬੇਸ ਦੀ ਬਣਤਰ ਖੁਦ, ਇਸ ਵਿੱਚ ਮਾਈਗਰੇਸ਼ਨ, ਇੱਕ ਗ੍ਰਾਫਿਕਲ ਦਾ ਗਠਨ ਇਸ ਖਾਤੇ ਦਾ ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਕੇਵਲ ਤਦ - PDF. 1C 'ਤੇ, ਸਾਰਾ ਕੰਮ, ਸ਼ੁਰੂ ਤੋਂ, ਬਿਲਕੁਲ ਇੱਕ ਘੰਟੇ ਵਿੱਚ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ।

ਖਰੀਦੇ/ਵੇਚਣ ਵਾਲੀ ਇੱਕ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਦੇ ਨਾਲ ਇੱਕ ਛੋਟੇ ਸਟਾਲ ਲਈ ਇੱਕ ਪੂਰਾ ਖਾਤਾ ਪ੍ਰਣਾਲੀ 3 ਘੰਟਿਆਂ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਖਰੀਦ ਅਤੇ ਵਿਕਰੀ ਦੀਆਂ ਕੀਮਤਾਂ 'ਤੇ ਮਾਲ ਦਾ ਲੇਖਾ-ਜੋਖਾ, ਵੇਅਰਹਾਊਸ ਦੁਆਰਾ ਤੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਪਹੁੰਚ ਅਧਿਕਾਰ ਕੰਟਰੋਲ, ਵੈਬ ਕਲਾਇੰਟ ਅਤੇ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ। . ਠੀਕ ਹੈ, ਮੈਂ ਐਪਲੀਕੇਸ਼ਨ ਬਾਰੇ ਭੁੱਲ ਗਿਆ, ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ 3 ਘੰਟਿਆਂ ਵਿੱਚ ਨਹੀਂ, ਛੇ ਵਿੱਚ.

ਇਹ ਕੰਮ ਇੱਕ .NET ਡਿਵੈਲਪਰ ਨੂੰ ਇੱਕ ਸਾਫ਼ ਕੰਪਿਊਟਰ 'ਤੇ ਵਿਜ਼ੂਅਲ ਸਟੂਡੀਓ ਸਥਾਪਤ ਕਰਨ ਤੋਂ ਗਾਹਕ ਨੂੰ ਦਿਖਾਉਣ ਲਈ ਕਿੰਨਾ ਸਮਾਂ ਲਵੇਗਾ? ਵਿਕਾਸ ਦੀ ਲਾਗਤ ਬਾਰੇ ਕੀ? ਇੱਕੋ ਜਿਹੀ ਚੀਜ.

ਪਲੇਟਫਾਰਮ ਵਜੋਂ 1C ਦੀ ਤਾਕਤ

1C ਮਜ਼ਬੂਤ ​​ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਇਸ ਬਾਰੇ ਕੁਝ ਖਾਸ ਹੈ ਜੋ ਸੰਸਾਰ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ। ਇਸਦੇ ਉਲਟ, ਹਰੇਕ ਵਿਅਕਤੀਗਤ ਉਪ-ਸਿਸਟਮ ਵਿੱਚ ਤੁਸੀਂ ਸੰਸਾਰ ਦੇ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਇੱਕ ਹੋਰ ਦਿਲਚਸਪ ਐਨਾਲਾਗ ਲੱਭ ਸਕਦੇ ਹੋ. ਹਾਲਾਂਕਿ, ਕਾਰਕਾਂ ਦੇ ਸੁਮੇਲ ਦੇ ਆਧਾਰ 'ਤੇ, ਮੈਨੂੰ 1C ਵਰਗਾ ਪਲੇਟਫਾਰਮ ਨਹੀਂ ਦਿਸਦਾ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਵਪਾਰਕ ਸਫਲਤਾ ਹੈ. ਪਲੇਟਫਾਰਮ ਦੇ ਫਾਇਦੇ ਇਸ ਵਿੱਚ ਫੈਲੇ ਹੋਏ ਹਨ ਅਤੇ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਇਹ ਦੂਜੇ ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ ਕਿਵੇਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ, ਇਹ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵੀ ਨਹੀਂ ਹਨ, ਪਰ ਇਸਦੇ ਉਲਟ - ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪੈਰਾਡਾਈਮ ਦੇ ਹੱਕ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਅਸਵੀਕਾਰ ਕਰਨਾ। ਕੁਝ ਉਦਾਹਰਣਾਂ:

1. ਯੂਨੀਕੋਡ। ਕੀ ਨਰਕ ਸਧਾਰਨ ਹੋ ਸਕਦਾ ਹੈ? 2019 ਵਿੱਚ ਸਿੰਗਲ-ਬਾਈਟ ASCII ਏਨਕੋਡਿੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ (ਪ੍ਰਾਚੀਨ ਵਿਰਾਸਤ ਦੇ ਨਾਲ ਏਕੀਕਰਣ ਨੂੰ ਛੱਡ ਕੇ)। ਕਦੇ ਨਹੀਂ। ਪਰ ਨਹੀਂ। ਵੈਸੇ ਵੀ, ਕੁਝ ਟੇਬਲ ਵਿੱਚ ਕੋਈ ਵਿਅਕਤੀ ਸਿੰਗਲ-ਬਾਈਟ ਵਰਚਰ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਏਨਕੋਡਿੰਗ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਹੋਣਗੀਆਂ। 2015 ਵਿੱਚ, gitlab ਦਾ LDAP ਪ੍ਰਮਾਣਿਕਤਾ ਐਨਕੋਡਿੰਗ ਦੇ ਨਾਲ ਗਲਤ ਕੰਮ ਦੇ ਕਾਰਨ ਅਸਫਲ ਹੋ ਗਈ ਸੀ; 1C ਡਾਟਾਬੇਸ ਲੇਅਰ ਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਦੀ ਉੱਚ-ਗੁਣਵੱਤਾ ਆਈਸੋਲੇਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਉੱਥੇ ਹੇਠਲੇ ਪੱਧਰ 'ਤੇ ਟੇਬਲਾਂ ਨੂੰ ਟਾਈਪ ਕਰਨਾ ਅਸੰਭਵ ਹੈ ਅਤੇ ਡਾਟਾਬੇਸ ਪੱਧਰ 'ਤੇ ਅਯੋਗ ਜੂਨੀਅਰਾਂ ਦੇ ਜਾਮ ਉੱਥੇ ਅਸੰਭਵ ਹਨ। ਹਾਂ, ਅਯੋਗ ਜੂਨੀਅਰਾਂ ਤੋਂ ਉੱਥੇ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਸਮੱਸਿਆਵਾਂ ਦੀ ਕਿਸਮ ਬਹੁਤ ਛੋਟੀ ਹੈ। ਹੁਣ ਤੁਸੀਂ ਮੈਨੂੰ ਦੱਸੋਗੇ ਕਿ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਸਹੀ ਢੰਗ ਨਾਲ ਤਿਆਰ ਕੀਤੀ ਗਈ ਹੈ ਅਤੇ ਡੇਟਾਬੇਸ ਐਕਸੈਸ ਲੇਅਰ ਨੂੰ ਅਲੱਗ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿਵੇਂ ਕਿ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਆਪਣੀ ਕਾਰਪੋਰੇਟ ਕਸਟਮ Java ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਇੱਕ ਹੋਰ ਨਜ਼ਰ ਮਾਰੋ। ਨਜ਼ਦੀਕੀ ਅਤੇ ਇਮਾਨਦਾਰੀ ਨਾਲ. ਕੀ ਤੁਹਾਡੀ ਜ਼ਮੀਰ ਤੁਹਾਨੂੰ ਪਰੇਸ਼ਾਨ ਕਰਦੀ ਹੈ? ਫਿਰ ਮੈਂ ਤੁਹਾਡੇ ਲਈ ਖੁਸ਼ ਹਾਂ.
2. ਦਸਤਾਵੇਜ਼ਾਂ/ਸੰਦਰਭ ਪੁਸਤਕਾਂ ਦੀ ਸੰਖਿਆ। 1C ਵਿੱਚ ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਲਚਕਦਾਰ ਨਹੀਂ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਨਹੀਂ ਹੈ। ਪਰ ਉਹ ਬੈਂਕਿੰਗ ਸੌਫਟਵੇਅਰ ਅਤੇ ਸਵੈ-ਲਿਖਤ ਲੇਖਾ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਕੀ ਕਰਦੇ ਹਨ - ਠੀਕ ਹੈ, ਇਹ ਸਿਰਫ਼ ਹਨੇਰਾ ਹੈ। ਜਾਂ ਤਾਂ ਪਛਾਣ ਵਿੱਚ ਫਸਿਆ ਰਹੇਗਾ (ਅਤੇ ਫਿਰ "ਓਹ, ਸਾਡੇ ਕੋਲ ਛੇਕ ਕਿਉਂ ਹਨ"), ਜਾਂ ਇਸਦੇ ਉਲਟ, ਉਹ ਇੱਕ ਜਨਰੇਟਰ ਬਣਾਉਣਗੇ ਜੋ DBMS ਪੱਧਰ 'ਤੇ ਲਾਕ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ (ਅਤੇ ਇੱਕ ਰੁਕਾਵਟ ਬਣ ਜਾਵੇਗਾ)। ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਪ੍ਰਤੀਤ ਹੁੰਦਾ ਸਧਾਰਨ ਕੰਮ ਕਰਨਾ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਹੈ - ਇਕਾਈਆਂ ਦਾ ਇੱਕ ਅੰਤ-ਤੋਂ-ਅੰਤ ਗਣਨਾਕਾਰ, ਕੁੰਜੀਆਂ ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੂਹ, ਅਗੇਤਰ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਵਿਲੱਖਣਤਾ ਭਾਗ ਦੇ ਨਾਲ, ਤਾਂ ਜੋ ਸਮਾਂਤਰ ਡੇਟਾ ਐਂਟਰੀ ਦੇ ਦੌਰਾਨ ਇਹ ਡੇਟਾਬੇਸ ਨੂੰ ਬਲੌਕ ਨਾ ਕਰੇ। .
3. ਡੇਟਾਬੇਸ ਵਿੱਚ ਰਿਕਾਰਡਾਂ ਦੀ ਪਛਾਣਕਰਤਾ। 1C ਨੇ ਇੱਕ ਮਜ਼ਬੂਤ-ਇੱਛਾ ਵਾਲਾ ਫੈਸਲਾ ਲਿਆ - ਸਾਰੇ ਲਿੰਕ ਪਛਾਣਕਰਤਾ ਬਿਲਕੁਲ ਸਿੰਥੈਟਿਕ ਹਨ ਅਤੇ ਇਹ ਹੀ ਹੈ। ਅਤੇ ਵਿਤਰਿਤ ਡੇਟਾਬੇਸ ਅਤੇ ਐਕਸਚੇਂਜਾਂ ਨਾਲ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ. ਦੂਜੇ ਸਿਸਟਮਾਂ ਦੇ ਡਿਵੈਲਪਰ ਜ਼ਿੱਦੀ ਤੌਰ 'ਤੇ ਪਛਾਣ ਵਰਗਾ ਕੁਝ ਬਣਾਉਂਦੇ ਹਨ (ਇਹ ਛੋਟਾ ਹੈ!), ਉਹਨਾਂ ਨੂੰ GUI ਵਿੱਚ ਉਦੋਂ ਤੱਕ ਖਿੱਚੋ ਜਦੋਂ ਤੱਕ ਕਈ ਸੰਬੰਧਿਤ ਉਦਾਹਰਨਾਂ ਬਣਾਉਣ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੁੰਦਾ (ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਖੋਜਿਆ ਜਾਵੇਗਾ)। ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਇਹ ਨਹੀਂ ਹੈ? ਇਮਾਨਦਾਰੀ ਨਾਲ?
4. ਸੂਚੀਆਂ। 1C ਕੋਲ (ਵੱਡੀਆਂ) ਸੂਚੀਆਂ ਦੁਆਰਾ ਪੇਜਿੰਗ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਦੁਆਰਾ ਨੈਵੀਗੇਟ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਸਫਲ ਵਿਧੀ ਹੈ। ਮੈਨੂੰ ਤੁਰੰਤ ਇੱਕ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਰਨ ਦਿਓ - ਵਿਧੀ ਦੀ ਸਹੀ ਵਰਤੋਂ ਨਾਲ! ਆਮ ਤੌਰ 'ਤੇ, ਵਿਸ਼ਾ ਕਾਫ਼ੀ ਦੁਖਦਾਈ ਹੈ, ਇਸ ਨੂੰ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਹੱਲ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਇਹ ਜਾਂ ਤਾਂ ਅਨੁਭਵੀ ਅਤੇ ਸਧਾਰਨ ਹੈ (ਪਰ ਕਲਾਇੰਟ 'ਤੇ ਵੱਡੇ ਰਿਕਾਰਡਸੈੱਟਾਂ ਦਾ ਜੋਖਮ), ਜਾਂ ਪੇਜਿੰਗ ਇੱਕ ਜਾਂ ਕਿਸੇ ਹੋਰ ਟੇਢੀ ਹੈ। ਪੇਜਿੰਗ ਕਰਨ ਵਾਲੇ ਅਕਸਰ ਇਸ ਨੂੰ ਟੇਢੇ ਢੰਗ ਨਾਲ ਕਰਦੇ ਹਨ. ਜੋ ਇੱਕ ਇਮਾਨਦਾਰ ਸਕ੍ਰੌਲਬਾਰ ਬਣਾਉਂਦੇ ਹਨ ਉਹ ਇੱਕ ਡੇਟਾਬੇਸ, ਇੱਕ ਚੈਨਲ ਅਤੇ ਇੱਕ ਕਲਾਇੰਟ ਜੋੜਦੇ ਹਨ।
5. ਪ੍ਰਬੰਧਿਤ ਫਾਰਮ। ਬਿਨਾਂ ਸ਼ੱਕ, ਵੈੱਬ ਕਲਾਇੰਟ ਵਿੱਚ ਇੰਟਰਫੇਸ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਪਰ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ. ਪਰ ਕਈ ਹੋਰ ਲੇਖਾਕਾਰੀ ਅਤੇ ਬੈਂਕਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਲਈ, ਇੱਕ ਰਿਮੋਟ ਕੰਮ ਵਾਲੀ ਥਾਂ ਬਣਾਉਣਾ ਇੱਕ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਪੱਧਰ ਦਾ ਪ੍ਰੋਜੈਕਟ ਹੈ। ਬੇਦਾਅਵਾ: ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ ਉਹਨਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੇ ਅਸਲ ਵਿੱਚ ਇਸਨੂੰ ਵੈੱਬ 'ਤੇ ਬਣਾਇਆ ਹੈ, ਇਸ ਦਾ ਕੋਈ ਅਸਰ ਨਹੀਂ ਹੋਵੇਗਾ।
6. ਮੋਬਾਈਲ ਐਪ। ਹਾਲ ਹੀ ਵਿੱਚ, ਤੁਸੀਂ ਉਸੇ ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ ਵੀ ਲਿਖ ਸਕਦੇ ਹੋ। ਇਹ ਇੱਕ ਵੈੱਬ ਕਲਾਇੰਟ ਦੇ ਮੁਕਾਬਲੇ ਥੋੜਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੈ; ਡਿਵਾਈਸਾਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਲਿਖਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀਆਂ ਹਨ, ਪਰ, ਫਿਰ ਵੀ, ਤੁਸੀਂ ਮੋਬਾਈਲ ਡਿਵੈਲਪਰਾਂ ਦੀ ਇੱਕ ਵੱਖਰੀ ਟੀਮ ਨੂੰ ਨਿਯੁਕਤ ਨਹੀਂ ਕਰਦੇ ਹੋ। ਜੇ ਤੁਹਾਨੂੰ ਕਿਸੇ ਕੰਪਨੀ ਦੀਆਂ ਅੰਦਰੂਨੀ ਲੋੜਾਂ ਲਈ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ (ਜਦੋਂ ਇੱਕ ਕਾਰਪੋਰੇਟ ਸਮੱਸਿਆ ਦਾ ਮੋਬਾਈਲ ਹੱਲ ਇੱਕ ਪੀਲੇ UI ਡਿਜ਼ਾਈਨ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ), ਤਾਂ ਤੁਸੀਂ ਬਸ ਉਸੇ ਪਲੇਟਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ।
7. ਰਿਪੋਰਟਿੰਗ। ਇਸ ਸ਼ਬਦ ਦੁਆਰਾ ਮੇਰਾ ਮਤਲਬ ਵੱਡੇ ਡੇਟਾ ਅਤੇ ETL ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਪਛੜਨ ਵਾਲਾ BI ਸਿਸਟਮ ਨਹੀਂ ਹੈ। ਇਹ ਸੰਚਾਲਨ ਸਟਾਫ ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਇੱਥੇ ਅਤੇ ਹੁਣੇ ਲੇਖਾ ਦੀ ਸਥਿਤੀ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ। ਬਕਾਇਆ, ਆਪਸੀ ਸਮਝੌਤਾ, ਰੀ-ਗ੍ਰੇਡਿੰਗ, ਆਦਿ। 1C ਯੂਜ਼ਰ ਸਾਈਡ 'ਤੇ ਗਰੁੱਪਿੰਗ, ਫਿਲਟਰ ਅਤੇ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਲਈ ਲਚਕਦਾਰ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ ਰਿਪੋਰਟਿੰਗ ਸਿਸਟਮ ਦੇ ਨਾਲ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਆਉਂਦਾ ਹੈ। ਹਾਂ, ਮਾਰਕੀਟ ਵਿੱਚ ਕੂਲਰ ਐਨਾਲਾਗ ਹਨ। ਪਰ ਇੱਕ ਆਲ-ਇਨ-ਵਨ ਹੱਲ ਦੇ ਢਾਂਚੇ ਦੇ ਅੰਦਰ ਨਹੀਂ ਅਤੇ ਇੱਕ ਕੀਮਤ 'ਤੇ ਕਈ ਵਾਰ ਆਲ-ਇਨ-ਵਨ ਹੱਲ ਤੋਂ ਵੱਧ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਅਕਸਰ ਇਹ ਇਸਦੇ ਉਲਟ ਵੀ ਹੁੰਦਾ ਹੈ: ਸਿਰਫ ਰਿਪੋਰਟਿੰਗ, ਪਰ ਪੂਰੇ ਪਲੇਟਫਾਰਮ ਨਾਲੋਂ ਵਧੇਰੇ ਮਹਿੰਗਾ, ਅਤੇ ਗੁਣਵੱਤਾ ਵਿੱਚ ਮਾੜਾ।
8. ਛਪਣਯੋਗ ਫਾਰਮ। ਖੈਰ, ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਈਮੇਲ ਦੁਆਰਾ PDF ਵਿੱਚ ਤਨਖਾਹ ਸਲਿੱਪਾਂ ਭੇਜਣ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ .NET ਦੀ ਵਰਤੋਂ ਕਰੋ। ਅਤੇ ਹੁਣ ਚਲਾਨ ਛਾਪਣ ਦਾ ਕੰਮ. ਉਹਨਾਂ ਦੀਆਂ ਕਾਪੀਆਂ ਨੂੰ ਉਸੇ PDF ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰਨ ਬਾਰੇ ਕੀ? 1C ਉਪਨਾਮ ਲਈ, ਕਿਸੇ ਵੀ ਖਾਕੇ ਨੂੰ PDF ਵਿੱਚ ਆਊਟਪੁੱਟ ਕਰਨਾ ਕੋਡ ਦੀ +1 ਲਾਈਨ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ + 40 ਸਕਿੰਟ ਕੰਮ ਕਰਨ ਦਾ ਸਮਾਂ, ਕਿਸੇ ਹੋਰ ਭਾਸ਼ਾ ਵਿੱਚ ਦਿਨਾਂ ਜਾਂ ਹਫ਼ਤਿਆਂ ਦੀ ਬਜਾਏ। 1C ਵਿੱਚ ਪ੍ਰਿੰਟ ਕੀਤੇ ਫਾਰਮ ਲੇਆਉਟ ਵਿਕਸਤ ਕਰਨ ਵਿੱਚ ਅਵਿਸ਼ਵਾਸ਼ਯੋਗ ਤੌਰ 'ਤੇ ਆਸਾਨ ਹਨ ਅਤੇ ਭੁਗਤਾਨ ਕੀਤੇ ਹਮਰੁਤਬਾ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹਨ। ਹਾਂ, ਸੰਭਵ ਤੌਰ 'ਤੇ, 1C ਸਪ੍ਰੈਡਸ਼ੀਟ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਇੰਟਰਐਕਟਿਵ ਮੌਕੇ ਨਹੀਂ ਹਨ, ਤੁਸੀਂ ਓਪਨਜੀਐਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਕੇਲਿੰਗ ਦੇ ਨਾਲ ਇੱਕ 3D ਚਿੱਤਰ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ ਕੀ ਇਹ ਸੱਚਮੁੱਚ ਜ਼ਰੂਰੀ ਹੈ?

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

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

ਮੈਂ ਇਹ ਨਹੀਂ ਕਹਿ ਰਿਹਾ ਹਾਂ ਕਿ 1C ਸਾਰੇ ਮਾਮਲਿਆਂ ਨੂੰ ਹੱਲ ਕਰੇਗਾ, ਪਰ ਇੱਕ ਅੰਦਰੂਨੀ ਕਾਰਪੋਰੇਟ ਐਪਲੀਕੇਸ਼ਨ ਲਈ, ਜਦੋਂ UI ਨੂੰ ਬ੍ਰਾਂਡ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ, ਤਾਂ ਹੋਰ ਕੀ ਚਾਹੀਦਾ ਹੈ?

ਟਾਰ ਦਾ ਇੱਕ ਚਮਚਾ

ਤੁਹਾਨੂੰ ਸ਼ਾਇਦ ਇਹ ਪ੍ਰਭਾਵ ਮਿਲਿਆ ਹੈ ਕਿ 1C ਸੰਸਾਰ ਨੂੰ ਬਚਾਏਗਾ ਅਤੇ ਕਾਰਪੋਰੇਟ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਲਿਖਣ ਦੇ ਹੋਰ ਸਾਰੇ ਤਰੀਕੇ ਗਲਤ ਹਨ। ਇਹ ਬਿਲਕੁਲ ਵੀ ਅਜਿਹਾ ਨਹੀਂ ਹੈ। ਇੱਕ ਵਪਾਰੀ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਜੇਕਰ ਤੁਸੀਂ 1C ਦੀ ਚੋਣ ਕਰਦੇ ਹੋ, ਤਾਂ ਫਾਸਟ ਟਾਈਮ-ਟੂ-ਮਾਰਕੀਟ ਤੋਂ ਇਲਾਵਾ, ਤੁਹਾਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਨੁਕਸਾਨਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਸਰਵਰ ਭਰੋਸੇਯੋਗਤਾ. ਅਸਲ ਵਿੱਚ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲੇ ਮਾਹਰਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਇਸ ਦੇ ਨਿਰਵਿਘਨ ਸੰਚਾਲਨ ਨੂੰ ਯਕੀਨੀ ਬਣਾ ਸਕਦੇ ਹਨ। ਮੈਨੂੰ ਵਿਕਰੇਤਾ ਤੋਂ ਅਜਿਹੇ ਮਾਹਿਰਾਂ ਲਈ ਤਿਆਰ ਸਿਖਲਾਈ ਪ੍ਰੋਗਰਾਮ ਬਾਰੇ ਪਤਾ ਨਹੀਂ ਹੈ। ਮਾਹਰ ਪ੍ਰੀਖਿਆ ਲਈ ਤਿਆਰ ਕਰਨ ਲਈ ਕੋਰਸ ਹਨ, ਪਰ ਇਹ, ਮੇਰੇ ਵਿਚਾਰ ਵਿੱਚ, ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ.
• ਸਪੋਰਟ. ਪਿਛਲਾ ਬਿੰਦੂ ਦੇਖੋ। ਵਿਕਰੇਤਾ ਤੋਂ ਸਮਰਥਨ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਖਰੀਦਣ ਦੀ ਲੋੜ ਹੈ। ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਇਹ 1C ਉਦਯੋਗ ਵਿੱਚ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਤੇ SAP ਦੇ ਨਾਲ, ਇਹ ਲਗਭਗ ਇੱਕ ਲਾਜ਼ਮੀ-ਖਰੀਦ ਹੈ ਅਤੇ ਇਹ ਕਿਸੇ ਨੂੰ ਪਰੇਸ਼ਾਨ ਨਹੀਂ ਕਰਦਾ. ਕਾਰਪੋਰੇਟ ਸਹਾਇਤਾ ਤੋਂ ਬਿਨਾਂ ਅਤੇ ਸਟਾਫ 'ਤੇ ਮਾਹਰ ਦੇ ਬਿਨਾਂ, ਤੁਸੀਂ 1C ਗਲਤੀਆਂ ਨਾਲ ਇਕੱਲੇ ਰਹਿ ਸਕਦੇ ਹੋ।
• ਫਿਰ ਵੀ, ਤੁਸੀਂ 1C ਨਾਲ ਬਿਲਕੁਲ ਸਭ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਇਹ ਇੱਕ ਟੂਲ ਹੈ ਅਤੇ ਹਰ ਟੂਲ ਦੀ ਤਰ੍ਹਾਂ ਇਸਦੀ ਵੀ ਲਾਗੂ ਹੋਣ ਦੀ ਸੀਮਾ ਹੁੰਦੀ ਹੈ। 1C ਲੈਂਡਸਕੇਪ ਵਿੱਚ, "ਗੈਰ-1C" ਸਿਸਟਮ ਆਰਕੀਟੈਕਟ ਹੋਣਾ ਬਹੁਤ ਫਾਇਦੇਮੰਦ ਹੈ।
• ਚੰਗੇ 1C ਉਪਨਾਮ ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਚੰਗੇ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨਾਲੋਂ ਸਸਤੇ ਨਹੀਂ ਹਨ। ਹਾਲਾਂਕਿ, ਮਾੜੇ ਪ੍ਰੋਗਰਾਮਰ ਨੂੰ ਕਿਰਾਏ 'ਤੇ ਲੈਣਾ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਕਿਸੇ ਵੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਦੇ ਹਨ।

ਆਓ ਬਿੰਦੀਆਂ ਨੂੰ ਬਿੰਦੀ ਕਰੀਏ

• 1C ਕਾਰੋਬਾਰ ਲਈ ਇੱਕ ਰੈਪਿਡ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਮੈਂਟ (RAD) ਫਰੇਮਵਰਕ ਹੈ ਅਤੇ ਇਸਦੇ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ।
• ਪ੍ਰਮੁੱਖ DBMS, ਕਲਾਇੰਟ UI, ਇੱਕ ਬਹੁਤ ਵਧੀਆ ORM ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਲਈ ਸਮਰਥਨ ਦੇ ਨਾਲ ਤਿੰਨ-ਪੱਧਰੀ ਲਿੰਕ
• ਸਿਸਟਮਾਂ ਨਾਲ ਏਕੀਕਰਣ ਲਈ ਵਿਆਪਕ ਸੰਭਾਵਨਾਵਾਂ ਜੋ ਉਹ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜੋ 1C ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ। ਜੇਕਰ ਤੁਸੀਂ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Python ਲਓ ਅਤੇ ਨਤੀਜਾ http ਜਾਂ RabbitMQ ਰਾਹੀਂ 1C 'ਤੇ ਭੇਜੋ।
• 1C ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਭ ਕੁਝ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਤੁਹਾਨੂੰ ਇਸ ਦੀਆਂ ਖੂਬੀਆਂ ਨੂੰ ਸਮਝਣ ਅਤੇ ਆਪਣੇ ਉਦੇਸ਼ਾਂ ਲਈ ਵਰਤਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ
• ਡਿਵੈਲਪਰ ਜੋ ਟੈਕਨੋਲੋਜੀ ਫਰੇਮਵਰਕ ਗੈਜੇਟਸ ਵਿੱਚ ਖੁਦਾਈ ਕਰਨ ਅਤੇ ਹਰ N ਸਾਲਾਂ ਵਿੱਚ ਇੱਕ ਨਵੇਂ ਇੰਜਣ ਨੂੰ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵੱਲ ਧਿਆਨ ਦਿੰਦੇ ਹਨ, 1C ਨਾਲ ਬੋਰ ਹੋ ਗਏ ਹਨ। ਉੱਥੇ ਸਭ ਕੁਝ ਬਹੁਤ ਰੂੜੀਵਾਦੀ ਹੈ.
• ਡਿਵੈਲਪਰ ਵੀ ਬੋਰ ਹਨ ਕਿਉਂਕਿ ਨਿਰਮਾਤਾ ਤੋਂ ਉਨ੍ਹਾਂ ਲਈ ਬਹੁਤ ਘੱਟ ਚਿੰਤਾ ਹੈ. ਬੋਰਿੰਗ ਭਾਸ਼ਾ, ਕਮਜ਼ੋਰ IDE। ਉਨ੍ਹਾਂ ਨੂੰ ਆਧੁਨਿਕੀਕਰਨ ਦੀ ਲੋੜ ਹੈ।
• ਦੂਜੇ ਪਾਸੇ, ਡਿਵੈਲਪਰ ਜੋ ਕਿਸੇ ਹੋਰ ਟੈਕਨਾਲੋਜੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਅਤੇ ਸਿੱਖਣ ਦੁਆਰਾ ਮਜ਼ੇਦਾਰ ਨਹੀਂ ਲੱਭ ਸਕਦੇ ਜਿਸਦਾ ਉਹ ਆਨੰਦ ਲੈਂਦੇ ਹਨ ਉਹ ਮਾੜੇ ਡਿਵੈਲਪਰ ਹਨ। ਉਹ ਚੀਕਣਗੇ ਅਤੇ ਕਿਸੇ ਹੋਰ ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਚਲੇ ਜਾਣਗੇ।
• ਉਹ ਰੁਜ਼ਗਾਰਦਾਤਾ ਜੋ ਆਪਣੇ 1C ਉਪਨਾਮਾਂ ਨੂੰ ਪਾਈਥਨ ਵਿੱਚ ਕੁਝ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੇ ਹਨ, ਉਹ ਮਾੜੇ ਮਾਲਕ ਹਨ। ਉਹ ਖੋਜੀ ਦਿਮਾਗ ਵਾਲੇ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਗੁਆ ਦੇਣਗੇ, ਅਤੇ ਉਹਨਾਂ ਦੀ ਥਾਂ 'ਤੇ ਬਾਂਦਰ ਕੋਡਰ ਆਉਣਗੇ, ਜੋ ਹਰ ਚੀਜ਼ ਨਾਲ ਸਹਿਮਤ ਹੁੰਦੇ ਹੋਏ, ਕਾਰਪੋਰੇਟ ਸੌਫਟਵੇਅਰ ਨੂੰ ਦਲਦਲ ਵਿੱਚ ਖਿੱਚਣਗੇ. ਇਸ ਨੂੰ ਅਜੇ ਵੀ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪਏਗਾ, ਇਸ ਲਈ ਸ਼ਾਇਦ ਪਾਇਥਨ ਵਿੱਚ ਥੋੜਾ ਜਿਹਾ ਪਹਿਲਾਂ ਨਿਵੇਸ਼ ਕਰਨਾ ਬਿਹਤਰ ਹੋਵੇਗਾ?
• 1C ਇੱਕ ਵਪਾਰਕ ਕੰਪਨੀ ਹੈ ਅਤੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਪਣੇ ਹਿੱਤਾਂ ਅਤੇ ਸਹੂਲਤ ਦੇ ਅਧਾਰ 'ਤੇ ਲਾਗੂ ਕਰਦੀ ਹੈ। ਤੁਸੀਂ ਇਸ ਲਈ ਉਸ 'ਤੇ ਦੋਸ਼ ਨਹੀਂ ਲਗਾ ਸਕਦੇ, ਕਾਰੋਬਾਰ ਨੂੰ ਲਾਭ ਬਾਰੇ ਸੋਚਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਜ਼ਿੰਦਗੀ ਹੈ
• 1C ਵਪਾਰਕ ਸਮੱਸਿਆਵਾਂ ਦੇ ਹੱਲ ਵੇਚ ਕੇ ਪੈਸਾ ਕਮਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਵਾਸਿਆ ਦੀਆਂ ਡਿਵੈਲਪਰ ਸਮੱਸਿਆਵਾਂ ਲਈ। ਇਹ ਦੋਵੇਂ ਧਾਰਨਾਵਾਂ ਆਪਸ ਵਿੱਚ ਜੁੜੀਆਂ ਹੋਈਆਂ ਹਨ, ਪਰ ਤਰਜੀਹ ਉਹੀ ਹੈ ਜੋ ਮੈਂ ਕਿਹਾ ਹੈ। ਜਦੋਂ ਡਿਵੈਲਪਰ ਵਾਸਿਆ 1C: Resharper ਲਈ ਨਿੱਜੀ ਲਾਇਸੈਂਸ ਲਈ ਭੁਗਤਾਨ ਕਰਨ ਲਈ ਤਿਆਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਦਿਖਾਈ ਦੇਵੇਗਾ, A. Orefkova ਦੁਆਰਾ "Resharper" ਇਸਦਾ ਸਬੂਤ ਹੈ। ਜੇ ਵਿਕਰੇਤਾ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਵਿਰੁੱਧ ਲੜਦਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਸੌਫਟਵੇਅਰ ਲਈ ਇੱਕ ਮਾਰਕੀਟ ਦਿਖਾਈ ਦੇਵੇਗੀ. ਹੁਣ ਇਸ ਮਾਰਕੀਟ ਵਿੱਚ ਸ਼ੱਕੀ ਨਤੀਜਿਆਂ ਦੇ ਨਾਲ ਡੇਢ ਖਿਡਾਰੀ ਹਨ, ਅਤੇ ਸਾਰੇ ਕਿਉਂਕਿ IDE ਨਾਲ ਏਕੀਕਰਣ ਨਕਾਰਾਤਮਕ ਹੈ ਅਤੇ ਸਭ ਕੁਝ ਬੈਸਾਖੀਆਂ 'ਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ.
• ਬਹੁ-ਮਸ਼ੀਨ ਆਪਰੇਟਰ ਦਾ ਅਭਿਆਸ ਭੁਲੇਖੇ ਵਿੱਚ ਅਲੋਪ ਹੋ ਜਾਵੇਗਾ. ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨਾਂ ਕੋਡ ਵਾਲੇ ਪਾਸੇ ਅਤੇ ਵਪਾਰਕ ਵਰਤੋਂ ਵਾਲੇ ਪਾਸੇ ਤੋਂ ਯਾਦ ਰੱਖਣ ਲਈ ਬਹੁਤ ਵੱਡੀਆਂ ਹਨ। 1C ਸਰਵਰ ਹੋਰ ਵੀ ਗੁੰਝਲਦਾਰ ਹੁੰਦਾ ਜਾ ਰਿਹਾ ਹੈ; ਇੱਕ ਕਰਮਚਾਰੀ ਵਿੱਚ ਹਰ ਕਿਸਮ ਦੀ ਮੁਹਾਰਤ ਰੱਖਣੀ ਅਸੰਭਵ ਹੋਵੇਗੀ। ਇਸ ਵਿੱਚ ਮਾਹਰਾਂ ਦੀ ਮੰਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਜਿਸਦਾ ਅਰਥ ਹੈ 1C ਪੇਸ਼ੇ ਦੀ ਖਿੱਚ ਅਤੇ ਤਨਖਾਹ ਵਿੱਚ ਵਾਧਾ। ਜੇਕਰ ਪਹਿਲਾਂ ਵਾਸਿਆ ਇੱਕ ਤਨਖ਼ਾਹ ਲਈ ਤਿੰਨ-ਵਿੱਚ-ਇੱਕ ਕੰਮ ਕਰਦਾ ਸੀ, ਤਾਂ ਹੁਣ ਤੁਹਾਨੂੰ ਦੋ ਵਾਸੀਆਂ ਨੂੰ ਨਿਯੁਕਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਵਾਸੀਆਂ ਵਿਚਕਾਰ ਮੁਕਾਬਲਾ ਉਹਨਾਂ ਦੇ ਪੱਧਰ ਦੇ ਸਮੁੱਚੇ ਵਿਕਾਸ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰ ਸਕਦਾ ਹੈ।

ਸਿੱਟਾ

1C ਇੱਕ ਬਹੁਤ ਹੀ ਯੋਗ ਉਤਪਾਦ ਹੈ. ਮੇਰੀ ਕੀਮਤ ਸੀਮਾ ਵਿੱਚ, ਮੈਨੂੰ ਕੋਈ ਵੀ ਐਨਾਲਾਗ ਨਹੀਂ ਪਤਾ, ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਲਿਖੋ ਜੇ ਕੋਈ ਹੈ. ਹਾਲਾਂਕਿ, ਈਕੋਸਿਸਟਮ ਤੋਂ ਡਿਵੈਲਪਰਾਂ ਦਾ ਆਊਟਫਲੋ ਵੱਧ ਤੋਂ ਵੱਧ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੁੰਦਾ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ "ਦਿਮਾਗ ਦੀ ਨਿਕਾਸੀ" ਹੈ, ਭਾਵੇਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਕਿਵੇਂ ਦੇਖਦੇ ਹੋ. ਉਦਯੋਗ ਆਧੁਨਿਕੀਕਰਨ ਲਈ ਭੁੱਖਾ ਹੈ.
ਜੇ ਤੁਸੀਂ ਇੱਕ ਡਿਵੈਲਪਰ ਹੋ, ਤਾਂ 1C 'ਤੇ ਅਟਕ ਨਾ ਜਾਓ ਅਤੇ ਇਹ ਨਾ ਸੋਚੋ ਕਿ ਦੂਜੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਸਭ ਕੁਝ ਜਾਦੂਈ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਜੂਨੀਅਰ ਹੋ, ਸ਼ਾਇਦ। ਜਿਵੇਂ ਹੀ ਕਿਸੇ ਵੱਡੀ ਚੀਜ਼ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਿਆਰ ਕੀਤੇ ਹੱਲਾਂ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਦੇਖਣਾ ਪਵੇਗਾ ਅਤੇ ਵਧੇਰੇ ਤੀਬਰਤਾ ਨਾਲ ਪੂਰਾ ਕਰਨਾ ਹੋਵੇਗਾ। "ਬਲਾਕ" ਦੀ ਗੁਣਵੱਤਾ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਜਿਸ ਤੋਂ ਇੱਕ ਹੱਲ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, 1C ਬਹੁਤ ਵਧੀਆ ਹੈ.

ਅਤੇ ਇੱਕ ਹੋਰ ਗੱਲ - ਜੇਕਰ ਇੱਕ 1C ਉਪਨਾਮ ਤੁਹਾਡੇ ਕੋਲ ਕਿਰਾਏ 'ਤੇ ਲੈਣ ਲਈ ਆਉਂਦਾ ਹੈ, ਤਾਂ 1C ਉਪਨਾਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਲੀਡ ਵਿਸ਼ਲੇਸ਼ਕ ਦੇ ਅਹੁਦੇ 'ਤੇ ਨਿਯੁਕਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਕੰਮ, ਵਿਸ਼ਾ ਖੇਤਰ, ਅਤੇ ਵਿਘਨ ਦੇ ਹੁਨਰ ਦੀ ਉਹਨਾਂ ਦੀ ਸਮਝ ਬਹੁਤ ਵਧੀਆ ਹੈ। ਮੈਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਇਹ 1C ਵਿਕਾਸ ਵਿੱਚ DDD ਦੀ ਜ਼ਬਰਦਸਤੀ ਵਰਤੋਂ ਦੇ ਕਾਰਨ ਹੈ. ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਕੰਮ ਦੇ ਅਰਥ ਬਾਰੇ ਸੋਚਣ ਲਈ ਸਿਖਲਾਈ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਵਿਸ਼ੇ ਖੇਤਰ ਦੀਆਂ ਵਸਤੂਆਂ ਦੇ ਵਿਚਕਾਰ ਸਬੰਧਾਂ ਬਾਰੇ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਏਕੀਕਰਣ ਤਕਨਾਲੋਜੀਆਂ ਅਤੇ ਡੇਟਾ ਐਕਸਚੇਂਜ ਫਾਰਮੈਟਾਂ ਵਿੱਚ ਇੱਕ ਤਕਨੀਕੀ ਪਿਛੋਕੜ ਹੈ.

ਧਿਆਨ ਰੱਖੋ ਕਿ ਆਦਰਸ਼ ਢਾਂਚਾ ਮੌਜੂਦ ਨਹੀਂ ਹੈ ਅਤੇ ਆਪਣੇ ਆਪ ਦਾ ਧਿਆਨ ਰੱਖੋ।
ਸਾਰਾ ਚੰਗਾ!

PS: ਤੁਹਾਡਾ ਬਹੁਤ ਬਹੁਤ ਧੰਨਵਾਦ speshuric ਲੇਖ ਨੂੰ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਲਈ।

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਤੁਹਾਡੇ ਉਦਯੋਗ ਵਿੱਚ 1C ਹੈ?

• 13,3%ਬਿਲਕੁਲ ਨਹੀਂ ।੭੧

• 30,3%ਹੈ, ਪਰ ਸਿਰਫ ਲੇਖਾ ਵਿਭਾਗ ਵਿੱਚ ਕਿਤੇ ਨਾ ਕਿਤੇ। ਹੋਰ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਕੋਰ ਸਿਸਟਮ 162

• 41,4%ਹਾਂ, ਮੁੱਖ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ it221 'ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ

• 15,0%1C ਮਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਭਵਿੱਖ %technology_name%80 ਦਾ ਹੈ

534 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਕੀਤਾ। 99 ਉਪਭੋਗਤਾ ਬਚੇ ਰਹੇ।

ਸਰੋਤ: www.habr.com