Хэрхэн нээх 

Стандарт 1c тохиргоог боловсронгуй болгох. Урьдчилан тодорхойлсон элементүүдийг нэмэх

Та 1С-ийн функцийг өргөжүүлэх шаардлагатай байна уу? Зөвхөн стандарт төдийгүй аж ахуйн нэгжийн тодорхой асуудлуудыг шийдвэрлэх хөтөлбөр танд хэрэгтэй байна уу? Active-IT-ийн 1C өөрчлөлтийн үйлчилгээ нь эдгээр асуудлыг хурдан шийдвэрлэхэд тусална.

Бид хувь хүн үүсгэхээс эхлээд ямар ч түвшний нарийн төвөгтэй 1С стандарт тохиргоонд өөрчлөлт оруулдаг хэвлэсэн маягтуудажлын цагийн урамшууллыг тооцох алгоритмыг нэвтрүүлэхээс өмнө гэх мэт.

Өөрчлөгдөх цаг- 5 хүртэл хоног. 10 хүртэл хоног саатсан тохиолдолд бид танд үнэ төлбөргүй засвар хийх болно.

Бидэнтэй хамтран ажилласны бас нэг давуу тал бол бид ажлаа үргэлж үнэнчээр хийдэг. Бид "ойлголоо" гэсэн схемийн дагуу ажилладаггүй техникийн даалгавар==> ажлаа хийсэн ==> хүлээлгэж өгөөд мартчихаж." Бид техникийн даалгаврыг хүлээн авч, ажлаа үр дүнтэй гүйцэтгэж, үр дүнг үнэлж, шаардлагатай бол нэмэлт төлбөргүйгээр засварыг тохируулах боломжийг танд олгоно.

1С програмистын өртөг

Тохиргоог өөрчлөх зардал: 1500 рубль. програмистын ажлын цаг тутамд.

Үүний үр дүнд та:

  • Туршлагатай програмистуудтай хамтран ажиллах.
  • Ямар ч түвшний нарийн төвөгтэй сайжруулалтыг бий болгох, хэрэгжүүлэх.
  • Ажлыг хамгийн богино хугацаанд дуусгах - 5 хүртэл хоног.
  • Хугацаа хоцорсон тохиолдолд мөнгө буцааж өгөх баталгаа.
  • Чанарын баталгаа.

Active-IT-ээс 1С Нягтлан бодох бүртгэлд өөрчлөлт оруулах захиалга!
Бидэнтэй хамтран 1С-ийн ажлыг өөрийн байгууллагын онцлогт тохируулан тохируулаарай.

Бараг бүх том 1С интегратор компанийн бараг бүх төслүүд нь стандарт тохиргоог сайжруулахаас бүрддэг бөгөөд нягтлан бодох бүртгэлийг оновчтой болгоход чиглэгддэг. эдийн засгийн үйл ажиллагаазохих зохицуулалттай тайланг зохион байгуулж ирүүлэх. Энэ нь эргээд ирээдүйд хэрэгжсэн шийдлүүдийг байнга өөрчлөгдөж байдаг хууль тогтоомжийн дагуу өөрчлөх шаардлагатай болно гэсэн үг юм. Практикт энэ нь бараг үргэлж шийдэлд суурилсан стандарт тохиргооны хувилбаруудыг шинэчлэх, дараагийн хувилбарт гарсан өөрчлөлтийн дагуу аль хэдийн хийсэн өөрчлөлтүүдийг тохируулах гэсэн үг юм.

Хэрэв үйлчлүүлэгч интегратор байгууллагад дэмжлэг үзүүлэхгүй бол төслийг бүрэн амжилттай гэж нэрлэх боломжгүй байдаг. Хэрэв та стандарт тохиргоог өөрчлөх хатуу дүрмийг дагаж мөрдвөл зарцуулсны дараа маш бага хугацаахөгжлийн үе шатанд та чадна ирээдүйд олон цаг, мэдрэлийг хэмнээрэйөөрчлөгдсөн тохиргоог байнга шинэчилж байх. Үүний эсрэгээр, кодын загварт бүдүүлэг, "хайх хэрэггүй" гэсэн хандлага, даалгавраа хэрэгжүүлэхийн тулд илүү хурдан бөгөөд хялбар арга замыг сонгох нь үүссэн тохиргоог шинэчлэхийг жинхэнэ там болгож чадна. Ирээдүйд энэ нь асар их цаг шинэчлэлт хийх, тайлангийн хугацаанд хөгжүүлэгчдийн ажлын ачаалал эрс нэмэгдэх болно. олон тоонышинэчлэлтийн дараах алдаа, хэрэглэгчийн сэтгэл ханамжгүй байдал гэх мэт.

Доорх нь ердийн тохиргоонуудын хөгжүүлэлтийн дүрмийн багц бөгөөд энэ нь тохиргооны цаашдын шинэчлэлтийг ихээхэн хөнгөвчлөх болно. Энэхүү код нь нэг гайхамшигтай компанийн олон тооны хөгжүүлэгчдийн олон жилийн туршлагаас аажмаар үүссэн бөгөөд миний бодлоор хамгийн гүн итгэл үнэмшил, ямар хэлтэс/төсөл/чиглэлд ажиллаж байгаагаас үл хамааран бүх хөгжүүлэгчид заавал байх ёстой.

1. Стандарт тохиргооны "устгалтыг" багасгах тухай ойлголт

Хэрэв өөрчлөгдсөн стандарт тохиргоог шинэ хувилбарууд гарах үед шинэчлэхээр төлөвлөж байгаа бол хөгжүүлэгчид үүнийг хийх ёстой үүнийг үргэлж санаж яваарайшинэчлэлтийг хөнгөвчлөх арга хэмжээ авна. Асуудлыг шийдвэрлэх аргуудыг та үргэлж сонгох хэрэгтэй тохиргоог шинэчлэхэд хялбарирээдүйд хэрэгжүүлэхэд арай илүү хэцүү байсан ч гэсэн. Мэдээжийн хэрэг, шинэчлэхэд илүү тохиромжтой арга нь гүйцэтгэлийн талбарт ноцтой дутагдал, кодын ойлгомжтой байдал гэх мэт зүйл байхгүй тохиолдолд л.

2. Кодын өөрчлөлтийг тайлбарлах:

Модулиудын програмын кодын бүх өөрчлөлтийг заавал тайлбарлах ёстой. Өөрчлөлт хийгдсэн мөрүүдийн хэсэг нь тусгай форматтай тайлбарын мөрөөр хүрээлэгдсэн байх ёстой. Эдгээр мөрүүдийг үүсгэх зарчмыг дараах жишээнд үзүүлэв.

//++ VION 07/20/2016 0001234 Эхлэл дээр дуусгах //-- VION 2016/07/20
  • //++ - блокийн эхлэл
  • //— - блокийн төгсгөл
  • VION - хөгжүүлэгчийн нэр (эсвэл хоч).
  • 0001234 - трекерийн дагуу даалгаврын дугаар, зөвхөн нээлтийн тайлбарт байрлуулсан бөгөөд ингэснээр кодын өөрчлөлт бүр дэлхийн хайлтын үр дүнд зөвхөн нэг удаа даалгаврын дугаараар гарч ирнэ.
  • Эхэндээ сайжруулсан- шаардлагатай бол дурын тайлбар, гэхдээ даалгаврын дугаар байхгүй бол товч тайлбар текст шаардлагатай

Сэтгэгдэл нь стандарт функцтэй харьцуулахад өөрчлөлтүүдийг тодруулах зорилготой юм. Хэрэв хөгжүүлэгч ижил даалгаврын хэсэг болгон хэсэг хугацааны дараа өөрийн хийсэн өөрчлөлтийн текстийг өөрчилсөн бол ийм өөрчлөлтийг тусад нь тайлбарлахгүй (мөн одоо байгаа гадаад тайлбарыг өөрчлөхгүй). Хэрэв хөгжүүлэгч текстдээ өөрчлөлт оруулсан боловч өөр даалгаварт зориулж, эсвэл өөр хөгжүүлэгчийн бичсэн кодыг өөрчилсөн бол тайлбарыг ашиглах хэрэгтэй.

Хоосон тайлбаруудыг засварласан кодын блокийн зүүн ирмэгтэй зэрэгцүүлсэн байна. Доорх жишээнүүд нь өөрчлөлтийн тайлбарыг хэрхэн ашиглахыг харуулж байна:

2.1 Код оруулах

Жишээ:

Нээх журам() Хэрэв энэ нь шинэ бол() Дараа нь талбаруудыг өгөгдмөлөөр бөглөнө үү(); endIf; SetFormElements(); //++ VION 07/20/2016 0001234 ConfigureAdditionalElements(); //-- VION 07/20/2016 SetFieldVisibility (); Процедурын төгсгөл

2.2 Кодыг устгах

Жишээ:

Процедур OnOpen() //++ VION 2016/07/20 0001234 //Хэрэв энэ нь шинэ бол() Дараа нь // Өгөгдмөл талбаруудыг бөглөнө үү(); //EndIf; ConfigureAdditionalItems(); //-- VION 07/20/2016 SetFieldVisibility (); Процедурын төгсгөл

2.3 Одоо байгаа кодыг өөрчлөх

Одоо байгаа кодыг өөрчлөхдөө эхлээд хуучин блокыг тайлбарлаж, дараа нь шинэ хувилбарыг бичнэ.

Жишээ:

Процедур OnOpen() Хэрэв энэ шинэ бол() Дараа нь //++ VION 07/20/2016 000123 //Талбаруудыг өгөгдмөлөөр бөглөх(); FieldFillSetting = GetFieldFillSetting(); FillFieldsDefaultExtended(SettingFillFields); //-- VION 2016.07.20 EndIf; SetFormElements(); SetFieldVisibility (); Процедурын төгсгөл

