การปรับแต่ง 1c องค์กร แนวคิดในการลด "การทำลาย" ของโครงร่างทั่วไป

สวัสดีทุกคนยินดีต้อนรับสู่แมว

กฎและเทคนิคในการสรุปการกำหนดค่า 1C ทั่วไปเพื่ออำนวยความสะดวกในการสนับสนุนและอัปเดตเพิ่มเติม

ดังนั้นเมื่อเราทำโครงการบางอย่าง (โดยคำว่า "เรา" ฉันหมายถึงทุกคนที่มีส่วนร่วมในกระบวนการทางธุรกิจอัตโนมัติ) เราหวังว่าจากนั้นจะได้รับการสนับสนุนอย่างราบรื่น ตามกฎแล้วหากทุกอย่างทำได้ดีและลูกค้าพอใจนี่คือสิ่งที่เกิดขึ้น

การสนับสนุนมีลักษณะเป็นชุดของงานที่เฉพาะเจาะจงมากซึ่งอาจเป็นงานสำหรับการให้คำปรึกษาจากหมวดหมู่ "ตัวเลขดังกล่าวมาจากที่ใด" หรือสำหรับการแก้ไขข้อผิดพลาดที่ไม่สามารถเข้าใจได้เป็นต้น แต่เนื่องจากโครงการเกือบทั้งหมดประกอบด้วยการปรับแก้โซลูชันทั่วไปบางอย่างให้เข้ากับความต้องการของลูกค้าการกำหนดค่าที่มีการสนับสนุนจึงต้องได้รับการอัปเดตเป็นระยะสำหรับรุ่นใหม่:

• หากคุณปฏิบัติตามกฎการพัฒนาบางอย่างการใช้ความพยายามเพียงเล็กน้อยในขั้นตอนโครงการในอนาคตคุณสามารถประหยัดค่าสนับสนุนและอัปเดตการกำหนดค่าได้
• และในทางกลับกันหากในขั้นตอนของโครงการมีข้อผิดพลาดบางอย่างรีบเร่งการออกแบบโค้ดที่ไม่ถูกต้องหลังจากนั้นอาจส่งผลให้เกิดการสนับสนุนและการอัปเดตที่แท้จริง

มีใครเคยต้องอัปเดตการกำหนดค่าที่เขียนใหม่โดยไม่มีเครื่องหมายใด ๆ คุณเห็นไหมว่าการเปรียบเทียบการกำหนดค่าผู้ให้บริการรายเก่ากับการกำหนดค่าใหม่นั้นเจ็บปวดเพียงใดแยกวิเคราะห์ "การเปลี่ยนแปลงสองครั้ง" ด้วยตนเองเมื่อเทียบกับการกำหนดค่าปัจจุบันและอื่น ๆ ทั้งหมดนี้เป็นปัญหามาก

กฎง่ายๆ 9 ข้อสำหรับการออกแบบการปรับเปลี่ยนในการกำหนดค่าทั่วไป

1. แนวคิดในการลด "การทำลาย" ของโครงร่างทั่วไป

ประการแรกไม่ใช่กฎ แต่เป็นแนวคิดบางประการในการลด "การทำลาย" ของโครงร่างทั่วไป

สาระสำคัญคือคุณควรเลือกวิธีการแก้ปัญหาเหล่านั้นซึ่งจะช่วยให้อัปเดตการกำหนดค่าได้ง่ายขึ้นในอนาคตแม้ว่าโซลูชันดังกล่าวจะใช้งานได้ยากกว่าก็ตาม เป็นที่ชัดเจนว่าสิ่งนี้ควรทำโดยปราศจากความคลั่งไคล้ภายในกรอบที่สมเหตุสมผล แต่นักพัฒนาควรจำไว้เสมอว่าการกำหนดค่ายังคงอยู่ในการสนับสนุนและวิเคราะห์ว่าโค้ดของเขาจะทำให้การอัปเดตการกำหนดค่ามีความซับซ้อนมากเพียงใดในอนาคตโดยเลือกโซลูชันที่เหมาะสมที่สุด

2. แสดงความคิดเห็นเกี่ยวกับการเปลี่ยนแปลงรหัส

กฎข้อที่สองคือ l การเปลี่ยนแปลงใด ๆ ในรหัสจะต้องแสดงความคิดเห็น.

ใน บริษัท ของเราเราใช้โครงการต่อไปนี้:

