ฉันเบื่อการกรอกใบแจ้งหนี้ด้วยมือ จึงสร้าง API ที่สร้างใบแจ้งหนี้ลักษณ์ยืมชำระแบบออกจากใจและใบหนี้เพิ่มเติมจาก JSON

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

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

เครื่องมือที่มีอยู่ไม่ได้แก้ปัญหาที่ถูกต้อง QuickBooks FreshBooks Zoho Invoice และอื่นๆ ทั้งหมดต้องการกลายเป็นกระดูกสันหลังของการบัญชีทั้งหมดของธุรกิจ พวกเขาต้องการการเชื่อมต่อธนาคาร การติดตามค่าใช้จ่าย การรวมเงินเดือน และการสมัครสมาชิกรายเดือนเพื่อให้สิทธิ์ สิ่งที่จำเป็นนั้นง่ายกว่ามาก: ส่งข้อมูลที่มีโครงสร้าง ออกมา รับ PDF ที่สวยงาม ไม่มีอะไรอื่นเลย ไม่มีแดชบอร์ด ไม่มีบัญชี ไม่มีการสร้างจากสิบสองขั้นตอน เพียงฟังก์ชันที่ยอมรับ JSON และส่งคืนเอกสาร

สามบริษัทและความสุ่มเสี่ยงที่การเรียกเก็บเงินรายเดือนสร้างขึ้น

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

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

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

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

API ทำอะไรจริงๆและทำไม JSON จึงเปลี่ยนทุกอย่าง

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

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

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

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

ห้าประเภทเอกสารและเมื่อแต่ละประเภทมีความสำคัญ

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

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

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

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

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

ลักษณะการให้หมายเลขอัตโนมัติและสติที่มันรักษาไว้

คุณลักษณะการให้หมายเลขอัตโนมัติเพียงอย่างเดียวที่ตัดสินใจความพยายามในการพัฒนาทั้งหมด บริษัทแต่ละแห่งรักษาลำดับหมายเลขของตัวเอง ประเภทเอกสารแต่ละประเภทในบริษัทนั้นรักษาลำดับย่อยของตัวเอง หมายเลขใบแจ้งหนี้ตามรูปแบบหนึ่ง ใบแจ้งหนี้ลักษณ์ยืมตามรูปแบบอื่น และใบหนี้เพิ่มเติมตามรูปแบบที่สาม ลำดับเพิ่มขึ้นโดยอัตโนมัติกับเอกสารที่สร้างขึ้นทั้งหมด และรูปแบบสามารถกำหนดค่าได้: บริษัทบางแห่งต้องการลำดับตัวเลขธรรมดาเช่น 001, 002, 003 ในขณะที่คนอื่นต้องการคำนำหน้าปีเช่น 2026-001 และคนอื่นต้องการคำนำหน้ารหัสบริษัทเช่น ABC-INV-001 API อาจรองรับรูปแบบทั้งหมดนี้ผ่านสตริงแม่แบบในการกำหนดค่าบริษัท และตัวนับจริงจัดการฝั่งเซิร์ฟเวอร์เพื่อไม่มีความเสี่ยงของหมายเลขที่ซ้ำกันหรือช่องว่างที่ไม่ตั้งใจ

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

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

ทำไมสิ่งนี้จึงมีมากกว่าการแก้ไขส่วนตัว

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