2.4 Модульд процедур, функц нэмэх

Нэмэлт журам, функцүүдийн хувьд, түүнчлэн стандарт объектуудын модулийн хувьсагчдыг зарлахад дараахь зүйл хамаарна. нэмэлт дүрэмсэтгэгдлийг форматлах:

  • Энэ нь бүхэлдээ нэмэлт процедурын блок биш, харин тайлбарыг өгдөг тус бүр-д процедур эсвэл функц нэмсэн тус тусад нь.
  • Нээлтийн тайлбар нь процедур эсвэл функцийн толгойн өмнөх мөрөнд, хаалтын тайлбар нь явдаг ижил мөрөнд, "Журмын төгсгөл" эсвэл "Процедурын төгсгөл" гэж бичээстэй зайгаар тусгаарлана.
  • Одоо байгаа журмын дагуу гарсан өөрчлөлтийн талаархи тайлбарыг ашиглан хийгддэг ерөнхий дүрэм.

Жишээ:

//++ VION 07/20/2016 000123 Хувьсах mSettingField Filling; Процедурыг ModifyFormProgrammatically () ... ... EndProcedure//-- VION 2016/07/20 //++ VION 2016/07/20 000123Процедурын огноо Ачаалах Боловсруулах Сонголт () ... ... EndProcedure//-- VION 2016.07.20

Энэ дүрэм нь тохиргооны "процедурын харьцуулалт" дахь модулийн өөрчлөлтийг хялбархан шилжүүлэх боломжийг танд олгоно.

Хэрэв та хаалтын тайлбарыг дараагийн мөрөнд оруулбал:

Дараа нь "процедурын харьцуулалт" хийх явцад энэ тайлбарыг текст дэх дараагийн журмын тайлбар гэж хүлээн зөвшөөрөх бөгөөд үүнийг өөрчлөгдсөн гэж үзнэ.

3. Дээд түвшний объектуудыг нэмэх

Нэр дээд түвшний объектууд,тохиргоонд үүсгэсэн, ЗаавалТанай компанийн угтвар эсвэл тодорхой төслийн угтвараас эхлэх ёстой. Дүрмээр бол энэ нь хоёр, гурваас бүрдэнэ том үсэгнүүдба доогуур зураас, жишээ нь AB_. Үүний дагуу үүсгэсэн объектуудыг дуудах болно AB_Шинэ лавлах, AB_ШинэМэдээллийн Бүртгэл, AB_NewDocumentгэх мэт.

Нэмсэн дээд түвшний объектуудын синоним (хэрэглэгчийн харагдах нэр) нь хаалтанд орсон угтвараас эхлэх ёстой: (AB). Үүний үр дүнд эдгээр объектуудыг жагсаалтад нүдээр тодруулж, эхэнд нь бүлэглэх болно (энэ нь туршилт, ашиглахад хялбар болгодог).

Үүсгэсэн объектын тайлбарт та хөгжүүлэгчийн нэр, огноо, даалгаврын дугаарыг нэмж оруулсан кодтой төстэй, гэхдээ "++" тэмдэггүйгээр зааж өгөх ёстой. Энэ нь тохиргооны объект нь глобал хайлтаар олдсон даалгавартай холбоотой байх болно.

Жишээ: "Төсөл" лавлах үүсгэнэ үү.

Хөгжүүлэгчийн үйлдлүүд: тохиргоонд дараах директор үүсгэгдсэн:

  • Нэр: AB_Projects
  • Ижил нэр: (AB) Төслүүд

4. Дэд объект нэмэх

Тохируулгын объектын дэлгэрэнгүй мэдээллийг нэмэх арга нь тухайн өмчийг аль тохиргооны объектод нэмсэнээс хамаарна: ханган нийлүүлэгчийн үүсгэсэн тохиргооны объектод стандарт шийдэл(жишээ нь дэмжлэгт байгаа объект) эсвэл одоогийн төслийн нэг хэсэг болгон нэмсэн объект (жишээ нь аль хэдийн угтвартай).

4.1 Стандарт тохиргооны объектуудад дэд объектуудыг нэмэх

Одоо байгаа (стандарт) тохиргооны объектуудад нэмсэн дэд объектууд заавал байх ёстой угтвар байх: AB_Нэмэлт хэрэглүүр, AB_NewTabularPart, AB_FormUserSettings, AB_LayoutSpecialInvoice. Гэхдээ үүнтэй зэрэгцэн ийм дэд объектуудын синонимууд үүсдэг угтваргүй.

Үүсгэсэн объектын тайлбар дээр та хөгжүүлэгчийн нэр, огноо, даалгаврын дугаарыг зааж өгөх ёстой. Энэ нь тохиргооны объект нь глобал хайлтаар олдсон даалгавартай холбоотой байх болно.

Жишээ: "Урьдчилгаа төлбөр" баримт бичгийн "Төсөл" атрибутыг үүсгэнэ.

Хөгжүүлэгчийн үйлдлүүд: тохиргоонд дараах шинж чанарыг үүсгэсэн:

  • Нэр: AB_Project
  • Ижил нэр: Төсөл
  • Сэтгэгдэл: // VION 07/20/2016 000123

4.2 Төслийн хүрээнд нэмсэн объектод дэд объектуудыг нэмэх

Төслийн доторх тохиргоонд нэмсэн дээд түвшний объектуудад нэмэгдсэн дэд объектуудыг, өөрөөр хэлбэл нэрэнд угтварыг аль хэдийн агуулж байна. угтваргүй. Ийм дэд объектуудын синонимууд бас үүсдэг угтваргүй.

Үүсгэсэн объектын тайлбар дээр та хөгжүүлэгчийн нэр, огноо, даалгаврын дугаарыг зааж өгөх ёстой. Энэ нь тохиргооны объект нь глобал хайлтаар олдсон даалгавартай холбоотой байх болно. Дэлгэрэнгүй мэдээллийг дээд түвшний объекттой ижил ажлын хэсэг болгон үүсгэсэн бол тайлбарыг орхигдуулж болно.

Жишээ: "(AB) Projects" лавлах дотор "Хариуцлагатай" шинж чанарыг үүсгэнэ үү.

Хөгжүүлэгчийн үйлдлүүд: Хэрэв даалгавар нь "(AB) Projects" лавлах үүсгэгдсэнээс өөр байвал тохиргоонд дараах дэлгэрэнгүй мэдээллийг үүсгэнэ.

  • Нэр: Хариуцлагатай
  • Ижил нэр: Хариуцлагатай
  • Тайлбар: // VION 07/20/2016 000456

5. Урьдчилан тодорхойлсон элементүүдийг нэмэх

Урьдчилан тодорхойлсон лавлах элементүүд, шинж чанарын графикууд, дансны графикуудыг нэмэхдээ дэд объектуудыг нэмэхтэй ижил дүрмийг ашиглах хэрэгтэй ( хүснэгтийн хэсгүүд, дэлгэрэнгүй) дээд түвшний объект руу оруулна.

5.1 Стандарт тохиргооны объектуудад урьдчилан тодорхойлсон элементүүдийг нэмэх

Ердийн тохиргооны объектуудад урьдчилан тодорхойлсон элементүүдийг заавал нэмэх шаардлагатай угтвартай. Нэрийг нь өгсөн угтваргүй.

Жишээ:Урьдчилан тодорхойлсон данс 10.15-ыг "Зардлын бүртгэл" дансны схемд нэмнэ үү - Хатуу тайлагнах маягтууд.

Хөгжүүлэгчийн үйлдлүүд: Дараах урьдчилан тодорхойлсон бүртгэлийг нэмнэ үү:

  • Нэр: AB_FormsStrictReporting
  • Код: 10.15
  • Нэр: Хатуу тайлагнах маягтууд

Хэрэв та ердийн тохиргооны объектын урьдчилан тодорхойлсон элементийн нэрийг өөрчлөх шаардлагатай бол (жишээлбэл, нэхэмжлэх) объектыг өөрчлөхгүй орхиж, тусгай .

5.2 Төслийн хүрээнд нэмсэн объектуудад урьдчилан тодорхойлсон элементүүдийг нэмэх

Урьдчилан тодорхойлсон элементүүдийг төслийн хүрээнд нэмсэн тохиргооны объектуудад нэмсэн, өөрөөр хэлбэл нэрэндээ угтварыг аль хэдийн агуулж байна. угтваргүйнэр, гарчиг дээр.

6. Нийтлэг модулиудын хэрэглээ, тэдгээрийн хатуу бүтэц

Тохиргоонд олон удаа ашиглагддаг журам, функцууд, захиалгын процессорууд болон ердийн даалгаварууд нь нийтлэг модулиудад байрладаг. Эдгээр зорилгын үүднээс та нэмэх хэрэгтэй өөрийн модулиуд, дээд түвшний объектуудаар нэмж, стандарт модулиудыг үлдээдэг өөрчлөгдөөгүй. Дараах нийтлэг модулиуд ("AB_" нь угтвар) хөгжүүлэлтийн явцад хэрэг болно:

  • AB_Ерөнхий зорилго (үйлчлүүлэгч, сервер, гадаад холболт) - нийтлэг журам, функцийг тохируулах.
  • AB_Server (зөвхөн сервер) - серверийн орчинд гүйцэтгэх ёстой процедур, функцүүдэд зориулагдсан.
  • AB_Global - стандарт аргаар дуудахад тохиромжгүй процедур, функцүүдийн хувьд (модулийн нэр, үеээр).
  • AB_Privileged - үргэлж бүрэн эрхтэйгээр гүйцэтгэх шаардлагатай журам, чиг үүргийн хувьд.
  • AB_Дахин ашиглах - зарим функцийн буцаах утгыг кэш болгох.