• จุดเริ่มต้นของการเปลี่ยนแปลงคือ เปิดความคิดเห็น (ขึ้นต้นด้วยสัญญาณ //++ )
• ในตอนท้าย - ปิดความคิดเห็น (ขึ้นต้นด้วยสัญญาณ //-- )
• และ การเปลี่ยนแปลงที่เกิดขึ้นโดยนักพัฒนาอยู่ระหว่างกลาง.

นี่เป็นกฎบังคับสำหรับการเปลี่ยนแปลงใด ๆ

ความคิดเห็นเปิดและปิดมีเครื่องหมายการเปลี่ยนแปลง... ประกอบด้วยสิ่งต่อไปนี้ องค์ประกอบ:

• คำนำหน้าโครงการ - โดยค่าเริ่มต้นเราใช้ FTO
• ชื่อโดเมนของผู้พัฒนา... ก่อตั้งขึ้นอย่างสะดวกมาก: บริษัท มีขนาดใหญ่กระจายและถ้าคุณไม่รู้จักนักพัฒนา แต่คุณต้องถามเขาเกี่ยวกับเขาคุณสามารถใช้ชื่อเล่นของเขาจากป้ายกำกับนี้ใส่ @ fto.com.ru ที่ถูกต้องและส่งจดหมายถึงเขาเพื่อติดต่อเขา
• ต่อไป เปลี่ยนวันที่... เมื่อมีการเปลี่ยนแปลงเกิดขึ้นในหลาย ๆ งานกลุ่มความคิดเห็นเหล่านี้สามารถซ้อนกันได้และไม่ชัดเจนเสมอไปว่าการปิดกั้นการเปิดนี้เป็นของความคิดเห็นใดดังนั้นเราจึงเน้นที่วันที่ นอกจากนี้วันที่จะแสดงทันทีเมื่อมีการแก้ไข: สามปีที่แล้วหกเดือนที่แล้วหรือเมื่อวานนี้
• แล้วมา หมายเลขงานซึ่งไฟล์ วางไว้ในความคิดเห็นเปิดเท่านั้น... ทำไมถึงมี? ดังนั้นในระหว่างการค้นหาทั่วโลกตามหมายเลขงานจะมีเพียงจุดเริ่มต้นของการเปลี่ยนแปลงรหัสเท่านั้นที่จะรวมอยู่ในการเลือกซึ่งคุณสามารถดูเพิ่มเติมได้มิฉะนั้นจะเพิ่มเป็นสองเท่า ตัวอย่างเช่นเมื่อส่งงานเพื่อตรวจสอบโค้ดการค้นหาด้วยแท็กจะสะดวกมาก

ตัวอย่างของ

นี่คือลักษณะที่ปรากฏ วางรหัส:

นี่คือลักษณะที่ปรากฏ ลบรหัส - เราไม่ได้ลบรหัสอย่างสมบูรณ์เราแสดงความคิดเห็นเกี่ยวกับรหัส ด้วยเหตุนี้คุณจึงสามารถดูสิ่งที่แสดงความคิดเห็นได้ตลอดเวลาและในกรณีนี้คุณสามารถย้อนกลับได้อย่างรวดเร็ว

นี่คือลักษณะที่ปรากฏ เปลี่ยนรหัส: ขั้นแรกรหัสผู้ขายทั้งหมดจะถูกแสดงความคิดเห็นจากนั้นรหัสของคุณจะถูกเพิ่มเข้าไป

กฎแยกใช้งานได้ เพื่อเพิ่มโพรซีเดอร์ฟังก์ชันและตัวแปรส่วนกลางให้กับโมดูล... ในกรณีนี้ ความคิดเห็นปิดถูกวางไว้ในบรรทัดเดียวกับคีย์เวิร์ด EndProcedure... ทำไมถึงทำเช่นนี้? เพื่อให้สะดวกในการถ่ายโอนการแก้ไขโดยใช้ "การเปรียบเทียบขั้นตอน"

ในภาพคุณจะเห็นว่า โดยใช้ "การเปรียบเทียบขั้นตอน" คุณสามารถเน้นขั้นตอนนี้เมื่อรวมเข้าด้วยกันและจะถูกถ่ายโอนอย่างสมบูรณ์ (พร้อมกับป้ายกำกับ) หรือในทางกลับกันคุณสามารถยกเลิกการเลือกช่องที่อยู่ด้านหน้าเพื่อไม่ให้พกพาไปได้

และหากความคิดเห็นปิดอยู่ในบรรทัดถัดไปความคิดเห็นนั้นจะถูกอ้างถึงในขั้นตอนถัดไปและจะไม่สามารถถ่ายโอนได้เช่นนั้นโดยไม่มีค่าใช้จ่ายเพิ่มเติม

3. การเพิ่มวัตถุระดับบนสุด

กฎต่อไปคือการเพิ่มออบเจ็กต์ระดับบนสุด (ไดเร็กทอรีเอกสารรีจิสเตอร์ ฯลฯ ) ในคอนฟิกูเรชัน

กฎนี้เป็นอย่างนั้น ชื่อวัตถุต้องขึ้นต้นด้วยคำนำหน้า เพื่ออะไร?

• ขั้นแรกมันจะเน้นองค์ประกอบที่เพิ่มเข้ามาในการกำหนดค่าและในโค้ดด้วยภาพ คุณจะเห็นได้ทันทีว่านี่คือวัตถุที่เพิ่มเข้ามาของเรา.
• ประการที่สอง ความเป็นเอกลักษณ์ของชื่อสามารถทำได้เนื่องจากผู้ให้บริการสามารถเพิ่มวัตถุของตนเองด้วยชื่อเดียวกัน และถ้าเราใช้คำนำหน้าชื่อของเราเองก็จะรับประกันได้ว่าชื่อของเราจะไม่ซ้ำกัน

คำพ้องความหมายของวัตถุต้องขึ้นต้นด้วยคำนำหน้าในวงเล็บ... สิ่งนี้ช่วยให้วัตถุที่เพิ่มของเราถูกเน้นในอินเทอร์เฟซ

แน่นอนว่านี่เป็นกฎที่ถกเถียงกันมากและ การสมัครจะต้องตกลงกับลูกค้า... ลูกค้าของเราพอใจกับโครงการดังกล่าวดังนั้นจึงติดอยู่กับเราและตกอยู่ในกฎ แต่ทั้งนี้ขึ้นอยู่กับคุณและลูกค้าที่จะตัดสินใจว่าจะทำเช่นนี้หรือไม่

กฎข้อสุดท้าย: ความคิดเห็นต่อออบเจ็กต์ที่เพิ่มทั้งหมดต้องมีแท็กพิเศษที่มีชื่อผู้พัฒนาและหมายเลขงาน ป้ายกำกับนี้คล้ายกับความคิดเห็นเปิดจากโมดูลโดยไม่มีอักขระพิเศษ - ด้วยความช่วยเหลือฉันสามารถเข้าใจได้เสมอว่าใครเพิ่มงานนี้เมื่อใดและเพื่ออะไร

ดังนั้นเพื่อสรุป:

• ชื่อขึ้นต้นด้วย
• คำพ้องความหมาย - นำหน้าในวงเล็บ
• และความคิดเห็นต้องมีป้ายกำกับพิเศษ

4. การเพิ่มวัตถุรอง

การเพิ่มวัตถุรองฉันหมายถึงการเพิ่มอุปกรณ์ประกอบฉากเลย์เอาต์แบบฟอร์ม ฯลฯ ลงในวัตถุการกำหนดค่า

ที่นี่เราต้องเน้นสองสถานการณ์ทันทีที่เราเพิ่มวัตถุรอง:

• ลงในวัตถุการกำหนดค่าทั่วไป
• หรือในวัตถุบางอย่างที่ถูกเพิ่มไว้ก่อนหน้านี้ภายในโครงการ

ลองพิจารณาแต่ละสถานการณ์แยกกัน

เพื่อเพิ่มอ็อบเจ็กต์รองให้กับอ็อบเจ็กต์คอนฟิกูเรชันทั่วไป ใช้กฎต่อไปนี้

• ชื่อต้องขึ้นต้นด้วยคำนำหน้าทุกประการ... ด้วยเหตุนี้เราจึงได้รับความเป็นเอกลักษณ์ของชื่อและเป็นที่ชัดเจนเสมอว่านี่คือวัตถุของเรา

• คำพ้องความหมายถูกเติมโดยไม่มีคำนำหน้าเนื่องจากไม่จำเป็นต้องเลือกวัตถุของเราอีกต่อไปข้อกำหนดของเรา

• และในที่สุดก็, ความคิดเห็นยังมีป้ายกำกับพิเศษเพื่อให้ชัดเจนว่าใครเมื่อไรและทำไม

ดังนั้นเรามาสรุปวิธีการเพิ่มวัตถุรองลงในวัตถุการกำหนดค่าทั่วไป:

• ชื่อขึ้นต้นด้วย
• คำพ้องความหมายทั่วไป
• และความคิดเห็นมีป้ายกำกับพิเศษ

และ หากเราเพิ่มวัตถุรองลงในวัตถุที่ถูกเพิ่มไว้ก่อนหน้านี้ภายในโครงการ และมีคำนำหน้าในชื่อของพวกเขาแล้ว:

• ของพวกเขา ชื่อต้องไม่มีคำนำหน้าเนื่องจากเป็นที่ชัดเจนอยู่แล้วว่าวัตถุนั้นมีเอกลักษณ์เฉพาะตัวอยู่แล้วและไม่จำเป็นต้องเน้นย้ำด้วยวิธีอื่นใด

• นอกจากนี้ยังระบุคำพ้องสำหรับวัตถุรองดังกล่าวโดยไม่มีคำนำหน้าเนื่องจากไม่จำเป็นต้องมีการเลือกพิเศษ

• และข้อคิดเห็นมีป้ายกำกับพิเศษเฉพาะเมื่อมีการเพิ่มวัตถุรองนี้เป็นส่วนหนึ่งของงานอื่น เนื่องจากหากในงานของฉันมีการเขียนว่าฉันต้องเพิ่มเอกสารที่มีรายละเอียดดังกล่าวฉันไม่จำเป็นต้องใส่เครื่องหมายดังกล่าวสำหรับแต่ละแอตทริบิวต์ แต่ถ้างานแตกต่างไปจากเดิมอย่างสิ้นเชิงฉันจะติดป้ายกำกับไว้อย่างชัดเจนเพื่อให้ชัดเจนว่าทำไมฉันถึงทำ

ตอนนี้เรามาสรุปวิธีเพิ่มวัตถุรองลงในวัตถุที่เพิ่มภายในโครงการ:

• ชื่อที่ไม่มีคำนำหน้า
• คำพ้องความหมายที่ไม่มีคำนำหน้า
• และความคิดเห็นควรมีเฉพาะป้ายกำกับพิเศษเมื่อเพิ่มเป็นส่วนหนึ่งของงานอื่น

หากรวมกฎนี้สำหรับทั้งสองกรณีและ "วางบนชั้นวาง" คุณจะได้รับตารางต่อไปนี้:

• วัตถุใหม่:
  • ชื่อขึ้นต้นด้วยคำนำหน้า
  • คำพ้องความหมายมีคำนำหน้าในวงเล็บ
  • ความคิดเห็นมีป้ายกำกับ
• วัตถุรองที่เราเพิ่มในวัตถุทั่วไป:
  • ชื่อเริ่มต้นด้วยคำนำหน้า
  • คำพ้องความหมายสำหรับกฎทั่วไป
  • เราใส่เครื่องหมายในความคิดเห็น
• และถ้าเราเพิ่มวัตถุรองลงในวัตถุที่เพิ่มภายในโครงการแล้ว
  • ไม่มีกฎพิเศษสำหรับพวกเขา
  • แต่ถ้างานแตกต่างกันเราก็ใส่เครื่องหมายในความคิดเห็นในลักษณะเดียวกัน

5. การเพิ่มองค์ประกอบที่กำหนดไว้ล่วงหน้า

กฎต่อไปคือการเพิ่มรายการที่กำหนดไว้ล่วงหน้า

สถานการณ์สองสถานการณ์สามารถแยกแยะได้ที่นี่ในลักษณะเดียวกัน:

• เมื่อเราเพิ่มองค์ประกอบที่กำหนดไว้ล่วงหน้าให้กับออบเจ็กต์คอนฟิกูเรชันทั่วไป (เพื่อการอ้างอิงไปยังแผนภูมิประเภทลักษณะเฉพาะ)
• และเมื่อเราเพิ่มรายการที่กำหนดไว้ล่วงหน้าให้กับวัตถุที่เพิ่มภายในโครงการ

หากเราเพิ่มรายการที่กำหนดไว้ล่วงหน้าให้กับวัตถุกำหนดค่าทั่วไป,

• ของเขา ชื่อ คล้ายกัน ต้องขึ้นต้นด้วยคำนำหน้า... ดังนั้นเราจึงรับประกันความเป็นเอกลักษณ์ของชื่อของเขาและสามารถระบุองค์ประกอบเพิ่มเติมของเราด้วยสายตาได้ทันที
• รหัสและชื่อจะเกิดขึ้น ตามกฎทั่วไป,
• แต่ ฉลาก ที่นี่โชคไม่ดี ไม่มีที่ไหนให้ใส่... ดังนั้นจะไม่สามารถค้นหาองค์ประกอบที่กำหนดไว้ล่วงหน้าที่เพิ่มเข้ามานี้โดยการค้นหางานส่วนกลาง

และ หากเราเพิ่มองค์ประกอบที่กำหนดไว้ล่วงหน้าให้กับวัตถุที่เพิ่มภายในโครงการแล้ว

• ของเขา ชื่อจะไม่มีคำนำหน้าเนื่องจากไม่จำเป็นต้องเน้นอย่างใด

ดังนั้นหากเราวาดการเปรียบเทียบกับตารางก่อนหน้าแล้ว:

• องค์ประกอบที่กำหนดไว้ล่วงหน้าสำหรับวัตถุทั่วไปจะถูกเพิ่มด้วยคำนำหน้า
• และส่วนที่เหลือทั้งหมด - ตามกฎทั่วไปไม่จำเป็นต้องเพิ่มคำนำหน้าพิเศษ

6. การใช้โมดูลทั่วไปและโครงสร้างที่เข้มงวด

กฎต่อไปเกี่ยวข้องกับการใช้โมดูลทั่วไปและการจัดโครงสร้างที่เข้มงวดสำหรับพวกเขา

ขั้นแรกคุณควรเพิ่มโมดูลของคุณเองสำหรับโพรซีเดอร์ฟังก์ชันตัวจัดการการสมัครสมาชิกและงานตามกำหนดเวลาที่ใช้ซ้ำ ๆ โดยปล่อยให้โมดูลมาตรฐานไม่เปลี่ยนแปลง และหากนักพัฒนาต้องการวางขั้นตอนการส่งออกบางประเภทในโมดูลทั่วไปเขาก็ไม่จำเป็นต้องทำเช่นนั้นเขาต้องสร้างโมดูลของตัวเอง

ประการที่สองโปรดทราบว่า โมดูลทั่วไปจะถูกเพิ่มตามกฎสำหรับการเพิ่มวัตถุระดับบนสุด (ชื่อและคำพ้องความหมายกับคำนำหน้าแท็กในความคิดเห็น ฯลฯ )

ประการที่สาม ชื่อโมดูลควรคล้ายกับโมดูลมาตรฐานที่เกี่ยวข้อง.

ไม่จำเป็นต้องสร้างวงล้อใหม่: เราเรียกมันว่าแบบเดียวกับที่เป็นธรรมเนียมในการกำหนดค่าทั่วไป - สำหรับแต่ละฟังก์ชันจะมีโมดูลที่สอดคล้องกับสัญกรณ์ที่ยอมรับโดยทั่วไปใน 1C ตัวอย่างเช่น:

• FTO_GeneralAppointmentClient,
• FTO_GeneralPurposeServer,
• FTO_General PurposeGlobal,
• FTO_RegularJobsServer
• ฯลฯ

และบางส่วน งานใหญ่ ๆ เป็นไปได้ (และอาจจำเป็น) ย้ายไปยังโมดูลทั่วไปที่แยกจากกัน.

7. การใช้การสมัครสมาชิกและโครงสร้างที่เข้มงวด

กฎต่อไปคือการใช้การสมัครสมาชิกและโครงสร้างที่เข้มงวด แก่นแท้ของมันคืออะไร?

การสมัครสมาชิกควรใช้เพื่อจัดการกับเหตุการณ์ต่างๆที่เกี่ยวข้องกับวัตถุทั่วไปเช่น:

• ก่อนบันทึก
• เมื่อบันทึก
• ฯลฯ

• แน่นอนคุณสามารถรับและ แก้ไขโมดูลของวัตถุทั่วไป โดยการใส่รหัสของคุณลงในขั้นตอนที่เหมาะสม แต่นี่ - วิธีที่ไม่ดี.
• มันจะดีกว่า แทนสิ่งนี้ เพิ่มการสมัครสมาชิกเพื่อจัดการกิจกรรมนี้.

เพิ่มการสมัครสมาชิกตามกฎที่ตกลงกันดังต่อไปนี้:

1. เพิ่มการสมัครสมาชิกเพียงรายการเดียวสำหรับกิจกรรมประเภทเดียวกันทั้งหมดในระบบ... ตัวอย่างเช่นหากฉันจำเป็นต้องใช้อัลกอริทึมของฉันสำหรับการอ้างอิงต่างๆในเหตุการณ์ "ก่อนบันทึกข้อมูลอ้างอิง" ดังนั้นสำหรับการอ้างอิงทั้งหมดนี้ฉันใช้การสมัครสมาชิกเพิ่มเพียงรายการเดียวเท่านั้น "ก่อนบันทึกข้อมูลอ้างอิง"
2. อ็อบเจ็กต์ทั้งหมดภายในคลาสนี้ถูกเลือกในซอร์ส(ตัวอย่างเช่นไดเรกทอรีทั้งหมด)
3. สำหรับการสมัครสมาชิกที่เพิ่มจะมีการสร้างโมดูลแยกต่างหากซึ่งมีชื่อเหมือนกันทุกประการ (เพียงเพื่อความสะดวก).
4. ในตัวจัดการเหตุการณ์หลักมีการกำหนดเงื่อนไขที่วิเคราะห์ประเภทของวัตถุ (ประเภทหนังสืออ้างอิง).
5. และแล้ว การดำเนินการบางอย่างจะดำเนินการขึ้นอยู่กับประเภทของวัตถุ.

ฉันสามารถแสดงให้คุณเห็นด้วยตัวอย่าง สมมติว่ามีงานดังกล่าว: เมื่อโพสต์เอกสาร "รายงานขั้นสูง" ให้ทำรายการในทะเบียนสะสมที่เพิ่มไว้ก่อนหน้านี้

ขั้นแรกเราเพิ่มโมดูลทั่วไป FTO_DocumentsProcessing ด้วยกฎทั้งหมด

• ระบุ DocumentObject (เอกสารทั้งหมด) เป็นแหล่งที่มา
• ในฐานะผู้ดูแล - โมดูลของเราได้เพิ่มไว้ด้านบน

และในโมดูลในตัวจัดการเองเรากำหนดว่าเอกสารประเภทใดมาถึงเราและขึ้นอยู่กับประเภทของเอกสารนั้นเราเรียกสิ่งนี้หรือขั้นตอนนั้น

การสมัครสมาชิกเป็นหนึ่งเดียว แต่การดำเนินการอาจแตกต่างกัน ทีคุณยังสามารถควบคุมลำดับการเรียกใช้โพรซีเดอร์

ด้วยเหตุนี้ขั้นตอนในการสร้างการสมัครสมาชิกจึงเป็นดังนี้:

• สมัครสมาชิกครั้งเดียว
• โมดูลทั่วไปหนึ่งโมดูล
• และไม่จำเป็นต้องใช้อะไรอีก: โมดูลเอกสารยังคงไม่เปลี่ยนแปลง - ใน "เปลี่ยนสองครั้ง" จะไม่ปรากฏอีกต่อไป

8. การแก้ไขแบบฟอร์ม

กฎต่อไปคือการแก้ไขแบบฟอร์ม

ในทำนองเดียวกันเราเน้นสองประเด็นสองสถานการณ์:

• เมื่อเราแก้ไขแบบฟอร์มตัวอย่าง
• และเมื่อเราแก้ไขแบบฟอร์มที่เพิ่มในโครงการ

สถานการณ์แรกกำลังแก้ไขe แบบฟอร์มมาตรฐาน รูปแบบของวัตถุทั่วไป... นี่คือประเด็นที่ถกเถียงกันมากที่สุดของกฎ ครั้งหนึ่งย้อนกลับไปในรูปแบบเดิม ๆ เมื่อโครงการส่วนใหญ่ทำกับ SCP เรามีการพูดคุยกันมากมายว่าจะทำอย่างไรกับแบบฟอร์ม มีตัวเลือกอะไรบ้าง?

• การแก้ไขรูปร่างปกติโดยตรง คือฉันเพิ่งเปลี่ยนรูปร่างด้วยตนเอง ด้วยตัวเลือกนี้ทุกครั้งที่ซัพพลายเออร์ทำการเปลี่ยนแปลงในแบบฟอร์มนี้ฉันจำเป็นต้องโอนการแก้ไขทั้งหมดของฉันใหม่ วิธีที่ไม่ดี.
• อีกวิธีหนึ่งคือ ทำสำเนาแบบฟอร์ม... นี่คือตอนที่ฉันทำสำเนาของแบบฟอร์มตัวอย่างกำหนดให้กับฟอร์มหลักและทำการเปลี่ยนแปลงของฉัน แต่อีกครั้งหากผู้ให้บริการเปลี่ยนแบบฟอร์มนี้ฉันจำเป็นต้องโอนการเปลี่ยนแปลงไปยังตัวแปรของฉันด้วยตนเอง ไม่ใช่วิธีที่ดีที่สุด.
• อีกทางเลือกหนึ่งคือ สร้างแท็บแยกต่างหาก... สร้างแท็บแยกต่างหากบนแบบฟอร์มและวางองค์ประกอบของเราไว้ เป็นที่ชัดเจนว่าวิธีนี้ไม่ยืดหยุ่นเพราะบางครั้งคุณจำเป็นต้องแทรกองค์ประกอบของคุณไว้ที่ใดที่หนึ่งในตำแหน่งเฉพาะบนแบบฟอร์ม หรือคุณต้องเปลี่ยนคุณสมบัติขององค์ประกอบมาตรฐานกำหนดตัวจัดการใหม่ให้กับองค์ประกอบเหล่านี้เป็นต้น เพราะฉะนั้นสิ่งนี้ ไม่ยืดหยุ่น - มันทำงานได้ไม่ดีเช่นกัน
• ผลที่ตามมา เราเลือกวิธีการแก้ไขแบบเป็นโปรแกรมโดยสมบูรณ์... นักพัฒนาใหม่ที่ไม่เคยเจอวิธีนี้ในตอนแรกพบว่าการแก้ไขแบบฟอร์มโดยใช้โปรแกรมเป็นเรื่องยากมาก แต่ในความเป็นจริง - ไม่ จากการปฏิบัติของฉันฉันจะบอกว่าคุณต้องจับมือกัน นอกจากนี้เรายังมีโมดูลที่เขียนไว้เป็นเวลานานพร้อมด้วยขั้นตอนการส่งออกสำหรับการเปลี่ยนแปลงรูปแบบทางโปรแกรมและทั้งหมดนี้ทำได้ค่อนข้างง่าย เมื่อมีการนำแบบฟอร์มที่มีการจัดการมาใช้เรายังได้ย้ายการปฏิบัตินี้โดยสมบูรณ์ของการเปลี่ยนแปลงแบบทางโปรแกรมไปยังรูปแบบที่มีการจัดการ ยิ่งไปกว่านั้นโดยทั่วไปแล้วการแก้ไขแบบฟอร์มที่มีการจัดการโดยทางโปรแกรมได้กลายเป็นเรื่องง่ายด้วย แบบฟอร์มปกติ อย่าเปรียบเทียบ.

มาดูตัวอย่างกัน ในตัวจัดการ OnCreateAtServer ฉันเพิ่มการเรียกไปยังขั้นตอนของฉัน ModifyFormProgrammatically โดยที่ฉันมี นอกจากนี้ซอฟต์แวร์ องค์ประกอบต่อแบบฟอร์ม

ในการกำหนดค่าตาม BSP 2 (เช่น ERP, การบัญชี ฯลฯ ) เพิ่ม ตัวจัดการเหตุการณ์Form OnCreateAtServer ()ซึ่งเหนือสิ่งอื่นใด เข้ามา ด้วย ลงในโมดูลที่ถูกแทนที่.

และอื่น ๆ ในโมดูลที่ถูกแทนที่คุณสามารถเพิ่มรหัสของคุณได้ - ตัวอย่างเช่นขั้นตอน OnCreateAtServer () ที่นี่ฉันกำหนดชื่อของฟอร์มและขึ้นอยู่กับว่าฉันเรียกสิ่งนี้หรือขั้นตอนนั้นซึ่งฉันเพิ่มองค์ประกอบโดยทางโปรแกรม

ดูเหมือนว่าจะเป็นเรื่องยากที่โครงการนี้จะยุ่งยาก แต่ในความเป็นจริงหากโครงการทั้งหมดทำตามกฎดังกล่าวนักพัฒนาที่ได้รับงานจะรู้ทันทีว่าต้องดูที่ไหนจะเพิ่มอะไร ดังนั้นดูเหมือนว่าฉันจะสะดวกมาก

นอกจากนี้ในการกำหนดค่าตาม BSP 2 ตัวจัดการรูปแบบอื่น ๆ ยังได้รับการกำหนดใหม่เช่น ReadOnServer (), BeforeWriteOnServer () เป็นต้น และในตัวจัดการเหล่านี้คุณยังสามารถใช้การลบล้างโพรซีเดอร์ที่เรียกว่า ยิ่งไปกว่านั้นโมดูลที่ถูกแทนที่ของผู้ขายจะไม่เปลี่ยนแปลงในทางทฤษฎีและคุณสามารถเขียนโค้ดของคุณที่นั่นได้โดยไม่ต้องกลัวว่าจะเกิดความขัดแย้ง

หากเราแก้ไขแบบฟอร์มที่เพิ่มเข้าไปในโปรเจ็กต์เราก็ไม่จำเป็นต้องทำอะไรเป็นพิเศษเราแก้ไขด้วยวิธีปกติด้วยตนเอง

9. หลักการทำงานตามบทบาท

และกฎสุดท้ายคือหลักการทำงานกับบทบาท

หลักการทำงานกับบทบาทมีดังนี้:

1. ถ้าเป็นไปได้ บทบาททั่วไปควรถูกปล่อยให้ไม่มีชื่อ... คุณต้องคิดอย่างรอบคอบว่าจำเป็นจริง ๆ หรือไม่ที่จะต้องเปลี่ยนบทบาทโดยทั่วไปหรือว่าคุณสามารถทำอะไรที่แตกต่างออกไปได้
2. เรากำหนดสิทธิ์ให้กับออบเจ็กต์การกำหนดค่าที่เพิ่มเข้ามาในบทบาทใหม่ที่สร้างขึ้นเป็นพิเศษ ดังนั้นเมื่อฉันเพิ่มรายงานในการกำหนดค่าและไม่มีบทบาทที่เหมาะสมที่เราได้เพิ่มไว้ก่อนหน้านี้ฉันจึงสร้างบทบาทแยกต่างหาก จากนั้นบทบาทนี้จะถูกเพิ่มลงในโปรไฟล์ที่ต้องการ และบทบาททั่วไปจะไม่เปลี่ยนแปลง
3. และ หากมีการเปลี่ยนแปลงในRLS จากนั้นจะถูกร่างขึ้นตามกฎสำหรับการแก้ไขโมดูล.

ตัวอย่างเช่นถ้าฉันต้องการเปลี่ยน RLS ฉันก็ใส่ความคิดเห็นเปิดแสดงความคิดเห็นเกี่ยวกับรหัสเก่าจากนั้นเพิ่มของฉันเองและใส่ความคิดเห็นปิด เป็นที่ชัดเจนเสมอ: ใครทำไม (ภายในงานอะไร) และเมื่อฉันเปลี่ยน

ดังนั้นฉันได้ระบุกฎง่ายๆทั้งเก้าข้อสำหรับการปรับเปลี่ยน

วัตถุและเทคนิคเพิ่มเติมเพื่อให้ชีวิตง่ายขึ้น

โดยสรุปฉันจะพูดถึงวัตถุและเทคนิคบางอย่างที่สามารถทำให้ชีวิตง่ายขึ้นสำหรับนักพัฒนา

1. การระบุฐานการทดสอบด้วยตนเอง

เทคนิคแรกคือการระบุฐานทดสอบด้วยตนเอง

บรรทัดล่างคือ:

• มีค่าคงที่บางอย่างที่เก็บที่อยู่ของฐานการผลิตที่ใช้งานได้.
• เมื่อระบบเริ่มทำงานระบบจะตรวจสอบที่อยู่นี้: ไม่ว่าจะตรงกับที่อยู่ฐานการทำงานหรือไม่ตรงกัน
• และ หากไม่ตรงกัน (ฐานไม่ทำงาน) จากนั้น ส่วนหัวของระบบถูกแทนที่.

ภาพหน้าจอแสดงให้เห็นว่ามีลักษณะอย่างไร สิ่งนี้มีประโยชน์อย่างยิ่งเมื่อนักพัฒนา (หรือที่ปรึกษา) เปิดฐานข้อมูลจำนวนมาก (ทำงานทดสอบพัฒนา ฯลฯ ) และสามารถทำผิดพลาดโดยไม่ได้ตั้งใจและเปลี่ยนแปลงข้อมูลในฐานข้อมูลที่ใช้งานได้ และถ้าหัวเรื่องเปลี่ยน "บนเครื่อง" - ตาที่มุมซ้ายบนคุณจะเห็นว่ามันเป็นฐานแบบไหน - ใช่ทดสอบคุณสามารถเปลี่ยนได้

ดังนั้นเราจึงทำให้การเปลี่ยนแปลงข้อมูลในฐานข้อมูลมีความปลอดภัยมากขึ้น

นอกจากนี้ การตรวจสอบค่าของค่าคงที่นี้ยังมีประโยชน์เมื่อทำงานประจำบางอย่าง... ได้แก่ :

• การแลกเปลี่ยนข้อมูล
• การแจ้งเตือนของผู้ใช้
• จดหมายบางฉบับ
• งานประจำหนัก
• ฯลฯ

เมื่อนักพัฒนาสร้างงานตามกำหนดเวลาดังกล่าวเขาต้องตรวจสอบว่าเป็นฐานการทำงานหรือไม่ เป็นที่ชัดเจนว่าตามทฤษฎีแล้วงานที่กำหนดเวลาไว้บนฐานทดสอบทั้งหมดควรถูกปิดใช้งานในคอนโซลคลัสเตอร์ แต่มีปัจจัยมนุษย์เสมอเมื่อมีคนสร้างฐานข้อมูลใหม่โหลดข้อมูลใหม่ลงในนั้นเปลี่ยนแปลงบางอย่างและด้วยเหตุนี้จึงมีการแลกเปลี่ยนที่สำคัญบางอย่างกับฐานข้อมูลที่ใช้งานได้ แล้วการประลอง - ทำไมมันถึงเกิดขึ้น? นั่นเป็นเหตุผลที่เรา ก่อนงานประจำที่สำคัญเราตรวจสอบเสมอว่าเป็นฐานการทำงานหรือไม่.

การกำหนดค่าตาม BSP 2 มีกลไกที่คล้ายกัน: หากตำแหน่งของ infobase เปลี่ยนแปลงคำถามจะถูกถาม - เป็นสำเนาของฐานข้อมูลหรือฐานข้อมูลถูกย้าย ตามหลักการกลไกนี้อาจเพียงพอ แต่อีกครั้งปัจจัยมนุษย์อาจเข้ามาแทรกแซงใครบางคนจะไม่เข้าใจสิ่งที่เกิดขึ้นและจะกดปุ่มผิด ดังนั้น, ในความคิดของฉันค่าคงที่มีความน่าเชื่อถือมากกว่า.

2. การจัดการการเริ่มต้น

เคล็ดลับต่อไปคือการจัดการการเริ่มต้น

• นี่คือการประมวลผลส่วนเสริมการกำหนดค่าที่มีเวอร์ชันปัจจุบันอยู่ในโค้ด
• ในขณะเดียวกันค่าคงที่บางส่วนจะถูกเพิ่มเข้าไปในคอนฟิกูเรชันซึ่งเก็บการประมวลผลการเริ่มต้นเวอร์ชันปัจจุบัน
• เมื่อเริ่มต้นระบบจะทำการตรวจสอบ
• และหากเวอร์ชันมีการเปลี่ยนแปลงตัวจัดการที่จำเป็นจะถูกดำเนินการและตั้งค่าคงที่ใหม่

เหตุใดจึงจำเป็น บ่อยครั้งเมื่อเพิ่มฟังก์ชันใหม่ในการกำหนดค่าจำเป็นต้องดำเนินการบางอย่างในฐานข้อมูลเองตัวอย่างเช่นเราได้เพิ่มองค์ประกอบแค็ตตาล็อกที่กำหนดไว้ล่วงหน้าและตอนนี้เราจำเป็นต้องกรอกรายละเอียด อาจมีฐานมากมายในโครงการและการกรอกข้อมูลนี้ด้วยตนเองนั้นไม่ดีแน่นอน ถูกต้องมากขึ้น:

• ขยายรุ่น การประมวลผลการเริ่มต้น
• อธิบายวิธีกรอกข้อมูลด้วยโปรแกรมในโค้ด;
• และหลังจากนั้น เวอร์ชันใหม่ การประมวลผล โดยอัตโนมัติผ่านที่จัดเก็บข้อมูลจะเข้าสู่ฐานข้อมูลที่จำเป็นทั้งหมดเริ่มต้นที่นั่นและ จะดำเนินการที่จำเป็นทั้งหมด.

ในแผนภาพนี้ ขั้นตอนการปฏิบัติงาน แสดงดังนี้:

• เริ่มต้นระบบ
• การเปรียบเทียบเวอร์ชันคงที่กับเวอร์ชันการประมวลผล.
• หากไม่ตรงกัน, จะดำเนินการ จำเป็นทั้งหมดอย่างสม่ำเสมอ ตัวจัดการ,
• มีการตั้งค่าใหม่ของค่าคงที่.

ด้วยเหตุนี้ข้อมูลจึงได้รับการอัปเดตทุกที่ในฐานข้อมูลทั้งหมด

3. ไดเร็กทอรีของค่าที่กำหนดไว้ล่วงหน้า

เคล็ดลับต่อไปคือไดเร็กทอรีของค่าที่กำหนดไว้ล่วงหน้า

มักจำเป็นต้องอ้างอิงจากโค้ดไปยังองค์ประกอบแค็ตตาล็อกที่มีอยู่ซึ่งไม่ได้กำหนดไว้ล่วงหน้า เป็นที่ชัดเจนว่าการสร้างองค์ประกอบที่กำหนดไว้ล่วงหน้าจะดีกว่า แต่เกิดขึ้นจนไม่สามารถกำหนดองค์ประกอบไว้ล่วงหน้าได้ แต่จะยังคงได้รับการแก้ไข

ตัวเลือกการใช้งานคืออะไร?

• อ้างถึงรายการตามชื่อ... เป็นที่ชัดเจนว่ามีการเปลี่ยนชื่อ - รหัสหยุดทำงาน ไม่ดี.
• อ้างอิงตามรหัส... ดีขึ้นเล็กน้อย แต่รหัสสามารถเปลี่ยนแปลงได้เช่นกัน ไม่ดีมาก.
• ติดต่อตามตัวระบุภายใน จากนั้นเมื่อทำการย้ายรหัสนี้จะใช้ไม่ได้เช่นกัน โดยทั่วไปทั้งสามกรณีนี้จะใช้ไม่ได้หากเราโอนการดัดแปลงจากฐานหนึ่งไปยังอีกฐานหนึ่ง ไม่ดีมาก.
• เสนอ สร้างไดเร็กทอรีของค่าที่กำหนดไว้ล่วงหน้า.

ไดเร็กทอรีนี้มีแอตทริบิวต์เดียวที่มีประเภท Directory (ลิงก์ไปยังหนังสืออ้างอิงทั้งหมด)

หากภายในกรอบของงานฉันต้องการอ้างถึงองค์ประกอบบางอย่างฉันเพิ่มองค์ประกอบที่กำหนดไว้ล่วงหน้าในการอ้างอิงนี้ (ตัวอย่างเช่น Contractor_Agroimpulse)

จากนั้นในรหัสประมวลผลการเริ่มต้นหรือด้วยตนเองฉันกรอกค่าของไดเร็กทอรีนี้ด้วยคู่ค้าที่ฉันต้องการ

ดังนั้นหลังจากนั้น ฉันจะสามารถอ้างถึงคู่สัญญานี้ผ่านไดเร็กทอรีค่าที่กำหนดไว้ล่วงหน้า... ด้วยเหตุนี้จึงทำได้:

• เมื่อถ่ายโอนการแก้ไขระหว่างฐานต่างๆ my รหัสทำงานได้โดยไม่ต้องทำงานเพิ่มเติม.
• นอกจากนี้ยังเป็นไปได้ว่าวันนี้คู่สัญญารายนี้คือ Agroimpulse และพรุ่งนี้ก็เป็นองค์กรอื่น แต่ฉันไม่จำเป็นต้องแก้ไขอะไรในการกำหนดค่าฉันแค่รับและเปลี่ยนค่าในไดเร็กทอรีของค่าที่กำหนดไว้ล่วงหน้า

4. การดูตารางชั่วคราวในดีบักเกอร์

เคล็ดลับสุดท้ายคือการดูตารางชั่วคราวในดีบักเกอร์

• เมื่อดีบักคิวรีที่ซับซ้อนด้วยตารางชั่วคราว ต้องสามารถดูเนื้อหาได้เหล่านี้ ตารางชั่วคราว.
• เพื่อวัตถุประสงค์เหล่านี้ สามารถ ใช้ฟังก์ชันพิเศษ เพื่อดูตารางชั่วคราว
• ฟังก์ชันนี้ สะดวก วางในโมดูลส่วนกลาง.

• และ ชื่อ อย่างใด สั้น ๆ เช่น BT ()

ในกรณีนี้:

• ผม วางเบรกพอยต์ ณ สถานที่ที่ฉันมีคำขอ
• ในหน้าต่าง "คำนวณนิพจน์" ฉันเขียน VT (คำขอ);
• ฉันคลิก "คำนวณ" และ รับโครงสร้างของตารางแบบสอบถามชั่วคราวเพื่อดูว่ามีข้อมูลใดบ้าง

นี่เป็นคุณสมบัติที่มีประโยชน์มากและเราใช้มันตลอดเวลา โดยเฉพาะอย่างยิ่งเมื่อคำนวณต้นทุนหรือในการกำหนดค่าเช่น ZUP ฉันไม่เข้าใจว่าคนอื่นอยู่ได้อย่างไรโดยไม่มีเธอ

เวอร์ชันล่าสุดของแพลตฟอร์มมี เครื่องมือในตัวซึ่งช่วยให้คุณดูตารางชั่วคราวได้ แต่สำหรับฉันแล้ว ไม่สบายมาก. การใช้ฟังก์ชันของคุณจะดีกว่ามาก.

สรุป

ขอบคุณทุกคน. ฉันมีไซต์เล็ก ๆ ในไซต์นี้กฎเหล่านี้ทั้งหมดถูกวางไว้อย่างละเอียดและไม่เพียง แต่เข้ามาอ่านเขียนถึงฉันทางไปรษณีย์หรือสไกป์

หัวข้อนี้น่าสนใจสำหรับฉันฉันพร้อมที่จะสื่อสารกับมัน มันสำคัญมากสำหรับฉันที่คุณจะประสบความสำเร็จเช่นกัน

ฝากชื่อและเบอร์โทรไว้เจ้าหน้าที่จะติดต่อกลับที่ เวลางาน ภายใน 2 ชั่วโมง

มอสโกเซนต์ปีเตอร์สเบิร์กซามารา

จัดเตรียมชุดเครื่องมือที่มีประสิทธิภาพและหลากหลายสำหรับ บริษัท และธุรกิจต่างๆ อย่างไรก็ตามเป็นที่น่าสังเกตว่าความเป็นสากลมีข้อเสีย: โปรแกรมทำหน้าที่ทั่วไปเท่านั้น สำหรับความต้องการของแต่ละ บริษัท นั้นค่อนข้างง่าย - การปรับปรุง 1C จะช่วยในเรื่องนี้

ประโยชน์ของการทำงานกับเรา

• บริการทั้งหมดสำหรับการแก้ไข 1C 8.2 ดำเนินการตามเทคโนโลยีที่ได้รับการยอมรับและได้รับการรับรองตามระบบบริหารคุณภาพสากล ISO 9001: 2001
• เรารับประกัน เงื่อนไขขั้นต่ำ ประสิทธิภาพของงานขึ้นอยู่กับความร่วมมืออย่างแข็งขันของลูกค้ากับผู้เชี่ยวชาญของ บริษัท ของเรา
• เราได้จัดตั้ง ราคาขั้นต่ำเพื่อให้ทั้งผู้เริ่มต้นและ บริษัท ขนาดใหญ่ สามารถทำการปรับปรุงที่จำเป็นสำหรับ 1C
• เรา เราควบคุมคุณภาพ ประสิทธิภาพการทำงาน พนักงานแต่ละคนจะได้รับมอบหมายให้เป็นผู้เชี่ยวชาญ 1C ที่ควบคุมงาน
• เรา เราให้การค้ำประกัน สำหรับงานที่ทำ หากภายในสองเดือนลูกค้าพบข้อผิดพลาดและความผิดปกติในการทำงานของโปรแกรม 1C เราจะแก้ไขโดยไม่เสียค่าใช้จ่ายใด ๆ

การปรับปรุง 1C คืออะไร?

การปรับแต่ง 1C เป็นการ "ปรับแต่ง" โปรแกรม 1C ที่คุณใช้บ่อยที่สุดในงานของคุณ

โดยพื้นฐานแล้วมีการปรับเปลี่ยนหลายอย่างที่ครอบคลุมองค์กร บริษัท และองค์กรที่เป็นตัวแทนในตลาดต่างประเทศมากที่สุด แต่คุณไม่สามารถทำให้ทุกคนพอใจได้เพราะทุก บริษัท มีเอกลักษณ์เฉพาะตัว นี่คือการปรับปรุง "ในท้องถิ่น" ที่เกิดขึ้นโดยผู้เชี่ยวชาญของ 1C: Franchisee Victoria

คุณควรอัปเดต 1C เมื่อใด

ก่อนที่จะทำการปรับปรุง 1C คุณต้องตอบคำถามสองสามข้อด้วยตัวคุณเอง:

• ความจำเพาะขององค์กรถูกนำไปใช้ในฟังก์ชันการทำงานทั่วไปหรือไม่? ประสบการณ์ของเราทำให้เราสามารถระบุได้ว่าการตัดสินใจแก้ไขส่วนใหญ่ดำเนินไปอย่างเร่งรีบ เป็นผลให้ บริษัท ต่างๆลงทุนเงินจำนวนมากในการปรับปรุงและแก้ไข แต่ไม่ได้รับผลที่คาดหวัง แต่พวกเขาต้องปรึกษาผู้เชี่ยวชาญ
• กระบวนการที่พยายามทำให้องค์กรเป็นแบบอัตโนมัติมีความสำคัญจริง ๆ กับรูปแบบที่พวกเขาพัฒนาใน บริษัท หรือไม่? เมื่อพัฒนาการกำหนดค่าสำหรับ 1C ผู้เชี่ยวชาญของ 1C: Franchisee Victoria ใช้วิธีการบัญชีที่ผ่านการทดสอบตามเวลาและประสบการณ์ของหลาย บริษัท เทคนิคดังกล่าวมีประสิทธิภาพสูงสุดดังนั้นจึงเป็นการดีกว่าที่จะไว้วางใจประสบการณ์ของเราและปรับโครงสร้างกระบวนการทางธุรกิจบางส่วนใน บริษัท เล็กน้อย

ผู้เชี่ยวชาญแนะนำให้ทำการปรับปรุงโดยมีเงื่อนไขว่าความเป็นไปได้ทั้งหมดของฟังก์ชันในตัวได้หมดลงแล้ว เราต้องการทราบว่าฟังก์ชันการทำงานทั่วไปของโปรแกรม 1C นั้นค่อนข้างกว้างและหากกำหนดค่าอย่างเหมาะสมก็จะสามารถใช้เพื่อแก้ปัญหางานมาตรฐานส่วนใหญ่ได้

หากไม่สามารถทำได้หากไม่มีการแก้ไขผู้เชี่ยวชาญจะวิเคราะห์ว่าการเปลี่ยนแปลงที่นำมาใช้จะส่งผลกระทบต่อส่วนการบัญชีอื่น ๆ หรือไม่

เป้าหมายของเราคือทำการปรับปรุงโดยมีการเปลี่ยนแปลงการกำหนดค่าเพียงเล็กน้อยเพื่อให้การบำรุงรักษาซอฟต์แวร์ต่อไปไม่กลายเป็น "หลุมดำ" และสร้างความปวดหัวให้กับ บริษัท

ใน บริษัท ของเราการปรับปรุงการกำหนดค่า 1C จะดำเนินการตามข้อกำหนดของระบบคุณภาพสากล ISO 9001: 2001

1C มีการกลั่นอย่างไร?

ข้อได้เปรียบทางการแข่งขันที่สำคัญของผลิตภัณฑ์ซอฟต์แวร์ 1C 8.2 และ 8.3 คือความสามารถในการปรับเปลี่ยนการกำหนดค่าโปรแกรมมาตรฐานและพัฒนาโซลูชันที่เหมาะสมที่สุดสำหรับความต้องการของผู้ใช้บนพื้นฐานของแพลตฟอร์ม 1C
ฟังก์ชันการทำงานที่กว้างใช้ภาษาโปรแกรมของตัวเองเช่นเดียวกับสภาพแวดล้อมการพัฒนาในตัวที่ให้ความยืดหยุ่นในการตั้งค่า

บริษัท 1C เพื่อผลประโยชน์ของผู้ใช้ ซอฟต์แวร์ สร้างโซลูชันสำเร็จรูปที่สามารถตอบสนองความต้องการของแต่ละองค์กรได้อย่างเท่าเทียมกันโดยคำนึงถึงความเป็นเอกลักษณ์และลักษณะเฉพาะขององค์กรใด ๆ ส่วนเสริมที่มีให้เลือกมากมายสำหรับการกำหนดค่าพื้นฐานทำให้การทำงานใน 1C สะดวกสบายที่สุด

คุณมีคำถามต้องการความช่วยเหลือจากที่ปรึกษาหรือไม่?

การปรับปรุง 1C บ่อยที่สุดคืออะไร?

ประเภทของการทำซ้ำที่พบบ่อยที่สุดคือการปรับเปลี่ยนอินเทอร์เฟซผู้ใช้ การเปลี่ยนแปลงในระดับลึกที่เกี่ยวข้องกับการสร้างและการนำอัลกอริทึมพิเศษไปใช้ในระบบนั้นพบได้น้อยกว่า แต่ก็สามารถนำไปใช้งานได้เช่นกัน

ตัวอย่างการปรับเปลี่ยน 1C

1. การกำหนดค่าการเข้าถึงและสิทธิ์ของผู้ใช้ที่ยืดหยุ่นอาจเป็นสิ่งที่เกี่ยวข้องมากที่สุดสำหรับระบบผู้ใช้หลายคน นอกจากนี้ใน 1C ยังสามารถกำหนดค่าเริ่มต้นซึ่งช่วยเพิ่มความเร็วในกระบวนการทำงานได้อย่างมาก
2. การพัฒนาและแก้ไขต่างๆ แบบพิมพ์ใน 1C ซึ่งคล้ายคลึงกับเอกสารกระดาษเช่นเดียวกับรายงานซึ่งเป็นผลิตภัณฑ์สุดท้ายของการวิเคราะห์ข้อมูลที่ป้อนในโปรแกรม 1C การปรับเปลี่ยนเหล่านี้ไม่จำเป็นต้องมีการแทรกแซงอย่างจริงจังในการกำหนดค่าโปรแกรม
3. การพัฒนาและดำเนินการตามข้อกำหนดทางเทคนิคที่ชัดเจนและเข้าใจได้สำหรับโปรแกรมเมอร์ 1C อำนวยความสะดวกในการปรับเปลี่ยนเพิ่มเติมและอนุญาตให้มีส่วนร่วมกับผู้รับเหมาบุคคลที่สามในการนำไปใช้งานได้สำเร็จ
4. ระบบ 1C ค่อนข้างเป็นสากลและในเวอร์ชันเริ่มต้นไม่ตรงตามความต้องการทั้งหมดของผู้ใช้ดังนั้นจึงมักต้องมีการพัฒนาและใช้ฟังก์ชันการทำงานที่เป็นเอกลักษณ์ตามความต้องการของลูกค้า
5. การปรับแต่งประสิทธิภาพและประสิทธิภาพเพื่อให้แน่ใจว่ามีประสิทธิภาพสูงสุดในการดำเนินการชำระบัญชี

ค่าบริการผู้เชี่ยวชาญสำหรับการทำงานกับ 1C

เกือบทุกโครงการใน บริษัท ผู้ประกอบ 1C ขนาดใหญ่เกือบทุกแห่งประกอบด้วยการสรุปการกำหนดค่าทั่วไปและส่วนใหญ่มุ่งเป้าไปที่การเพิ่มประสิทธิภาพการบัญชี กิจกรรมทางเศรษฐกิจ การจัดระเบียบและการส่งรายงานที่มีการควบคุมที่เกี่ยวข้อง และในทางกลับกันนั่นหมายความว่าในอนาคตแนวทางแก้ไขที่นำมาใช้จะต้องได้รับการปรับปรุงให้สอดคล้องกับกฎหมายที่เปลี่ยนแปลงบ่อย ในทางปฏิบัติสิ่งนี้มักหมายถึงการอัปเดตรุ่นของการกำหนดค่าทั่วไปตามการตัดสินใจและการปรับเปลี่ยนการปรับเปลี่ยนที่ทำไว้แล้วให้สอดคล้องกับการเปลี่ยนแปลงในรุ่นถัดไป

บ่อยครั้งที่โครงการไม่สามารถเรียกได้ว่าประสบความสำเร็จอย่างสมบูรณ์หากลูกค้าไม่ได้อยู่ในองค์กรผู้รวมระบบเพื่อรับการสนับสนุน และหากคุณปฏิบัติตามกฎที่เข้มงวดในการเปลี่ยนการกำหนดค่าโดยทั่วไปให้ใช้จ่าย เวลาน้อยมาก ในขั้นตอนการพัฒนาคุณสามารถทำได้ ประหยัดเวลาหลายชั่วโมงและความกังวลในอนาคต ในการอัปเดตการกำหนดค่าที่เปลี่ยนแปลงอย่างต่อเนื่อง ในทางกลับกันทัศนคติที่หยาบคาย "ปีศาจอาจดูแล" ต่อการออกแบบโค้ดการเลือกใช้งานที่เร็วและง่ายกว่า แต่ไม่ใช่วิธีที่ถูกต้องในการนำงานไปใช้สามารถเปลี่ยนการอัปเดตการกำหนดค่าผลลัพธ์ให้กลายเป็นนรกที่แท้จริงสำหรับการสนับสนุน ในอนาคตสิ่งนี้จะส่งผลให้มีชั่วโมงการอัปเดตจำนวนมากภาระงานที่เพิ่มขึ้นอย่างรวดเร็วของนักพัฒนาในช่วงระยะเวลารายงานข้อผิดพลาดจำนวนมากหลังการอัปเดตความไม่พอใจของลูกค้า ฯลฯ

ด้านล่างนี้คือชุดกฎการพัฒนาในการกำหนดค่าทั่วไปซึ่งจะช่วยอำนวยความสะดวกในการอัปเดตการกำหนดค่าเพิ่มเติม รหัสนี้เกิดขึ้นทีละน้อยจากประสบการณ์หลายปีของนักพัฒนาจำนวนมากของ บริษัท ที่ยอดเยี่ยมแห่งหนึ่งและในความเชื่อมั่นอย่างสุดซึ้งของฉันควรเป็นข้อบังคับสำหรับนักพัฒนาทุกคนไม่ว่าพวกเขาจะทำงานในแผนก / โครงการ / ทิศทางใดก็ตาม

1. แนวคิดในการลด "การทำลาย" ของโครงร่างทั่วไป

หากการกำหนดค่าทั่วไปที่ได้รับการแก้ไขควรได้รับการอัปเดตเมื่อมีการเผยแพร่รุ่นใหม่นักพัฒนาควร จำสิ่งนี้ไว้เสมอ และดำเนินการเพื่ออำนวยความสะดวกในการอัพเกรด คุณควรเลือกวิธีการแก้ปัญหาที่จะให้เสมอ อัปเดตการกำหนดค่าได้ง่ายขึ้น ในอนาคตแม้ว่าจะค่อนข้างยากในการนำไปใช้ แน่นอนโดยมีเงื่อนไขว่าวิธีการที่เป็นมิตรกับการอัปเดตมากขึ้นจะไม่มีข้อบกพร่องร้ายแรงในแง่ของประสิทธิภาพความเข้าใจโค้ด ฯลฯ

2. แสดงความคิดเห็นเกี่ยวกับการเปลี่ยนแปลงรหัส:

ควรแสดงความคิดเห็นการเปลี่ยนแปลงโค้ดโปรแกรมของโมดูลทั้งหมด บล็อกของบรรทัดที่ผ่านการเปลี่ยนแปลงจะต้องล้อมรอบด้วยบรรทัดความคิดเห็นของรูปแบบพิเศษ หลักการสร้างเส้นเหล่านี้แสดงโดยตัวอย่าง:

// ++ VION 07/20/2016 0001234 การปรับปรุงในช่วงเริ่มต้น // - VION 07/20/2016

• // ++ - จุดเริ่มต้นของบล็อก
• // - - ท้ายบล็อก
• VION - ชื่อ (หรือชื่อเล่น) ของผู้พัฒนา
• 0001234 - หมายเลขงานตามตัวติดตามใส่เฉพาะความคิดเห็นเปิดเพื่อให้การเปลี่ยนแปลงแต่ละครั้งในรหัสเข้าสู่ผลลัพธ์ของการค้นหาทั่วโลกตามหมายเลขงานเพียงครั้งเดียว
• การปรับแต่งเมื่อเริ่มต้น - ความคิดเห็นโดยพลการใช้หากจำเป็น แต่หากหมายเลขงานหายไปจำเป็นต้องมีข้อความอธิบายสั้น ๆ

ความคิดเห็นมีจุดมุ่งหมายเพื่อเน้นการปรับเปลี่ยนกับฟังก์ชันการทำงานทั่วไป หากนักพัฒนาเปลี่ยนแปลงข้อความของการแก้ไขของตนเองหลังจากผ่านไประยะหนึ่งภายในกรอบของงานเดียวกันการเปลี่ยนแปลงดังกล่าวจะไม่ได้รับการแสดงความคิดเห็นแยกกัน (และความคิดเห็นภายนอกที่มีอยู่จะไม่เปลี่ยนแปลงด้วย) หากนักพัฒนาทำการเปลี่ยนแปลงข้อความของเขา แต่สำหรับงานอื่นหรือเปลี่ยนแปลงโค้ดที่เขียนโดยนักพัฒนารายอื่นควรใช้การแสดงความคิดเห็น

การจัดกรอบความคิดเห็นจะจัดชิดด้านซ้ายของบล็อกโค้ดที่แก้ไขได้ ตัวอย่างด้านล่างสาธิตวิธีใช้การแสดงความคิดเห็นการเปลี่ยนแปลง:

2.1 การใส่รหัส

ตัวอย่าง:

ขั้นตอน OnOpening () ถ้านี่คือ New () แล้ว FillFieldsDefault (); EndIf; ConfigureFormElements (); // ++ VION 07/20/2016 0001234 ConfigureAdditionalElements (); // - VION 07/20/2016 การมองเห็น SetFields (); สิ้นสุดขั้นตอน

2.2 การลบรหัส

ตัวอย่าง:

ขั้นตอนการเปิด () // ++ VION 07/20/2016 0001234 // ถ้านี่คือใหม่ () จากนั้น // FillFieldsDefault (); // EndIf;ConfigureAdditionalElements (); // - VION 07/20/2016 การมองเห็น SetFields (); สิ้นสุดขั้นตอน

2.3 การแก้ไขรหัสที่มีอยู่

เมื่อเปลี่ยนรหัสที่มีอยู่บล็อกเก่าจะถูกแสดงความคิดเห็นก่อนจากนั้นจึงเขียนเวอร์ชันใหม่

ตัวอย่าง:

ขั้นตอน OnOpen () หากเป็นสิ่งใหม่ () แล้ว // ++ VION 07/20/2016 000123 // FillFieldsDefault ();FieldFillSettings \u003d GetFieldsFillSettings (); FillFieldsDefault ขั้นสูง (CustomizeFillFields); // - VION 07/20/2016 EndIf; ConfigureFormElements (); SetVisibilityFields (); สิ้นสุดขั้นตอน

2.4 การเพิ่มขั้นตอนและฟังก์ชันในโมดูล

สำหรับโพรซีเดอร์และฟังก์ชันที่เพิ่มขึ้นรวมถึงการประกาศตัวแปรของโมดูลอ็อบเจ็กต์มาตรฐาน กฎเพิ่มเติม แสดงความคิดเห็น:

• ไม่ใช่บล็อกของขั้นตอนเพิ่มเติมที่แสดงความคิดเห็นโดยรวม แต่เป็น ทุก เพิ่มขั้นตอนหรือฟังก์ชันใน แยกกัน.
• ความคิดเห็นเปิดอยู่บนบรรทัดก่อนส่วนหัวของขั้นตอนหรือฟังก์ชันและความคิดเห็นปิดจะไป ในบรรทัดเดียวกันโดยระบุว่า "สิ้นสุดขั้นตอน" หรือ "สิ้นสุดขั้นตอน" คั่นด้วยช่องว่าง
• การแสดงความคิดเห็นเกี่ยวกับการเปลี่ยนแปลงภายในขั้นตอนที่มีอยู่ดำเนินการตามกฎทั่วไป

ตัวอย่าง:

// ++ VION 07/20/2559 000123 Var mSettingsFillFields; ขั้นตอนแก้ไขแบบฟอร์มโดยทางโปรแกรม () ... ... EndProcedure// - VION 07/20/2559 // ++ VION 07/20/2559 000123วันที่จัดส่งขั้นตอนการประมวลผลการเลือก () ... ... EndProcedure// - VION 07/20/2016

กฎนี้ทำให้ง่ายต่อการถ่ายโอนการเปลี่ยนแปลงในโมดูลใน "การเปรียบเทียบขั้นตอน" ของการกำหนดค่า

หากคุณใส่ความคิดเห็นปิดในบรรทัดถัดไป:

จากนั้นใน "การเปรียบเทียบขั้นตอน" ความคิดเห็นนี้จะถือเป็นคำอธิบายของขั้นตอนถัดไปในข้อความซึ่งจะถือว่ามีการแก้ไข

3. การเพิ่มวัตถุระดับบนสุด

ชื่อ วัตถุระดับบนสุด สร้างขึ้นในการกำหนดค่า อย่างจำเป็น ต้องขึ้นต้นด้วยคำนำหน้า บริษัท ของคุณหรือคำนำหน้าโครงการแยกต่างหาก ตามกฎแล้วจะประกอบด้วยตัวพิมพ์ใหญ่สองหรือสามตัวและขีดล่างเป็นต้น AB_... ดังนั้นวัตถุที่สร้างขึ้นจะถูกตั้งชื่อ AB_NewReference, AB_NewDataRegister, AB_NewDocument เป็นต้น

คำพ้องความหมาย (ชื่อที่ผู้ใช้มองเห็นได้) ของอ็อบเจ็กต์ระดับบนสุดที่เพิ่มต้องขึ้นต้นด้วยคำนำหน้าที่อยู่ในวงเล็บ: (AB)... ด้วยเหตุนี้วัตถุเหล่านี้จะถูกไฮไลต์ด้วยสายตาในรายการและจัดกลุ่มไว้ที่จุดเริ่มต้น (ซึ่งทำให้ทั้งการทดสอบและการใช้งานง่ายขึ้น)

ในความคิดเห็นของออบเจ็กต์ที่กำลังสร้างคุณควรระบุชื่อผู้พัฒนาวันที่และหมายเลขงานโดยเปรียบเทียบกับโค้ดที่เพิ่มเข้ามา แต่ไม่มีเครื่องหมาย "++" เพื่อให้แน่ใจว่าอ็อบเจ็กต์คอนฟิกูเรชันถูกผูกไว้กับงานที่การค้นหาส่วนกลางกำลังมองหา

ตัวอย่าง: สร้างไดเร็กทอรี "Projects"

การดำเนินการของนักพัฒนา: การอ้างอิงต่อไปนี้ถูกสร้างขึ้นในการกำหนดค่า:

• ชื่อ: AB_Projects
• ไวพจน์: (AB) Projects

4. การเพิ่มวัตถุรอง

วิธีการเพิ่มแอ็ตทริบิวต์ของอ็อบเจ็กต์คอนฟิกูเรชันขึ้นอยู่กับอ็อบเจ็กต์คอนฟิกูเรชันที่แอ็ตทริบิวต์ถูกเพิ่มไปยังอ็อบเจ็กต์คอนฟิกูเรชันที่สร้างโดยผู้จำหน่ายโซลูชันทั่วไป (เช่นอ็อบเจ็กต์ภายใต้การสนับสนุน) หรืออ็อบเจ็กต์ที่เพิ่มภายในโปรเจ็กต์ปัจจุบัน ( คือมีคำนำหน้าอยู่แล้ว) ...

4.1 การเพิ่มอ็อบเจ็กต์รองลงในอ็อบเจ็กต์การกำหนดค่าทั่วไป

อ็อบเจ็กต์รองที่เพิ่มเข้ากับอ็อบเจ็กต์คอนฟิกูเรชันที่มีอยู่ (ทั่วไป) ต้อง คำนำหน้า: AB_AdditionalProps, AB_ TabularPart ใหม่, AB_UserSettingsForm, AB_Layout ใบแจ้งหนี้พิเศษ... แต่ในเวลาเดียวกันคำพ้องความหมายของวัตถุรองดังกล่าวจะถูกสร้างขึ้น ไม่มีคำนำหน้า.

ในความคิดเห็นของออบเจ็กต์ที่สร้างขึ้นคุณควรระบุชื่อผู้พัฒนาวันที่และหมายเลขงานโดยเปรียบเทียบกับ เพื่อให้แน่ใจว่าอ็อบเจ็กต์คอนฟิกูเรชันถูกผูกไว้กับงานที่การค้นหาส่วนกลางกำลังมองหา

ตัวอย่าง: สร้างแอตทริบิวต์ "โครงการ" ของเอกสาร "การชำระเงินล่วงหน้า"

การดำเนินการของนักพัฒนา: อุปกรณ์ประกอบฉากต่อไปนี้ถูกสร้างขึ้นในการกำหนดค่า:

• ชื่อ: AB_Project
• ไวพจน์: โครงการ
• แสดงความคิดเห็น: // VION 07/20/2559 000123

4.2 การเพิ่มวัตถุรองลงในวัตถุที่เพิ่มภายในโครงการ

เพิ่มวัตถุรองลงในวัตถุระดับบนสุดที่เพิ่มในการกำหนดค่าภายในโปรเจ็กต์นั่นคือมีการเพิ่มคำนำหน้าในชื่อ ไม่มีคำนำหน้า... นอกจากนี้ยังมีการสร้างคำพ้องสำหรับวัตถุรองดังกล่าว ไม่มีคำนำหน้า.

ในความคิดเห็นของออบเจ็กต์ที่สร้างขึ้นคุณควรระบุชื่อผู้พัฒนาวันที่และหมายเลขงานโดยเปรียบเทียบกับ เพื่อให้แน่ใจว่าอ็อบเจ็กต์คอนฟิกูเรชันถูกผูกไว้กับงานที่การค้นหาส่วนกลางกำลังมองหา ข้อคิดเห็นสามารถละเว้นได้หากข้อกำหนดถูกสร้างขึ้นภายในงานเดียวกันกับอ็อบเจ็กต์ระดับบนสุด

ตัวอย่าง: สร้างแอตทริบิวต์ "Responsible" สำหรับไดเร็กทอรี "(AB) Projects"

การดำเนินการของนักพัฒนา: หากงานแตกต่างจากงานที่สร้างไดเร็กทอรี "(AB) Projects" แอตทริบิวต์ต่อไปนี้จะถูกสร้างขึ้นในการกำหนดค่า:

• ชื่อ: ผู้รับผิดชอบ
• ไวพจน์: มีความรับผิดชอบ
• แสดงความคิดเห็น: // VION 07/20/2559 000456

5. การเพิ่มองค์ประกอบที่กำหนดไว้ล่วงหน้า

เมื่อเพิ่มองค์ประกอบแค็ตตาล็อกที่กำหนดไว้ล่วงหน้าแผนภูมิประเภทลักษณะเฉพาะและแผนภูมิของบัญชีคุณควรใช้กฎเดียวกันกับเมื่อเพิ่มวัตถุรอง (ส่วนตารางแอตทริบิวต์) ให้กับวัตถุระดับบนสุด

5.1 การเพิ่มองค์ประกอบที่กำหนดไว้ล่วงหน้าให้กับวัตถุการกำหนดค่าทั่วไป

จำเป็นต้องเพิ่มองค์ประกอบที่กำหนดไว้ล่วงหน้าสำหรับออบเจ็กต์คอนฟิกูเรชันทั่วไป ด้วยคำนำหน้า... ตั้งชื่อแล้ว ไม่มีคำนำหน้า.

ตัวอย่าง: เพิ่มบัญชีที่กำหนดไว้ล่วงหน้า 10.15 - แบบฟอร์มการรายงานที่เข้มงวดลงในผังบัญชี "สนับสนุนตนเอง"

การดำเนินการของนักพัฒนา: เพิ่มบัญชีที่กำหนดไว้ล่วงหน้าดังต่อไปนี้:

• ชื่อ: แบบฟอร์ม AB_Statement
• รหัส: 10.15
• ชื่อ: รูปแบบของการรายงานที่เข้มงวด

หากคุณต้องการเปลี่ยนชื่อองค์ประกอบที่กำหนดไว้ล่วงหน้าของออบเจ็กต์คอนฟิกูเรชันทั่วไป (ตัวอย่างเช่นบัญชี) คุณควรปล่อยให้อ็อบเจ็กต์นั้นไม่เปลี่ยนแปลงและเปลี่ยนชื่อแบบเป็นโปรแกรมในแบบพิเศษ

5.2 การเพิ่มองค์ประกอบที่กำหนดไว้ล่วงหน้าให้กับวัตถุที่เพิ่มภายในโครงการ

องค์ประกอบที่กำหนดไว้ล่วงหน้าจะถูกเพิ่มลงในออบเจ็กต์การกำหนดค่าที่เพิ่มภายในโปรเจ็กต์นั่นคือมีคำนำหน้าอยู่แล้วในชื่อของพวกเขา ไม่มีคำนำหน้า ในชื่อและชื่อเรื่อง

6. การใช้โมดูลทั่วไปและโครงสร้างที่เข้มงวด

ขั้นตอนและฟังก์ชันที่ใช้ซ้ำ ๆ ในการกำหนดค่าการสมัครสมาชิกและตัวจัดการงานตามกำหนดเวลาจะอยู่ในโมดูลทั่วไป สำหรับวัตถุประสงค์เหล่านี้ให้เพิ่ม โมดูลของตัวเองเพิ่มโดยวัตถุระดับบนสุดโดยปล่อยให้โมดูลมาตรฐาน ไม่เปลี่ยนแปลง... โมดูลทั่วไปต่อไปนี้ ("AB_" - คำนำหน้า) จะเป็นประโยชน์ในระหว่างการพัฒนา:

• AB_General (ไคลเอนต์เซิร์ฟเวอร์การเชื่อมต่อภายนอก) - เพื่อโฮสต์โพรซีเดอร์และฟังก์ชันปกติ
• AB_Server (เซิร์ฟเวอร์เท่านั้น) - สำหรับโพรซีเดอร์และฟังก์ชันที่ต้องดำเนินการในสภาพแวดล้อมเซิร์ฟเวอร์
• AB_Global - สำหรับขั้นตอนและฟังก์ชั่นซึ่งไม่สะดวกในการเรียกแบบมาตรฐาน (ผ่านชื่อโมดูลและช่วงเวลา)
• AB_Privileged - สำหรับขั้นตอนและหน้าที่ที่จะต้องดำเนินการภายใต้สิทธิเต็มรูปแบบเสมอ
• AB_Reuse - เพื่อแคชค่าที่ส่งคืนของบางฟังก์ชัน

รหัสบล็อกฟังก์ชันสามารถโอนไปยังโมดูลทั่วไปที่แยกจากกันได้ ปริมาณมากทำให้ง่ายต่อการดีบักโค้ดดังกล่าวเมื่อใช้ที่เก็บการกำหนดค่า มิฉะนั้นผู้พัฒนาควรตรวจสอบให้แน่ใจว่ามีโมดูลทั่วไปที่เหมาะสมก่อนที่จะเพิ่มโมดูลใหม่ในการกำหนดค่า

7. การใช้การสมัครสมาชิกและโครงสร้างที่เข้มงวด

ในการจัดการเหตุการณ์ต่างๆที่เกี่ยวข้องกับอ็อบเจ็กต์คอนฟิกูเรชันมาตรฐานคุณควรใช้กลไกการสมัครสมาชิกแทนการปรับเปลี่ยนโมดูลของอ็อบเจ็กต์ด้วยตนเองหากเป็นไปได้

สำหรับแต่ละเหตุการณ์อาจมี ไม่เกินหนึ่งการสมัครสมาชิก (เป็นออบเจ็กต์ข้อมูลเมตา) ซึ่งตัวจัดการและโค้ดที่เกี่ยวข้องควรอยู่ใน โมดูลทั่วไปแยกต่างหาก (เพื่อเพิ่มความเท่าเทียมกันของนักพัฒนากับที่เก็บ) ชื่อการสมัครสมาชิกและชื่อโมดูลที่แบ่งใช้ต้องเป็น เหมือนกัน และ พอดี กำลังประมวลผลเหตุการณ์ มีการระบุแหล่งที่มาของการสมัครสมาชิก ทั้งหมด วัตถุที่อาจเป็นไปได้สำหรับการประมวลผล (ไดเรกทอรีทั้งหมดเอกสารทั้งหมด ฯลฯ )

ขั้นตอนตัวจัดการการสมัครสมาชิกต้องมีการเรียกรูทีนย่อยที่ดำเนินการตามที่ต้องการ โดยขึ้นอยู่กับประเภทของแหล่งที่มาและตามลำดับที่ต้องการ การแสดงความคิดเห็นในโมดูลการสมัครสมาชิกเมื่อเพิ่มรหัสสำหรับงานใหม่จะดำเนินการ

ตัวอย่าง: เมื่อโพสต์เอกสาร "การชำระเงินล่วงหน้า" ให้กรอกข้อมูลในทะเบียนสะสม "(AB) ต้นทุนโครงการ"

การดำเนินการของนักพัฒนา:

1. สร้างการสมัคร "AB_DocumentsProcessingProcessing" (หากไม่ได้สร้างการสมัครสมาชิกไว้ก่อนหน้านี้) ระบุเอกสารทั้งหมดเป็นแหล่งที่มาเหตุการณ์ - "PostingProcessing"

2. สร้างโมดูลเซิร์ฟเวอร์ทั่วไป "AB_DocumentsProcessingProcessing"

3. ในโมดูลสร้างขั้นตอนการส่งออก "การประมวลผลการโพสต์" เลือกโพรซีเดอร์นี้เป็นตัวจัดการสำหรับการสมัครสมาชิกที่สร้างไว้ก่อนหน้านี้ ในขั้นตอนขึ้นอยู่กับประเภทของเอกสารจะมีการเรียกตัวจัดการที่จำเป็น

4. โมดูลของเอกสาร "การชำระเงินล่วงหน้า" จะต้องไม่เปลี่ยนแปลง

8. การแก้ไขแบบฟอร์ม

8.1 การแก้ไขรูปร่างของวัตถุทั่วไป

หากการเปลี่ยนแปลงในรูปแบบมาตรฐาน (ทั้งแบบปกติและแบบมีการจัดการ) มีขนาดเล็ก (ตัวอย่างเช่นเมื่อต้องการใส่รายละเอียดใหม่ ๆ ในแบบฟอร์ม) การเปลี่ยนแปลงดังกล่าวควรดำเนินการตามโปรแกรมอย่างสมบูรณ์ นั่นคือการเปลี่ยนแปลงจะเกิดขึ้นกับ โมดูลฟอร์มและฟอร์มในตัวกำหนดค่ายังคงอยู่ ไม่เปลี่ยนแปลง... สำหรับนักพัฒนาบางคนวิธีการแก้ไขแบบฟอร์มนี้อาจดูเหมือนใช้เวลานานในตอนแรก อย่างไรก็ตามการมีประสบการณ์เพียงพอในการเปลี่ยนแปลงรูปแบบทางโปรแกรมจะใช้เวลาไม่เกิน 3-5 นาทีในการเพิ่มองค์ประกอบหนึ่งรายการ เวลาที่ใช้จ่ายออกไปหลายครั้งด้วยการอัปเดตการกำหนดค่าทั่วไปในภายหลัง

ตัวอย่าง: ในรูปแบบหลักของเอกสาร "การชำระเงินล่วงหน้า" ให้เพิ่มตัวแปร "(AB) Project"

การดำเนินการของนักพัฒนา: ในตัวจัดการของแบบฟอร์ม "OnCreateAtServer" ให้เพิ่มขั้นตอน "ModifyFormProgrammatically ()" ในขั้นตอนนี้ให้เพิ่มองค์ประกอบที่ต้องการเพื่อสร้างองค์ประกอบ

เป็นไปได้ที่จะสร้างโมดูลแยกต่างหากซึ่งจะมีขั้นตอนและฟังก์ชันที่จำเป็นทั้งหมดสำหรับการเปลี่ยนรูปแบบมาตรฐาน

ในการกำหนดค่าโดยทั่วไปตาม BSP 2 มีฟังก์ชันพิเศษสำหรับวัตถุประสงค์เหล่านี้อยู่แล้ว:

ในขั้นตอน "OnCreateAtServer" ของโมดูลทั่วไป "ModifyConfigurationRedefinable" คุณสามารถเรียกตัวจัดการของคุณ

โดยที่ชื่อของฟอร์มคุณสามารถเรียกขั้นตอนที่จำเป็นด้วยการปรับเปลี่ยนแบบเป็นโปรแกรม

หากคุณวางแผนที่จะเพิ่มลงในแบบฟอร์ม องค์ประกอบจำนวนมาก หรือส่วนแบบตารางก็สามารถเปลี่ยนแบบฟอร์มได้ด้วยตนเอง ในกรณีนี้ขอแนะนำให้สร้างแท็บแยกต่างหากบนแบบฟอร์มและวางองค์ประกอบที่จำเป็นทั้งหมดไว้ ซึ่งจะทำให้ง่ายต่อการอัปเดตแบบฟอร์มเพิ่มเติม

8.2 การแก้ไขรูปร่างของวัตถุที่เพิ่มภายในโครงการ

รูปร่างของออบเจ็กต์ที่เพิ่มภายในโปรเจ็กต์ (นั่นคือสิ่งที่มีคำนำหน้าในชื่อของพวกเขา) จะได้รับการแก้ไขตามปกติ

9. หลักการทำงานตามบทบาท

บทบาททั่วไปควรไม่เปลี่ยนแปลง (ถ้าเป็นไปได้) เพื่อให้ง่ายต่อการอัปเดตการกำหนดค่าที่เปลี่ยนแปลงจากรุ่นใหม่เนื่องจากการเปรียบเทียบและกู้คืนบทบาทเป็นกระบวนการที่ซับซ้อนและต้องใช้ความพยายาม

ควรกำหนดสิทธิ์ให้กับวัตถุที่เพิ่มในการกำหนดค่า ใหม่บทบาทที่สร้างขึ้นเพื่อจุดประสงค์นี้

ควรใช้ข้อ จำกัด การเข้าถึงข้อมูลที่อนุญาตโดยบทบาททั่วไป โดยทางโปรแกรมตราบเท่าที่เป็นไปได้. และเฉพาะเมื่อข้อห้ามดังกล่าวจะเป็นเรื่องยากมากที่จะนำไปใช้โดยทางโปรแกรม (หรือวิธีแก้ปัญหาดังกล่าวจะไม่น่าเชื่อถือ) จึงอนุญาตให้แก้ไขบทบาททั่วไปได้ การเปลี่ยนแปลงบทบาททั่วไปควรมีความจำเป็นน้อยที่สุดและจัดทำเป็นเอกสาร ตัวอย่างเช่นหากคุณต้องการเปลี่ยนข้อความของการ จำกัด การเข้าถึงในบทบาท (RLS) คุณควรแสดงความคิดเห็นเกี่ยวกับโค้ดตัวอย่างทั้งหมดจากนั้นเพิ่มรหัสพร้อมกับการเปลี่ยนแปลงที่จำเป็น

10. รายงานภายนอกและการประมวลผล

การปรับปรุงส่วนใหญ่ในระบบสามารถทำได้โดยใช้รายงานเพิ่มเติมและกลไกการประมวลผล

ในการกำหนดค่าตาม BSP 2 (ERP, UT 11, BP 3.0, ZUP 3.0 ฯลฯ ) กลไกนี้ได้รับการขยายอย่างมีนัยสำคัญ ด้วยความช่วยเหลือโดยไม่ต้องเปลี่ยนการกำหนดค่าก็สามารถสร้างได้ รายงานภายนอก และการประมวลผล (ด้วยตำแหน่งของคำสั่งเรียกใช้งานในอินเทอร์เฟซคำสั่งและความสามารถในการกำหนดค่าการเข้าถึงผู้ใช้ต่างๆ) การประมวลผลการกรอกเอกสารการประมวลผลการสร้างเอกสารบนพื้นฐานแบบฟอร์มการพิมพ์เพิ่มเติม ฯลฯ

บทความนี้ช่วยคุณได้หรือไม่?

พัฒนาโดยทั้งแผนกของผู้เชี่ยวชาญที่มีคุณสมบัติสูงของ บริษัท "1C" โดยทั่วไปและการกำหนดค่าในอุตสาหกรรมที่ออกแบบมาสำหรับการบัญชีธุรกิจรวมถึงการจัดส่งบัญชีและ การรายงานภาษี... นักพัฒนาสร้างขึ้น สื่อการสอน และพวกเขาให้การสนับสนุนด้านเทคโนโลยีและการให้คำปรึกษาสำหรับโปรแกรมของพวกเขาเป็นเวลาหลายสิบปีตามบรรทัดฐานและคำแนะนำของกฎหมายของสหพันธรัฐรัสเซีย

ดูเหมือนว่าโปรแกรมมีให้สำหรับทุกอย่างแล้วไม่ว่าจะเป็นเอกสารทุกชนิดหนังสืออ้างอิงการลงทะเบียนกลไกในการทำงานกับส่วนต่อประสานผู้ใช้ที่สะดวกการกำหนดค่าการสาธิตพร้อมข้อมูลที่กรอกเป็นตัวอย่างจริงของการบัญชี

การกำหนดค่าโดยทั่วไปเขียนขึ้นสำหรับการบัญชีทั่วไปและมุ่งเน้นไปที่องค์กรโดยเฉลี่ยและเกือบจะเหมาะที่สุด

ในชีวิตจริงการบัญชีธุรกิจอาจมีสถานการณ์ที่ค่อนข้างซับซ้อนและไม่ได้มาตรฐาน นักบัญชีและผู้เชี่ยวชาญต้องการดูรายงานนี้หรือรายงานนั้นในรูปแบบที่ปรับเปลี่ยนเล็กน้อยและความสามารถปกติในการอัปโหลดข้อมูลข้อมูลจากโปรแกรมหนึ่งไปยังอีกโปรแกรมหนึ่ง (ตัวอย่างเช่นจากการบัญชีสู่การค้าหรือจากเงินเดือนไปสู่การบัญชี) ไม่ได้คำนึงถึงทั้งหมด ข้อมูลเฉพาะขององค์กร

ในกรณีเช่นนี้ผู้ที่เข้าใจโครงสร้างการกำหนดค่าความสามารถของระบบกลไกเฉพาะและรู้วิธีการนำข้อมูลนี้ไปใช้ในทางปฏิบัติอย่างมีประสิทธิภาพจะได้รับการช่วยเหลือ พวกเขาจะไม่เพียง แต่เลือกและปรับแต่งการกำหนดค่า 1C ได้อีกด้วยเพื่อขยายฟังก์ชันการทำงานมาตรฐาน

ประโยชน์ของการกำหนดค่าที่แก้ไข

เพื่อให้สามารถทำการเปลี่ยนแปลงเล็กน้อย (รูปแบบเอกสารรูปลักษณ์ของเอกสารและหนังสืออ้างอิง) ในโซลูชันแอปพลิเคชันทั่วไปที่ใช้ 1C: แพลตฟอร์ม Enterprise 7.7 จำเป็นต้องลบการกำหนดค่าออกจากการสนับสนุน สำหรับแพลตฟอร์มที่เริ่มต้นด้วย 8.0 ปัญหานี้ได้รับการแก้ไขแล้วบางส่วน: รูปแบบที่พิมพ์ภายนอกรายงานและแบบฟอร์มสามารถแก้ไขหรือสร้างขึ้นใหม่ได้โดยไม่ต้องเปลี่ยนโครงสร้างการกำหนดค่าและรูปแบบที่มีการจัดการของแพลตฟอร์ม 8.3 มีตัวเลือกมากขึ้น

โมดูลของ 1C: โซลูชันที่ใช้สำหรับองค์กรที่เปิดให้มีการเปลี่ยนแปลงช่วยให้คุณสามารถปรับเปลี่ยนและปรับแต่งโซลูชันแอปพลิเคชัน "สำหรับตัวคุณเอง" ได้ การปรับแต่งโปรแกรม 1C มีข้อดีหลายประการ:

1. ประการแรกโซลูชันซอฟต์แวร์ปรับให้เข้ากับข้อกำหนดของการบัญชีเฉพาะในองค์กร
2. ด้วยความช่วยเหลือของโครงสร้างการกำหนดค่าสิทธิ์และบทบาทของผู้ใช้ที่ได้รับการพัฒนาขึ้นใหม่ทำให้สามารถอธิบายการกระทำที่ได้รับอนุญาตและต้องห้ามได้อย่างยืดหยุ่นมากขึ้นเมื่อทำงานกับเอกสารและไดเรกทอรีของพนักงานคนใดคนหนึ่งหรือกลุ่มหนึ่ง
3. การกำหนดค่าและเปลี่ยนอินเทอร์เฟซผู้ใช้ (สำหรับแอปพลิเคชันที่มีการจัดการจะมีการใช้งานจำนวนมากเป็นประจำ)
4. ความสามารถในการเปลี่ยนรูปแบบเอกสารแบบฟอร์มและรายงานที่พิมพ์ออกมา
5. การเปลี่ยนกลไกของการคำนวณซอฟต์แวร์ภายในการตั้งค่าการคำนวณที่ซับซ้อนสูตรการผลิตเอกสารฟิลด์ที่ซับซ้อน ฯลฯ
6. การเปลี่ยนแปลง ลักษณะ เอกสารสมุดรายวันเอกสารรีจิสเตอร์ผู้ใช้รายการไดเร็กทอรี
7. ความสามารถในการเพิ่มการแสดงภาพของวัตถุ

ในการปรับเปลี่ยนโซลูชันแอปพลิเคชันคุณไม่จำเป็นต้องใช้ผลิตภัณฑ์ซอฟต์แวร์แยกใด ๆ - เครื่องมือในการพัฒนาทั้งหมดเป็นส่วนหนึ่งของแพลตฟอร์มเทคโนโลยี

ข้อเสียของการปรับแต่งการกำหนดค่า

ด้วยข้อดีที่ชัดเจนทั้งหมดการปรับแต่งของการกำหนดค่า 1C ทั่วไปทำให้เกิดผลกระทบที่ไม่พึงประสงค์:

1. โซลูชันทั่วไปถูกลบออกจากการสนับสนุนทางเทคนิค 1C สำหรับความเป็นไปได้ในการแก้ไข สูญเสียความสามารถในการอัปเดตโดยอัตโนมัติ... อย่างไรก็ตามหากทำการอัปเดตแล้วการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นกับสถาปัตยกรรมการกำหนดค่าจะสูญหายไป เฉพาะช่างผู้ชำนาญเท่านั้นที่จะสามารถอัปเดตซอฟต์แวร์และจะย้ายการปรับปรุงที่เขียนด้วยตนเองไปยังซอฟต์แวร์ที่อัปเดต
2. บ่อยครั้งที่มันเกิดขึ้นบ่อยครั้งที่กลไกการกำหนดค่าที่เขียนขึ้นเองได้รับการปรับใช้ในเวลาต่อมาโดยนักพัฒนา 1C เป็นประจำและรวมไว้เป็นส่วนหนึ่งของการอัปเดตอย่างใดอย่างหนึ่ง ดังนั้นการแก้ไขก่อนหน้านี้จึงไม่จำเป็นอีกต่อไป
3. โปรแกรมเมอร์ 1C แต่ละคนในฐานะศิลปินมีสไตล์ของตัวเอง: คนที่มีประสบการณ์เขียนได้เก่งและเป็นมืออาชีพมากกว่าบางคนมีความเป็นต้นฉบับมากกว่า อาจเป็นเรื่องยากมากที่จะเข้าใจรหัสของบุคคลอื่นหากจำเป็นจนถึงจุดที่การเขียนโมดูลตั้งแต่เริ่มต้นจะเร็วกว่าการเปลี่ยนแปลงรหัสของผู้อื่น ดังนั้นจึงมีสิ่งที่แนบมากับโปรแกรมเมอร์ที่ทำการเปลี่ยนแปลงโปรแกรม
4. ลูกค้าไม่มีคุณสมบัติเพียงพอที่จะแต่งเป็นผู้มีอำนาจเสมอไป งานด้านเทคนิค และอธิบายสิ่งที่ชัดเจน ผลลัพธ์สุดท้าย เขาอยากเห็น ดังนั้นจึงอาจมีความเข้าใจผิดระหว่างทั้งสองฝ่ายและจำเป็นต้องมีการปรับคำสั่งเพิ่มเติม

มักเกิดขึ้นว่าเป็นผู้ใช้ที่ไม่แน่ใจของ 1C: โซลูชันซอฟต์แวร์สำหรับองค์กรที่ยังไม่ได้ศึกษาการตั้งค่าวิธีการบัญชีกลไกการชำระบัญชีทั้งหมดที่ไม่เข้าใจการตั้งค่าของแบบฟอร์มและรายงานที่พิมพ์ออกมาซึ่งขอให้มีการแก้ไขการกำหนดค่า ในกรณีเช่นนี้งานของนักพัฒนาคือการระบุวิธีแก้ไขปัญหามาตรฐานที่เป็นไปได้สำหรับปัญหาที่เกิดขึ้นเพื่อสอนให้ผู้ใช้ใช้งานและทำการเปลี่ยนแปลงการกำหนดค่าเฉพาะในกรณีที่จำเป็นเร่งด่วนจริงๆ