เมนู

สถานการณ์ที่อยู่ข้ามพรมแดน: หนึ่งคำสั่งซื้อมีกี่ประเทศ

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

เผยแพร่เมื่อ

  • ข้ามพรมแดน
  • หลายประเทศ

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

ในคำสั่งซื้อข้ามพรมแดนหนึ่งรายการมีประเทศได้กี่แห่ง?

คำตอบคืออย่างน้อยสองแห่งเสมอในกรณีข้ามพรมแดน คือประเทศของผู้ซื้อและประเทศของผู้รับ และในทางปฏิบัติมักมีมากกว่านั้น

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

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

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

เมื่อประเทศของผู้จ่ายกับผู้รับไม่ตรงกันจะยึดฝ่ายใด?

ไม่มีคำตอบเดียวที่ใช้ได้กับทุกช่อง สิ่งที่ต้องมีคือการตอบคำถามนี้เป็นรายช่อง และเขียนคำตอบไว้อย่างชัดเจนว่าอ้างอิงฝ่ายใด

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

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

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

กลุ่มช่อง ฝ่ายที่มักใช้อ้างอิง เหตุผล
ช่องที่อยู่จัดส่ง ประเทศปลายทาง ต้องนำจ่ายได้
ช่องเอกสาร ประเทศผู้ออกเอกสาร ต้องตรงกับทะเบียน
ช่องติดต่อ ประเทศที่ติดต่อได้จริง ต้องใช้งานได้จริง
ช่องที่เกี่ยวกับภาษี ตามที่กฎเกณฑ์กำหนด ไม่ใช่ทางเลือกของเรา

ทำไมโทรศัพท์ สกุลเงิน และเขตเวลาต้องดูแยก?

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

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

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

เขตเวลามีผลกับเวลาในการตัดรอบและการแสดงกำหนดเวลา และผู้ใช้ที่ทำงานข้ามเขตมักต้องเห็นเวลาที่ต่างจากที่ตั้งของที่อยู่

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

ความยาวของชื่อประเทศและที่อยู่ทำให้ส่วนใดพัง?

ในงานข้ามพรมแดน ค่าความยาวของชื่อประเทศและของที่อยู่มักขึ้นพร้อมกัน เพราะประเทศที่มีชื่อยาวมักเป็นประเทศที่มีที่อยู่ยาวด้วย ทำให้ผลกระทบรุนแรงกว่ากรณีที่เจอทีละอย่าง

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

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

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

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

ทางแก้ที่ใช้ได้จริงคือทดสอบด้วยค่าที่ยาวที่สุดที่หาได้ตั้งแต่ก่อนออกแบบแม่แบบ ไม่ใช่หลังออกแบบเสร็จ

การไม่รองรับการจัดส่งต่างจากความผิดพลาดของรูปแบบอย่างไร?

สองเรื่องนี้ต้องแยกข้อความแจ้งให้ชัด เพราะผลต่อผู้ใช้ต่างกันอย่างมาก

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

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

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

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

สำหรับนักพัฒนา: ทำผู้ใช้เป็นพารามิเตอร์ที่ชัดเจน

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

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

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

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

ขั้นตอนถัดไปที่ควรทำก่อนเปิดใช้งาน

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

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

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

อ่านต่อ

บทความเกี่ยวกับ รูปแบบที่อยู่และข้อมูลตัวตนตามประเทศ

บทความเกี่ยวกับ รูปแบบที่อยู่และข้อมูลตัวตนตามประเทศ

รายการนี้แสดงเฉพาะบทความในหัวข้อของหน้านี้