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