ข้ามไปยังเนื้อหาหลัก

Mobile Borrow และ Customer Management

หน้านี้ใช้บันทึก behavior ปัจจุบันของ mobile สำหรับการแก้ไขรายการในใบเบิกดูปลา และ field บนหน้าแก้ไขการจัดการลูกค้า

การค้นหาลูกค้าใน Customer List​

  • หน้า CustomerList ใช้ CustomerManagementListHeader สำหรับช่องค้นหา
  • เมื่อผู้ใช้กดค้นหาจาก keyboard ตัว header จะส่งข้อความจาก TextInput submit event กลับเข้า screen โดยตรง
  • หน้า CustomerList ใช้ข้อความที่ submit มาเป็นค่า search สำหรับ getCustomerSapList ทันที แล้วค่อย sync ค่าใน state/ref ของช่องค้นหา
  • การทำแบบนี้ป้องกันปัญหา timing ของ Thai IME ที่พิมพ์คำ เช่น ขาย แล้วกดค้นหา แต่ API ได้ค่าแค่ตัวอักษรแรก เช่น ข
  • การค้นหายังคงใช้ filter เดิมร่วมด้วย ได้แก่ประเภทการจัดส่งและรหัสสายส่ง

ฟอร์มที่อยู่ของลูกค้าบน iOS​

  • หน้า CustomerDetail ไม่เปิดฟอร์ม เพิ่มที่อยู่ใหม่ เป็น nested modal แล้ว
  • เมื่อกด เพิ่มที่อยู่ใหม่ หน้าจอจะสลับจาก view รายละเอียดลูกค้าไปเป็น view ฟอร์มเพิ่มที่อยู่แบบเต็มหน้าใน screen เดิม
  • ปุ่ม back บน header และปุ่ม กลับ ในฟอร์มจะปิดฟอร์มที่อยู่และกลับไปหน้า detail ลูกค้า
  • หน้า CustomerManagementEdit ใช้ pattern เดียวกันสำหรับการเพิ่มและแก้ไขที่อยู่ของ customer draft
  • ระหว่างเปิด address editor หน้าฟอร์มหลักของลูกค้าจะถูกซ่อน เพื่อให้มี scroll owner เดียวบนหน้าจอ
  • การค้นหาที่อยู่ เลือกสายส่ง และเลือกตำแหน่งจากแผนที่ยังเป็น modal/picker flow ได้ แต่เปิดจาก address form ระดับ screen ไม่ได้เปิดซ้อนจาก modal อีกชั้น
  • visibility ของ modal ถูก guard ตาม view ที่กำลังใช้งาน:
    • modal ค้นหาที่อยู่/แผนที่/สายส่งของ CustomerDetail เปิดได้เฉพาะตอน address form ของหน้า detail ทำงาน
    • modal ค้นหาที่อยู่/แผนที่/สายส่งของ CustomerManagementEdit เปิดได้เฉพาะตอน address editor ทำงาน
    • selector ของฟอร์มหลักใน CustomerManagementEdit เช่น ประเภทลูกค้า, รู้จักเราจาก, สาขา, วัน, เดือน จะถูกซ่อนเมื่อ address editor เปิดอยู่
  • การปรับนี้เลี่ยงปัญหา modal-over-modal และ scroll gesture conflict บน iOS โดยยังคง behavior การบันทึก, address payload, ตัวเลือก auto-create ShipTo, และการ reload draft เดิมไว้เหมือนเดิม

การแก้ไขรายการในใบเบิกดูปลา​

  • หน้า BorrowDetail อนุญาตให้แก้ไขรายการสินค้าได้เมื่อเอกสารยังเป็นสถานะ NEW และผู้ใช้ปัจจุบันเป็นเจ้าของใบเบิก
  • การเทียบ owner ตอนนี้ใช้การ trim() ทั้ง user.userCode และ detail.userCode ก่อนเปรียบเทียบ
  • เมื่อกดรายการสินค้าเดิมในใบเบิก ระบบจะเปิด modal แก้ไขเฉพาะรายการนั้น
  • modal แก้ไขใช้หน้าตาและสไตล์เดียวกับ modal เพิ่มสินค้า แต่จะไม่แสดงรายการสินค้าอื่นและไม่แสดงช่องค้นหาสินค้า
  • ตอนเข้าแก้ไข ระบบจะโหลดสินค้าปัจจุบันจาก productCode และถ้า item นั้นไม่อยู่ใน inventory snapshot ที่อยู่ใน memory จะไปดึงจาก inventory ก่อนเปิด modal
  • สิทธิ์การแก้ไขจะถูกตรวจซ้ำอีกครั้งตอนผู้ใช้กดบันทึก

