สถานะของคู่สัญญาที่ไม่ดี 1s คืออะไร การเปลี่ยนไปใช้การรับส่งเอกสารอิเล็กทรอนิกส์แบบไร้กระดาษ: ประสบการณ์ ปัญหา แนวโน้ม

เวอร์ชัน 1.3.8 เป็นการพัฒนาเวอร์ชัน 1.3 "1C: Electronic Document Library 8" ซึ่งได้รับการออกแบบมาเพื่อให้มีการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ในโซลูชันแอปพลิเคชันที่พัฒนาบนแพลตฟอร์ม 1C:Enterprise เวอร์ชัน 8.3.10.2252 และสูงกว่า

คุณสมบัติใหม่และการเปลี่ยนแปลง

  • ในแบบฟอร์มการค้นหาข้อเสนอการค้าได้เพิ่มความสามารถในการค้นหาโดยไม่ต้องเชื่อมต่อกับ 1C: บริการเครือข่ายธุรกิจและเพิ่มความสามารถในการค้นหาซัพพลายเออร์ตามชื่อแล้ว
  • เพิ่มรายงานข้อเสนอการค้าที่เผยแพร่
  • เพิ่มสถานที่ทำงานสำหรับการเผยแพร่ข้อเสนอทางการค้าในบริการ 1C:Business Network แล้ว
  • การปรับเปลี่ยนเกิดขึ้นกับระบบย่อย "1C: Library of Standard Subsystems" เวอร์ชัน 2.4.2, "1C: Library of Internet User Support" เวอร์ชัน 2.2.2

การเปลี่ยนไปใช้เวอร์ชัน 1.3.8 จากเวอร์ชัน 1.3.7

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

การเปลี่ยนแปลงโมดูล:

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

การเปลี่ยนแปลงในโมดูล ข้อเสนอทางการค้า

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

เพิ่มบทบาทแล้ว รายงานข้อเสนอการซื้อขายที่จำเป็นในการเข้าถึงรายงาน ข้อเสนอทางการค้าที่เผยแพร่.

เวอร์ชัน 1.3.7

เวอร์ชัน 1.3.7 เป็นการพัฒนาเวอร์ชัน 1.3 "1C: Electronic Document Library 8" ซึ่งได้รับการออกแบบมาเพื่อให้มีการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ในโซลูชันแอปพลิเคชันที่พัฒนาบนแพลตฟอร์ม 1C:Enterprise เวอร์ชัน 8.3.10 และสูงกว่า

ค่าคุณสมบัติการกำหนดค่า:

  • ควรตั้งค่าโหมดความเข้ากันได้เป็น "ห้ามใช้"
  • โหมดการใช้งานแบบกิริยาสามารถตั้งค่าเป็น "ห้ามใช้"
  • โหมดความเข้ากันได้ของอินเทอร์เฟซสามารถรับค่า "เวอร์ชัน 8.2", "เวอร์ชัน 8.2 อนุญาตแท็กซี่" หรือ "แท็กซี่ อนุญาตเวอร์ชัน 8.2"

คุณสมบัติใหม่และการเปลี่ยนแปลง

  • เพิ่มความสามารถในการรับสถานะของเอกสารการชำระเงินจาก Sberbank
  • ใช้การรับการตั้งค่าอัตโนมัติสำหรับ Sberbank เมื่อเชื่อมต่อกับบริการ 1C: DirectBank
  • เพิ่มความสามารถในการแสดงโฆษณาตามบริบท 1C:DirectBank
  • มีการปรับเปลี่ยนเพื่อทำงานร่วมกับ 1C: บริการเครือข่ายธุรกิจในบริการคลาวด์ 1CFresh
  • เพิ่มความสามารถในการเผยแพร่ ค้นหา และสั่งซื้อข้อเสนอการค้าในบริการ 1C: ข้อเสนอการค้าสำหรับผู้เข้าร่วมในบริการ 1C: เครือข่ายธุรกิจ
  • การปรับตัวดำเนินการกับระบบย่อย "1C: Library of Standard Subsystems" เวอร์ชัน 2.4.1, "1C: Library of Internet User Support" เวอร์ชัน 2.1.9, "1C: Library of Service Technology" เวอร์ชัน 1.0.12

ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"

การเปลี่ยนแปลงโมดูล:

  • เอกสารวันที่, DocBaseDate

ระบบย่อย "แลกเปลี่ยนกับธนาคาร"

การเปลี่ยนแปลงในโมดูล การทำงานกับ FilesOverridable:

  • ไปจนถึงขั้นตอน เมื่อกำหนดการตั้งค่าคุณต้องเพิ่มรหัส:

ElectronicInteraction เมื่อกำหนดการตั้งค่า (การตั้งค่า);

  • ไปจนถึงขั้นตอน เมื่อกำหนดไดเร็กทอรีการจัดเก็บไฟล์คุณต้องเพิ่มรหัส:

การโต้ตอบทางอิเล็กทรอนิกส์เมื่อกำหนดไดเร็กทอรี FileStorage (FileOwnerType, DirectoryNames);

  • ไดเร็กทอรี MessageExchangeWithBanksAttachedFiles และ EDAttachedFiles ได้รับการเพิ่มลงในแผนการแลกเปลี่ยน UpdateInformationBase
  • ไดเร็กทอรี MessageExchangeWithBanksAttachedFiles และ EDAttachedFiles ได้รับการเพิ่มลงในประเภทที่กำหนดไว้ SignedObject

ลูกค้าธนาคาร) ย้ายกลุ่มองค์ประกอบออกจากรูปแบบทั่วไป

ในตัวจัดการเหตุการณ์แบบฟอร์ม เมื่อ CreateOnServer

&บนเซิร์ฟเวอร์




สิ้นสุดขั้นตอน

ในตัวจัดการเหตุการณ์แบบฟอร์ม การแจ้งเตือนการประมวลผล

&บนไคลเอนต์


// ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์ แลกเปลี่ยนกับธนาคาร

Elements.GroupAdvertisingDirectBankแนวนอน, Elements.TextDirectBankแนวนอน);
// ยุติปฏิสัมพันธ์ทางอิเล็กทรอนิกส์ แลกเปลี่ยนกับธนาคาร
สิ้นสุดขั้นตอน

สำหรับองค์ประกอบ ข้อความDirectBankแนวนอนเพิ่มตัวจัดการเหตุการณ์ กำลังประมวลผลการนำทางลิงก์

&บนไคลเอนต์


สิ้นสุดขั้นตอน

ไปยังขั้นตอนโมดูลทั่วไป ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์ คำสั่งจ่ายเงินในโซลูชันแอปพลิเคชัน

ระบบย่อย "แลกเปลี่ยนกับไซต์"

การเปลี่ยนแปลงในโมดูล การแลกเปลี่ยนไซต์เอาชนะได้:

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

การเปลี่ยนแปลงในโมดูล ExchangeSiteClientOverridable:

  • ขั้นตอนที่ถูกถอดออก กำหนดประเภทแคตตาล็อก GroupTableUประเภทค่าของคอลัมน์ Groups ของตาราง Product Catalog จะถูกกำหนดโดยการตั้งค่าการแลกเปลี่ยน
  • เพิ่มขั้นตอนแล้ว InputFieldOnChangeถูกเรียกให้ประมวลผลเหตุการณ์ เมื่อมีการเปลี่ยนแปลงฟิลด์ป้อนข้อมูลของแบบฟอร์มโหนดแผนการแลกเปลี่ยน เพิ่มในขั้นตอน SiteExchangeOverridden.AddNodeFormDetails
  • เพิ่มขั้นตอนแล้ว ช่องทำเครื่องหมายFieldOnChangeถูกเรียกให้ประมวลผลเหตุการณ์เมื่อมีการเปลี่ยนแปลงเขตข้อมูลค่าสถานะของโหนดแผนการแลกเปลี่ยนที่เพิ่มในขั้นตอน SiteExchangeOverridden.AddNodeFormDetails
  • เพิ่มขั้นตอนแล้ว แบบฟอร์มตารางก่อนเสร็จสิ้นการแก้ไขถูกเรียกให้ประมวลผลเหตุการณ์ BeforeFinishEdit ของเขตข้อมูลในส่วนตารางของรูปแบบของโหนดแผนการแลกเปลี่ยนที่เพิ่มในกระบวนงาน SiteExchangeOverridden.AddNodeFormDetails

ระบบย่อย "เครือข่ายธุรกิจ"

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

// ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์
ElectronicInteraction.OnReceivingListTemplates (เทมเพลตงาน);

  • ในขั้นตอน เมื่อกำหนด AliasesHandlers:

// ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์
ElectronicInteraction.WhenDinningHandlerAliases (MatchNamesAliases);
// สิ้นสุดการโต้ตอบทางอิเล็กทรอนิกส์

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

ระบบย่อย "ข้อเสนอการค้า"

มีการเพิ่มระบบย่อยใหม่ "ข้อเสนอการค้า" สำหรับการฝังที่คุณต้องการ:

  • พัฒนาวิธีการแทนที่ในโมดูลทั่วไป TradeOffersClientOverridable, ข้อเสนอการค้าเอาชนะได้.
  • ระบุประเภทข้อมูลตามประเภทที่กำหนด ประเภทของค่ารายละเอียด1СBusinessNetwork, ประเภทของระบบการตั้งชื่อ BED, รายละเอียดเพิ่มเติมBED, ข้อเสนอทางการค้า.

ดูเอกสารประกอบการฝังสำหรับรายละเอียด

เวอร์ชัน 1.3.6

เวอร์ชัน 1.3.6 เป็นการพัฒนาเวอร์ชัน 1.3 "1C: Electronic Document Library 8" ซึ่งได้รับการออกแบบมาเพื่อให้มีการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ในโซลูชันแอปพลิเคชันที่พัฒนาบนแพลตฟอร์ม 1C:Enterprise เวอร์ชัน 8.3.8 และสูงกว่า ในกรณีนี้ คุณสมบัติการกำหนดค่า "โหมดความเข้ากันได้" จะต้องตั้งค่าเป็น "เวอร์ชัน 8.3.8"

การกำหนดค่านี้มีไว้สำหรับใช้ร่วมกับการกำหนดค่า "1C: Library of Standard Subsystems" ไม่ต่ำกว่าเวอร์ชัน 2.3.4.112 โดยมีการกำหนดค่า "1C: Library of Internet User Support 8" ไม่ต่ำกว่าเวอร์ชัน 2.1.9.4

คุณสมบัติใหม่และการเปลี่ยนแปลง

  • รองรับรูปแบบของเอกสารใบแจ้งหนี้หลัก (ในแง่ของการโอนเอกสารหลักแยกต่างหาก ใบแจ้งหนี้) ตามคำสั่งของ Federal Tax Service ลงวันที่ 24 มีนาคม 2016 เลขที่ ММВ-7-15/155@ “เมื่อได้รับอนุมัติจาก รูปแบบใบแจ้งหนี้และรูปแบบการนำเสนอเอกสารในการขนส่งสินค้า (การปฏิบัติงาน) การโอนสิทธิในทรัพย์สิน (เอกสารการให้บริการ) รวมถึงใบแจ้งหนี้ในรูปแบบอิเล็กทรอนิกส์”
  • รองรับรูปแบบของเอกสารหลักเกี่ยวกับการเปลี่ยนแปลงมูลค่า รวมถึงใบแจ้งหนี้การปรับปรุง (ในแง่ของการโอนเอกสารหลักแยกต่างหาก ใบแจ้งหนี้การปรับปรุง) ตามคำสั่งของ Federal Tax Service ลงวันที่ 13 เมษายน 2016 N ММВ -7-15/189@ " ในการอนุมัติรูปแบบของใบแจ้งหนี้การปรับปรุงและรูปแบบในการส่งเอกสารเกี่ยวกับการเปลี่ยนแปลงต้นทุนของสินค้าที่จัดส่ง (งานที่ทำ, การให้บริการ), โอนสิทธิในทรัพย์สินรวมถึงใบแจ้งหนี้การปรับปรุงใน แบบฟอร์มอิเล็กทรอนิกส์”
  • เพิ่มเอกสารอิเล็กทรอนิกส์ใหม่: การโอนสินค้า, การโอนผลงาน, การนำเสนอเอกสารรูปแบบใหม่
  • เพิ่มกลไกการแลกเปลี่ยนทางเดียวที่ไม่ต้องแจ้งการรับจากผู้รับ
  • เพิ่มความสามารถในการควบคุมการแกะเอกสารอิเล็กทรอนิกส์ขาเข้า (อัตโนมัติหรือด้วยตนเอง) ความสามารถในการกำหนดค่าการสร้างเอกสารประเภทเฉพาะเมื่อรับเอกสารอิเล็กทรอนิกส์
  • เพิ่มความสามารถในการเชื่อมโยงเอกสารอิเล็กทรอนิกส์กับเอกสารทางบัญชีฐานข้อมูลหลายชุด
  • มีการแบ่งเอกสารอิเล็กทรอนิกส์เข้าและออก
  • มีการนำบูรณาการเข้ากับบริการแล้ว 1C-UMIให้คุณสร้างเว็บไซต์จากโปรแกรมตั้งค่าการแลกเปลี่ยนกับร้านค้าออนไลน์ได้ ยูมิ.
  • มีการปรับเปลี่ยนสำหรับการทำงานกับบริการ 1C-EDO ในบริการคลาวด์ 1CFresh

การเปลี่ยนไปใช้เวอร์ชัน 1.3.6 จากเวอร์ชัน 1.3.5

ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"

โมดูลทั่วไป ExchangewithCounterpartiesRedefinable

  • เพิ่มวิธีการ UPD SCHFDOP
  • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลผู้ซื้อ UPD Federal Tax Service. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท UPD (ข้อมูลผู้ซื้อ) ฟังก์ชัน SCHFDOP
  • เพิ่มฟังก์ชันวิธี UPD (ข้อมูลผู้ขาย) SCHFDOP ให้กับออบเจ็กต์ความปลอดภัยของข้อมูล
  • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลเพิ่มเติมของบริการภาษีของรัฐบาลกลางของผู้ขาย. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ เช่น ฟังก์ชัน STD (ข้อมูลผู้ขาย) DOP
  • เพิ่มวิธีการแล้ว ค้นหาสร้างเอกสาร UPDT เกี่ยวกับการถ่ายโอน. วิธีการนี้จะบันทึกข้อมูลจากเอกสารอิเล็กทรอนิกส์ UPD (ข้อมูลผู้ขาย) ฟังก์ชัน DOP ลงในวัตถุ IS
  • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลของ SCHFISeller Federal Tax Service. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภทฟังก์ชัน UTD (ข้อมูลผู้ขาย) SSF
  • เพิ่มวิธีการแล้ว ค้นหาสร้างUPDSInvoiceใบแจ้งหนี้. วิธีการบันทึกข้อมูลจากเอกสารอิเล็กทรอนิกส์ฟังก์ชัน UPD (ข้อมูลผู้ขาย) SSF ลงในออบเจ็กต์ความปลอดภัยของข้อมูล
  • เพิ่มวิธีการแล้ว วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท UCD (ข้อมูลผู้ขาย) ฟังก์ชัน KSCHFDIS
  • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลผู้ซื้อ UKID Federal Tax Service. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท UKD (ข้อมูลผู้ซื้อ) ฟังก์ชัน KSCHFDIS
  • เพิ่มวิธีการแล้ว วิธีการบันทึกข้อมูลจากเอกสารอิเล็กทรอนิกส์ฟังก์ชัน UCD (ข้อมูลผู้ขาย) KSCHFDIS ลงในออบเจ็กต์ความปลอดภัยของข้อมูล
  • เพิ่มวิธีการแล้ว กรอกข้อมูลเพื่อ DISInformation ของผู้ขาย Federal Tax Service. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท UCD (ข้อมูลผู้ขาย) ฟังก์ชัน DIS
  • เพิ่มวิธีการแล้ว FindCreateUKDDocumentAboutChangeValue. วิธีการนี้จะบันทึกข้อมูลจากฟังก์ชัน DIS ของเอกสารอิเล็กทรอนิกส์ UCD (ข้อมูลผู้ขาย) ลงในออบเจ็กต์ IS
  • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลของ KSCHFISeller Federal Tax Service. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท UCD (ข้อมูลผู้ขาย) ฟังก์ชัน KSCHF
  • เพิ่มวิธีการแล้ว ค้นหาสร้าง UKDSAccountInvoice. วิธีการนี้จะบันทึกข้อมูลจากฟังก์ชัน UCD (ข้อมูลผู้ขาย) ของเอกสารอิเล็กทรอนิกส์ KSCHF ลงในออบเจ็กต์ความปลอดภัยของข้อมูล
  • เพิ่มวิธีการแล้ว การปฏิบัติตามประเภทขาออกของ ED กับเอกสารความปลอดภัยของข้อมูล. วิธีการนี้เป็นการติดต่อระหว่างเอกสารอิเล็กทรอนิกส์ขาออกและเอกสารความปลอดภัยของข้อมูล
  • เพิ่มวิธีการแล้ว ค้นหาสร้างผลลัพธ์การโอนเอกสาร. วิธีการนี้ใช้ในการกรอกเอกสารใบตราส่งสินค้าที่ได้รับในรูปแบบ “การโอนสินค้า”
  • เพิ่มวิธีการแล้ว FindCreateDocumentการโอนสินค้า. วิธีการนี้ใช้ในการกรอกเอกสารใบรับรองการให้บริการที่ได้รับในรูปแบบการโอนผลงาน
  • เพิ่มวิธีการแล้ว ติดตั้ง StateExchange เสร็จสมบูรณ์. วิธีการนี้จะถูกเรียกเมื่อสถานะการไหลของเอกสารเปลี่ยนเป็น การแลกเปลี่ยนเสร็จสมบูรณ์, แลกเปลี่ยนเสร็จสมบูรณ์พร้อมการแก้ไข.
  • เมื่อสร้างเอกสารอิเล็กทรอนิกส์ UPD, UKD, โอนสินค้า, โอนผลงาน, รายละเอียด เอกสารวันที่, DocBaseDateจะต้องกรอก

การประมวลผลการแลกเปลี่ยนกับคู่สัญญา

ในเค้าโครง "Torg-12Seller":

  • เพิ่มฟิลด์ "IdStateContract"
  • เพิ่มส่วนตาราง "ใบแจ้งหนี้การขนส่ง" แล้ว
  • ฟิลด์ "Transport InvoiceDate", "Transport InvoiceNumber" ได้ถูกเอาออกแล้ว
  • เพิ่มช่อง "ข้อมูลเกี่ยวกับผู้โอนสินค้า"