Та функциональ блокуудын кодыг тусдаа нийтлэг модулиудад оруулж болно их хэмжээний эзэлхүүн, энэ тохиолдолд ийм кодыг дибаг хийх нь тохиргооны дэлгүүрийг ашиглах үед хялбаршуулсан болно. Бусад тохиолдолд хөгжүүлэгч нь тохиргоонд шинэ модуль нэмэхээс өмнө тохирох нийтлэг модулийг байгаа эсэхийг шалгах ёстой.

7. Захиалгын ашиглалт, түүний хатуу бүтэц

Стандарт тохиргооны объектуудтай холбоотой янз бүрийн үйл явдлуудыг боловсруулахын тулд боломжтой бол объектын модулиудад өөрчлөлт оруулахын оронд захиалгын механизмыг ашиглах хэрэгтэй.

Үйл явдал бүрийн хувьд байж болно нэгээс илүүгүй захиалга(мета өгөгдлийн объектын хувьд) зохицуулагч болон холбогдох кодыг оруулах ёстой тусдаа нийтлэг модуль(хөгжүүлэгчдийн хадгалалтын ажлын зэрэгцээ байдлыг нэмэгдүүлэх). Захиалгын нэр болон нийтлэг модулийн нэр байх ёстой адилхан байнаТэгээд харгалзахболовсруулж буй үйл явдал. Захиалгын эх сурвалжийг зааж өгсөн болно Бүгдболовсруулах боломжтой объектууд (бүх лавлах, бүх баримт бичиг гэх мэт).

Захиалга зохицуулагчийн процедур нь шаардлагатай үйлдлийг гүйцэтгэх дэд процедурын дуудлагыг агуулсан байх ёстой. Тэдэнд эх сурвалжийн төрлөөс хамаарч, шаардлагатай дарааллаар ханддаг. Шинэ даалгаврын код нэмэх үед захиалгын модульд тайлбар хийх боломжтой.

Жишээ: “Урьдчилгаа төлбөр” баримтыг байршуулахдаа “(AB) Төслийн зардал” хуримтлалын бүртгэлд бичилт хийнэ.

Хөгжүүлэгчийн үйлдлүүд:

1. “AB_DocumentsProcessingProcessing” захиалгыг үүсгэ (хэрэв ийм захиалга өмнө нь үүсгэгдээгүй бол), бүх баримт бичгийг эх сурвалж болгон зааж өгөх, үйл явдал нь “ProcessingProcessing”.

2. “AB_DocumentsProcessing” нийтлэг сервер модулийг үүсгэ.

3. Модульд “ProcessingProcessing” экспортын процедурыг үүсгэнэ. Энэ процедурыг өмнө нь үүсгэсэн захиалгын зохицуулагч болгон сонгоно уу. Процедурын хувьд баримт бичгийн төрлөөс хамааран шаардлагатай зохицуулагчдыг дууддаг.

4. "Урьдчилгаа төлбөр" баримт бичгийн модулийг өөрчлөхгүй байх ёстой.

8. Маягтуудыг засварлах

8.1 Стандарт объектын хэлбэрийг засах

Хэрэв стандарт хэлбэрт (ердийн болон удирддаг) өөрчлөлт бага байвал (жишээлбэл, маягтанд хэд хэдэн шинэ мэдээлэл нэмэх) бол ийм өөрчлөлтийг бүхэлд нь програмын дагуу хийх ёстой. Энэ нь зөвхөн өөрчлөлтийг хийх болно маягтын модуль, мөн хэлбэр нь өөрөө тохируулагчд үлдэнэ өөрчлөгдөөгүй. Зарим хөгжүүлэгчид маягт засварлах энэ аргыг эхэндээ нэлээд төвөгтэй гэж үздэг. Гэсэн хэдий ч программчлагдсан маягтыг өөрчлөх хангалттай туршлагатай бол нэг элемент нэмэхэд 3-5 минутаас ихгүй хугацаа шаардагдана. Стандарт тохиргооны дараагийн шинэчлэлтүүдээр зарцуулсан цаг нь хэд дахин үр дүнгээ өгдөг.

Жишээ: "Урьдчилгаа төлбөр" гэсэн баримт бичгийн үндсэн маягт дээр "(AB) Төсөл" гэсэн дэлгэрэнгүй мэдээллийг оруулна.

Хөгжүүлэгчийн үйлдлүүд: "When CreatedOnServer" маягт зохицуулагч дээр "EditFormProgrammatically()" процедурыг нэмнэ. Энэ процедурт хүссэн элементээ маягтын элементүүдэд нэмнэ.

Стандарт маягтыг өөрчлөхөд шаардлагатай бүх процедур, функцуудыг агуулсан тусдаа модулийг үүсгэх боломжтой.

BSP 2 дээр суурилсан ердийн тохиргоонд эдгээр зорилгоор тусгай функцууд аль хэдийн байдаг:

"Тохиргоог өөрчлөх" ерөнхий модулийн "When CreateOnServer" процедурт та өөрийн зохицуулагчийг дуудаж болно.

Маягтын нэрээр та маягтыг программчлан өөрчлөх замаар шаардлагатай процедурыг дуудаж болно.

Хэрэв та маягтанд нэмэхээр төлөвлөж байгаа бол олон тооны элементүүдэсвэл хүснэгтийн хэсгүүдийг гараар өөрчлөх боломжтой. Энэ тохиолдолд маягт дээр тусдаа таб үүсгэж, шаардлагатай бүх элементүүдийг байрлуулахыг зөвлөж байна. Энэ нь ирээдүйн маягтын шинэчлэлтийг илүү хялбар болгоно.

8.2 Төслийн хүрээнд нэмсэн объектуудын хэлбэрийг засварлах

Төслийн хүрээнд нэмсэн объектын хэлбэрийг (өөрөөр хэлбэл нэрэнд нь угтвар бичсэн) ердийн аргаар засварладаг.

9. Дүртэй ажиллах зарчим

Ерөнхий үүргийг үргэлж өөрчлөхгүй байх ёстой (боломжтой бол). Энэ нь шинэ хувилбаруудаас өөрчлөгдсөн тохиргоог шинэчлэхэд зайлшгүй шаардлагатай, учир нь дүрүүдийг харьцуулах, сэргээх нь нарийн төвөгтэй бөгөөд хэцүү үйл явц юм.

Тохиргоонд нэмсэн объектуудын эрхийг хуваарилах ёстой шинээрэнэ зорилгоор бүтээсэн дүрүүд.

Ердийн дүрүүдийн зөвшөөрөгдсөн өгөгдөлд хандах хязгаарлалтыг хэрэгжүүлэх ёстой программын хувьд, боломжтой байхад. Зөвхөн ийм хоригийг програмын хувьд хэрэгжүүлэхэд маш хэцүү (эсвэл ийм шийдэл нь найдваргүй байх) үед л стандарт дүрд өөрчлөлт оруулахыг зөвшөөрнө. Ердийн дүрд гарсан өөрчлөлт нь хамгийн бага шаардлагатай бөгөөд баримтжуулсан байх ёстой. Жишээлбэл, хэрэв та дүрд (RLS) нэвтрэх хязгаарлалтын текстийг өөрчлөх шаардлагатай бол та бүх жишээ кодыг тайлбарлаж, шаардлагатай өөрчлөлтүүдтэй кодыг нэмэх хэрэгтэй.

10. Гадны тайлан, боловсруулалт

Системийн ихэнх сайжруулалтыг Нэмэлт тайлан, боловсруулах механизмыг ашиглан хийж болно.

BSP 2 (ERP, UT 11, BP 3.0, ZUP 3.0 гэх мэт) дээр суурилсан тохиргоонд энэ механизм ихээхэн өргөжиж байна. Түүний тусламжтайгаар тохиргоог өөрчлөхгүйгээр гадны тайланг үүсгэх, боловсруулах (командын интерфейс дээр эхлүүлэх командыг байрлуулж, янз бүрийн хэрэглэгчдэд хандах хандалтыг тохируулах боломжтой), баримт бичгийг бөглөх, боловсруулах боломжтой. үндсэн дээр баримт бичиг үүсгэх, нэмэлт хэвлэсэн маягт гэх мэт.

Энэ нийтлэл танд тусалсан уу?

1С 8.2 ба 8.3 нь маш чухал ач холбогдолтой өрсөлдөх давуу тал— 1С стандарт тохиргоог өөрчлөх, платформ дээр тулгуурлан өөрийн шийдлийг боловсруулах чадвар. Энэ нь суурилуулсан хөгжүүлэлтийн орчны ачаар хийгддэг бөгөөд систем нь бүр өөрийн гэсэн .

1С компани нь үйлчлүүлэгчдийнхээ төлөө санаа зовж, зах зээл дээрх бүх байгууллагад хамгийн сайн тохирох шийдлүүдийг гаргахыг хичээж байна. Компани бүр хүн шиг өвөрмөц байдаг. Энэ бол таны хэрэгцээнд нийцүүлэн 1С тохиргооны нэг төрлийн "тохируулга" юм.

1С-д ихэвчлэн ямар шинэ зүйл хийдэг вэ?

Дүрмээр бол өөрчлөлтүүд нь програмын интерфейсийн хэсэгт хамаарна. Гэсэн хэдий ч тохиргоонд ноцтой өөрчлөлтүүд бас бий - шинэ дэд системүүд, шинэ алгоритмуудыг нэвтрүүлэх.

