สถานะของคู่สัญญาที่ไม่ดี 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 เป็นระบบนิเวศทั้งหมด ในบางแง่ก็สามารถเปรียบเทียบกับ 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 ผู้คนแบบสุ่มจึงมีส่วนร่วมในการให้บริการผลิตภัณฑ์ซอฟต์แวร์ ซึ่งไม่ได้มีส่วนช่วยสร้างภาพลักษณ์เชิงบวกด้วย
แท็ก: เพิ่มแท็ก