ในการจัดวาง พระราชบัญญัติการโอนสิทธิ:

  • เพิ่มส่วนตาราง "ฐาน"
  • ฟิลด์ "DocumentBaseName", "DocumentBaseNumber", "DocumentBaseDate", "DocumentBaseAdditionalInformation" ได้ถูกเอาออกแล้ว
  • เพิ่มช่อง "CurrencyName" แล้ว
  • เพิ่มช่อง "การเรียกร้อง"
  • เพิ่มช่อง "วันที่ดำเนินการ"
  • ในคุณสมบัติของผู้เข้าร่วมธุรกรรม ฟิลด์ "แฟกซ์" จะถูกแทนที่ด้วยฟิลด์ "อีเมล"
  • ในคุณสมบัติของผู้เข้าร่วมธุรกรรม ฟิลด์ "รหัสประเทศ" ได้ถูกแทนที่ด้วยฟิลด์ "รหัสประเทศ"
  • ในคุณสมบัติของผู้เข้าร่วมธุรกรรม ฟิลด์ "AddressText" ถูกแทนที่ด้วยฟิลด์ "AddressText"

การอัปเดตประเภทที่กำหนด คู่สัญญา:

เมื่ออัปเกรดจากเวอร์ชัน 1.3.5 จำเป็นต้องอัปเดตประเภท Counterparty ที่กำหนดไว้ มิฉะนั้น การอ้างอิงไปยังไดเรกทอรี Counterparty ในออบเจ็กต์ BED เมื่ออัปเดตจะถูกแทนที่ด้วยประเภทสตริงโดยสูญเสียการอ้างอิงไปยังออบเจ็กต์โดยไม่มีความเป็นไปได้ การกู้คืน.

ขั้นตอนการอัปเดต:

  • เปลี่ยนชื่อประเภทบัญชีที่กำหนดเป็น AccountBED
  • ลบการกำหนดค่าออกจากการรองรับ BED 1.3.5
  • ดำเนินการเปรียบเทียบ/ผสานกับการกำหนดค่า BED 1.3.5 ตกลงที่จะตั้งค่าการกำหนดค่าให้รองรับ
  • ยกเลิกการเลือกออบเจ็กต์ทั้งหมดและปล่อยให้เหลือเฉพาะประเภทบัญชีที่กำหนดไว้ ดำเนินการผสาน
  • เริ่มการอัพเดตการกำหนดค่า เลือกไฟล์ BED 1.3.6
  • เลือกช่องทำเครื่องหมายตามประเภท AccountBED และบัญชีที่กำหนด ระบุวัตถุฐานข้อมูลที่จำเป็นอื่น ๆ สำหรับการอัพเดต
  • ดำเนินการอัปเดต

ระบบย่อย “แลกเปลี่ยนกับธนาคาร”

ไปจนถึงขั้นตอน รับใบแจ้งยอดธนาคารโมดูลทั่วไป แลกเปลี่ยนกับ BanksClientเพิ่มพารามิเตอร์ทางเลือก OpenFormClarificationPeriodมีประเภท บูลีน. จะต้องตั้งค่าเป็น True หากแบบฟอร์มที่ได้รับใบแจ้งยอดไม่มีความสามารถในการเปลี่ยนระยะเวลาการขอใบแจ้งยอดด้วยตนเอง

ระบบย่อย "แลกเปลี่ยนกับไซต์"

โหนดการแลกเปลี่ยนมีการเปลี่ยนแปลง การแลกเปลี่ยนไซต์, แบบฟอร์ม, โมดูลวัตถุ:

  • เพิ่มความสามารถในการอัปโหลดรายการโดยเลือกตามประเภทรายการ (ก่อนหน้านี้ใช้ได้เฉพาะกลุ่มรายการเท่านั้น)

เพิ่มหนังสืออ้างอิงแล้ว เว็บไซต์:

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

เพิ่มการประมวลผล สร้างเว็บไซต์:

  • เพิ่มความสามารถในการสร้างไซต์ในโดเมน 1C-UMI ไซต์จะถูกสร้างขึ้นโดยอัตโนมัติ (องค์ประกอบไซต์) และเต็มไปด้วยข้อมูลจาก 1C โหนดแลกเปลี่ยน ExchangeSite จะถูกสร้างขึ้นโดยอัตโนมัติ และทำการแลกเปลี่ยนแบบเต็มครั้งแรกกับไซต์

โมดูลทั่วไป การแลกเปลี่ยนไซต์เอาชนะได้:

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

โมดูลทั่วไป เหตุการณ์ ExchangeSite:

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

การเปลี่ยนแปลงอื่นๆ

การตั้งค่าระบบย่อย การจัดการภาษีในรูปแบบการให้บริการห้องสมุด เทคโนโลยีการบริการ

ไปยังโมดูลทั่วไป การเก็บภาษีกำหนดใหม่ได้ในวิธีการเมื่อสร้างรายการบริการ () คุณต้องเพิ่มรหัสหลังจากเรียกวิธี InternetUser Support เมื่อสร้างรายการบริการ (ผู้ให้บริการ):

// ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์
ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์เมื่อสร้างรายชื่อบริการ (ผู้ให้บริการ);
// สิ้นสุดการโต้ตอบทางอิเล็กทรอนิกส์

เวอร์ชัน 1.3.5

เวอร์ชัน 1.3.5 เป็นการพัฒนาของ "1C: Electronic Document Libraries 8" เวอร์ชัน 1.3 ซึ่งได้รับการออกแบบมาเพื่อให้มีการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ในโซลูชันแอปพลิเคชันที่พัฒนาบนแพลตฟอร์ม 1C:Enterprise เวอร์ชัน 8.3.8 และสูงกว่า

ค่าคุณสมบัติการกำหนดค่า:

  • ควรตั้งค่าโหมดความเข้ากันได้เป็น "ห้ามใช้"
  • โหมดการใช้งานแบบกิริยาสามารถตั้งค่าเป็น "ห้ามใช้"
  • โหมดความเข้ากันได้ของอินเทอร์เฟซสามารถรับค่า "เวอร์ชัน 8.2", "เวอร์ชัน 8.2 อนุญาตแท็กซี่" หรือ "แท็กซี่ อนุญาตเวอร์ชัน 8.2"

คุณสมบัติใหม่และการเปลี่ยนแปลง

  • ฟังก์ชั่นไลบรารีได้รับการปรับให้เข้ากับคุณสมบัติเฉพาะของการทำงานบนแพลตฟอร์ม 8.3.8 โดยปิดใช้งานโหมดความเข้ากันได้
  • ระบบย่อยของ "ไลบรารีระบบย่อยมาตรฐาน" ได้รับการอัพเดตเป็นเวอร์ชัน 2.3.3.45;
  • ไลบรารีประกอบด้วยระบบย่อย "Internet User Support Libraries" เวอร์ชัน 2.1.8.3

การเปลี่ยนไปใช้เวอร์ชัน 1.3.5 จากเวอร์ชัน 1.3.4

ไม่จำเป็นต้องเปลี่ยนแปลง

เวอร์ชัน 1.3.4

เวอร์ชัน 1.3.4 เป็นการพัฒนาของ "1C: Electronic Document Libraries 8" เวอร์ชัน 1.3 ซึ่งได้รับการออกแบบมาเพื่อให้มีการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ในโซลูชันแอปพลิเคชันที่พัฒนาบนแพลตฟอร์ม 1C:Enterprise เวอร์ชัน 8.3.6 และสูงกว่า ในกรณีนี้ คุณสมบัติการกำหนดค่า "โหมดความเข้ากันได้" จะต้องตั้งค่าเป็น "ห้ามใช้" โหมดการใช้งานแบบกิริยาสามารถตั้งค่าเป็น "ห้ามใช้" และโหมดความเข้ากันได้ของอินเทอร์เฟซสามารถตั้งค่าเป็น "เวอร์ชัน 8.2", "เวอร์ชัน 8.2. อนุญาตแท็กซี่" หรือ "แท็กซี่ อนุญาตเวอร์ชัน 8.2"

คุณสมบัติใหม่และการเปลี่ยนแปลง

  • มีการใช้ระบบการแจ้งเตือนเกี่ยวกับเหตุการณ์ EDI (เอกสารอิเล็กทรอนิกส์ใหม่ คำเชิญใหม่ การหมดอายุของใบรับรอง ฯลฯ) ตอนนี้คุณสามารถกำหนดค่าการแจ้งเตือนทางอีเมลในโปรไฟล์การตั้งค่า EDF รวมถึงแสดงการแจ้งเตือนเกี่ยวกับเหตุการณ์โดยตรงในโปรแกรม 1C โดยใช้ข้อความป๊อปอัป
  • รองรับรูปแบบของเอกสารหลัก รวมถึงใบแจ้งหนี้ (รูปแบบ UPD) ตามคำสั่งของ Federal Tax Service ลงวันที่ 24 มีนาคม 2559 เลขที่ ММВ-7-15/155@ “เมื่อได้รับอนุมัติรูปแบบใบแจ้งหนี้และ รูปแบบการส่งเอกสารเกี่ยวกับการขนส่งสินค้า ( ประสิทธิภาพการทำงาน) การโอนสิทธิในทรัพย์สิน (เอกสารเกี่ยวกับการให้บริการ) รวมถึงใบแจ้งหนี้ในรูปแบบอิเล็กทรอนิกส์";
  • รองรับรูปแบบของเอกสารเกี่ยวกับการเปลี่ยนแปลงมูลค่าซึ่งรวมถึงใบแจ้งหนี้การปรับปรุง" (รูปแบบ UKD) ตามคำสั่งของ Federal Tax Service ลงวันที่ 04/13/2016 N ММВ-7-15/189@ "ในการอนุมัติรูปแบบของใบแจ้งหนี้การปรับปรุงและเอกสารรูปแบบการนำเสนอเกี่ยวกับการเปลี่ยนแปลงต้นทุนของสินค้าที่จัดส่ง (งานที่ทำ, การให้บริการ), สิทธิในทรัพย์สินที่โอน, รวมถึงใบแจ้งหนี้การปรับปรุงในรูปแบบอิเล็กทรอนิกส์";
  • รองรับการใช้ส่วนประกอบภายนอกเพื่อแลกเปลี่ยนกับธนาคารโดยใช้เทคโนโลยี DirectBank

การเปลี่ยนไปใช้เวอร์ชัน 1.3.4 จากเวอร์ชัน 1.3.2, 1.3.3

การเปลี่ยนแปลงแบบฟอร์มรายการเอกสารโซลูชันแอปพลิเคชัน

ในแบบฟอร์มรายการเอกสาร คุณต้องเพิ่มขั้นตอนปลั๊กอิน แลกเปลี่ยนกับ CounterpartiesClient กำลังรอโปรเซสเซอร์ EDW:

&บนไคลเอนต์

สิ้นสุดขั้นตอน

เมื่ออัพเดตระบบย่อย จำเป็นในตัวจัดการเหตุการณ์ของแบบฟอร์มรายการเอกสาร: เมื่อ CreateOnServer, เมื่อเปิด, การแจ้งเตือนการประมวลผล

&บนเซิร์ฟเวอร์
ขั้นตอนเมื่อสร้างบนเซิร์ฟเวอร์

ParametersWhenCreatedOnServer = ExchangeWithCounterparties.ParametersWhenCreatedOnServer_ListForm();
ParametersWhenCreatedOnServer.Form = ThisObject;
ParametersWhenCreatedOnServer.LocationofCommands = คำสั่ง Elements.EDO;
ExchangewithCounterparties.WhenCreatedOnServer_ListForm (ความล้มเหลว การประมวลผลมาตรฐาน พารามิเตอร์เมื่อสร้างบนเซิร์ฟเวอร์);
สิ้นสุดขั้นตอน

&บนไคลเอนต์
ขั้นตอนการเปิด (ล้มเหลว)

// ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
// สิ้นสุดระบบย่อย "Counterparty Exchange"
สิ้นสุดขั้นตอน

&บนไคลเอนต์
การแจ้งเตือนกระบวนการขั้นตอน (ชื่อเหตุการณ์, พารามิเตอร์, แหล่งที่มา)

// ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
พารามิเตอร์การแจ้งเตือนEDO = แลกเปลี่ยนกับ CounterpartiesClient.AlertParametersEDO_ListForm();
พารามิเตอร์การแจ้งเตือน EDO.Form = ThisObject;
พารามิเตอร์การแจ้งเตือน EDO.DynamicListName = "รายการ";
ExchangewithCounterpartiesClient.ProcessingAlert_ListForm (ชื่อเหตุการณ์ พารามิเตอร์ แหล่งที่มา EDI AlertParameters);
// สิ้นสุดระบบย่อย "Counterparty Exchange"
สิ้นสุดขั้นตอน

การเปลี่ยนแปลงแบบฟอร์มเอกสารการแก้ปัญหาการสมัคร

ในแบบฟอร์มเอกสาร คุณต้องเพิ่มขั้นตอนปลั๊กอิน Connectable_WaitingHandlerEDOโดยที่คุณต้องทำการเรียกเมธอด

แลกเปลี่ยนกับคู่ค้าไคลเอนต์ กำลังรอตัวประมวลผล EDW:

&บนไคลเอนต์
ขั้นตอน Connectable_EDOWaitingHandler()
ExchangeCounterpartiesClient.EDOWaitingHandler (ThisObject);
สิ้นสุดขั้นตอน

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

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

ตัวอย่างเช่น:

&บนเซิร์ฟเวอร์


// ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
พารามิเตอร์ EDO เมื่อสร้าง = แลกเปลี่ยนกับคู่สัญญา พารามิเตอร์เมื่อสร้างบน Server_DocumentForm();
พารามิเตอร์ EDO เมื่อสร้างแล้วForm = ThisObject;
พารามิเตอร์ EDO เมื่อสร้าง DocumentLink = Object.Link;
พารามิเตอร์ EDO เมื่อ Create.DecorationStateEDO = Elements.DecorationStateEDO;
พารามิเตอร์ EDO เมื่อสร้างขึ้น กลุ่มรัฐ EDO = กลุ่มรัฐ Elements.EDO;
แลกเปลี่ยนกับคู่สัญญาเมื่อสร้างขึ้นบน Server_DocumentForm (การปฏิเสธ, การประมวลผลมาตรฐาน, พารามิเตอร์ EDO เมื่อสร้าง);
// สิ้นสุดระบบย่อย "Counterparty Exchange"
สิ้นสุดขั้นตอน

&บนไคลเอนต์
ขั้นตอนการเปิด (ล้มเหลว)

// ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
ExchangeWithCounterpartiesClient.OnOpening (ThisObject);
// สิ้นสุดระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
สิ้นสุดขั้นตอน

&บนเซิร์ฟเวอร์
ขั้นตอน AfterRecordOnServer (CurrentObject, RecordParameters)

// ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
ParametersAfterRecord = ExchangeWithCounterparties.ParametersAfterRecordOnServer();
ParametersAfterRecord.Form = ThisObject;
พารามิเตอร์AfterRecord.DocumentLink = Object.Link;
ParametersAfterRecording.DecorationStateEDO = Elements.DecorationStateEDO;
ParametersAfterRecord.GroupEDOStatus = Elements.GroupEDOState;
แลกเปลี่ยนกับคู่ค้า AfterRecordOnServer (CurrentObject, RecordParameters, AfterRecordParameters);
// สิ้นสุดระบบย่อย "Counterparty Exchange"
สิ้นสุดขั้นตอน

&บนไคลเอนต์
การแจ้งเตือนกระบวนการขั้นตอน (ชื่อเหตุการณ์, พารามิเตอร์, แหล่งที่มา)

// ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
พารามิเตอร์การแจ้งเตือน = ExchangewithCounterpartiesClient.AlertParametersEDO_DocumentForm();
AlertParameters.Form = ThisObject;
AlertParameters.DocumentLink = Object.Link;
พารามิเตอร์การแจ้งเตือน.DecorationEDO State = Elements.DecorationEDO State;
พารามิเตอร์การแจ้งเตือน กลุ่มสถานะ EDO = กลุ่มสถานะ Elements.EDO;
ExchangeWithCounterpartiesClient.ProcessingAlert_DocumentForm (ชื่อเหตุการณ์ พารามิเตอร์ แหล่งที่มา พารามิเตอร์การแจ้งเตือน);
// สิ้นสุดระบบย่อย "Counterparty Exchange"
สิ้นสุดขั้นตอน

การเปลี่ยนแปลงในโมดูล ExchangeCounterpartys

  • เพิ่มขั้นตอนแล้ว เมื่อ CreateOnServer_ListFormเรียกจากตัวจัดการเหตุการณ์ "เมื่อ CreateOnServer" ของแบบฟอร์มรายการเอกสาร เนื่องจากเป็นพารามิเตอร์ตัวที่สามของเมธอด โครงสร้างจะถูกส่งผ่านซึ่งเตรียมใช้งานโดยเมธอด พารามิเตอร์เมื่อสร้างOnServer_ListForm.
  • เพิ่มขั้นตอนแล้ว เมื่อ CreateOnServer_FormDocumentเรียกจากตัวจัดการเหตุการณ์ "เมื่อ CreateOnServer" ของแบบฟอร์มเอกสาร เนื่องจากเป็นพารามิเตอร์ตัวที่สามของเมธอด โครงสร้างจะถูกส่งผ่านซึ่งเตรียมใช้งานโดยเมธอด พารามิเตอร์เมื่อสร้างOnServer_DocumentForm.
  • เพิ่มขั้นตอนแล้ว หลังจากบันทึกบนเซิร์ฟเวอร์เรียกจากตัวจัดการเหตุการณ์ "AfterRecordOnServer" ของแบบฟอร์มเอกสาร เนื่องจากเป็นพารามิเตอร์ตัวที่สามของเมธอด โครงสร้างจะถูกส่งผ่านซึ่งเตรียมใช้งานโดยเมธอด พารามิเตอร์ AfterRecordingOnServer.

การเปลี่ยนแปลงในโมดูล แลกเปลี่ยนกับคู่ค้าลูกค้า.

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

// จัดเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภทการโอนสินค้าไปยังผู้ขาย
// ตัวเลือก:
// LinkToObject - ลิงก์ไปยัง ED ซึ่งจำเป็นในการสร้างเอกสารอิเล็กทรอนิกส์