1С 8.3 дахь өөрчлөлтүүдийн жишээ:

  • Хэрэглэгчийн эрхийг тохируулахболон үндсэн утгууд. Эрхийн уян хатан тохиргоо - маш чухал цэг. Хэрэглэгчид болон тэдний эрхүүд нь үүнгүйгээр олон хэрэглэгчийн системд ажиллах боломжгүй зүйл юм.
  • Өөрчлөлт хийх, шинээр бий болгох хэвлэсэн маягтууд. Хэвлэсэн маягт нь 1С дахь баримт бичигтэй тэнцэх цаас юм. Байгааг нь боловсронгуй болгож, шинээр нэмэх боломжтой. Хэвлэсэн маягтыг засварлах нь тохиргоог өөрчлөхгүйгээр хийж болно.
  • Шинээр бий болгох, одоо байгаа зүйлийг өөрчлөх тайлангууд. Тайлан бол аливаа шинжилгээний эцсийн бүтээгдэхүүн юм мэдээллийн систем, үүнд 1С Enterprise орно. Програмын тайланг тохиргоог өөрчлөхгүйгээр өөрчлөх боломжтой.
  • . Дүрмээр бол, техникийн мэдлэггүй үйлчлүүлэгч програмистуудад зориулсан чадварлаг техникийн тодорхойлолтыг үргэлж бичиж чаддаггүй. Үүний зэрэгцээ, даалгаврыг өөрөө дотооддоо эсвэл гуравдагч этгээдийн компаниуд гүйцэтгэж болно.
  • Тохиргоонд нэмж байна шинэ функц. 1С бол бүх нийтийн систем бөгөөд үйлчлүүлэгч бүрийн хүслийг харгалзан үзэх боломжгүй юм. Чадварлаг мэргэжилтнүүд програмын функцийг мэдэгдэхүйц өргөжүүлж, "тогтоолгүй" нэгтгэх боломжтой.
  • 1С гүйцэтгэлийг оновчтой болгох. 1С Enterprise систем нь гүйцэтгэлийн хувьд сегментдээ тэргүүлэгчдийн нэг юм. Гэсэн хэдий ч олж авах хамгийн дээд хурдСистемийг ажиллуулахын тулд үйлчлүүлэгчийн мэдээллийн технологийн дэд бүтцэд тохируулсан зарим өөрчлөлтийг хийх шаардлагатай.

1С мэргэжилтний нэг цагийн ажлын үнэ

Стандарт 1С тохиргоог өөрчлөх ажлын зардлыг ихэвчлэн хүн-цагаар тооцдог.

За, бусад хүмүүс мууранд тавтай морилно уу.

Цаашдын дэмжлэг, шинэчлэлтийг хөнгөвчлөхийн тулд стандарт 1С тохиргоог дуусгах дүрэм, арга техник

Тиймээс бид төсөл хэрэгжүүлэхдээ (“Бид” гэдэг нь бизнесийн үйл явцыг автоматжуулахад оролцдог бүх хүмүүсийг хэлж байна) дараа нь энэ нь дэмжлэг болж хувирна гэж найдаж байна. Дүрмээр бол бүх зүйл сайн хийгдсэн, үйлчлүүлэгч сэтгэл хангалуун байвал ийм зүйл тохиолддог.

Тусламж нь маш тодорхой багц даалгавраар тодорхойлогддог - эдгээр нь "эдгээр тоо хаанаас ирсэн бэ" эсвэл зарим ойлгомжгүй алдааг засах гэх мэт зөвлөгөө өгөх даалгавар байж болно. Гэхдээ бараг бүх төслүүд нь хэрэглэгчийн хэрэгцээнд зарим стандарт шийдлийг дасан зохицохыг шаарддаг тул дэмжлэг бүхий тохиргоог үе үе шинэ хувилбаруудад шинэчилж байх шаардлагатай.

  • Хэрэв та хөгжлийн зарим дүрмийг дагаж мөрдвөл төслийн үе шатанд маш бага хөдөлмөр зарцуулсан бол ирээдүйд тохиргоог хадгалах, шинэчлэхэд хэмнэлт гаргах боломжтой.
  • Мөн эсрэгээр, хэрэв төслийн үе шатанд зарим алдаа, яаруу эсвэл буруу код форматтай байсан бол дараа нь энэ нь дэмжлэг, шинэчлэлтийн жинхэнэ тамд хүргэж болзошгүй юм.

Хэн нэгэн таних тэмдэггүйгээр дахин бичсэн тохиргоог шинэчлэх шаардлагатай байсан уу? Хуучин үйлдвэрлэгчийн тохиргоог шинэ тохиргоотой харьцуулах, одоогийн тохиргоотой харьцуулахдаа "хоёр удаа өөрчлөгдсөн" тохиолдол бүрийг гараар задлан шинжлэх нь ямар зовлонтой болохыг та ойлгож байна уу. Энэ бүхэн нэлээд асуудалтай.

Стандарт тохиргоонд өөрчлөлт оруулах 9 энгийн дүрэм

1. Стандарт тохиргооны "устгалтыг" багасгах тухай ойлголт

Эхнийх нь дүрэм биш, энэ нь стандарт тохиргоог "устгах" -ыг багасгах нэг төрлийн ойлголт юм.

Үүний мөн чанар нь ийм шийдлийг хэрэгжүүлэхэд арай илүү хэцүү байсан ч гэсэн ирээдүйд тохиргооны шинэчлэлтийг илүү хялбар болгох асуудлыг шийдвэрлэх аргуудыг үргэлж сонгох хэрэгтэй. Үүнийг фанатизмгүйгээр, боломжийн хязгаарт багтаан хийх нь ойлгомжтой боловч хөгжүүлэгч нь тохиргоо нь дэмжлэгтэй хэвээр байгаа гэдгийг үргэлж санаж, түүний код ирээдүйд тохиргоог шинэчлэхэд хэр их хүндрэл учруулж байгааг дүн шинжилгээ хийж, хамгийн тохиромжтой шийдлийг сонгох ёстой.

2. Кодын өөрчлөлтийг тайлбарлах

Хоёрдахь дүрэм бол l аливаа кодын өөрчлөлтийг тайлбар өгөх ёстой.