พฤติกรรมการบันทึกและลบรายการในใบเบิกดูปลา​

  • การบันทึกรายการเดิมจะอัปเดตด้วย itemId และ fallback ไปใช้ id เมื่อ payload ของรายการไม่มี itemId
  • การแก้นี้ช่วยไม่ให้ flow แก้ไขเผลอเรียก create-item API แล้วชน error สินค้าซ้ำในรายการ
  • การลบรายการในใบเบิกก็ fallback ไปใช้ item.id ได้เช่นกันเมื่อ item.itemId ไม่มี
  • ถ้าไม่พบ identifier ของรายการที่ใช้ได้ หน้าจอจะแสดง error ตรง ๆ แทนการไม่ตอบสนอง
  • ทั้ง Mobile และ POS Terminal ใช้ payload shape เดียวกันสำหรับ create/update item ของใบเบิกดูปลา:
    • productCode
    • productName
    • qty
    • price
    • amount
    • weight
    • limitWeight
    • UOMCode
    • UOMName
    • UOMEntry
    • whGrpCode
    • whGrpName
    • whsCode
    • weightBaseFlag
    • companyCode
    • companyName
    • taxNo
    • vatGroup
    • stepPriceFlag
    • editPriceBy
  • editPriceBy ของใบเบิกดูปลาส่งเป็น null เสมอ เพราะ flow นี้ไม่มีการแก้ไขราคา
  • payload ของใบเบิกดูปลาไม่ส่ง field เสริมอย่าง onHand, bookingQty, uomCode, และ uomName เข้า create/update item API

Field บนหน้าแก้ไขการจัดการลูกค้า​

  • หน้า CustomerManagementEdit แยกการเก็บค่า customerType/customerTypeCode และ knowus/knowusCode ออกจากกันอย่างชัดเจน
  • หน้า CustomerManagementEdit มีช่องกรอก taxID แบบ optional อยู่ใต้ field ฉายา
  • taxID ไม่บังคับกรอกตอนบันทึก และจะถูกส่งไปใน customer draft payload เมื่อมีค่า
  • หน้า CustomerManagementDetail และ CustomerDetail แสดง taxID ในส่วนข้อมูลลูกค้า โดย fallback เป็น - เมื่อไม่มีค่า
  • รายการตัวเลือกตอนนี้โหลดจาก source ที่ถูกต้อง:
    • customerTypes ใช้สำหรับ selector ประเภทลูกค้า
    • knowUs ใช้สำหรับ selector รู้จักเราจาก
  • การแก้นี้ทำให้ field ทั้งสองไม่สลับกันอีกบนหน้า edit

การสร้าง customer draft, replace หน้าจอ, และรายการลูกที่ยังบันทึกไม่สำเร็จ​

  • การสร้างลูกค้าใหม่จากหน้า CustomerManagementEdit จะสร้าง customer draft ก่อน
  • หลังจากได้ draft แล้ว หน้าจอจะพยายามสร้างที่อยู่และสาขาใต้ draft id นั้นต่อ
  • ถ้าที่อยู่หรือสาขาบางรายการบันทึกไม่สำเร็จ หน้าจอยังคงเก็บ customerDraftId ที่สร้างสำเร็จไว้ และ replace กลับเข้าหน้าแก้ไข draft เดิม
  • หน้าจอจะส่ง child records ที่ยังบันทึกไม่สำเร็จไปกับ route params แบบ pending แล้ว merge กลับเข้ากับ state หลังจาก reload draft detail, addresses และ branches จาก server
  • ดังนั้นที่อยู่หรือสาขาที่ยังไม่ถูกบันทึกลง server จะยังแสดงอยู่บนหน้าจอหลัง reload
  • เมื่อกดบันทึกครั้งถัดไป ระบบจะอัปเดต draft เดิม ไม่สร้าง draft ใหม่ซ้ำอีก