ขั้นตอนการกรอกข้อมูลผู้ดำเนินการถ่ายโอนข้อมูล (ลิงก์ออบเจ็กต์, โครงสร้าง ED, ทรีข้อมูล) ส่งออก
กรอกข้อมูลสำหรับ Act 501 ผู้ดำเนินการของ Federal Tax Service (ลิงก์ไปยังวัตถุ โครงสร้าง ED แผนผังข้อมูล)
สิ้นสุดขั้นตอน

  • วิธี ตรวจสอบความสามารถในการแก้ไขวัตถุกลายเป็นขั้นตอน
  • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับ UPDInformation ของบริการภาษีของรัฐบาลกลางของผู้ขาย. วิธีการจัดเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท รปภ(ข้อมูลผู้ขาย) ฟังก์ชั่น สคฟดอป.
  • เพิ่มวิธีการแล้ว ค้นหาสร้างเอกสารโอนสากล. วิธีการนี้จะบันทึกข้อมูลจากเอกสารอิเล็กทรอนิกส์ รปภ(ข้อมูลผู้ขาย) ฟังก์ชั่น SCHFDOPvวัตถุไอเอส
  • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลผู้ขาย UKDI Federal Tax Service. วิธีการจัดเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท สหราชอาณาจักร(ข้อมูลผู้ขาย) ฟังก์ชั่น กสชฟดีส.
  • เพิ่มวิธีการแล้ว FindCreateUniversalAdjustmentDocument. วิธีการนี้จะบันทึกข้อมูลจากเอกสารอิเล็กทรอนิกส์ สหราชอาณาจักร(ข้อมูลผู้ขาย) ฟังก์ชั่น กสชฟดีสไปยังวัตถุความปลอดภัยของข้อมูล

การเปลี่ยนแปลงในระบบย่อย "แลกเปลี่ยนกับธนาคาร"

การเปลี่ยนแปลงในโมดูล ExchangeWithBanksRedefinable

ขั้นตอน เมื่อเงื่อนไข ED เปลี่ยนแปลงเพิ่ม เรียกว่าเมื่อสถานะการไหลของเอกสารอิเล็กทรอนิกส์เปลี่ยนแปลง

การเปลี่ยนแปลงการทำงานในโหมดบริการ

หากจำเป็นต้องมีการกำหนดค่าปลายทางสำหรับการทำงานในโหมดบริการ:

  • ในขั้นตอน GetProvidedDataHandlers ของโมดูลทั่วไป SuppliedDataOverridden ให้เพิ่มรหัสต่อไปนี้:

ElectronicInteraction.RegisterDeliveredDataHandlers (ตัวจัดการ);

  • เพิ่มงานประจำ Update External Modules Exchange With Banks ให้กับแอตทริบิวต์ทั่วไป Data Area Basic Data

การเปลี่ยนแปลงอื่นๆ

  • คุณต้องเพิ่มค่าคงที่ให้กับประเภทที่กำลังกำหนด ใช้ ExchangeWithBanks;
  • คุณสมบัติที่ถูกลบออก แลกเปลี่ยนกับธนาคาร แนะนำแลกเปลี่ยนโดยตรงกับธนาคาร.

เวอร์ชัน 1.3.3

เวอร์ชัน 1.3.3 เป็นการพัฒนาผลิตภัณฑ์ "1C: Library of Electronic Documents" รุ่น 1.3 ออกแบบมาเพื่อการพัฒนาการกำหนดค่าที่ออกแบบมาเพื่อทำงานบนแพลตฟอร์ม 1C:Enterprise 8.3 เวอร์ชัน 8.3.6 และสูงกว่า

ค่าคุณสมบัติการกำหนดค่า:

  • ควรตั้งค่าโหมดความเข้ากันได้เป็น "ห้ามใช้"
  • โหมดการใช้งานแบบกิริยาสามารถตั้งค่าเป็น "ห้ามใช้"
  • โหมดความเข้ากันได้ของอินเทอร์เฟซสามารถรับค่า "เวอร์ชัน 8.2", "เวอร์ชัน 8.2 อนุญาตแท็กซี่" หรือ "แท็กซี่ อนุญาตเวอร์ชัน 8.2"

คุณสมบัติใหม่และการเปลี่ยนแปลง

  • ตามคำสั่งลงวันที่ 30 พฤศจิกายน 2558 เลขที่ ММВ-7-10/551@ "การอนุมัติรูปแบบการยื่นเอกสารการโอนสินค้าระหว่างธุรกรรมทางการค้าในรูปแบบอิเล็กทรอนิกส์" และคำสั่ง ลงวันที่ 30 พฤศจิกายน 2558 เลขที่ ММВ-7-10/552@ "เมื่อได้รับอนุมัติรูปแบบการส่งเอกสารการโอนผลงาน (เอกสารการให้บริการ) ในรูปแบบอิเล็กทรอนิกส์" รองรับเอกสารอิเล็กทรอนิกส์รูปแบบใหม่

การเปลี่ยนแปลงในระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"

ในโมดูล แลกเปลี่ยนกับคู่สัญญาเอาชนะได้ทำการเปลี่ยนแปลง:

// เตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภทใบตราส่ง
// ตัวเลือก:
// LinkOnED - ลิงก์ไปยัง ED ซึ่งจำเป็นในการสร้างเอกสารอิเล็กทรอนิกส์
// StructureED - โครงสร้างโครงสร้างข้อมูลสำหรับการสร้างเอกสารอิเล็กทรอนิกส์
// Data Tree - แผนผังแห่งค่า, แผนผังข้อมูลสำหรับการกรอกเอกสารอิเล็กทรอนิกส์
ขั้นตอนการกรอกการถ่ายโอนข้อมูลของผู้ขายสินค้า (Object Link, โครงสร้าง ED, Data Tree) การส่งออก
กรอกข้อมูลในการต่อรองผู้ขาย 12 รายของบริการภาษีของรัฐบาลกลาง (ลิงก์ไปยังวัตถุ โครงสร้าง ED แผนผังข้อมูล)
สิ้นสุดขั้นตอน

จำเป็นต้องเพิ่มการกำหนดค่าที่ใช้ BED ซึ่งเป็นเทมเพลตสำหรับการจำกัดการเข้าถึงในระดับบันทึกตามองค์กร (RLS) เมื่อทำงานกับเอกสารอิเล็กทรอนิกส์ (ดูเอกสารประกอบที่ฝัง)

เวอร์ชัน 1.3.2

เวอร์ชัน 1.3.2 เป็นการพัฒนาผลิตภัณฑ์ "1C: Library of Electronic Documents" รุ่น 1.3 ออกแบบมาเพื่อการพัฒนาการกำหนดค่าที่ออกแบบมาเพื่อทำงานบนแพลตฟอร์ม 1C:Enterprise 8.3 เวอร์ชัน 8.3.6 และสูงกว่า

ค่าคุณสมบัติการกำหนดค่า:

  • ควรตั้งค่าโหมดความเข้ากันได้เป็น "ห้ามใช้"
  • โหมดการใช้งานแบบกิริยาสามารถตั้งค่าเป็น "ห้ามใช้"
  • โหมดความเข้ากันได้ของอินเทอร์เฟซสามารถรับค่า "เวอร์ชัน 8.2", "เวอร์ชัน 8.2 อนุญาตแท็กซี่" หรือ "แท็กซี่ อนุญาตเวอร์ชัน 8.2"

คุณสมบัติใหม่และการเปลี่ยนแปลง

  • นำแสดงเอกสารอิเล็กทรอนิกส์ 2 หัวข้อ (TORG12, พระราชบัญญัติ, เอกสารการปรับ) ในรูปแบบเดียวสำหรับการดูเอกสารอิเล็กทรอนิกส์ ข้อมูลทั้งหมดจากชื่อเรื่องจะถูกรวบรวมไว้ในแบบฟอร์มเดียว สามารถดูแบบฟอร์มของชื่อเรื่องที่สองแยกกันได้จากแบบฟอร์ม "เอกสารอิเล็กทรอนิกส์"
  • ความสามารถในการสรุปมาตรฐาน "ข้อตกลง EDA" ในรูปแบบอิเล็กทรอนิกส์จาก "การตั้งค่า EDF" ในโปรแกรม 1C ได้ถูกนำมาใช้แล้ว เมื่อใช้คำสั่ง "สร้างข้อตกลงโดยใช้เทมเพลต" เอกสารอิเล็กทรอนิกส์ที่กำหนดเองจะถูกสร้างขึ้นโดยอัตโนมัติ โดยไฟล์แนบจะเป็นไฟล์ข้อตกลง หลังจากลงนามแล้วสามารถส่งเอกสารไปยังคู่สัญญาได้ทันที
  • การแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ตามอำเภอใจพร้อมไฟล์แนบ ขณะนี้ไฟล์ที่แนบมาสามารถลงนามและส่งไปยังคู่สัญญาได้อย่างรวดเร็วโดยใช้เอกสารอิเล็กทรอนิกส์
  • รองรับความสามารถในการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์กับธนาคารในโครงการเงินเดือน
  • เพิ่มผู้ช่วยในการเชื่อมต่อองค์กรกับ DirectBank
  • รายชื่อธนาคารที่รองรับ DirectBank ได้รับการอัพเดตผ่านทางอินเทอร์เน็ต
  • รองรับการทำงานกับโทเค็นประเภทต่าง ๆ (กุญแจอิเล็กทรอนิกส์) ของ Sberbank: "ปกติ", "สัมผัส", "พร้อมหน้าจอ"
  • ระบบย่อยของ "Standard Subsystem Library" (BSS) ได้รับการอัพเดตเป็นเวอร์ชัน 2.3.2.27

การเปลี่ยนไปใช้เวอร์ชัน 1.3.2.19 จากเวอร์ชัน 1.2.7, 1.3.1

คุณต้องเพิ่มขั้นตอนโดยไม่ต้องเติมลงในโมดูล:

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

ในโมดูล งานปกติที่เอาชนะได้ทำการเปลี่ยนแปลง:

ขั้นตอนการกำหนดการตั้งค่าสำหรับการส่งออกงานประจำ (การตั้งค่า)
ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์เมื่อกำหนดการตั้งค่าของงานประจำ (การตั้งค่า);
สิ้นสุดขั้นตอน

ในโมดูล ไคลเอนต์ลายเซ็นอิเล็กทรอนิกส์เอาชนะได้ทำการเปลี่ยนแปลง:

ขั้นตอนสำหรับการส่งออกการตรวจสอบใบรับรองเพิ่มเติม (พารามิเตอร์)
ExchangeWithBanksClient.AtAdditionalCertificateVerification (พารามิเตอร์);
สิ้นสุดขั้นตอน

ไปยังโมดูล ลายเซ็นอิเล็กทรอนิกส์เอาชนะได้ทำการเปลี่ยนแปลง:

ขั้นตอนการสร้างแบบฟอร์มการตรวจสอบใบรับรอง (ใบรับรอง การตรวจสอบเพิ่มเติม พารามิเตอร์ของการตรวจสอบเพิ่มเติม การตรวจสอบมาตรฐาน) ส่งออก
ExchangeWithBanks เมื่อสร้างแบบฟอร์มการตรวจสอบใบรับรอง (
ใบรับรอง การตรวจสอบเพิ่มเติม พารามิเตอร์การตรวจสอบเพิ่มเติม การตรวจสอบมาตรฐาน)
สิ้นสุดขั้นตอน