Манай компанид бид дараахь схемийг ашигладаг.

  • Өөрчлөлтийн эхэнд байна нээлтийн сэтгэгдэл(тэмдэгтээр эхэлдэг //++ )
  • Төгсгөлд нь - хаалтын сэтгэгдэл(тэмдэгтээр эхэлдэг //-- )
  • А хөгжүүлэгчийн хийсэн өөрчлөлтүүд дунд байна.

Энэ нь аливаа өөрчлөлтөд заавал дагаж мөрдөх дүрэм юм.

Нээлтийн болон хаалтын тайлбарууд нь өөрчлөлтийн тэмдэгтэй байдаг. Үүнд дараахь зүйлс орно бүрэлдэхүүн хэсгүүд:

  • Төслийн угтвар- анхдагч байдлаар бид FTO ашигладаг
  • Хөгжүүлэгчийн домэйн нэр. Энэ нь маш тохиромжтой байдлаар байгуулагдсан: компани нь том, тархсан, хэрэв та хөгжүүлэгчийг мэдэхгүй, гэхдээ та түүнээс түүний талаар ямар нэгэн зүйл асуух шаардлагатай бол энэ хаягаас түүний хоч авч, @fto.com.ru дээр тавьж болно. баруун тийш, түүнд захидал илгээж, түүнтэй холбоо барина уу.
  • Дараа нь ирдэг өөрчлөлт оруулсан огноо. Хэд хэдэн даалгаврын хүрээнд өөрчлөлт гарах үед эдгээр багц сэтгэгдлүүд хоорондоо үүрлэж болох бөгөөд энэ хаалтын тайлбар аль нээх блокт хамаарах нь үргэлж тодорхой байдаггүй тул бид он сар өдөр дээр анхаарлаа хандуулдаг. Нэмж дурдахад, огноо нь хэзээ өөрчлөлт хийгдсэнийг шууд харуулдаг: гурван жилийн өмнө, зургаан сарын өмнө эсвэл өчигдөр.
  • Дараа нь ирдэг даалгаврын дугаар, аль зөвхөн нээлтийн тайлбарт байрлуулсан. Яагаад зөвхөн тэнд? Тиймээс даалгаврын дугаараар дэлхийн хэмжээнд хайх явцад зөвхөн код өөрчлөлтийн эхлэлийг сонгоход оруулсан бөгөөд үүнээс доош харж болно, эс тэгвээс хоёр дахин нэмэгдэх болно. Жишээлбэл, кодыг шалгахад даалгавраа илгээхдээ тусгай шошгооор хайх нь маш тохиромжтой.

Жишээ

Энэ нь иймэрхүү харагдаж байна код оруулах:

Энэ нь иймэрхүү харагдаж байна кодыг арилгах- бид кодыг бүрэн устгахгүй, бид кодын тайлбарыг өгдөг. Үүний ачаар та юу гэж бичсэнийг үргэлж харж, ямар нэг зүйл тохиолдвол хурдан буцаж болно.

Энэ нь иймэрхүү харагдаж байна кодын өөрчлөлт: Эхлээд бүх борлуулагчийн кодыг тайлбарлаж, дараа нь өөрийн кодыг нэмнэ.

Тусдаа дүрэм ажилладаг журам, функц болон глобал модулийн хувьсагчдыг нэмэх. Энэ тохиолдолд гэсэнтэй ижил мөрөнд хаалтын тайлбарыг байрлуулна түлхүүр үгПроцедурын төгсгөл. Яагаад үүнийг хийсэн бэ? "Процедурын харьцуулалт" ашиглан өөрчлөлтийг шилжүүлэхэд хялбар болгохын тулд.

Зурган дээрээс та үүнийг харж болно "процедурын харьцуулалт" -ыг ашиглан та нэгтгэхдээ энэ процедурыг зүгээр л онцолж болно, мөн энэ нь бүрэн шилжинэ (тэмдэглэгээний хамт). Эсвэл эсрэгээр нь шилжүүлэхгүйн тулд хажууд байгаа хайрцгийн сонголтыг арилгаж болно.

Хэрэв хаалтын тайлбар нь дараагийн мөрөнд байвал дараагийн процедурт хуваарилагдах бөгөөд нэмэлт зардалгүйгээр үүнийг зүгээр л шилжүүлэх боломжгүй болно.

3. Дээд түвшний объектуудыг нэмэх

Дараагийн дүрэм бол дээд түвшний объектуудыг (лавлах, баримт бичиг, бүртгэл гэх мэт) тохиргоонд нэмэх явдал юм.

Энэ дүрэм нь ийм юм объектын нэр угтвараас эхлэх ёстой.Юуны төлөө?

  • Нэгдүгээрт, энэ нь тохиргоо болон кодонд нэмсэн элементийг нүдээр тодотгож өгдөг Энэ нь бидний нэмсэн объект болох нь шууд тодорхой болно.
  • Хоёрдугаарт, нэрний өвөрмөц байдалд хүрсэн, учир нь үйлчилгээ үзүүлэгч ижил нэртэй өөрийн объектыг нэмж болно. Хэрэв бид өөрсдийн угтварыг ашиглавал энэ нь бидний нэр өвөрмөц байх болно гэсэн баталгаа юм.

Объектын синонимууд нь хаалтанд угтвараас эхлэх ёстой. Энэ нь интерфэйс дээр нэмсэн объектоо тодруулах боломжийг бидэнд олгодог.

Мэдээжийн хэрэг, энэ бол маш маргаантай дүрэм бөгөөд түүний ашиглалтыг хэрэглэгчтэй тохиролцсон байх ёстой. Манай үйлчлүүлэгчид энэ схемд сэтгэл хангалуун байсан тул энэ нь бидэнтэй хамт үндэслэж, дүрмийн нэг хэсэг болсон. Гэхдээ үүнийг хийх эсэхээ та болон үйлчлүүлэгч өөрөө шийдэх болно.

За, сүүлийн дүрэм: бүх нэмсэн объектын тайлбар нь хөгжүүлэгчийн нэр, даалгаврын дугаар бүхий тусгай шошго агуулсан байх ёстой. Энэ шошго нь модулийн нээлтийн тайлбартай төстэй бөгөөд зөвхөн тусгай тэмдэгтгүй - түүний тусламжтайгаар би энэ объектыг хэн, хэзээ, ямар зорилгоор нэмсэнийг үргэлж ойлгож чадна.

Тиймээс, нэгтгэн дүгнэхэд:

  • Нэрсийг угтвараар зааж өгсөн,
  • Синонимууд - хаалтанд угтвартай
  • Мөн сэтгэгдэл нь тусгай шошго агуулсан байх ёстой.

4. Дэд объект нэмэх

Дэд объект нэмснээр би таяг, зохион байгуулалт, маягт гэх мэтийг нэмэхийг хэлж байна. тохиргооны объектууд руу.

Энд бид дэд объект нэмэх хоёр нөхцөл байдлыг нэн даруй тодруулах хэрэгтэй.

  • Ердийн тохиргооны объектод
  • Эсвэл төслийн хүрээнд өмнө нь нэмсэн объект руу.

Эдгээр нөхцөл байдал бүрийг тусад нь авч үзье.

Стандарт тохиргооны объектуудад дэд объектуудыг нэмэхДараах дүрмийг баримтална.

  • Нэр нь ижил угтвараар эхлэх ёстой. Үүний ачаар бид нэрний өвөрмөц байдлыг олж авдаг бөгөөд энэ нь бидний объект болох нь үргэлж тодорхой байдаг.

  • Синонимыг угтваргүйгээр бөглөнө, учир нь энд бидний объект, нарийн ширийн зүйлийг тодруулах шаардлагагүй болсон.

  • Мөн эцэст нь, сэтгэгдэл нь мөн тусгай шошго агуулна, ингэснээр хэн, хэзээ, яагаад гэдэг нь тодорхой болно.

Тиймээс, ердийн тохиргооны объектуудад дэд объектуудыг нэмэх нь хэрхэн ажилладагийг нэгтгэн дүгнэж үзье.

  • Нэрсийг угтвараар зааж өгсөн,
  • Ерөнхий дүрмийн дагуу синонимууд
  • Мөн сэтгэгдэл нь тусгай шошго агуулдаг.

А хэрэв бид өмнө нь төсөлд нэмж оруулсан объектуудад дэд объектуудыг нэмбэлмөн тэдний нэрэнд угтвар байгаа бол:

  • Тэдний нэрэнд угтвар байж болохгүй, учир нь тухайн объект аль хэдийн өвөрмөц болсон нь тодорхой болсон бөгөөд үүнийг өөр аргаар тусгайлан тодруулах шаардлагагүй болно.

  • Ийм дэд объектуудын синонимуудыг мөн угтваргүйгээр зааж өгдөг, учир нь тусгай сонголт хийх шаардлагагүй.

  • Хэрэв энэ дэд объектыг өөр даалгаврын нэг хэсэг болгон нэмсэн бол тайлбар нь тусгай шошгыг агуулна. Учир нь миний даалгаварт ийм, ийм нарийн ширийн зүйлийг агуулсан баримт бичгийг нэмэх шаардлагатай гэж үзвэл би дэлгэрэнгүй мэдээлэл бүрт ийм шошго тавих шаардлагагүй болно. Гэхдээ даалгавар нь шал өөр бол би яагаад үүнийг хийсэн нь тодорхой болохын тулд тэмдэглэгээ хийхээ мартуузай.

Одоо төслийн хүрээнд нэмсэн объектуудад дэд объектууд хэрхэн нэмэгдэж байгааг нэгтгэн дүгнэж үзье.

  • Угтваргүй нэрс.
  • Угтваргүй синонимууд.
  • Сэтгэгдэл нь өөр ажлын хэсэг болгон нэмсэн тохиолдолд зөвхөн тусгай шошго агуулсан байх ёстой.

Хэрэв бид энэ дүрмийг хоёр тохиолдолд нэгтгэж, "хэсэг болгон хуваах" бол дараах хүснэгтийг авна.

  • Шинэ объектууд:
    • Нэр нь угтвараас эхэлдэг.
    • Синонимууд - хаалтанд угтвартай.
    • Сэтгэгдэл нь шошго агуулж байна.
  • Бидний ерөнхий объектуудад нэмдэг дэд объектууд:
    • Нэр нь угтвараас эхэлдэг,
    • Ерөнхий дүрмийн дагуу синоним
    • Сэтгэгдэл дээр шошго хийнэ үү.
  • Хэрэв бид төслийн хүрээнд нэмсэн объектуудад дэд объектуудыг нэмбэл
    • Тэдний хувьд тусгай дүрэм байдаггүй,
    • Гэхдээ хэрэв даалгавар өөр бол бид ижил аргаар тайлбар дээр шошго тавьдаг.

5. Урьдчилан тодорхойлсон элементүүдийг нэмэх

Дараагийн дүрэм бол урьдчилан тодорхойлсон элементүүдийг нэмэх явдал юм.

Энд хоёр нөхцөл байдлыг яг ижил байдлаар ялгаж болно.

  • Бид ердийн тохиргооны объектод урьдчилан тодорхойлсон элементийг нэмэх үед (лавлах ном, шинж чанарын төрлүүдийн төлөвлөгөөнд)
  • Мөн бид төслийн хүрээнд нэмсэн объектод урьдчилан тодорхойлсон элемент нэмэх үед.

Хэрэв бид ерөнхий тохиргооны объектод урьдчилан тодорхойлсон элемент нэмбэл,

  • Түүний Нэртөстэй угтвараас эхлэх ёстой. Тиймээс бид түүний нэрний өвөрмөц байдлыг баталгаажуулж, нэмсэн элементээ шууд нүдээр тодорхойлох боломжтой болно.
  • Код болон нэрбүрдэх болно ерөнхий дүрмийн дагуу,
  • Гэхдээ шошгоэнд харамсалтай нь хаана ч тавихгүй. Тиймээс, дэлхийн даалгаврын хайлтыг ашиглан урьдчилан тодорхойлсон нэмэлт элементийг олох боломжгүй болно.

А хэрэв бид төслийн хүрээнд нэмсэн объектуудад урьдчилан тодорхойлсон элементүүдийг нэмбэл, Тэр

  • Түүний нэр нь угтвар агуулаагүй болно, учир нь ямар нэгэн байдлаар онцлох шаардлагагүй.

Тиймээс, хэрэв бид өмнөх хүснэгттэй аналоги зурвал:

  • Ерөнхий объектуудын урьдчилан тодорхойлсон элементүүдийг угтвартай нэмж,
  • Бусад бүх зүйл - ерөнхий дүрмийн дагуу тусгай угтвар нэмэх шаардлагагүй.

6. Нийтлэг модулиудын хэрэглээ, тэдгээрийн хатуу бүтэц

Дараагийн дүрэм нь нийтлэг модулиудыг ашиглах, тэдгээрийн хатуу бүтцийг зохион байгуулахтай холбоотой юм.

Нэгдүгээрт, олон удаа ашигладаг процедур, функц, захиалга зохицуулагч болон ердийн ажлуудын хувьд та өөрийн модулиудыг нэмж, стандарт модулиудыг өөрчлөхгүй байх хэрэгтэй. Хэрэв хөгжүүлэгч ямар нэг төрлийн экспортын процедурыг стандарт модульд байрлуулахыг хүсч байвал үүнийг хийх шаардлагагүй, та өөрийн модулийг үүсгэх хэрэгтэй.

Хоёрдугаарт, үүнийг анхаарна уу нийтлэг модулиуд нь дээд түвшний объектуудыг нэмэх дүрмийн дагуу нэмэгддэг(нэр, угтвартай ижил утгатай, тайлбар дахь шошго гэх мэт)

Гуравдугаарт, модулийн нэр нь холбогдох стандарт модулиудтай төстэй байх ёстой.

Дугуйг дахин зохион бүтээх шаардлагагүй: бид үүнийг стандарт тохиргоонд ашигладаг заншилтай адил гэж нэрлэдэг - функц бүрийн хувьд 1С-ийн нийтээр хүлээн зөвшөөрөгдсөн тэмдэглэгээнд тохирсон өөрийн модуль юм. Жишээлбэл:

  • FTO_Ерөнхий зориулалтын үйлчлүүлэгч,
  • FTO_Ерөнхий зориулалтын сервер,
  • FTO_General Purpose Global,
  • FTO_RoutineTasksServer
  • гэх мэт.

Мөн зарим нь бие даасан томоохон ажлуудчи чадна (мөн магадгүй) тусдаа нийтлэг модулиудад оруулах.


7. Захиалгын ашиглалт, түүний хатуу бүтэц

Дараагийн дүрэм бол захиалга, тэдгээрийн хатуу бүтэц ашиглах явдал юм. Түүний мөн чанар юу вэ?

Захиалга нь ерөнхий объектуудтай холбоотой янз бүрийн үйл явдлуудыг зохицуулахад ашиглагдах ёстойгэх мэт:

  • Бичлэг хийхээс өмнө
  • Бичлэг хийх үед
  • гэх мэт.

  • Мэдээж авч болно стандарт объектын модулийг засварлах,зохих процедурт өөрийн кодыг оруулах замаар. Гэхдээ энэ - муу арга.
  • Илүү сайнүүний оронд энэ үйл явдлыг боловсруулахын тулд захиалга нэмнэ үү.

Дараах тохиролцсон дүрмийн дагуу захиалга нэмэгдэнэ.

  1. Систем дэх ижил төрлийн бүх үйл явдлын хувьд зөвхөн нэг захиалга нэмэгддэг. Жишээлбэл, хэрэв би "Лавлах бичихээс өмнө" үйл явдлын янз бүрийн лавлахын тулд өөрийн алгоритмыг ашиглах шаардлагатай бол эдгээр бүх лавлахын хувьд "Лавлах бичихээс өмнө" зөвхөн нэг нэмэлт бүртгэлийг ашигладаг.
  2. Эх сурвалж нь энэ ангийн бүх объектыг сонгоно(жишээ нь, бүх лавлах)
  3. Нэмэгдсэн захиалгын хувьд тусдаа модулийг үүсгэсэн бөгөөд үүнийг яг адилхан гэж нэрлэдэг(зөвхөн ая тухтай байлгах үүднээс).
  4. Үндсэн үйл явдал зохицуулагчийн хувьд объектын төрлийг шинжилдэг нөхцөлийг тодорхойлсон(сангийн төрөл).
  5. Тэгээд аль хэдийн Объектын төрлөөс хамааран тодорхой үйлдлүүд хийгддэг.

Би танд жишээгээр харуулж чадна. Ийм даалгавар байна гэж бодъё: "Урьдчилсан тайлан" баримт бичгийг байршуулахдаа өмнө нь нэмсэн хуримтлалын бүртгэлд бичилт хийнэ үү.

Эхлээд бид бүх дүрмийн дагуу FTO_DocumentsProcessingProcessing ерөнхий модулийг нэмнэ.

  • Бид DocumentObject (бүх баримт бичиг)-ийг эх сурвалж болгон зааж өгдөг;
  • Дээр нэмсэн манай модулийг зохицуулагч болгон ашигладаг.

Мөн аль хэдийн модульд, зохицуулагчийн хувьд бид ямар төрлийн баримт бичиг бидэнд ирснийг тодорхойлж, түүний төрлөөс хамааран нэг буюу өөр процедурыг дууддаг.

Нэг захиалга байгаа боловч үйлдэл нь өөр байж болно. ТТа мөн процедурыг дуудах дарааллыг хянах боломжтой.

Үүний үр дүнд захиалга үүсгэх журам дараах байдалтай байна.

  • Нэг захиалга,
  • Нэг нийтлэг модуль
  • Өөр юу ч хэрэггүй: баримт бичгийн модуль өөрчлөгдөөгүй хэвээр байна - энэ нь "хоёр удаа өөрчлөгдсөн" хэсэгт харагдахгүй.


8. Маягтуудыг засварлах

Дараагийн дүрэм бол маягтыг засах явдал юм.

Энд бид хоёр цэг, хоёр нөхцөл байдлыг онцлон тэмдэглэх болно.

  • Бид стандарт маягтуудыг засах үед;
  • Мөн бид төслийн хүрээнд нэмсэн маягтуудыг засах үед.

Эхний нөхцөл байдал бол засварлах явдал юмстандарт маягтууд, ердийн объектын хэлбэрүүд. Энэ бол дүрмийн хамгийн маргаантай цэг юм. Нэгэн үе, ердийн хэлбэрийн үед, төслүүдийг ихэвчлэн SCP дээр хийдэг байсан үед бид маягтыг яах талаар маш их ярилцдаг байсан. Ямар сонголтууд байсан бэ?

  • Тогтмол маягтыг шууд засварлахБи зүгээр л гараар хэлбэрээ өөрчилдөг. Энэ сонголтоор ханган нийлүүлэгч энэ маягтанд өөрчлөлт оруулах бүрт би бүх өөрчлөлтөө дахин шилжүүлэх шаардлагатай болдог. Муу зам.
  • Өөр нэг арга маягтын хуулбарыг үүсгэх. Энэ бол би стандарт маягтын хуулбарыг хийж, үндсэн маягтаар нь тодорхойлж, түүнд өөрчлөлт оруулах явдал юм. Гэхдээ дахин, хэрэв ханган нийлүүлэгч энэ маягтыг өөрчилвөл би тэдний өөрчлөлтийг өөрийн хувилбарт гараар шилжүүлэх хэрэгтэй. Хамгийн сайн арга биш.
  • Өөр нэг сонголт бол тусдаа таб үүсгэх. Бид маягт дээр тусдаа таб үүсгэж, түүн дээр элементүүдээ байрлуулна. Энэ арга нь уян хатан биш нь тодорхой байна, учир нь заримдаа таны элементийг маягтын тодорхой газар хаа нэгтээ оруулах шаардлагатай болдог. Эсвэл та стандарт элементүүдийн шинж чанарыг өөрчлөх, тэдэнд шинэ зохицуулагч томилох гэх мэт хэрэгтэй. Тиймээс энэ уян хатан арга биш- энэ нь бас тийм ч сайн ажиллахгүй байна.
  • Үр дүнд нь Бид маягтуудыг бүрэн программчлан засварлах аргыг сонгосон. Энэ аргыг эхэндээ тааруулж үзээгүй шинэ хөгжүүлэгчид маягтыг программчлан засварлахад маш хэцүү байдаг. Гэвч бодит байдал дээр - үгүй. Миний туршлагаас харахад та үүнийг илүү сайн хийх хэрэгтэй гэдгийг би хэлэх болно. Нэмж дурдахад, бид маягтыг програмаар өөрчлөх экспортын журам бүхий урт хугацааны модулиудыг бичсэн бөгөөд энэ бүгдийг хялбархан хийдэг. Удирдлагатай маягтууд гарч ирэхэд бид маягтуудыг программчлан өөрчлөх энэ туршлагыг удирддаг хэлбэрт бүрэн шилжүүлсэн. Үүнээс гадна засварлах хяналттай хэлбэрПрограмчлал нь ерөнхийдөө хялбар болсон - үүнийг ердийн хэлбэрүүдтэй харьцуулах боломжгүй юм.

Би танд жишээгээр үзүүлье. OnCreateOnServer зохицуулагч дээр би EditFormProgrammatically процедуртаа дуудлагыг нэмж, программ ёсоор маягт руу элементүүдийг нэмдэг.

BSP 2 дээр суурилсан тохиргоонд(ERP, Нягтлан бодох бүртгэл гэх мэт) нэмсэн Үйл явдал зохицуулагчForm.WhenCreatedOnServer(), энэ нь бусад зүйлсээс гадна орж ирдэгбас дарагдсан модуль руу.

Гэх мэт Та дарагдсан модульд өөрийн кодыг нэмж болно- жишээлбэл, WhenCreatingOnServer() процедурт. Энд би маягтын нэрийг тодорхойлж, үүнээс хамааран би нэг эсвэл өөр процедурыг дуудаж, элементүүдийг программчлан нэмдэг.

Энэ нь хэцүү, энэ схем нь төвөгтэй юм шиг санагдаж байна, гэхдээ бодит байдал дээр бүх төслүүд эдгээр дүрмийн дагуу хийгдсэн бол хөгжүүлэгч даалгавар хүлээн авахдаа хаанаас хайх, хаана юу нэмэхээ тэр даруй мэддэг. Тиймээс энэ нь маш тохиромжтой гэж бодож байна.

Нэмж дурдахад, BSP 2 дээр суурилсан тохиргоонуудад бусад маягт боловсруулагчид дахин тодорхойлогддог - When ReadingOnServer(), BeforeWritingOnServer() гэх мэт. Мөн эдгээр зохицуулагчид та дуудагдсан процедурын дахин тодорхойлолтыг идэвхтэй ашиглаж болно. Түүнээс гадна ханган нийлүүлэгчийн дахин тодорхойлсон модуль нь онолын хувьд өөрчлөгддөггүй бөгөөд та зөрчилдөөнөөс айхгүйгээр тэнд өөрийн кодыг бичиж болно.

Хэрэв бид төслийн нэг хэсэг болгон нэмсэн маягтыг засах юм бол бид ямар нэг онцгой зүйл хийх шаардлагагүй, бид үүнийг ердийн аргаар гараар засдаг.

9. Дүртэй ажиллах зарчим

Мөн сүүлчийн дүрэм бол дүртэй ажиллах зарчим юм.

Үүрэгтэй ажиллах зарчим нь дараах байдалтай байна.

  1. Боломжтой бол тэгвэл ердийн дүрүүдийг үргэлж нэргүй үлдээх ёстой. Ердийн дүрийг өөрчлөх шаардлагатай юу, эсвэл өөр зүйл хийх боломжтой юу гэдгийг сайтар бодох хэрэгтэй.
  2. Бид шинэ, тусгайлан үүсгэсэн дүрд нэмэлт тохиргооны объектуудад эрхийг олгодог.Тиймээс, би тохиргоонд тайлан нэмэх үед бидний өмнө нь нэмсэн тохирох үүрэг байхгүй бол би тусдаа үүрэг үүсгэдэг. Дараа нь энэ үүргийг шаардлагатай профайлуудад нэмнэ. Гэхдээ ердийн дүрүүд өөрчлөгддөггүй.
  3. БА өөрчлөлт гарсан тохиолдолдRLS, дараа нь тэдгээрийг модулиудыг засварлах дүрмийн дагуу форматлана.

Жишээлбэл, хэрэв би RLS-ийг өөрчлөх шаардлагатай бол би нээх тайлбар хийж, хуучин код дээр тайлбар хийж, дараа нь өөрийн гэсэн тайлбарыг нэмж, хаалтын тайлбарыг оруулна. Энэ нь үргэлж тодорхой байдаг: хэн, яагаад (ямар ажлын хүрээнд), би хэзээ өөрчлөгдсөн.

Тиймээс би есийг бүгдийг нь жагсаасан энгийн дүрэмөөрчлөлтийг бүртгэх.

Амьдралыг хөнгөвчлөх нэмэлт объект, арга техник

Эцэст нь би хөгжүүлэгчийн амьдралыг хөнгөвчлөх зарим объект, арга техникийг авч үзэх болно.

1. Туршилтын мэдээллийн санг өөрөө таних

Эхний арга бол тестийн мэдээллийн санг өөрөө таних явдал юм.

Гол нь:

  • ажлын бүтээмжтэй мэдээллийн сангийн хаягийг хадгалдаг тогтмол байдаг.
  • Систем эхлэхэд энэ хаягийг шалгана: ажлын үндсэн хаягтай таарч байна уу эсвэл тохирохгүй байна уу.
  • БА таарахгүй бол(суурь ажиллахгүй байна), тэгвэл Системийн толгой хэсгийг сольж байна.

Дэлгэцийн зураг нь ямар харагдахыг харуулж байна. Энэ нь ялангуяа хөгжүүлэгчид (эсвэл зөвлөхүүд) олон мэдээллийн сан нээлттэй (ажиллаж, туршилт, хөгжүүлэлт гэх мэт) байгаа бөгөөд тэд санамсаргүйгээр алдаа гаргаж, ажлын мэдээллийн сан дахь өгөгдлийг өөрчлөх боломжтой үед ялангуяа ашигтай байдаг. Хэрэв гарчиг өөрчлөгдсөн бол "автоматаар" - зүүн дээд буланд хар, ямар төрлийн мэдээллийн сан болохыг хараарай - тийм ээ, туршиж үзээрэй, та үүнийг өөрчилж болно.

Ийм байдлаар бид мэдээллийн сан дахь өгөгдлийг өөрчлөхийг илүү найдвартай болгодог.

Түүнээс гадна, Зарим ердийн ажлыг гүйцэтгэхдээ энэ тогтмолын утгыг шалгахыг ашиглах нь бас ашигтай байдаг. Тухайлбал:

  • өгөгдөл солилцох,
  • хэрэглэгчийн мэдэгдэл,
  • зарим шуудан
  • зохицуулалтын хүнд даалгавар.
  • гэх мэт.

Хөгжүүлэгч ийм ердийн даалгаврыг бүтээхдээ энэ нь ажлын суурь мөн эсэхийг шалгах ёстой. Онолын хувьд бүх тестийн өгөгдлийн сан дээр ердийн даалгавруудыг кластерийн консол дээр идэвхгүй болгох нь тодорхой байна. Гэхдээ хэн нэгнийг бүтээхэд үргэлж хүний ​​хүчин зүйл байдаг шинэ суурь, түүнд шинэ өгөгдлийг ачаалж, ямар нэг зүйлийг өөрчилсөн бөгөөд үүний үр дүнд ажлын мэдээллийн баазтай зарим нэг чухал солилцоо гарсан. Дараа нь тулаан - яагаад ийм зүйл болов? Тийм учраас бид шүүмжлэлийн өмнө ердийн ажлуудЭнэ нь ажиллаж байгаа мэдээллийн сан мөн эсэхийг бид байнга шалгадаг.

BSP 2 дээр суурилсан тохиргоонд ижил төстэй механизм байдаг: хэрэв байршил мэдээллийн баазөөрчлөгдвөл асуулт гарч ирнэ - энэ нь мэдээллийн сангийн хуулбар уу эсвэл мэдээллийн баазыг зөөсөн үү. Зарчмын хувьд энэ механизм хангалттай байж болох ч дахин хүний ​​хүчин зүйл саад болж магадгүй, хэн нэгэн нь юу болж байгааг ойлгохгүй, буруу товчлуур дээр дарна. Тийм ч учраас, Миний бодлоор тогтмол нь илүү найдвартай байдаг.

2. Эхлүүлэх боловсруулалт

Дараагийн заль мэх бол эхлүүлэх боловсруулалт юм.

  • Энэ нь кодын одоогийн хувилбарыг агуулсан тохиргоонд нэмсэн боловсруулалт юм.
  • Үүний зэрэгцээ тохиргоонд зарим тогтмолыг нэмж оруулсан бөгөөд энэ нь эхлүүлэх боловсруулалтын одоогийн хувилбарыг хадгалдаг.
  • Систем эхлэхэд шалгалт хийгдэнэ.
  • Хэрэв хувилбар өөрчлөгдсөн бол шаардлагатай зохицуулагчийг ажиллуулж, тогтмолын шинэ утгыг тохируулна.

Энэ яагаад хэрэгтэй вэ? Ихэнхдээ тохиргоонд шинэ функц нэмэх үед өгөгдлийн санд зарим үйлдлийг хийх шаардлагатай байдаг: жишээлбэл, та урьдчилан тодорхойлсон лавлах элементийг нэмсэн бөгөөд одоо та түүний дэлгэрэнгүй мэдээллийг бөглөх хэрэгтэй. Төсөл дээр маш олон мэдээллийн сан байж болох бөгөөд энэ өгөгдлийг гараар бөглөх нь мэдээжийн хэрэг муу. Илүү зөв:

  • Томруулах хувилбарэхлүүлэх боловсруулалт;
  • Өгөгдлийг программчлан бөглөх дарааллыг кодоор тайлбарлана уу;
  • Тэгээд дараа нь боловсруулах шинэ хувилбарХадгалалтаар дамжуулан автоматаар шаардлагатай бүх мэдээллийн сан руу орж, тэнд ажиллуулна шаардлагатай бүх үйлдлийг гүйцэтгэх болно.

Диаграммд энэ үйл ажиллагааны журамдараах байдлаар харуулав:

  • Системийн эхлэл
  • Тогтмол хувилбарыг боловсруулах хувилбартай харьцуулах.
  • Хэрэв таарахгүй бол, хийгдэж байнадараалсан бүх шаардлагатай зохицуулагчид,
  • Тогтмолд шинэ утгыг тохируулна.

Үүний үр дүнд хаа сайгүй, бүх мэдээллийн санд өгөгдөл шинэчлэгддэг.

3. Урьдчилан тодорхойлсон утгуудын лавлах

Дараагийн заль мэх бол урьдчилан тодорхойлсон утгуудын лавлагаа юм.

Ихэнхдээ урьдчилж тодорхойлогдоогүй кодоос одоо байгаа лавлах элементүүдэд хандах шаардлагатай байдаг. Урьдчилан тодорхойлсон элементийг үүсгэх нь илүү дээр болох нь тодорхой боловч уг элементийг урьдчилан тодорхойлох боломжгүй, гэхдээ хандах боломжтой хэвээр байх болно.

Хэрэгжүүлэх ямар хувилбарууд байна вэ?

  • Элементийг нэрээр нь харна уу. Нэр өөрчлөгдсөн нь тодорхой байна - код ажиллахаа больсон. Муу.
  • Кодоор холбоо барина уу. Бага зэрэг сайн, гэхдээ код нь бас өөрчлөгдөж магадгүй юм. Их сайн биш.
  • Дотоод танигчаар холбоо барина уу.Дараа нь энэ кодыг шилжүүлэх үед ажиллахгүй болно. Ерөнхийдөө нэг мэдээллийн сангаас өөр өгөгдлийн сан руу өөрчлөлт шилжүүлбэл энэ гурван тохиолдол бүгд ажиллахгүй. Их сайн биш.
  • Санал болгосон урьдчилан тодорхойлсон утгуудын лавлах үүсгэх.

Энэ директор нь DirectoryLink төрлийн зөвхөн нэг шинж чанарыг агуулна(бүх лавлах номын холбоос).

Хэрэв би ямар нэг элементийг даалгаврын хэсэг болгон дурдах шаардлагатай бол энэ лавлах номонд урьдчилан тодорхойлсон элементийг нэмнэ (жишээ нь, Counterparty_Agroimpulse)

Тэгээд дараа нь эхлүүлэх боловсруулах код эсвэл гараар би энэ лавлахын утгыг өөрт хэрэгтэй эсрэг талын хамт бөглөнө.

Үүний дагуу үүний дараа Би энэ эсрэг талтай урьдчилан тодорхойлсон утгуудын лавлахаар холбогдож болно. Үүний ачаар дараахь үр дүнд хүрнэ.

  • хооронд өөрчлөлт шилжүүлэх үед өөр өөр суурьбүгд минийх код нь нэмэлт өөрчлөлтгүйгээр ажилладаг.
  • Нэмж дурдахад, өнөөдөр энэ эсрэг тал нь Agroimpulse, маргааш энэ нь өөр байгууллага байх магадлалтай, гэхдээ би тохиргоонд ямар нэгэн зүйлийг өөрчлөх шаардлагагүй, би зүгээр л очиж, урьдчилан тодорхойлсон утгуудын лавлах дахь утгыг нь өөрчлөх болно.

4. Дибаг хийгчийн түр хүснэгтүүдийг харах

За, хамгийн сүүлийн арга бол дибаг хийгчийн түр хүснэгтүүдийг үзэх явдал юм.

  • Түр зуурын хүснэгт бүхий нарийн төвөгтэй асуулгад дибаг хийх үед агуулгыг үзэх чадвартай байх шаардлагатайэдгээр түр ширээ.
  • Эдгээр зорилгоор Чадах тусгай функц ашиглахтүр хүснэгтүүдийг үзэх.
  • Энэ функц тав тухтай глобал модульд байрлуулах.

  • БА нэрямар нэг байдлаар богино, жишээ нь VT()

Энэ тохиолдолд:

  • I Би таслах цэг тавьсаннадад хүсэлт байгаа газар.
  • "Илэрхийлэлийг тооцоолох" цонхонд би VT (Query) гэж бичнэ.;
  • Би "Тооцоолох" дээр дарна уу Би түр зуурын асуулгын хүснэгтийн бүтцийг олж авдагямар өгөгдөл байгааг харахын тулд.

Энэ бол маш тохиромжтой функц бөгөөд бид үүнийг байнга ашигладаг. Ялангуяа зардлыг тооцоолохдоо эсвэл ZUP гэх мэт тохиргоонд. Үнэнийг хэлэхэд бусад хүмүүс түүнгүйгээр яаж амьдардагийг би ойлгохгүй байна.

Платформын хамгийн сүүлийн хувилбар гарч ирэв суурилуулсан хэрэгсэлЭнэ нь түр зуурын хүснэгтүүдийг үзэх боломжийг олгодог, гэхдээ би үүнийг бодож байна тийм ч тохиромжтой биш. Өөрийнхөө функцийг ашиглах нь илүү дээр юм.

Дүгнэлт

Бүгдэд нь баярлалаа. Би жижиг вэбсайттай, энэ сайт дээр эдгээр бүх дүрмийг нарийвчлан тусгасан болно - орж, уншина уу, над руу имэйл эсвэл Skype дээр бичээрэй.

Энэ сэдэв надад сонирхолтой байна, би үүнийг хэлэлцэхэд бэлэн байна. Бүх зүйл танд тохирсон байх нь миний хувьд үнэхээр чухал.

Ямар ч, бүр жижиг байгууллагаөөрийн гэсэн бизнесийн үйл явцтай. Үр дүнтэй ажиллах, хүлээн авах хамгийн өндөр ашигтомоохон бизнесийн үйл явцыг автоматжуулах шаардлагатай. 1С програмууд энэ функцийг маш сайн гүйцэтгэдэг. Гэвч харамсалтай нь төгс төгөлдөр байдлын талаар хүн бүр өөрийн гэсэн санаатай байдаг шиг төгс хөтөлбөр байдаггүй. 1С програмист нь таны хөтөлбөрийг сайжруулахад тусална. Стандарт 1С-ийг өөрчилсний дараа та өөрийн санаа, хэрэгцээг бүрэн хангасан хөтөлбөрийг хүлээн авах болно.

Хувилбар 1C- 1С програмыг өөрийн аж ахуйн нэгжийн хэрэгцээнд нийцүүлэн тохируулах, шинэчлэх цогц арга хэмжээ.

Бид 1С хөтөлбөрүүдийг хэрхэн сайжруулах

Тохиромжтой үр дүнд хүрэхийн тулд үйлчлүүлэгч 1С хөтөлбөрийг дуусгахдаа яг юу хүсч байгаагаа хүлээн авбал бид дараахь ажлын схемийг санал болгож байна.

  1. үйлчлүүлэгч суулгасан тухай мэдээллийг мэдээлдэг;
  2. үйлчлүүлэгч манай мэргэжилтэнд байгууллагынхаа ажлын үндсэн зарчмуудыг танилцуулж, асуудлын мөн чанарыг илэрхийлж, яг юу сайжруулахыг хүсч байгаагаа тайлбарлах;
  3. Үйлчлүүлэгчид 1С програмистыг томилсон бөгөөд тэрээр манай компанитай ажиллах бүх хугацаанд үйлчлүүлэгчтэй хамтран ажиллах бөгөөд үйлчлүүлэгчийн бизнесийн нягтлан бодох бүртгэлийн бүх шинж чанарыг мэддэг байх болно. 1С хувийн программист нь түүний хэрэгжүүлсэн сайжруулалтын гүйцэтгэлийг бүрэн хариуцах болно;
  4. техникийн тодорхойлолтыг боловсруулсан болно. Хүлээн авсан мэдээлэлд үндэслэн манай 1С програмистууд шаардлагатай дүгнэлтийг гаргаж, 1С-д өөрчлөлт оруулах эсвэл тохируулга хийх замаар асуудлыг шийдэх хувилбаруудыг санал болгоно;
  5. 1С-ийг дуусгах цаг хугацаа, мөнгөний зардлыг тохиролцсон;
  6. үйлчлүүлэгчтэй тохиролцсон ажил хэрэгжсэн;
  7. Ажлын үр дүнг шалгаж, захиалагчид хүлээлгэн өгдөг.

1С-ийн хамгийн түгээмэл өөрчлөлтүүд

Доор бид 1С хөтөлбөрүүдийн хамгийн алдартай сайжруулалтыг жагсаав.

  • Лавлах болон дэлгэрэнгүй мэдээллийг бий болгох. Бүтээл нэмэлт газруудмашины дугаар зэрэг мэдээллийг хадгалах
  • Шинэ хэвлэх хэлбэрийг сайжруулах эсвэл хөгжүүлэх. Өөрчлөх Гадаад төрхТанай байгууллагын хүсэлтийн дагуу төлбөр тооцоо, нэхэмжлэх болон бусад хэвлэсэн баримт бичгийн хэлбэр.
  • Шинэ тайлан үүсгэх эсвэл одоо байгаа тайланг өөрчлөх. Нягтлан бодогчид, менежерүүд эсвэл компанийн захирлуудад зориулж нэмэлт тайлан гаргах эсвэл одоо байгаа тайланг засах.
  • Хандалтын эрхийг тохируулах. Өгөгдлийн сан дахь мэдээлэлд хэрэглэгчийн хандалтыг хязгаарлах буюу өргөжүүлэх.
  • Эмчилгээний хөгжил.Мэдээлэл оруулах системийг хялбарчлах процессыг бий болгох, аж ахуйн нэгжийн үйл ажиллагаанд дүн шинжилгээ хийх, автоматаар гүйцэтгэдэг функцууд, жишээлбэл, баримт бичгийн багц хэвлэх эсвэл Excel файлаас мэдээлэл татаж авах (*.xls).
  • 1С солилцоог тохируулах.Нэг 1С програмаас нөгөө рүү өгөгдөл импортлох/экспортлох.
  • 1С хэрэглэгчдэд зөвлөгөө өгөх.Хэрэгжүүлсэн сайжруулалттай ажиллахын тулд хэрэглэгчдэд тайлбар өгөх эсвэл сургах.
  • Өөрчлөгдсөн тохиргоог шинэчилж байна.Бид өөрсдийн болон гуравдагч талын 1С програмистуудын өөрчилсөн тохиргоог шинэчилдэг.

1С-ийн сайжруулалтыг бидэнд даатгасны давуу тал

Манай компанид өөрчлөлт захиалах нь ашигтай байдаг хэд хэдэн шалтгаан бий.

  • Өндөр чанартай.Манай 1С програмистууд нь өндөр мэргэшсэн мэргэжилтнүүд бөгөөд үүнийг холбогдох 1С гэрчилгээгээр баталгаажуулдаг.
  • Бага зардал.Манай компани жижиг боловч хурдацтай хөгжиж байгаа тул бид үйлчлүүлэгч ба програмист хоёрын хоорондох зуучлагчдыг устгадаг тул 1С үйлчилгээний үнийг 1000 рубльээс бага түвшинд байлгаж чадсан. нарийн мэргэжлийн ажлын цаг тутамд.
  • Ажлыг хурдан дуусгах. Таны даалгаврыг биелүүлэхийг хойшлуулах нь манай компанид ашиггүй юм. Тиймээс ажлын гурав хоногийн дотор ажлын үр дүнг хүлээн авах баталгаатай. Хэрэв даалгавар нь жижиг бол та түүнтэй холбогдох өдөр л 1С-д шаардлагатай өөрчлөлтийг авах боломжтой байх магадлалтай.
  • Өөрчлөлтийн гүйцэтгэлийн 100% баталгаа.Манай компани танай хөтөлбөрт ажилтнуудынхаа хийсэн сайжруулалтын ажиллагааг баталгаажуулдаг. Хэрэгжүүлснээс хойш нэг жилийн дотор далд доголдол илэрсэн эсэхээ бидэнд мэдэгдэх ба бид аль болох хурдан хугацаанд бүрэн үнэ төлбөргүй засварлах болно.
  • Хэдийгээр бид газарзүйн байрлалтай Санкт-Петербург, Бид танд дэлхийн хаана ч байсан ямар ч ажлыг алсаас гүйцэтгэж чадна.