มีการเพิ่มออบเจ็กต์ที่ไม่ได้แชร์ต่อไปนี้:

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

    หากการกำหนดค่ามีวัตถุประสงค์เพื่อให้ทำงานในโหมดโมเดลบริการ คุณจะต้องเปลี่ยน Subscription Handler เป็นเหตุการณ์ Control of Unshared Objects While Writing the BED to WorkIn the Service Model.Control of Unshared Objects While Writing

    เวอร์ชัน 1.3.1

    เวอร์ชัน 1.3.1 เป็นการพัฒนาผลิตภัณฑ์ "1C: Library of Electronic Documents" รุ่น 1.2 ออกแบบมาเพื่อการพัฒนาการกำหนดค่าที่ออกแบบมาเพื่อทำงานบนแพลตฟอร์ม 1C:Enterprise 8.3 เวอร์ชัน 8.3.6 และสูงกว่า

    ค่าคุณสมบัติการกำหนดค่า:

    • ควรตั้งค่าโหมดความเข้ากันได้เป็น "ห้ามใช้"
    • โหมดการใช้งานแบบกิริยาสามารถตั้งค่าเป็น "ห้ามใช้"
    • โหมดความเข้ากันได้ของอินเทอร์เฟซสามารถรับค่า "เวอร์ชัน 8.2", "เวอร์ชัน 8.2 อนุญาตแท็กซี่" หรือ "แท็กซี่ อนุญาตเวอร์ชัน 8.2"

    คุณสมบัติใหม่และการเปลี่ยนแปลง

    • ความสามารถในการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์โดยไม่มีลายเซ็นอิเล็กทรอนิกส์ผ่านบริการ EDI ได้ถูกนำมาใช้สำหรับ 1C: ผู้เข้าร่วมเครือข่ายธุรกิจ
    • มีการใช้ระบบย่อยการแลกเปลี่ยนอัตโนมัติกับธนาคาร
    • ระบบย่อยของ "Standard Subsystem Library" (BSS) ได้รับการอัพเดตเป็นเวอร์ชัน 2.3.1.71

    การเปลี่ยนไปใช้เวอร์ชัน 1.3.1 จากเวอร์ชัน 1.2.6, 1.2.7

    การเปลี่ยนแปลงทางสถาปัตยกรรม

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

    เอกสารอิเล็กทรอนิกส์วี ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์:

    • นามสกุล ชื่อย่อ บุคคล

    รายการวิธีการที่ถูกย้ายออกจากโมดูล เอกสารอิเล็กทรอนิกส์วี แลกเปลี่ยนกับธนาคาร:

    • สามารถแลกเปลี่ยนโดยตรงกับธนาคารได้
    • GetDataBankStatementsTreeValues
    • รับ DataBankStatementsTextFormat
    • การแยกวิเคราะห์ TreeExtractsBank

    รายการวิธีการที่ถูกย้ายจากโมดูลไปที่ ElectronicInteractionClientOverridable:

    • ดำเนินการตรวจสอบเอกสาร

    รายการวิธีการที่ถูกย้ายออกจากโมดูล เอกสารอิเล็กทรอนิกส์ไคลเอนต์เอาชนะได้วี แลกเปลี่ยนกับ BanksClientOverridable:

    • ParseFileExtracts

    รายการวิธีการที่ถูกย้ายจากโมดูลไปที่ เซิร์ฟเวอร์ไคลเอนต์ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์:

    • GetMessageText (เปลี่ยนชื่อเป็น MessageText)
    • นั่นการกระทำ

    รายการวิธีการที่ถูกย้ายออกจากโมดูล เอกสารอิเล็กทรอนิกส์ไคลเอนต์เซิร์ฟเวอร์วี ExchangeWithBanksClientServer:

    • กรอกรายละเอียดการตั้งค่า EDSBanks (เปลี่ยนชื่อเป็นกรอกรายละเอียดการตั้งค่าการแลกเปลี่ยน)
    • HeaderSettingsEDOSBank ถูกเปลี่ยนชื่อเป็น HeaderSettingsExchangeWithBank
    • รับข้อความสถานะ

    รายการวิธีการที่ถูกย้ายจากโมดูลไปที่ ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์เอาชนะได้:

    • ChangeFormElementProperties
    • ปัจจุบันไดเร็กทอรีไฟล์ชั่วคราว
    • รับตัวเลือกการทำงานที่ตรงกัน
    • รับไดเรกทอรีที่ตรงกัน
    • รับความสอดคล้องกับชื่อของวัตถุ MD และรายละเอียด
    • ความสอดคล้องของรหัสรายละเอียดและการรับรอง
    • รับโครงสร้างของรายละเอียดที่สำคัญของวัตถุ
    • ข้อความการตั้งค่าระบบที่จำเป็น
    • แก้ไขข้อความแสดงข้อผิดพลาด
    • เตรียมข้อความเกี่ยวกับการละเมิดสิทธิ์การเข้าถึง
    • ถอดแยกชื่อบุคคล
    • ค้นหาReferenceToObject
    • รับหมายเลขเอกสารที่พิมพ์
    • ตรวจสอบความพร้อมแหล่งที่มา
    • GetData LegalIndividuals
    • คำอธิบาย องค์กร
    • มีสิทธิที่จะประมวลผล ED
    • มีสิทธิอ่าน ED ได้
    • มีสิทธิเปิดทะเบียนวารสารได้

    รายการวิธีการที่ถูกย้ายออกจากโมดูล เอกสารอิเล็กทรอนิกส์เอาชนะได้วี แลกเปลี่ยนกับธนาคารเอาชนะได้:

    • รับ ED ประเภทปัจจุบัน
    • รับหมายเลขบัญชีธนาคาร
    • กรอกพารามิเตอร์ ED ตามแหล่งที่มา
    • กรอกข้อมูลคำสั่งชำระเงิน
    • กรอกข้อมูลคำขอชำระเงิน
    • ตรวจสอบความสามารถในการแก้ไขวัตถุ

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

    เค้าโครงย้ายจากการประมวลผล แลกเปลี่ยนคู่สัญญาวี แลกเปลี่ยนกับธนาคาร:

    • คำสั่งจ่ายเงิน
    • ข้อกำหนดในการชำระเงิน

    คุณต้องเพิ่มประเภทที่กำหนดไว้

    • documentObject.PackageED

    การเปลี่ยนแปลงอินเทอร์เฟซ

    • ในโมดูลทั่วไป แลกเปลี่ยนกับธนาคาร, แลกเปลี่ยนคู่สัญญาเพิ่มขั้นตอนแล้ว เมื่อ CreateOnServer. เรียกว่าเมื่อเปิดแบบฟอร์มวัตถุเพื่อสร้างคำสั่ง EDI ตัวเลือก: รูปร่าง– แบบฟอร์มปัจจุบัน การจัดตำแหน่งทีมค่าเริ่มต้น– องค์ประกอบของรูปแบบเมนูย่อยที่จะสร้างคำสั่ง EDI
    • ในโมดูลทั่วไป แลกเปลี่ยนกับธนาคารเอาชนะได้, แลกเปลี่ยนกับคู่สัญญาเอาชนะได้เพิ่มขั้นตอนสำหรับการสร้างรายการคำสั่ง EDM เตรียมโครงสร้างวัตถุของทีม EDF. พารามิเตอร์ องค์ประกอบของ TeamsEDOสามารถเป็นอาร์เรย์ได้ (สำหรับระบบย่อย แลกเปลี่ยนกับธนาคาร) หรือโครงสร้างอาร์เรย์ ( แลกเปลี่ยนคู่สัญญา).
    • กลุ่มคำสั่ง EDI ถูกลบออก การเติมแผงคำสั่งอัตโนมัติด้วยคำสั่ง EDI จะไม่ถูกดำเนินการอีกต่อไป

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

    ตัวอย่างในโมดูล แลกเปลี่ยนกับคู่สัญญาเอาชนะได้:


    องค์ประกอบของทีม EDM.Outgoing.Add("Document.Sales of Goods and Services");
    องค์ประกอบของ EDO Commands.Outgoing.Add("Document.Buyer's Order");

    องค์ประกอบของทีม EDF.Incoming.Add("Document.Receipt of Goods and Services");
    องค์ประกอบของ EDO Commands.Incoming.Add("Document.InvoiceReceived");

    สิ้นสุดขั้นตอน

    แลกเปลี่ยนกับธนาคารเอาชนะได้:

    ขั้นตอนการเตรียมโครงสร้างวัตถุของทีม EDF (องค์ประกอบของทีม EDF) การส่งออก
    องค์ประกอบของ EDO Commands.Add("Document.Payment Order");
    องค์ประกอบของ EDO Commands.Add("Document.PaymentRequest");

    สิ้นสุดขั้นตอน

    เมื่อสร้างแบบฟอร์ม ให้เรียกใช้คำสั่งการสร้างโปรแกรม

    แลกเปลี่ยนกับคู่สัญญา เมื่อสร้างบน Server:

    ขั้นตอนเมื่อ CreateOnServer (ล้มเหลว, การประมวลผลมาตรฐาน)
    //คำสั่ง EDO
    แลกเปลี่ยนกับคู่สัญญาเมื่อ CreateOnServer (ThisObject, Elements.EDO Commands);
    // สิ้นสุดคำสั่ง EDO
    สิ้นสุดขั้นตอน

    เพิ่มตัวจัดการแบบฟอร์มที่เสียบได้ Connectable_Execute คำสั่ง EDO:

    ขั้นตอน Connectable_Execute คำสั่ง EDO (คำสั่ง)
    ElectronicInteractionServiceClient.ExecuteConnectedCommandEDO (คำสั่ง, ThisForm, Elements.List);
    สิ้นสุดขั้นตอน

    การเปลี่ยนแปลงในระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"

    • กรอกประเภทที่กำหนดไว้ "Grounds of Arbitrary ED" พร้อมประเภทของเอกสารตามรายการที่จะป้อน ED โดยพลการ(ส่วนใหญ่แล้วสิ่งเหล่านี้จะเป็นเอกสารเดียวกับในประเภทที่กำหนดไว้ เจ้าของไฟล์แนบ) นอกจากนี้ในเอกสารเหล่านี้คุณต้องเพิ่มเอกสาร "Custom ED" ในรายการ "เป็นพื้นฐานสำหรับ:"
    • ในรูปแบบเอกสารและรายการเอกสาร (ตามการป้อน Custom ED) จำเป็นต้องปิดการใช้งาน Custom ED ในเมนูย่อย "สร้างตาม" เนื่องจาก คำสั่งสำหรับการป้อน Custom ED จะอยู่ในเมนูย่อย EDO (คำสั่ง "เพิ่มไฟล์");
    • ในรูปแบบพระราชบัญญัติการโอนสิทธิ, การสั่งซื้อสินค้า, การตอบสนองต่อการสั่งซื้อ, รายงานของตัวแทนค่าคอมมิชชันด้านการขาย, รายงานของตัวแทนค่าคอมมิชชันในเรื่องคำอธิบาย, ใบแจ้งหนี้สำหรับการชำระเงิน, แค็ตตาล็อกผลิตภัณฑ์, รายการราคาในกลุ่มพารามิเตอร์ "ธนาคาร" ในฟิลด์ "BIC" มีการเปลี่ยนแปลงแอตทริบิวต์การเติมข้อมูลบังคับ ต้องกรอกข้อมูลในช่องนี้
    • ในเค้าโครง InvoiceInvoice รูปแบบของฟิลด์รหัสประเทศแหล่งกำเนิดสินค้าและหมายเลขสำแดงศุลกากรมีการเปลี่ยนแปลง เพื่อการเติมที่ถูกต้องยิ่งขึ้น จะรวมไว้ในตารางศุลกากร ตัวอย่างการกรอกองค์ประกอบเหล่านี้ในขั้นตอนการเตรียมข้อมูล ESF สามารถพบได้ในฐานข้อมูลสาธิตของ BED

    การเปลี่ยนแปลงในโมดูล ExchangewithCounterpartiesClient

    • วิธีการ OpenEDList เลิกใช้แล้ว ขอแนะนำให้ใช้ OpenEDTree แทนซึ่งจะเปิดผู้ใช้ไปยังแผนผังกฎเกณฑ์สำหรับการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์สำหรับเอกสารความปลอดภัยของข้อมูล

    การเปลี่ยนแปลงในโมดูลการโต้ตอบทางอิเล็กทรอนิกส์ถูกแทนที่

    มีการเพิ่มสองคีย์ในการรับการติดต่อกับชื่อของออบเจ็กต์และรายละเอียดเพื่อการกำหนดใหม่:

    • การขายสินค้าและบริการในเมตาดาต้า
    • การรับสินค้าและบริการในเมตาดาต้า

    การเปลี่ยนแปลงในโมดูล ExchangeCounterpartys

    เพิ่มวิธี Fill DataBy 1SEDOD สำหรับ 1C-Reporting Master ซึ่งเตรียมข้อมูลสำหรับ 1C-Reporting Master

    เพิ่มวิธีการตรวจสอบ AccounterV1EDMSWhen CreateOnServer ซึ่งจะต้องถูกเรียกเมื่อสร้างแบบฟอร์มบัญชี วิธีนี้จะเรียกใช้การตรวจสอบการเชื่อมต่อของคู่สัญญากับบริการ 1C-EDO
    ตัวอย่าง แลกเปลี่ยนกับคู่สัญญา ตรวจสอบคู่สัญญาใน 1 SEDO เมื่อสร้างบนเซิร์ฟเวอร์:

    ขั้นตอนเมื่อ CreateOnServer (ล้มเหลว, การประมวลผลมาตรฐาน)
    // ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์ แลกเปลี่ยนกับคู่สัญญา
    แลกเปลี่ยนกับคู่สัญญา ตรวจสอบคู่สัญญาใน 1SEDO เมื่อ CreateOnServer (Object.Link)
    // ยุติปฏิสัมพันธ์ทางอิเล็กทรอนิกส์ แลกเปลี่ยนกับคู่สัญญา
    สิ้นสุดขั้นตอน

    เพิ่มไม่แยกงานประจำ การตรวจสอบคู่สัญญาBEDซึ่งทำการเลือกคู่สัญญาและตรวจสอบการเชื่อมต่อกับ 1C-EDO

    เพิ่มการลงทะเบียนข้อมูลแยก สถานะของคู่สัญญาBEDซึ่งรวบรวมสถิติผู้รับเหมาที่เชื่อมต่อกับบริการ 1C-EDO

    เพิ่มการแสดงสัญลักษณ์การเชื่อมต่อกับบริการ 1C-EDO ในคอลัมน์ "EDO" ในแบบฟอร์มรายการและแบบฟอร์มการเลือกคู่สัญญา เพิ่มคำแนะนำในคอลัมน์ "เชื่อมต่อกับบริการ 1C-EDO"
    ตัวอย่าง:

    เลือก
    ทางเลือก
    เมื่อCounterparty StatusBED.Status = VALUE (Enumeration.CounterpartyStateBED.Connected)
    แล้ว 0
    อื่น ๆ 1
    จบ
    จบเหมือนเอโดะ
    ไดเรกทอรีคู่สัญญาชื่อ
    DirectoryCounterpartys.INN,
    DirectoryCounterpartys.KPP,
    ....
    ไดเรกทอรีคู่สัญญาชื่อเต็ม
    จาก
    Directory.Counterpartys AS DirectoryCounterparties
    การเชื่อมต่อด้านซ้าย การลงทะเบียนข้อมูล สถานะของผู้รับเหมา BED AS สถานะของผู้รับเหมา BED
    ซอฟต์แวร์ (ผู้รับเหมา StatesBED.Counterparty = DirectoryCounterparties.Link)

    ในแบบฟอร์มเอกสารฐานข้อมูล จำเป็นต้องลบลิงก์ไปยังตัวเลือกการทำงาน "ใช้ ED Exchange" ออกจากแอตทริบิวต์แบบฟอร์ม "ข้อความสถานะ ED" ลบส่วนหัวออกจากแอตทริบิวต์ "สถานะ ED"

    การเปลี่ยนแปลงในระบบย่อย "แลกเปลี่ยนกับธนาคาร"

    เพิ่มการสมัครสมาชิกกิจกรรม แลกเปลี่ยนกับ BanksOwnerED ก่อนการบันทึกและ ExchangeWithBanksOwnerEDOnRecording.

    • เพิ่มประเภทที่กำหนดไว้ OwnersExchangeWithBanks และ DirectoryBanks
    • เพิ่มคำสั่งทั่วไป SettingsExchangeWithBanks

    เพื่อกำหนดประเภท ไฟล์ที่แนบมาเพิ่ม:

    • directoryLink.MessageExchangeWithBanksAttachedFiles;
    • ไดเร็กทอรีObject.MessageExchangeWithBanksAttachedFiles;
    • directoryLink.PackageExchangeWithBanksAttachedFiles;
    • directoryObject.PackageExchangeWithBanksAttachedFiles.

    เพื่อกำหนดประเภท เจ้าของไฟล์แนบจำเป็นต้องเพิ่ม

    • documentLink.MessageExchangeWithBanks;
    • documentLink.PackageExchangeWithBanks

    เพื่อกำหนดประเภท OwnerAttachedFilesObjectจำเป็นต้องเพิ่ม

    • documentObject.MessageExchangeWithBanks;
    • documentObject.PackageExchangeWithBanks;
    • documentObject.PackageED

    เพิ่มระบบย่อยใหม่ "เครือข่ายธุรกิจ"

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

    จำเป็นต้องปฏิบัติตามขั้นตอนและฟังก์ชันต่างๆ ในโมดูลให้เสร็จสิ้น ธุรกิจเครือข่ายเอาชนะได้:

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

    การเปลี่ยนไปใช้เวอร์ชัน 1.3.7 จากเวอร์ชัน 1.3.6

    ในรูปแบบการอัพโหลดเอกสารการชำระเงินเป็นไฟล์และดาวน์โหลดใบแจ้งยอดธนาคารจากไฟล์ (กำลังประมวลผล ลูกค้าธนาคาร) ย้ายกลุ่มองค์ประกอบ กลุ่มโฆษณาDirectBankแนวนอนจากรูปแบบทั่วไป OfferConnect1SDirectBank.

    ในตัวจัดการเหตุการณ์แบบฟอร์ม เมื่อ CreateOnServerวิธีการวาง ExchangeWithBanksClientServer.ShowAdvertisingDirectBank:

    &บนเซิร์ฟเวอร์
    ขั้นตอนเมื่อ CreateOnServer (ล้มเหลว, การประมวลผลมาตรฐาน)

    // ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์ แลกเปลี่ยนกับธนาคาร
    ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(
    Elements.GroupAdvertisingDirectBankแนวนอน, Elements.TextDirectBankแนวนอน);
    // ยุติปฏิสัมพันธ์ทางอิเล็กทรอนิกส์ แลกเปลี่ยนกับธนาคาร
    สิ้นสุดขั้นตอน

    ในตัวจัดการเหตุการณ์แบบฟอร์ม การแจ้งเตือนการประมวลผลวางวิธี ExchangeWithBanksClient.UpdateAdvertisingDirectBank:

    &บนไคลเอนต์
    การแจ้งเตือนกระบวนการขั้นตอน (ชื่อเหตุการณ์, พารามิเตอร์, แหล่งที่มา)

    // ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์ แลกเปลี่ยนกับธนาคาร
    ExchangeWithBanksClient.UpdateAdvertisingDirectBank (ชื่อกิจกรรม
    Elements.GroupAdvertisingDirectBankแนวนอน, Elements.TextDirectBankแนวนอน);
    // ยุติปฏิสัมพันธ์ทางอิเล็กทรอนิกส์ แลกเปลี่ยนกับธนาคาร
    สิ้นสุดขั้นตอน

    สำหรับองค์ประกอบ ข้อความDirectBankแนวนอนเพิ่มตัวจัดการเหตุการณ์ กำลังประมวลผลการนำทางลิงก์และวางวิธี ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank ไว้ในนั้น:

    &บนไคลเอนต์
    ขั้นตอนข้อความDirectBankHorizontalNavigationLinkProcessing (องค์ประกอบ, FormattedStringNavigationLink, StandardProcessing)
    ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank(
    NavigationLinkFormatString, การประมวลผลมาตรฐาน);
    สิ้นสุดขั้นตอน

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

    09.06.2017

    เวอร์ชัน 1.3.8 ใหม่ของการกำหนดค่ามาตรฐาน "1C: Library of Electronic Documents 1.3" ได้รับการเผยแพร่แล้ว

    เวอร์ชัน 1.3.8

    เวอร์ชัน 1.3.8 เป็นการพัฒนาเวอร์ชัน 1.3 "1C: Electronic Document Library 8" ซึ่งได้รับการออกแบบมาเพื่อให้มีการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ในโซลูชันแอปพลิเคชันที่พัฒนาบนแพลตฟอร์ม 1C:Enterprise เวอร์ชัน 8.3.10.2252 และสูงกว่า

    คุณสมบัติใหม่และการเปลี่ยนแปลง

    • ในแบบฟอร์มการค้นหาข้อเสนอการค้าได้เพิ่มความสามารถในการค้นหาโดยไม่ต้องเชื่อมต่อกับ 1C: บริการเครือข่ายธุรกิจและเพิ่มความสามารถในการค้นหาซัพพลายเออร์ตามชื่อแล้ว
    • เพิ่มรายงานข้อเสนอการค้าที่เผยแพร่
    • เพิ่มสถานที่ทำงานสำหรับการเผยแพร่ข้อเสนอทางการค้าในบริการ 1C:Business Network แล้ว
    • การปรับเปลี่ยนเกิดขึ้นกับระบบย่อย "1C: Library of Standard Subsystems" เวอร์ชัน 2.4.2, "1C: Library of Internet User Support" เวอร์ชัน 2.2.2

    การเปลี่ยนไปใช้เวอร์ชัน 1.3.8 จากเวอร์ชัน 1.3.7

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

    การเปลี่ยนแปลงโมดูล:

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

    การเปลี่ยนแปลงในโมดูล ข้อเสนอทางการค้า

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

    เพิ่มบทบาทแล้ว รายงานข้อเสนอการซื้อขายที่จำเป็นในการเข้าถึงรายงาน ข้อเสนอทางการค้าที่เผยแพร่.

    เวอร์ชัน 1.3.7

    เวอร์ชัน 1.3.7 เป็นการพัฒนาเวอร์ชัน 1.3 "1C: Electronic Document Library 8" ซึ่งได้รับการออกแบบมาเพื่อให้มีการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ในโซลูชันแอปพลิเคชันที่พัฒนาบนแพลตฟอร์ม 1C:Enterprise เวอร์ชัน 8.3.10 และสูงกว่า

    ค่าคุณสมบัติการกำหนดค่า:

    • ควรตั้งค่าโหมดความเข้ากันได้เป็น "ห้ามใช้"
    • โหมดการใช้งานแบบกิริยาสามารถตั้งค่าเป็น "ห้ามใช้"
    • โหมดความเข้ากันได้ของอินเทอร์เฟซสามารถรับค่า "เวอร์ชัน 8.2", "เวอร์ชัน 8.2 อนุญาตแท็กซี่" หรือ "แท็กซี่ อนุญาตเวอร์ชัน 8.2"

    คุณสมบัติใหม่และการเปลี่ยนแปลง

    • เพิ่มความสามารถในการรับสถานะของเอกสารการชำระเงินจาก Sberbank
    • ใช้การรับการตั้งค่าอัตโนมัติสำหรับ Sberbank เมื่อเชื่อมต่อกับบริการ 1C: DirectBank
    • เพิ่มความสามารถในการแสดงโฆษณาตามบริบท 1C:DirectBank
    • มีการปรับเปลี่ยนเพื่อทำงานร่วมกับ 1C: บริการเครือข่ายธุรกิจในบริการคลาวด์ 1CFresh
    • เพิ่มความสามารถในการเผยแพร่ ค้นหา และสั่งซื้อข้อเสนอการค้าในบริการ 1C: ข้อเสนอการค้าสำหรับผู้เข้าร่วมในบริการ 1C: เครือข่ายธุรกิจ
    • การปรับตัวดำเนินการกับระบบย่อย "1C: Library of Standard Subsystems" เวอร์ชัน 2.4.1, "1C: Library of Internet User Support" เวอร์ชัน 2.1.9, "1C: Library of Service Technology" เวอร์ชัน 1.0.12

    การเปลี่ยนไปใช้เวอร์ชัน 1.3.7 จากเวอร์ชัน 1.3.6

    ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"

    การเปลี่ยนแปลงโมดูล:

    • เอกสารวันที่, DocBaseDate

    ระบบย่อย "แลกเปลี่ยนกับธนาคาร"

    การเปลี่ยนแปลงในโมดูล การทำงานกับ FilesOverridable:

    • ไปจนถึงขั้นตอน เมื่อกำหนดการตั้งค่าคุณต้องเพิ่มรหัส:

    ElectronicInteraction เมื่อกำหนดการตั้งค่า (การตั้งค่า);

    • ไปจนถึงขั้นตอน เมื่อกำหนดไดเร็กทอรีการจัดเก็บไฟล์คุณต้องเพิ่มรหัส:

    การโต้ตอบทางอิเล็กทรอนิกส์เมื่อกำหนดไดเร็กทอรี FileStorage (FileOwnerType, DirectoryNames);

    • ไดเร็กทอรี MessageExchangeWithBanksAttachedFiles และ EDAttachedFiles ได้รับการเพิ่มลงในแผนการแลกเปลี่ยน UpdateInformationBase
    • ไดเร็กทอรี MessageExchangeWithBanksAttachedFiles และ EDAttachedFiles ได้รับการเพิ่มลงในประเภทที่กำหนดไว้ SignedObject

    ในรูปแบบการอัพโหลดเอกสารการชำระเงินเป็นไฟล์และดาวน์โหลดใบแจ้งยอดธนาคารจากไฟล์ (กำลังประมวลผล ลูกค้าธนาคาร) ย้ายกลุ่มองค์ประกอบ กลุ่มโฆษณาDirectBankแนวนอนจากรูปแบบทั่วไป OfferConnect1SDirectBank.

    ในตัวจัดการเหตุการณ์แบบฟอร์ม เมื่อ CreateOnServerวิธีการวาง ExchangeWithBanksClientServer.ShowAdvertisingDirectBank:

    &บนเซิร์ฟเวอร์
    ขั้นตอนเมื่อ CreateOnServer (ล้มเหลว, การประมวลผลมาตรฐาน)

    ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(

    สิ้นสุดขั้นตอน

    ในตัวจัดการเหตุการณ์แบบฟอร์ม การแจ้งเตือนการประมวลผลวางวิธี ExchangeWithBanksClient.UpdateAdvertisingDirectBank:

    &บนไคลเอนต์


    // ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์ แลกเปลี่ยนกับธนาคาร
    ExchangeWithBanksClient.UpdateAdvertisingDirectBank (ชื่อกิจกรรม
    Elements.GroupAdvertisingDirectBankแนวนอน, Elements.TextDirectBankแนวนอน);
    // ยุติปฏิสัมพันธ์ทางอิเล็กทรอนิกส์ แลกเปลี่ยนกับธนาคาร
    สิ้นสุดขั้นตอน

    สำหรับองค์ประกอบ ข้อความDirectBankแนวนอนเพิ่มตัวจัดการเหตุการณ์ กำลังประมวลผลการนำทางลิงก์และวางวิธี ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank ไว้ในนั้น:

    &บนไคลเอนต์
    ขั้นตอนข้อความDirectBankHorizontalNavigationLinkProcessing (องค์ประกอบ, FormattedStringNavigationLink, StandardProcessing)
    ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank(
    NavigationLinkFormatString, การประมวลผลมาตรฐาน);
    สิ้นสุดขั้นตอน

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

    ระบบย่อย "แลกเปลี่ยนกับไซต์"

    การเปลี่ยนแปลงในโมดูล การแลกเปลี่ยนไซต์เอาชนะได้:

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

    การเปลี่ยนแปลงในโมดูล ExchangeSiteClientOverridable:

    • ขั้นตอนที่ถูกถอดออก กำหนดประเภทแคตตาล็อก GroupTableUประเภทค่าของคอลัมน์ Groups ของตาราง Product Catalog จะถูกกำหนดโดยการตั้งค่าการแลกเปลี่ยน
    • เพิ่มขั้นตอนแล้ว InputFieldOnChangeถูกเรียกให้ประมวลผลเหตุการณ์ เมื่อมีการเปลี่ยนแปลงฟิลด์ป้อนข้อมูลของแบบฟอร์มโหนดแผนการแลกเปลี่ยน เพิ่มในขั้นตอน SiteExchangeOverridden.AddNodeFormDetails
    • เพิ่มขั้นตอนแล้ว ช่องทำเครื่องหมายFieldOnChangeถูกเรียกให้ประมวลผลเหตุการณ์เมื่อมีการเปลี่ยนแปลงเขตข้อมูลค่าสถานะของโหนดแผนการแลกเปลี่ยนที่เพิ่มในขั้นตอน SiteExchangeOverridden.AddNodeFormDetails
    • เพิ่มขั้นตอนแล้ว แบบฟอร์มตารางก่อนเสร็จสิ้นการแก้ไขถูกเรียกให้ประมวลผลเหตุการณ์ BeforeFinishEdit ของเขตข้อมูลในส่วนตารางของรูปแบบของโหนดแผนการแลกเปลี่ยนที่เพิ่มในกระบวนงาน SiteExchangeOverridden.AddNodeFormDetails

    ระบบย่อย "เครือข่ายธุรกิจ"

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

    // ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์
    ElectronicInteraction.OnReceivingListTemplates (เทมเพลตงาน);

    • ในขั้นตอน เมื่อกำหนด AliasesHandlers:

    // ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์
    ElectronicInteraction.WhenDinningHandlerAliases (MatchNamesAliases);
    // สิ้นสุดการโต้ตอบทางอิเล็กทรอนิกส์

    • การเปลี่ยนแปลงในโมดูล ธุรกิจเครือข่ายเอาชนะได้:
      • เปลี่ยนชื่อขั้นตอนแล้ว รับข้อมูลติดต่อผู้ใช้ IBวี รับข้อมูลติดต่อผู้ใช้.
      • ขั้นตอนเปลี่ยนเป็นฟังก์ชัน สร้างคู่สัญญาตามรายละเอียดพารามิเตอร์บัญชีได้ถูกลบออกแล้ว

    ระบบย่อย "ข้อเสนอการค้า"

    มีการเพิ่มระบบย่อยใหม่ "ข้อเสนอการค้า" สำหรับการฝังที่คุณต้องการ:

    • พัฒนาวิธีการแทนที่ในโมดูลทั่วไป TradeOffersClientOverridable, ข้อเสนอการค้าเอาชนะได้.
    • ระบุประเภทข้อมูลตามประเภทที่กำหนด ประเภทของค่ารายละเอียด1СBusinessNetwork, ประเภทของระบบการตั้งชื่อ BED, รายละเอียดเพิ่มเติมBED, ข้อเสนอทางการค้า.

    ดูเอกสารประกอบการฝังสำหรับรายละเอียด

    เวอร์ชัน 1.3.6

    เวอร์ชัน 1.3.6 เป็นการพัฒนาเวอร์ชัน 1.3 "1C: Electronic Document Library 8" ซึ่งได้รับการออกแบบมาเพื่อให้มีการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ในโซลูชันแอปพลิเคชันที่พัฒนาบนแพลตฟอร์ม 1C:Enterprise เวอร์ชัน 8.3.8 และสูงกว่า ในกรณีนี้ คุณสมบัติการกำหนดค่า "โหมดความเข้ากันได้" จะต้องตั้งค่าเป็น "เวอร์ชัน 8.3.8"

    การกำหนดค่านี้มีไว้สำหรับใช้ร่วมกับการกำหนดค่า "1C: Library of Standard Subsystems" ไม่ต่ำกว่าเวอร์ชัน 2.3.4.112 โดยมีการกำหนดค่า "1C: Library of Internet User Support 8" ไม่ต่ำกว่าเวอร์ชัน 2.1.9.4

    คุณสมบัติใหม่และการเปลี่ยนแปลง

    • รองรับรูปแบบของเอกสารใบแจ้งหนี้หลัก (ในแง่ของการโอนเอกสารหลักแยกต่างหาก ใบแจ้งหนี้) ตามคำสั่งของ Federal Tax Service ลงวันที่ 24 มีนาคม 2016 เลขที่ ММВ-7-15/155@ “เมื่อได้รับอนุมัติจาก รูปแบบใบแจ้งหนี้และรูปแบบการนำเสนอเอกสารในการขนส่งสินค้า (การปฏิบัติงาน) การโอนสิทธิในทรัพย์สิน (เอกสารการให้บริการ) รวมถึงใบแจ้งหนี้ในรูปแบบอิเล็กทรอนิกส์”
    • รองรับรูปแบบของเอกสารหลักเกี่ยวกับการเปลี่ยนแปลงมูลค่า รวมถึงใบแจ้งหนี้การปรับปรุง (ในแง่ของการโอนเอกสารหลักแยกต่างหาก ใบแจ้งหนี้การปรับปรุง) ตามคำสั่งของ Federal Tax Service ลงวันที่ 13 เมษายน 2016 N ММВ -7-15/189@ " ในการอนุมัติรูปแบบของใบแจ้งหนี้การปรับปรุงและรูปแบบในการส่งเอกสารเกี่ยวกับการเปลี่ยนแปลงต้นทุนของสินค้าที่จัดส่ง (งานที่ทำ, การให้บริการ), โอนสิทธิในทรัพย์สินรวมถึงใบแจ้งหนี้การปรับปรุงใน แบบฟอร์มอิเล็กทรอนิกส์”
    • เพิ่มเอกสารอิเล็กทรอนิกส์ใหม่: การโอนสินค้า, การโอนผลงาน, การนำเสนอเอกสารรูปแบบใหม่
    • เพิ่มกลไกการแลกเปลี่ยนทางเดียวที่ไม่ต้องแจ้งการรับจากผู้รับ
    • เพิ่มความสามารถในการควบคุมการแกะเอกสารอิเล็กทรอนิกส์ขาเข้า (อัตโนมัติหรือด้วยตนเอง) ความสามารถในการกำหนดค่าการสร้างเอกสารประเภทเฉพาะเมื่อรับเอกสารอิเล็กทรอนิกส์
    • เพิ่มความสามารถในการเชื่อมโยงเอกสารอิเล็กทรอนิกส์กับเอกสารทางบัญชีฐานข้อมูลหลายชุด
    • มีการแบ่งเอกสารอิเล็กทรอนิกส์เข้าและออก
    • มีการนำบูรณาการเข้ากับบริการแล้ว 1C-UMIให้คุณสร้างเว็บไซต์จากโปรแกรมตั้งค่าการแลกเปลี่ยนกับร้านค้าออนไลน์ได้ ยูมิ.
    • มีการปรับเปลี่ยนสำหรับการทำงานกับบริการ 1C-EDO ในบริการคลาวด์ 1CFresh

    การเปลี่ยนไปใช้เวอร์ชัน 1.3.6 จากเวอร์ชัน 1.3.5

    ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"

    โมดูลทั่วไป ExchangewithCounterpartiesRedefinable

    • เพิ่มวิธีการ UPD SCHFDOP
    • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลผู้ซื้อ UPD Federal Tax Service. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท UPD (ข้อมูลผู้ซื้อ) ฟังก์ชัน SCHFDOP
    • เพิ่มฟังก์ชันวิธี UPD (ข้อมูลผู้ขาย) SCHFDOP ให้กับออบเจ็กต์ความปลอดภัยของข้อมูล
    • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลเพิ่มเติมของบริการภาษีของรัฐบาลกลางของผู้ขาย. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ เช่น ฟังก์ชัน STD (ข้อมูลผู้ขาย) DOP
    • เพิ่มวิธีการแล้ว ค้นหาสร้างเอกสาร UPDT เกี่ยวกับการถ่ายโอน. วิธีการนี้จะบันทึกข้อมูลจากเอกสารอิเล็กทรอนิกส์ UPD (ข้อมูลผู้ขาย) ฟังก์ชัน DOP ลงในวัตถุ IS
    • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลของ SCHFISeller Federal Tax Service. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภทฟังก์ชัน UTD (ข้อมูลผู้ขาย) SSF
    • เพิ่มวิธีการแล้ว ค้นหาสร้างUPDSInvoiceใบแจ้งหนี้. วิธีการบันทึกข้อมูลจากเอกสารอิเล็กทรอนิกส์ฟังก์ชัน UPD (ข้อมูลผู้ขาย) SSF ลงในออบเจ็กต์ความปลอดภัยของข้อมูล
    • เพิ่มวิธีการแล้ว วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท UCD (ข้อมูลผู้ขาย) ฟังก์ชัน KSCHFDIS
    • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลผู้ซื้อ UKID Federal Tax Service. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท UKD (ข้อมูลผู้ซื้อ) ฟังก์ชัน KSCHFDIS
    • เพิ่มวิธีการแล้ว วิธีการบันทึกข้อมูลจากเอกสารอิเล็กทรอนิกส์ฟังก์ชัน UCD (ข้อมูลผู้ขาย) KSCHFDIS ลงในออบเจ็กต์ความปลอดภัยของข้อมูล
    • เพิ่มวิธีการแล้ว กรอกข้อมูลเพื่อ DISInformation ของผู้ขาย Federal Tax Service. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท UCD (ข้อมูลผู้ขาย) ฟังก์ชัน DIS
    • เพิ่มวิธีการแล้ว FindCreateUKDDocumentAboutChangeValue. วิธีการนี้จะบันทึกข้อมูลจากฟังก์ชัน DIS ของเอกสารอิเล็กทรอนิกส์ UCD (ข้อมูลผู้ขาย) ลงในออบเจ็กต์ IS
    • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลของ KSCHFISeller Federal Tax Service. วิธีการเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท UCD (ข้อมูลผู้ขาย) ฟังก์ชัน KSCHF
    • เพิ่มวิธีการแล้ว ค้นหาสร้าง UKDSAccountInvoice. วิธีการนี้จะบันทึกข้อมูลจากฟังก์ชัน UCD (ข้อมูลผู้ขาย) ของเอกสารอิเล็กทรอนิกส์ KSCHF ลงในออบเจ็กต์ความปลอดภัยของข้อมูล
    • เพิ่มวิธีการแล้ว การปฏิบัติตามประเภทขาออกของ ED กับเอกสารความปลอดภัยของข้อมูล. วิธีการนี้เป็นการติดต่อระหว่างเอกสารอิเล็กทรอนิกส์ขาออกและเอกสารความปลอดภัยของข้อมูล
    • เพิ่มวิธีการแล้ว ค้นหาสร้างผลลัพธ์การโอนเอกสาร. วิธีการนี้ใช้ในการกรอกเอกสารใบตราส่งสินค้าที่ได้รับในรูปแบบ “การโอนสินค้า”
    • เพิ่มวิธีการแล้ว FindCreateDocumentการโอนสินค้า. วิธีการนี้ใช้ในการกรอกเอกสารใบรับรองการให้บริการที่ได้รับในรูปแบบการโอนผลงาน
    • เพิ่มวิธีการแล้ว ติดตั้ง StateExchange เสร็จสมบูรณ์. วิธีการนี้จะถูกเรียกเมื่อสถานะการไหลของเอกสารเปลี่ยนเป็น การแลกเปลี่ยนเสร็จสมบูรณ์, แลกเปลี่ยนเสร็จสมบูรณ์พร้อมการแก้ไข.
    • เมื่อสร้างเอกสารอิเล็กทรอนิกส์ UPD, UKD, โอนสินค้า, โอนผลงาน, รายละเอียด เอกสารวันที่, DocBaseDateจะต้องกรอก

    การประมวลผลการแลกเปลี่ยนกับคู่สัญญา

    ในเค้าโครง "Torg-12Seller":

    • เพิ่มฟิลด์ "IdStateContract"
    • เพิ่มส่วนตาราง "ใบแจ้งหนี้การขนส่ง" แล้ว
    • ฟิลด์ "Transport InvoiceDate", "Transport InvoiceNumber" ได้ถูกเอาออกแล้ว
    • เพิ่มช่อง "ข้อมูลเกี่ยวกับผู้โอนสินค้า"

    ในการจัดวาง พระราชบัญญัติการโอนสิทธิ:

    • เพิ่มส่วนตาราง "ฐาน"
    • ฟิลด์ "DocumentBaseName", "DocumentBaseNumber", "DocumentBaseDate", "DocumentBaseAdditionalInformation" ได้ถูกเอาออกแล้ว
    • เพิ่มช่อง "CurrencyName" แล้ว
    • เพิ่มช่อง "การเรียกร้อง"
    • เพิ่มช่อง "วันที่ดำเนินการ"
    • ในคุณสมบัติของผู้เข้าร่วมธุรกรรม ฟิลด์ "แฟกซ์" จะถูกแทนที่ด้วยฟิลด์ "อีเมล"
    • ในคุณสมบัติของผู้เข้าร่วมธุรกรรม ฟิลด์ "รหัสประเทศ" ได้ถูกแทนที่ด้วยฟิลด์ "รหัสประเทศ"
    • ในคุณสมบัติของผู้เข้าร่วมธุรกรรม ฟิลด์ "AddressText" ถูกแทนที่ด้วยฟิลด์ "AddressText"

    การอัปเดตประเภทที่กำหนด คู่สัญญา:

    เมื่ออัปเกรดจากเวอร์ชัน 1.3.5 จำเป็นต้องอัปเดตประเภท Counterparty ที่กำหนดไว้ มิฉะนั้น การอ้างอิงไปยังไดเรกทอรี Counterparty ในออบเจ็กต์ BED เมื่ออัปเดตจะถูกแทนที่ด้วยประเภทสตริงโดยสูญเสียการอ้างอิงไปยังออบเจ็กต์โดยไม่มีความเป็นไปได้ การกู้คืน.

    ขั้นตอนการอัปเดต:

    • เปลี่ยนชื่อประเภทบัญชีที่กำหนดเป็น AccountBED
    • ลบการกำหนดค่าออกจากการรองรับ BED 1.3.5
    • ดำเนินการเปรียบเทียบ/ผสานกับการกำหนดค่า BED 1.3.5 ตกลงที่จะตั้งค่าการกำหนดค่าให้รองรับ
    • ยกเลิกการเลือกออบเจ็กต์ทั้งหมดและปล่อยให้เหลือเฉพาะประเภทบัญชีที่กำหนดไว้ ดำเนินการผสาน
    • เริ่มการอัพเดตการกำหนดค่า เลือกไฟล์ BED 1.3.6
    • เลือกช่องทำเครื่องหมายตามประเภท AccountBED และบัญชีที่กำหนด ระบุวัตถุฐานข้อมูลที่จำเป็นอื่น ๆ สำหรับการอัพเดต
    • ดำเนินการอัปเดต

    ระบบย่อย “แลกเปลี่ยนกับธนาคาร”

    ไปจนถึงขั้นตอน รับใบแจ้งยอดธนาคารโมดูลทั่วไป แลกเปลี่ยนกับ BanksClientเพิ่มพารามิเตอร์ทางเลือก OpenFormClarificationPeriodมีประเภท บูลีน. จะต้องตั้งค่าเป็น True หากแบบฟอร์มที่ได้รับใบแจ้งยอดไม่มีความสามารถในการเปลี่ยนระยะเวลาการขอใบแจ้งยอดด้วยตนเอง

    ระบบย่อย "แลกเปลี่ยนกับไซต์"

    โหนดการแลกเปลี่ยนมีการเปลี่ยนแปลง การแลกเปลี่ยนไซต์, แบบฟอร์ม, โมดูลวัตถุ:

    • เพิ่มความสามารถในการอัปโหลดรายการโดยเลือกตามประเภทรายการ (ก่อนหน้านี้ใช้ได้เฉพาะกลุ่มรายการเท่านั้น)

    เพิ่มหนังสืออ้างอิงแล้ว เว็บไซต์:

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

    เพิ่มการประมวลผล สร้างเว็บไซต์:

    • เพิ่มความสามารถในการสร้างไซต์ในโดเมน 1C-UMI ไซต์จะถูกสร้างขึ้นโดยอัตโนมัติ (องค์ประกอบไซต์) และเต็มไปด้วยข้อมูลจาก 1C โหนดแลกเปลี่ยน ExchangeSite จะถูกสร้างขึ้นโดยอัตโนมัติ และทำการแลกเปลี่ยนแบบเต็มครั้งแรกกับไซต์

    โมดูลทั่วไป การแลกเปลี่ยนไซต์เอาชนะได้:

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

    โมดูลทั่วไป เหตุการณ์ ExchangeSite:

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

    การเปลี่ยนแปลงอื่นๆ

    การตั้งค่าระบบย่อย การจัดการภาษีในรูปแบบการให้บริการห้องสมุด เทคโนโลยีการบริการ

    ไปยังโมดูลทั่วไป การเก็บภาษีกำหนดใหม่ได้ในวิธีการเมื่อสร้างรายการบริการ () คุณต้องเพิ่มรหัสหลังจากเรียกวิธี InternetUser Support เมื่อสร้างรายการบริการ (ผู้ให้บริการ):

    // ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์
    ปฏิสัมพันธ์ทางอิเล็กทรอนิกส์เมื่อสร้างรายชื่อบริการ (ผู้ให้บริการ);
    // สิ้นสุดการโต้ตอบทางอิเล็กทรอนิกส์

    เวอร์ชัน 1.3.5

    เวอร์ชัน 1.3.5 เป็นการพัฒนาของ "1C: Electronic Document Libraries 8" เวอร์ชัน 1.3 ซึ่งได้รับการออกแบบมาเพื่อให้มีการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ในโซลูชันแอปพลิเคชันที่พัฒนาบนแพลตฟอร์ม 1C:Enterprise เวอร์ชัน 8.3.8 และสูงกว่า

    ค่าคุณสมบัติการกำหนดค่า:

    • ควรตั้งค่าโหมดความเข้ากันได้เป็น "ห้ามใช้"
    • โหมดการใช้งานแบบกิริยาสามารถตั้งค่าเป็น "ห้ามใช้"
    • โหมดความเข้ากันได้ของอินเทอร์เฟซสามารถรับค่า "เวอร์ชัน 8.2", "เวอร์ชัน 8.2 อนุญาตแท็กซี่" หรือ "แท็กซี่ อนุญาตเวอร์ชัน 8.2"

    คุณสมบัติใหม่และการเปลี่ยนแปลง

    • ฟังก์ชั่นไลบรารีได้รับการปรับให้เข้ากับคุณสมบัติเฉพาะของการทำงานบนแพลตฟอร์ม 8.3.8 โดยปิดใช้งานโหมดความเข้ากันได้
    • ระบบย่อยของ "ไลบรารีระบบย่อยมาตรฐาน" ได้รับการอัพเดตเป็นเวอร์ชัน 2.3.3.45;
    • ไลบรารีประกอบด้วยระบบย่อย "Internet User Support Libraries" เวอร์ชัน 2.1.8.3

    การเปลี่ยนไปใช้เวอร์ชัน 1.3.5 จากเวอร์ชัน 1.3.4

    ไม่จำเป็นต้องเปลี่ยนแปลง

    เวอร์ชัน 1.3.4

    เวอร์ชัน 1.3.4 เป็นการพัฒนาของ "1C: Electronic Document Libraries 8" เวอร์ชัน 1.3 ซึ่งได้รับการออกแบบมาเพื่อให้มีการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ในโซลูชันแอปพลิเคชันที่พัฒนาบนแพลตฟอร์ม 1C:Enterprise เวอร์ชัน 8.3.6 และสูงกว่า ในกรณีนี้ คุณสมบัติการกำหนดค่า "โหมดความเข้ากันได้" จะต้องตั้งค่าเป็น "ห้ามใช้" โหมดการใช้งานแบบกิริยาสามารถตั้งค่าเป็น "ห้ามใช้" และโหมดความเข้ากันได้ของอินเทอร์เฟซสามารถตั้งค่าเป็น "เวอร์ชัน 8.2", "เวอร์ชัน 8.2. อนุญาตแท็กซี่" หรือ "แท็กซี่ อนุญาตเวอร์ชัน 8.2"

    คุณสมบัติใหม่และการเปลี่ยนแปลง

    • มีการใช้ระบบการแจ้งเตือนเกี่ยวกับเหตุการณ์ EDI (เอกสารอิเล็กทรอนิกส์ใหม่ คำเชิญใหม่ การหมดอายุของใบรับรอง ฯลฯ) ตอนนี้คุณสามารถกำหนดค่าการแจ้งเตือนทางอีเมลในโปรไฟล์การตั้งค่า EDF รวมถึงแสดงการแจ้งเตือนเกี่ยวกับเหตุการณ์โดยตรงในโปรแกรม 1C โดยใช้ข้อความป๊อปอัป
    • รองรับรูปแบบของเอกสารหลัก รวมถึงใบแจ้งหนี้ (รูปแบบ UPD) ตามคำสั่งของ Federal Tax Service ลงวันที่ 24 มีนาคม 2559 เลขที่ ММВ-7-15/155@ “เมื่อได้รับอนุมัติรูปแบบใบแจ้งหนี้และ รูปแบบการส่งเอกสารเกี่ยวกับการขนส่งสินค้า ( ประสิทธิภาพการทำงาน) การโอนสิทธิในทรัพย์สิน (เอกสารเกี่ยวกับการให้บริการ) รวมถึงใบแจ้งหนี้ในรูปแบบอิเล็กทรอนิกส์";
    • รองรับรูปแบบของเอกสารเกี่ยวกับการเปลี่ยนแปลงมูลค่าซึ่งรวมถึงใบแจ้งหนี้การปรับปรุง" (รูปแบบ UKD) ตามคำสั่งของ Federal Tax Service ลงวันที่ 04/13/2016 N ММВ-7-15/189@ "ในการอนุมัติรูปแบบของใบแจ้งหนี้การปรับปรุงและเอกสารรูปแบบการนำเสนอเกี่ยวกับการเปลี่ยนแปลงต้นทุนของสินค้าที่จัดส่ง (งานที่ทำ, การให้บริการ), สิทธิในทรัพย์สินที่โอน, รวมถึงใบแจ้งหนี้การปรับปรุงในรูปแบบอิเล็กทรอนิกส์";
    • รองรับการใช้ส่วนประกอบภายนอกเพื่อแลกเปลี่ยนกับธนาคารโดยใช้เทคโนโลยี DirectBank

    การเปลี่ยนไปใช้เวอร์ชัน 1.3.4 จากเวอร์ชัน 1.3.2, 1.3.3

    การเปลี่ยนแปลงแบบฟอร์มรายการเอกสารโซลูชันแอปพลิเคชัน

    ในแบบฟอร์มรายการเอกสาร คุณต้องเพิ่มขั้นตอนปลั๊กอิน แลกเปลี่ยนกับ CounterpartiesClient กำลังรอโปรเซสเซอร์ EDW:

    &บนไคลเอนต์

    สิ้นสุดขั้นตอน

    เมื่ออัพเดตระบบย่อย จำเป็นในตัวจัดการเหตุการณ์ของแบบฟอร์มรายการเอกสาร: เมื่อ CreateOnServer, เมื่อเปิด, การแจ้งเตือนการประมวลผล

    &บนเซิร์ฟเวอร์
    ขั้นตอนเมื่อสร้างบนเซิร์ฟเวอร์

    ParametersWhenCreatedOnServer = ExchangeWithCounterparties.ParametersWhenCreatedOnServer_ListForm();
    ParametersWhenCreatedOnServer.Form = ThisObject;
    ParametersWhenCreatedOnServer.LocationofCommands = คำสั่ง Elements.EDO;
    ExchangewithCounterparties.WhenCreatedOnServer_ListForm (ความล้มเหลว การประมวลผลมาตรฐาน พารามิเตอร์เมื่อสร้างบนเซิร์ฟเวอร์);
    สิ้นสุดขั้นตอน

    &บนไคลเอนต์
    ขั้นตอนการเปิด (ล้มเหลว)

    // ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
    // สิ้นสุดระบบย่อย "Counterparty Exchange"
    สิ้นสุดขั้นตอน

    &บนไคลเอนต์
    การแจ้งเตือนกระบวนการขั้นตอน (ชื่อเหตุการณ์, พารามิเตอร์, แหล่งที่มา)

    // ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
    พารามิเตอร์การแจ้งเตือนEDO = แลกเปลี่ยนกับ CounterpartiesClient.AlertParametersEDO_ListForm();
    พารามิเตอร์การแจ้งเตือน EDO.Form = ThisObject;
    พารามิเตอร์การแจ้งเตือน EDO.DynamicListName = "รายการ";
    ExchangewithCounterpartiesClient.ProcessingAlert_ListForm (ชื่อเหตุการณ์ พารามิเตอร์ แหล่งที่มา EDI AlertParameters);
    // สิ้นสุดระบบย่อย "Counterparty Exchange"
    สิ้นสุดขั้นตอน

    การเปลี่ยนแปลงแบบฟอร์มเอกสารการแก้ปัญหาการสมัคร

    ในแบบฟอร์มเอกสาร คุณต้องเพิ่มขั้นตอนปลั๊กอิน Connectable_WaitingHandlerEDOโดยที่คุณต้องทำการเรียกเมธอด

    แลกเปลี่ยนกับคู่ค้าไคลเอนต์ กำลังรอตัวประมวลผล EDW:

    &บนไคลเอนต์
    ขั้นตอน Connectable_EDOWaitingHandler()
    ExchangeCounterpartiesClient.EDOWaitingHandler (ThisObject);
    สิ้นสุดขั้นตอน

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

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

    ตัวอย่างเช่น:

    &บนเซิร์ฟเวอร์
    ขั้นตอนเมื่อ CreateOnServer (ล้มเหลว, การประมวลผลมาตรฐาน)

    // ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
    พารามิเตอร์ EDO เมื่อสร้าง = แลกเปลี่ยนกับคู่สัญญา พารามิเตอร์เมื่อสร้างบน Server_DocumentForm();
    พารามิเตอร์ EDO เมื่อสร้างแล้วForm = ThisObject;
    พารามิเตอร์ EDO เมื่อสร้าง DocumentLink = Object.Link;
    พารามิเตอร์ EDO เมื่อ Create.DecorationStateEDO = Elements.DecorationStateEDO;
    พารามิเตอร์ EDO เมื่อสร้างขึ้น กลุ่มรัฐ EDO = กลุ่มรัฐ Elements.EDO;
    แลกเปลี่ยนกับคู่สัญญาเมื่อสร้างขึ้นบน Server_DocumentForm (การปฏิเสธ, การประมวลผลมาตรฐาน, พารามิเตอร์ EDO เมื่อสร้าง);
    // สิ้นสุดระบบย่อย "Counterparty Exchange"
    สิ้นสุดขั้นตอน

    &บนไคลเอนต์
    ขั้นตอนการเปิด (ล้มเหลว)

    // ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
    ExchangeWithCounterpartiesClient.OnOpening (ThisObject);
    // สิ้นสุดระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
    สิ้นสุดขั้นตอน

    &บนเซิร์ฟเวอร์
    ขั้นตอน AfterRecordOnServer (CurrentObject, RecordParameters)

    // ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
    ParametersAfterRecord = ExchangeWithCounterparties.ParametersAfterRecordOnServer();
    ParametersAfterRecord.Form = ThisObject;
    พารามิเตอร์AfterRecord.DocumentLink = Object.Link;
    ParametersAfterRecording.DecorationStateEDO = Elements.DecorationStateEDO;
    ParametersAfterRecord.GroupEDOStatus = Elements.GroupEDOState;
    แลกเปลี่ยนกับคู่ค้า AfterRecordOnServer (CurrentObject, RecordParameters, AfterRecordParameters);
    // สิ้นสุดระบบย่อย "Counterparty Exchange"
    สิ้นสุดขั้นตอน

    &บนไคลเอนต์
    การแจ้งเตือนกระบวนการขั้นตอน (ชื่อเหตุการณ์, พารามิเตอร์, แหล่งที่มา)

    // ระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"
    พารามิเตอร์การแจ้งเตือน = ExchangewithCounterpartiesClient.AlertParametersEDO_DocumentForm();
    AlertParameters.Form = ThisObject;
    AlertParameters.DocumentLink = Object.Link;
    พารามิเตอร์การแจ้งเตือน.DecorationEDO State = Elements.DecorationEDO State;
    พารามิเตอร์การแจ้งเตือน กลุ่มสถานะ EDO = กลุ่มสถานะ Elements.EDO;
    ExchangeWithCounterpartiesClient.ProcessingAlert_DocumentForm (ชื่อเหตุการณ์ พารามิเตอร์ แหล่งที่มา พารามิเตอร์การแจ้งเตือน);
    // สิ้นสุดระบบย่อย "Counterparty Exchange"
    สิ้นสุดขั้นตอน

    การเปลี่ยนแปลงในโมดูล ExchangeCounterpartys

    • เพิ่มขั้นตอนแล้ว เมื่อ CreateOnServer_ListFormเรียกจากตัวจัดการเหตุการณ์ "เมื่อ CreateOnServer" ของแบบฟอร์มรายการเอกสาร เนื่องจากเป็นพารามิเตอร์ตัวที่สามของเมธอด โครงสร้างจะถูกส่งผ่านซึ่งเตรียมใช้งานโดยเมธอด พารามิเตอร์เมื่อสร้างOnServer_ListForm.
    • เพิ่มขั้นตอนแล้ว เมื่อ CreateOnServer_FormDocumentเรียกจากตัวจัดการเหตุการณ์ "เมื่อ CreateOnServer" ของแบบฟอร์มเอกสาร เนื่องจากเป็นพารามิเตอร์ตัวที่สามของเมธอด โครงสร้างจะถูกส่งผ่านซึ่งเตรียมใช้งานโดยเมธอด พารามิเตอร์เมื่อสร้างOnServer_DocumentForm.
    • เพิ่มขั้นตอนแล้ว หลังจากบันทึกบนเซิร์ฟเวอร์เรียกจากตัวจัดการเหตุการณ์ "AfterRecordOnServer" ของแบบฟอร์มเอกสาร เนื่องจากเป็นพารามิเตอร์ตัวที่สามของเมธอด โครงสร้างจะถูกส่งผ่านซึ่งเตรียมใช้งานโดยเมธอด พารามิเตอร์ AfterRecordingOnServer.

    การเปลี่ยนแปลงในโมดูล แลกเปลี่ยนกับคู่ค้าลูกค้า.

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

    // จัดเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภทการโอนสินค้าไปยังผู้ขาย
    // ตัวเลือก:
    // LinkToObject - ลิงก์ไปยัง ED ซึ่งจำเป็นในการสร้างเอกสารอิเล็กทรอนิกส์


    ขั้นตอนการกรอกข้อมูลผู้ดำเนินการถ่ายโอนข้อมูล (ลิงก์ออบเจ็กต์, โครงสร้าง ED, ทรีข้อมูล) ส่งออก
    กรอกข้อมูลสำหรับ Act 501 ผู้ดำเนินการของ Federal Tax Service (ลิงก์ไปยังวัตถุ โครงสร้าง ED แผนผังข้อมูล)
    สิ้นสุดขั้นตอน

    • วิธี ตรวจสอบความสามารถในการแก้ไขวัตถุกลายเป็นขั้นตอน
    • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับ UPDInformation ของบริการภาษีของรัฐบาลกลางของผู้ขาย. วิธีการจัดเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท รปภ(ข้อมูลผู้ขาย) ฟังก์ชั่น สคฟดอป.
    • เพิ่มวิธีการแล้ว ค้นหาสร้างเอกสารโอนสากล. วิธีการนี้จะบันทึกข้อมูลจากเอกสารอิเล็กทรอนิกส์ รปภ(ข้อมูลผู้ขาย) ฟังก์ชั่น SCHFDOPvวัตถุไอเอส
    • เพิ่มวิธีการแล้ว กรอกข้อมูลสำหรับข้อมูลผู้ขาย UKDI Federal Tax Service. วิธีการจัดเตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภท สหราชอาณาจักร(ข้อมูลผู้ขาย) ฟังก์ชั่น กสชฟดีส.
    • เพิ่มวิธีการแล้ว FindCreateUniversalAdjustmentDocument. วิธีการนี้จะบันทึกข้อมูลจากเอกสารอิเล็กทรอนิกส์ สหราชอาณาจักร(ข้อมูลผู้ขาย) ฟังก์ชั่น กสชฟดีสไปยังวัตถุความปลอดภัยของข้อมูล

    การเปลี่ยนแปลงในระบบย่อย "แลกเปลี่ยนกับธนาคาร"

    การเปลี่ยนแปลงในโมดูล ExchangeWithBanksRedefinable

    ขั้นตอน เมื่อเงื่อนไข ED เปลี่ยนแปลงเพิ่ม เรียกว่าเมื่อสถานะการไหลของเอกสารอิเล็กทรอนิกส์เปลี่ยนแปลง

    การเปลี่ยนแปลงการทำงานในโหมดบริการ

    หากจำเป็นต้องมีการกำหนดค่าปลายทางสำหรับการทำงานในโหมดบริการ:

    • ในขั้นตอน GetProvidedDataHandlers ของโมดูลทั่วไป SuppliedDataOverridden ให้เพิ่มรหัสต่อไปนี้:

    ElectronicInteraction.RegisterDeliveredDataHandlers (ตัวจัดการ);

    • เพิ่มงานประจำ Update External Modules Exchange With Banks ให้กับแอตทริบิวต์ทั่วไป Data Area Basic Data

    การเปลี่ยนแปลงอื่นๆ

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

    เวอร์ชัน 1.3.3

    เวอร์ชัน 1.3.3 เป็นการพัฒนาผลิตภัณฑ์ "1C: Library of Electronic Documents" รุ่น 1.3 ออกแบบมาเพื่อการพัฒนาการกำหนดค่าที่ออกแบบมาเพื่อทำงานบนแพลตฟอร์ม 1C:Enterprise 8.3 เวอร์ชัน 8.3.6 และสูงกว่า

    ค่าคุณสมบัติการกำหนดค่า:

    • ควรตั้งค่าโหมดความเข้ากันได้เป็น "ห้ามใช้"
    • โหมดการใช้งานแบบกิริยาสามารถตั้งค่าเป็น "ห้ามใช้"
    • โหมดความเข้ากันได้ของอินเทอร์เฟซสามารถรับค่า "เวอร์ชัน 8.2", "เวอร์ชัน 8.2 อนุญาตแท็กซี่" หรือ "แท็กซี่ อนุญาตเวอร์ชัน 8.2"

    คุณสมบัติใหม่และการเปลี่ยนแปลง

    • ตามคำสั่งลงวันที่ 30 พฤศจิกายน 2558 เลขที่ ММВ-7-10/551@ "การอนุมัติรูปแบบการยื่นเอกสารการโอนสินค้าระหว่างธุรกรรมทางการค้าในรูปแบบอิเล็กทรอนิกส์" และคำสั่ง ลงวันที่ 30 พฤศจิกายน 2558 เลขที่ ММВ-7-10/552@ "เมื่อได้รับอนุมัติรูปแบบการส่งเอกสารการโอนผลงาน (เอกสารการให้บริการ) ในรูปแบบอิเล็กทรอนิกส์" รองรับเอกสารอิเล็กทรอนิกส์รูปแบบใหม่

    การเปลี่ยนไปใช้เวอร์ชัน 1.3.2.19 จากเวอร์ชัน 1.2.7, 1.3.1

    การเปลี่ยนแปลงในระบบย่อย "แลกเปลี่ยนกับคู่สัญญา"

    ในโมดูล แลกเปลี่ยนกับคู่สัญญาเอาชนะได้ทำการเปลี่ยนแปลง:

    // เตรียมข้อมูลสำหรับเอกสารอิเล็กทรอนิกส์ประเภทใบตราส่ง
    // ตัวเลือก:
    // LinkOnED - ลิงก์ไปยัง ED ซึ่งจำเป็นในการสร้างเอกสารอิเล็กทรอนิกส์
    // StructureED - โครงสร้างโครงสร้างข้อมูลสำหรับการสร้างเอกสารอิเล็กทรอนิกส์
    // Data Tree - แผนผังแห่งค่า, แผนผังข้อมูลสำหรับการกรอกเอกสารอิเล็กทรอนิกส์
    ขั้นตอนการกรอกข้อมูลการโอนข้อมูลสินค้าไปยังผู้ขาย (Link to Volume

    เพื่อนร่วมงาน!

    ในการกำหนดค่าบางอย่าง ข้อผิดพลาดไม่สามารถทำให้สามารถดาวน์โหลดข้อมูลได้ ดังนั้นจึงสามารถส่งรายงานไปยัง Federal Tax Service ได้

    การจัดการกับคู่สัญญา - เหตุใดการตรวจสอบ TIN/KPP จึงไม่ผ่าน - เป็นกระบวนการที่ยาวนาน และบ่อยครั้งคุณเพียงแค่ต้องถ่ายโอนข้อมูลไปยัง Federal Tax Service และจัดเตรียมใบรับรองเกี่ยวกับคู่สัญญาในกรณีที่มีคำถาม เพื่อให้ สามารถจัดการได้เอง แทนที่จะพยายามแก้ไขปัญหานี้ด้วยตัวเอง และรับค่าปรับจากการรายงานล่าช้า

    ตอนนี้เราจะมุ่งเน้นไปที่เทคนิคบางอย่างในการออกจากสถานการณ์ดังกล่าวโดยใช้ตัวอย่างของการกำหนดค่า 1C: การบัญชี 8th ed. 3.0.

    ดังนั้นเคล็ดลับหมายเลข 1:การตรวจสอบคู่สัญญาในตัวในการบัญชี 8 ใช้งานได้กับคู่สัญญาที่มี TIN/KPP เท่านั้น หากคุณลบ TIN/KPP ออกจากคู่สัญญาที่ไม่ผ่านการตรวจสอบ จะไม่มีข้อความแสดงข้อผิดพลาด มันถูกแยกออกจากการพิจารณาในโมดูลการตรวจสอบความถูกต้องของรายงาน

    เคล็ดลับที่ 2: เมื่อตรวจสอบคู่สัญญา การลงทะเบียนข้อมูลพิเศษจะถูกกรอก: "สถานะของคู่สัญญา" นี่คือสิ่งที่คุณต้องทำงานด้วย

    เราจะพิจารณาตัวเลือกนี้โดยใช้ตัวอย่างฐานการฝึกอบรม เรามีรายชื่อคู่สัญญาที่ไม่ได้รับการยืนยัน:

    โปรแกรมรายงานว่าสถานะของคู่สัญญา Camellia “KPP ไม่สอดคล้องกับข้อมูลในฐานข้อมูล Federal Tax Service” คู่สัญญาดังกล่าวจะไม่ผ่านการตรวจสอบและโปรแกรมจะไม่อนุญาตให้คุณดาวน์โหลดรายงาน VAT ที่มีคู่สัญญาดังกล่าว

    สิ่งที่สามารถทำได้?

    เราเปิดการลงทะเบียนข้อมูล "สถานะของคู่สัญญา" - Ch. เมนู - ฟังก์ชั่นทั้งหมด - การลงทะเบียนข้อมูล:

    ในการลงทะเบียนข้อมูล "สถานะผู้รับเหมา" ให้วางเคอร์เซอร์บนบรรทัดที่มีคู่สัญญาที่ต้องการ:

    และเราเปลี่ยนสถานะการตรวจสอบจาก “จุดตรวจไม่สอดคล้องกับข้อมูล Federal Tax Service” เป็น “คู่สัญญาอยู่ในฐานข้อมูล Federal Tax Service”

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

    การอภิปรายเกี่ยวกับการเปลี่ยนไปใช้ BED เกิดขึ้นมาระยะหนึ่งแล้วในระดับรัฐ - อย่างแข็งขันมาตั้งแต่ปี 2551 แต่กระบวนการนี้มีความไดนามิกและประสบความสำเร็จเพียงใด เหตุใดผลลัพธ์วันนี้จึงแตกต่างจากที่คาดการณ์ไว้เมื่อ 7-10 ปีที่แล้ว? หากต้องการคำตอบสำหรับคำถามเหล่านี้ เราได้ติดต่อผู้เชี่ยวชาญ - ผู้พัฒนาเครื่องมือ EDMS/ECM และผู้ที่เกี่ยวข้องกับการใช้งานและการทำงานของระบบดังกล่าว

    การเปลี่ยนมาใช้ BED มีความเกี่ยวข้องอย่างไร

    Oleg Beilezon หัวหน้าฝ่ายปฏิบัติการ Alfresco ของ Business Logic (IT Group) กล่าวว่าหัวข้อนี้มีความเกี่ยวข้องมากขึ้นเรื่อยๆ สำหรับลูกค้าประเภทต่างๆ ทั้งองค์กรเชิงพาณิชย์และภาครัฐ ทุกคนจมอยู่ในกองกระดาษอย่างแท้จริง - นี่กำลังกลายเป็นปัญหาทางกายภาพ เดสก์ท็อปและตู้ของพนักงานหลายคนเกลื่อนไปด้วยเอกสารที่ผ่านการตรวจสอบ ตกลง ลงนาม จัดเก็บ และ "การรายงานภาษี" และกลายเป็นเรื่องยากมากขึ้นเรื่อยๆ เพื่อจัดการพวกเขา ในความเห็นของเขาหน่วยงานกำกับดูแลของรัฐบาลหลายแห่ง (เช่น Federal Tax Service) ได้ตระหนักถึงสิ่งนี้ดังนั้นพวกเขาจึงแนะนำให้เปลี่ยนมาใช้การหมุนเวียนเอกสารทางการแบบไร้กระดาษแม้กระทั่งข้อกำหนดบังคับก็ตาม

    ในทางกลับกัน Elena Ivanova หัวหน้าฝ่ายการตลาดของบริษัท EOS ตั้งข้อสังเกตว่าแม้ว่าการเปลี่ยนไปใช้การรับส่งเอกสารแบบไร้กระดาษช่วยให้องค์กรต่างๆ สามารถลดต้นทุนและเพิ่มประสิทธิภาพของกระบวนการทางธุรกิจของตนได้ แต่ก็ต้องคำนึงว่าการเปลี่ยนแปลงดังกล่าวจำเป็นต้องมี ต้นทุนบางอย่างที่เกี่ยวข้องกับการนำโซลูชันทางเทคโนโลยีไปใช้ การเปลี่ยนแปลงกฎระเบียบ การลดความเสี่ยงที่เกิดจากการใช้เอกสารอิเล็กทรอนิกส์ โดยทั่วไป สถานการณ์จะชัดเจน: ยิ่งมีการไหลของเอกสารที่เป็นกระดาษมากขึ้นเท่าไร ปัญหาการแลกเปลี่ยนแบบไร้กระดาษก็จะยิ่งกดดันมากขึ้นเท่านั้น เธอมองเห็นความจำเป็นในค่าใช้จ่ายเพิ่มเติม “ในขณะนี้” และความเต็มใจของพนักงานที่จะละทิ้งกระบวนการและคุณลักษณะตามปกติของเอกสารกระดาษ เนื่องจากอุปสรรคหลักที่ทำให้การเปลี่ยนแปลงดังกล่าวช้าลง แต่นักพัฒนาซอฟต์แวร์ก็มีเครื่องมือที่สามารถเอาชนะความท้าทายในการนำไปใช้ได้

    อย่างไรก็ตาม ขณะนี้ ในสภาวะวิกฤตเศรษฐกิจที่ยืดเยื้อ ไม่ใช่ทุกบริษัทที่พร้อมที่จะทำเช่นนี้ Dmitry Shmailov หัวหน้าแผนกพัฒนาโซลูชัน ECM ของ ELAR Corporation กล่าว นอกจากนี้ BED ไม่ได้มีความสำคัญสำหรับธุรกิจ เช่น ระบบอัตโนมัติในการผลิต โซลูชันสำหรับงานที่สำคัญ และระบบที่มุ่งลดต้นทุน เช่น โครงการที่สามารถนำเงินมาได้

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

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

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

    เมื่อพูดถึงเรื่องนี้ Ernest Kolesnikov รองผู้อำนวยการฝ่ายการตลาดของ Taxkom อ้างถึงการคาดการณ์ของนักวิเคราะห์: ภายในปี 2560 การใช้กลไก EDI กับคู่ค้าจะสูงถึง 22.5% ตอนนี้ หลังจากการแนะนำการคืนภาษีมูลค่าเพิ่มใหม่ (ผู้เสียภาษีเกือบทั้งหมดต้องยื่นแบบอิเล็กทรอนิกส์) ปัญหาของเอกสารอัตโนมัติมีความเกี่ยวข้องเป็นพิเศษ เนื่องจากการป้อนข้อมูลด้วยตนเอง การบัญชีมีแนวโน้มสูงที่จะได้รับคำขออัตโนมัติสำหรับความคลาดเคลื่อนกับคู่สัญญา . นอกจากนี้เขายังเตือนด้วยว่าบทที่ 49.1 ของประมวลกฎหมายแรงงานของสหพันธรัฐรัสเซียอนุญาตให้ใช้ EDI เมื่อทำงานจากระยะไกล และตั้งแต่วันที่ 1 กรกฎาคม 2016 การแก้ไขกฎหมายของรัฐบาลกลาง "ในบริษัทร่วมหุ้น" จะมีผลบังคับใช้ ซึ่งจะช่วยให้ผู้ถือหุ้น เพื่อเข้าร่วมการประชุมจากระยะไกลโดยใช้ EDI

    Artem Tanan ผู้จัดการโครงการสำหรับ Electronic Document Exchange ที่ 1C มั่นใจว่าแรงจูงใจหลักในการเปลี่ยนมาใช้ BED คือความปรารถนาของบริษัทต่างๆ ที่จะเพิ่มขีดความสามารถในการแข่งขัน ผู้ที่ต้องการเป็นผู้นำในตลาดเริ่มเตรียมตัวสำหรับการเปลี่ยนแปลงดังกล่าวมานานก่อนที่จะได้รับอนุญาตจากกฎหมาย และเป็นคนแรกที่เชี่ยวชาญโอกาสเหล่านี้ในทางปฏิบัติ ย้อนกลับไปในปี 2556–2557 บริษัทจากอุตสาหกรรมเทคโนโลยีที่มีการแข่งขันสูงเริ่มใช้วิธีการโต้ตอบทางอิเล็กทรอนิกส์กับคู่ค้า เช่น เครือข่ายการค้าปลีก ผู้จัดจำหน่าย ผู้ประกอบการโทรคมนาคม ฯลฯ สิ่งนี้ทำให้พวกเขาได้รับผลที่ครอบคลุม: จากการเร่งการคืน VAT และการลดความเสี่ยงทางภาษีไปจนถึงการเพิ่มประสิทธิภาพ ต้นทุนและเพิ่มประสิทธิภาพของการโต้ตอบกับคู่สัญญา ภายใต้แรงกดดันจากบริษัทจัดหาสินค้า คู่ค้าก็เริ่มเปลี่ยนมาใช้ BED ในปี 2558 กระบวนการนี้แพร่หลายมากขึ้นซึ่งได้รับการอำนวยความสะดวกจากการพัฒนากฎหมายและการเกิดขึ้นของข้อกำหนดด้านกฎระเบียบใหม่หลายประการสำหรับการยื่นรายงานภาษี ในช่วงไม่กี่ปีที่ผ่านมา จำนวนผู้ใช้ที่เชื่อมต่อกับบริการเพิ่มขึ้นอย่างมาก

    การฝึกปฏิบัติการเปลี่ยนผ่านสู่การจัดการเอกสารอิเล็กทรอนิกส์แบบไร้กระดาษ

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

    “เมื่อพูดถึงการเปลี่ยนไปใช้ต้นฉบับอิเล็กทรอนิกส์ บริษัทต่างๆ จะเริ่มต้นด้วยคำว่า 'เราต้องการ' ตามด้วย 'แต่...'” Oleg Beilezon ตั้งข้อสังเกต “แล้วก็มีเหตุผลที่สามารถเอาชนะได้ไม่มากก็น้อย: บางหน่วยไม่พร้อม, งบประมาณไม่ได้รับการจัดสรร, เราไม่สามารถทำลายประเพณีขององค์กรได้ ฯลฯ” แต่โดยทั่วไป เขาเชื่อว่าแนวโน้มไปสู่ระบบอิเล็กทรอนิกส์ของการไหลของเอกสารนั้นมองเห็นได้ค่อนข้างดี หากเพียงเพราะมีโครงการสำหรับการเปลี่ยนผ่านสู่เทคโนโลยีไร้กระดาษ แต่ยังไม่มีการได้ยินเกี่ยวกับโครงการสำหรับการเปลี่ยนผ่านแบบย้อนกลับ BED ครอบคลุมประเด็นต่างๆ มากมาย ได้แก่ EDMS แบบคลาสสิก การรับส่งเอกสารทางการเงินขององค์กร และการหมุนเวียนเอกสารทางการเงินที่มีนัยสำคัญทางกฎหมาย การไหลของเอกสารขององค์กรและการบริหารที่มีนัยสำคัญทางกฎหมายค่อนข้างหยุดชะงัก - มีรายละเอียดปลีกย่อยทางกฎหมายมากเกินไป และแนวทางปฏิบัติที่เพียงพอยังไม่ได้รับการพัฒนา การจัดเก็บทางอิเล็กทรอนิกส์และการประมวลผลเอกสารที่มีการจำแนกประเภทการเข้าถึงที่หลากหลายนั้นยังล่าช้ากว่านั้นอีก เนื่องจาก (โดยทั่วไปสมเหตุสมผลแล้ว) มีการกำหนดข้อกำหนดที่ค่อนข้างเข้มงวดกับระบบที่นำเอกสารเหล่านั้นไปใช้

    Maxim Kainer นักวิเคราะห์ธุรกิจของ Directum กล่าวว่าเมื่อใช้ EDMS/ECM การประหยัดในการพิมพ์กระดาษทำได้ผ่านกระบวนการอัตโนมัติเท่านั้น แต่กลับกลายเป็นว่าปริมาณการพิมพ์ทั้งหมดทั่วทั้งองค์กรสามารถเพิ่มขึ้นได้ นอกจากนี้ ระบบอัตโนมัติของกระบวนการทางธุรกิจเฉพาะผ่าน ECM ในกรณีน้อยกว่า 10% ช่วยให้คุณหลีกเลี่ยงการพิมพ์เอกสารแม้อยู่ในกระบวนการนี้ โดยทั่วไป เขาเชื่อว่าจนถึงขณะนี้ยังไม่มีการพูดถึงองค์กรต่างๆ ที่เปลี่ยนไปใช้การรับส่งเอกสารแบบไร้กระดาษ

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

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

    “การเปลี่ยนผ่านสู่เทคโนโลยีไร้กระดาษกำลังกลายเป็นเรื่องธรรมดาและได้รับแรงผลักดันจากความต้องการด้านการผลิต การทำงานโดยไม่ใช้กระดาษนั้นให้ผลกำไร” Dmitry Shmailov เห็นด้วย - BED มีความเกี่ยวข้องอย่างมากกับการรับส่งเอกสารภายในองค์กร ทุกวันนี้ เมื่อเอกสารอิเล็กทรอนิกส์ค่อยๆ ได้รับสถานะทางกฎหมาย การทำงานใน EDMS กับคู่สัญญาก็กลายเป็นเรื่องปกติไปแล้ว” แต่ในขณะเดียวกัน เขาตั้งข้อสังเกตว่าในองค์กรที่ใช้ระบอบการปกครองพิเศษ เอกสารที่เป็นความลับของรัฐหรือทางการค้าหรือมีคุณค่าโดยเฉพาะจะยังคงจัดเก็บไว้ในกระดาษ การเปลี่ยนมาใช้ BED สำหรับเอกสารดังกล่าวเป็นไปไม่ได้หรือเกี่ยวข้องกับการรับรองความปลอดภัยระดับสูงสุด ซึ่งมีราคาแพง ยาก และมักจะไม่สมเหตุสมผลกับต้นทุน

    จากข้อมูลของ Ernest Kolesnikov การแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์กับคู่สัญญากำลังผ่านขั้นตอนของการเปลี่ยนแปลงจากสถานะตัวอ่อนไปสู่สถานะที่เป็นผู้ใหญ่มากขึ้น ในตอนแรกผู้ดำเนินการ EDF เลือกกลยุทธ์ในการดึงดูดบริษัทที่ใหญ่ที่สุด - ผู้กำเนิดการรับส่งข้อมูล ในภาคธุรกิจหลัก การแลกเปลี่ยนเอกสารในรูปแบบอิเล็กทรอนิกส์กำลังกลายเป็นเรื่องธรรมดา ในส่วนอื่น ๆ โครงการนำร่องกำลังดำเนินการอยู่ กระบวนการนี้ได้รับการกระตุ้นอย่างมาก และบางครั้งก็เริ่มต้นโดยการกระทำของหน่วยงานกำกับดูแลด้วยซ้ำ กรณีทั่วไปสำหรับระบบอัตโนมัติคือกลุ่มของบริษัทที่มีการถือครองเดียวกันซึ่งมีการกระจายอาณาเขตทั่วประเทศ โดยที่เอกสารส่วนใหญ่จะถูกแปลงเป็นรูปแบบอิเล็กทรอนิกส์และรับประกันผลทางการเงินสูงสุด ในเวลาเดียวกัน ผู้เชี่ยวชาญตั้งข้อสังเกตถึงประเด็นสำคัญ: “ส่วนใหญ่ขึ้นอยู่กับวิธีการบัญชีในบริษัท หากทุกอย่างเป็นไปตามกฎหมาย ก็ยินดีต้อนรับความโปร่งใสที่เพิ่มขึ้น แต่ถ้าสถานการณ์ตรงกันข้าม มันจะทำหน้าที่เป็นเครื่องมือในการฟื้นฟูความสงบเรียบร้อย แต่นี่ไม่ใช่กระบวนการที่รวดเร็ว”

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

    อุปสรรคระหว่างทางไป BED

    ไม่กี่ปีที่ผ่านมาคำตอบหลักสำหรับคำถามนี้คือวิทยานิพนธ์เรื่อง "ความไม่พร้อมของกรอบการกำกับดูแลและกฎหมาย" แต่ตอนนี้ผู้เชี่ยวชาญเมื่อพูดถึงปัญหานี้ไม่ได้วางไว้เป็นอันดับแรก “องค์กรต่างๆ ไม่สนใจที่จะเลิกใช้กระดาษ” Maxim Kainer กล่าว - ค่าใช้จ่ายในการพิมพ์และทำงานกับเอกสารที่เป็นกระดาษไม่มากนักจนถือว่าได้ประโยชน์ ระบบ ECM ไม่ได้ถูกนำมาใช้เพื่อเปลี่ยนไปใช้การไหลของเอกสารแบบไร้กระดาษ แต่เพื่อให้ได้รับผลอื่นๆ ที่เป็นรูปธรรมและชัดเจนมากขึ้น: ความโปร่งใสของกระบวนการและการเร่งความเร็ว การลดความเสี่ยง ฯลฯ นอกจากนี้ บางครั้งการแปลงกระบวนการให้เป็นรูปแบบอิเล็กทรอนิกส์ก็ไม่สมเหตุสมผล รวมถึงเนื่องจากใบรับรองลายเซ็นอิเล็กทรอนิกส์มีราคาค่อนข้างสูง” ในเวลาเดียวกัน เขายังตั้งข้อสังเกตถึงข้อบกพร่องของกรอบการกำกับดูแล - ความคลุมเครือของสูตรจำนวนหนึ่งและลักษณะการให้คำปรึกษาทั่วไป ปล่อยให้ทางเลือกแก่องค์กรที่อาจไม่ต้องการเปลี่ยนแปลงรูปแบบการทำงานที่ได้รับการพิสูจน์แล้ว ในเวลาเดียวกัน เขามั่นใจว่าไม่ควรกำหนดแนวทางใหม่อย่างรุนแรง เนื่องจากในบริษัทส่วนใหญ่ แนวทางดังกล่าวจะต้องมีการเปลี่ยนแปลงในระดับโครงสร้างพื้นฐานด้านไอที

    เมื่อพูดถึงปัญหาของกรอบกฎหมาย Elena Ivanova ดึงความสนใจไปที่ความจริงที่ว่าประเด็นด้านกฎระเบียบหลายประการเป็นความรับผิดชอบขององค์กรเอง “ในหลาย ๆ ด้าน เจตจำนงของฝ่ายบริหารมีบทบาทในการพัฒนา BED” เธอมั่นใจ - หากผู้จัดการสั่งให้ทำงานโดยไม่ใช้กระดาษ ทุกคนก็จะทำ ไม่ว่าพวกเขาต้องการหรือไม่ก็ตาม หากไม่มีการดำเนินการจูงใจดังกล่าวในส่วนของฝ่ายบริหารในองค์กร ก็หมายความว่าพวกเขาไม่เห็นความเป็นไปได้ทางเศรษฐกิจและผลกระทบใน BEA นอกจากนี้ยังมีปัญหาการขาดแคลนบุคลากรที่สามารถทำหน้าที่เป็นตัวขับเคลื่อนกระบวนการดำเนินการ BED และถ่ายทอดความพึงพอใจทั้งหมดให้กับผู้จัดการ”

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

    Ernest Kolesnikov ถอดความจากคำพูดที่รู้จักกันดี โดยตั้งชื่อปัญหาหลักสองประการในการจัดการเอกสารอิเล็กทรอนิกส์ของรัสเซีย ได้แก่ กฎหมายและประชาชน “ยังมีช่องว่างในกฎหมาย เช่น รูปแบบได้รับการอนุมัติสำหรับเอกสารเพียงไม่กี่ฉบับ ในขณะที่งานประเภทอื่นๆ อยู่ระหว่างดำเนินการ ในอนาคตอันใกล้นี้ควรอนุมัติรูปแบบของเอกสารการโอนสากลมีการพูดถึงคอนเทนเนอร์สากลที่สามารถแนบเอกสารใดก็ได้ แนวทางปฏิบัติด้านตุลาการในการใช้เอกสารที่ไม่เป็นทางการยังไม่เพียงพอสำหรับทุกบริษัทที่จะเปลี่ยนมาใช้ EDI โดยไม่ต้องกลัว แต่เวลาผ่านไปและสถานการณ์กำลังเปลี่ยนแปลงไปในทางที่ดีขึ้น ปัญหาสำคัญประการที่สองคือผู้คนและความเป็นจริงของชีวิต เรามักจะได้ยินจากลูกค้าว่า เราจะปฏิเสธกระดาษก็ต่อเมื่อพวกเขาบังคับเรา”

    เพื่อแนะนำเทคโนโลยีใหม่ภายในกรอบของกระบวนการที่มีอยู่นั้น ส่วนใหญ่ต้องมีการฝึกอบรมบุคลากรใหม่และความปรารถนาของฝ่ายบริหารของบริษัทในการใช้นวัตกรรม แต่โดยพื้นฐานแล้วกระบวนการยังคงเหมือนเดิม Artem Tanan กล่าว เขาให้คำแนะนำเฉพาะ: ในการดำเนินการ BED คุณควรแต่งตั้งผู้รับผิดชอบและปฏิบัติงานหลักสามประการ - สร้างขั้นตอนใหม่ในการทำงานกับเอกสาร ฝึกอบรมพนักงาน และกำหนดกำหนดเวลาในการละทิ้งขั้นตอนเก่าสำหรับคู่สัญญาที่เลือก เพื่อให้ขั้นตอนใหม่ในการทำงานกับเอกสารเป็นเรื่องง่าย เข้าใจได้ และมีความแตกต่างน้อยที่สุดจากที่มีอยู่ จำเป็นต้องสนับสนุนการรวม BED เข้ากับโปรแกรมการบัญชี การจัดการ และ EDMS และดียิ่งขึ้น - เพื่อสร้าง BED เป็นส่วนสำคัญของพวกเขา บล็อกที่แยกจากกันน่าจะเป็นปัญหามากที่สุดคือประเด็นของการเกี่ยวข้องกับคู่สัญญา ไม่เพียงแต่จำเป็นในการเชื่อมโยงคู่ค้าของลูกค้า BED เท่านั้น แต่ยังต้องช่วยในการเปลี่ยนไปใช้ขั้นตอนใหม่ในการทำงานกับเอกสารด้วย มิฉะนั้น แม้จะมีการใช้ BED ข้อผิดพลาดและความคลาดเคลื่อนในข้อมูลในบัญชีการซื้อและการขายจะยังคงอยู่ และมีผลกระทบด้านลบอื่นๆ ผู้เชี่ยวชาญมั่นใจว่าปัญหาในการบูรณาการ BED เข้ากับระบบธุรกิจอื่นๆ และผู้รับเหมาที่เกี่ยวข้องในอีกไม่กี่ปีข้างหน้าจะมีบทบาทสำคัญในการเผยแพร่เทคโนโลยี BED ในประเทศของเรา

    จะทำอย่างไร?

    “สำหรับตอนนี้ ในรัสเซีย เป็นไปไม่ได้ที่จะละทิ้งกระดาษโดยสิ้นเชิง ไม่ว่าจะในภาครัฐหรือภาคการค้า” Elena Ivanova กล่าว - ประการแรก จำเป็นต้องพัฒนากรอบกฎหมายที่จะสนับสนุนให้องค์กรต่างๆ เปลี่ยนมาใช้ BED ส่วนหนึ่งตอนนี้เริ่มปรากฏให้เห็นในองค์กรภาครัฐที่เกี่ยวข้องกับการปรับปรุง SMEV, M” เธอเชื่อว่าส่วนใหญ่ขึ้นอยู่กับผู้จำหน่าย EDMS; พวกเขาสามารถพิสูจน์ผลกระทบทางเศรษฐกิจของการเปลี่ยนมาใช้ BED และนำเสนอโซลูชั่นทางเทคโนโลยี สิ่งสำคัญคือต้องทำงานในชุมชนวิชาชีพและองค์กรที่เกี่ยวข้องกับการกำหนดมาตรฐานในพื้นที่ EDMS/ECM และต้องมีปฏิสัมพันธ์กับหน่วยงานกำกับดูแลของรัฐ

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

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

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

    “เราขอแนะนำว่าบริษัทต่างๆ อย่ารอ “การโทรครั้งสุดท้าย” เมื่อพวกเขาจะไม่สามารถรับมือกับการไหลของกระดาษได้อีกต่อไป และจะไม่ปฏิบัติตามข้อกำหนดของหน่วยงานกำกับดูแล” Artem Tanan แนะนำ - ตอนนี้พวกเขาจำเป็นต้องตัดสินใจว่าจะใช้ธุรกรรม/เอกสารประเภทใด และจะใช้กับคู่สัญญาใด จากนั้นจึงแต่งตั้งผู้ที่รับผิดชอบและกำหนดเวลา หากจำเป็น ให้เกี่ยวข้องกับผู้เชี่ยวชาญที่มีความสามารถเพียงพอในสาขานี้เพื่อการดำเนินงานที่ได้รับมอบหมายคุณภาพสูง หากมีปัญหาด้านระเบียบวิธีหรือทางเทคนิค ให้หยิบยกขึ้นมาหารือในเวทีเฉพาะทางในคณะทำงานเกี่ยวกับประเด็น BED เฉพาะการกำหนดงานเฉพาะเมื่อเปลี่ยนมาใช้ BED ในบริษัทเดียวเท่านั้นที่จะช่วยให้ได้รับประสบการณ์ที่ประสบความสำเร็จซึ่งผู้เข้าร่วมตลาดรายอื่นสามารถเข้าใจได้ การจำลองประสบการณ์นี้โดยบริษัทขนาดใหญ่ร่วมกับผู้ให้บริการ SF ผู้จำหน่ายซอฟต์แวร์ และเครือข่ายพันธมิตรของพวกเขาเป็นวิธีที่มีประสิทธิภาพมากที่สุดในการเผยแพร่เทคโนโลยี BED สู่ตลาด”

    เราสานต่อสิ่งที่เราทำมามากแล้ว

    เชอร์โนไมร์ดิน VS.

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

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

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

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

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

    1C เริ่มต้นได้อย่างไร? จำไว้!

    โดยส่วนตัวแล้วฉันเริ่มทำงานกับซอฟต์แวร์ 1C ตั้งแต่เวอร์ชัน 6.0 ในความคิดของฉัน โปรแกรมนี้ซับซ้อนกว่าตัวเลือกการบัญชีต่างๆ ที่เก็บไว้ในสเปรดชีต Excel เล็กน้อย

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

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

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

    ปัจจุบัน บริษัท 1C มอบระบบนิเวศทั้งหมดให้กับลูกค้า:

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

    อัปเดต 1C: มันทำงานอย่างไร

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

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

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

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

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

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

    ขาดความเป็นโมดูล: เหตุใดจึงสำคัญมาก

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

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

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

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

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

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

    นโยบายลิขสิทธิ์และข้อบกพร่องในระบบ

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

    ลองจินตนาการถึงสถานการณ์ มีบริษัทแห่งหนึ่งที่จ้างพนักงานประมาณ 30 คน หลังจากการอัพเดต โปรแกรมหยุดรับรหัสลิขสิทธิ์แล้ว งานของบริษัทเป็นอัมพาต บริษัทประสบความสูญเสีย

    ปัญหาสำคัญ: ความไม่แน่นอนของพฤติกรรมของแพลตฟอร์มเมื่อทำการอัพเดต

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

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

    ดังนั้นสถานการณ์ของโปรแกรมเมอร์จะเป็นดังนี้:

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

    เหตุใดจึงมีข้อบกพร่องมากมาย?

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

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

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

    แน่นอนว่ามีการสร้างผลิตภัณฑ์ซอฟต์แวร์ทางเลือกซึ่งบางส่วนก็ค่อนข้างดี แต่จนถึงตอนนี้ทั้งหมดเป็นวิธีแก้ปัญหาที่สามารถแก้ไขปัญหาบางอย่างได้ ในขณะที่ 1C นั้นเป็นระบบนิเวศทั้งหมด

    นอกจากนี้ บริษัท 1C ยังโดดเด่นด้วยการตลาดที่ทรงพลังและเชิงรุก ทุกคนรู้เกี่ยวกับซอฟต์แวร์นี้

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

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

    เรือธง การกำหนดค่าทั่วไป

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

    แต่ผู้ใช้ส่วนใหญ่ใช้การกำหนดค่าเพียง 4 แบบเท่านั้น:

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

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

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

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

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

    การตลาดเชิงรุกและผลลัพธ์

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

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

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

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

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

    ข้อเสียของการบริการและแฟรนไชส์

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

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

    แต่ในความเป็นจริง บริษัท 1C ไม่สามารถทำงานร่วมกับพันธมิตรได้จริง:

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

    ฉันได้กล่าวไปแล้วว่า 1C เป็นระบบนิเวศทั้งหมด ในบางแง่ก็สามารถเปรียบเทียบกับ Apple ได้ มีทั้งระบบที่สร้างขึ้นที่นั่น ซึ่งประกอบด้วยฮาร์ดแวร์ ซอฟต์แวร์ และผู้ค้าปลีก 1C ยังมีแพลตฟอร์ม มีการกำหนดค่า มีตัวแทนจำหน่ายที่ได้รับการรับรอง

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

    สิ่งที่น่าสนใจคือบริษัท 1C มุ่งเป้าไปที่การตลาดไปยังผู้บริโภคผลิตภัณฑ์เป็นหลัก เช่น เกี่ยวกับผู้ใช้ และการทำงานกับการกำหนดค่านั้นมุ่งเน้นไปที่โปรแกรมเมอร์อย่างสมบูรณ์ เป็นผลให้มีการโฆษณาสิ่งหนึ่ง แต่ในทางปฏิบัติปรากฎว่าผู้ซื้อได้รับสิ่งที่แตกต่างไปจากเดิมอย่างสิ้นเชิง

    และนี่คือสาเหตุของการปฏิเสธต่อโปรแกรมเมอร์ 1C และผลิตภัณฑ์ซอฟต์แวร์เองก็ปรากฏขึ้นเช่นกัน
    เมื่อฉันหยุดทำงานกับ 1C เท่านั้นและเริ่มให้คำปรึกษาทางธุรกิจ ฉันเริ่มใช้ผลิตภัณฑ์ซอฟต์แวร์ที่หลากหลายในงานของฉัน ไซต์เหล่านี้เป็นไซต์บน Drupal และระบบต่างๆ เช่น ZOHO CRM, ATOL RMK, Redmine และระบบอื่นๆ อีกมากมาย และบริการและโปรแกรมเหล่านี้เกือบทั้งหมดไม่ต้องการการอัปเดตอย่างต่อเนื่องและบ่อยครั้ง และเมื่อทำการอัพเดตก็ไม่มีปัญหาอะไรมากมายนัก

    ในขณะที่บริษัท 1C สร้างรายได้ในสองทิศทาง: จากการขายและการอัปเดตอย่างต่อเนื่อง แต่ลูกค้าต้องทำอย่างไรกับมัน? เขาถูกบังคับให้จ่ายเงินและอัพเกรด เนื่องจากไม่มีทางเลือกอื่น นอกจากนี้ผลิตภัณฑ์ทั้งหมดที่ใช้ในองค์กรจะต้องได้รับการอัพเดตพร้อมกัน

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

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

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

    1C: Bitrix - ปัญหา คุณลักษณะ การตลาด

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

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

    ผลลัพธ์คืออะไร?
    มีการบูรณาการฐานข้อมูลร้านค้าออนไลน์และผลิตภัณฑ์ซอฟต์แวร์ 1C อย่างแน่นอน แต่มันซับซ้อนมากและหากไม่ได้รับความช่วยเหลือจากผู้เชี่ยวชาญ ก็แทบจะเป็นไปไม่ได้เลยที่จะตั้งค่าการแลกเปลี่ยนข้อมูล และการเปลี่ยนแปลงก็ยากมาก

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

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

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

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

    แทนที่จะเป็นเรซูเม่

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

    การปฏิเสธจากผู้ใช้เกิดจาก:

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

    แท็ก: เพิ่มแท็ก