Đáp ứng các ngoại lệ trong chương trình quản lý vận đơn

bởi Nguyễn Đức Anh
đáp ứng các ngoại lệ

Trong khi thiết kế chương tình quản lý vận đơn, tôi nhận thấy có một số thao tác rất ít dùng. Những trường hợp ít dùng này có từ 2 nguyên nhân chính:

  • Chúng xuất phát từ sự kiện thực tế ít khi xảy ra trong thực tế
  • Chúng xuất phát từ thao tác lỗi của người thao tác vận đơn

Câu hỏi là bạn nên đối xử với các thao tác ít dùng này như thế nào?

Có lẽ hay nhất là tôi lặp lại quá trình chính bản thân xử lý vấn đề này.

A. Phớt lờ

Thông thường ngay từ đầu không phải tôi phớt lờ mà tôi không để ý nó bởi vì nó ít khi xảy ra. Đến khi nó xảy ra rồi và gây ảnh hưởng đến thực tế thì tôi mới thực sự chú ý, nhưng cái thường tiếp theo là không giải quyết luôn!

Chẳng hạn như việc khách muốn đổi sang sản phẩm khác. Các chương trình thiết kế bắt buộc người nhập vận đơn phải nhập số tiền khác 0 ở phần thanh toán, đúng trong hầu hết các trường hợp, nhưng có thể sai khi xảy ra việc đổi hàng lỗi / vỡ. Khi ấy người bán mang sản phẩm mới đến đổi, và lần giao dịch này không có thanh toán.

Khi ấy tôi đã yêu cầu người lập vận đơn viết ra file word những đơn không có thanh toán kiểu như vậy. Điều này rõ ràng gây phiền toái thêm cho họ, còn về mặt hệ thống quản lý vận đơn nó tạo ra sự phân mảnh thông tin, thiếu đồng bộ. Tôi đã cố tình phớt lờ việc giải quyết.

Cuối cùng sau khi không cảm thấy ổn với cách trên tôi lại để mở khả năng để thanh toán bàng 0, nhưng như vậy dễ tiềm ẩn nguy cơ lỗi cho rất nhiều trường hợp khác! Mặc dù biết vậy nhưng phải vài ngày sau tôi mới sửa cho hoàn chỉnh tính năng này. Giai đoạn chờ trên cũng chính là phớt lờ hoặc đúng hơn là trì hoãn.

Vậy tôi đã làm thế nào để vẫn ngăn việc để thanh toán bằng 0 trong đa số trường hợp đồng thời cũng cho phép thanh toán bằng zero trong một số trường hợp nhất định. Đơn giản là tôi để mặc định cấm, còn nếu muốn có ngoại lệ (tức là thanh toán zero), người thao tác phải tick vào một cái ô. Việc tick này đảm bảo họ ý thức được việc bản thân đang làm.

Đây sẽ là cách giải quyết điển hình đối với các ngoại lệ:

  • Các ngoại lệ cần phải thực hiện với sự xác nhận, và để ý từ phía người nhập
  • Các ngoại lệ cần được ghi lại để phục vụ cho việc xem xét về sau & đồng thời tránh nguy cơ gian lận từ việc lợi dụng tính năng trên

B. Cực đoan

Khuynh hướng này xảy đến khi tôi nhận thấy vấn đề khá phức tạp nên muốn giải quyết theo hướng gọn lẹ, tuyệt đối, bỏ qua không đáp ứng các ngoại lệ.

Chẳng hạn như tôi vẫn đang duy trì việc cấm sửa vận đơn trong còng 3 ngày sau giao để phòng lỗi và gian lận mặc dù vẫn thấy vấn đề của nó. Chẳng hạn có những đơn cần sửa đổi sau 3 ngày giao (thí dụ đơn giao hàng đi tỉnh, sau 5 ngày hàng mới đến tay khách và họ nhận thấy hàng thiếu cho nên đơn hàng điện tử phải sửa lại để đáp ứng thực tế này).

Việc cấm sửa như trên mà không chịu điều chỉnh lại hệ thống là cực đoan.

Hoặc việc bạn giả định người thao tác không thể gặp một lỗi nào đó cũng là cực đoan. Tôi sẽ bàn tiếp vấn đề này ngay bên dưới.

C. Thiếu đồng bộ

Trước khi bàn chi tiết về điều này, tôi muốn nói lại việc các trường hợp ít dùng có từ các nguyên nhân nào.

Nếu như việc thanh toán bằng zero xuất phát từ thực tế là có khi phải đổi hàng thì cũng có một số thao tác xảy do sai xót của người thao tác đơn hàng trên hệ thống điện tử.

Chẳng hạn về việc đổi ngày giao hàng. Có 2 luật tôi tạo ra để cấm:

  • Không thể chuyển ngày giao hàng về quá khứ [1]. Nếu đơn hàng ngày mùng 5/8/2017 không giao được thành công, bạn phải chuyển nó đến ngày tương lai để giao bạn không thể chuyển ngày giao về quá khứ như ngày 4/8/2017.
  • Không thể chuyển ngày giao hàng sau 3 ngày [2]. Trong hầu hết các trường hợp, sau 24 tiếng đơn hàng của tôi sẽ giao hàng thành công, nếu không nó sẽ được chuyển sang ngày khác để giao. Do vậy trong đa số các trường hợp sau 3 ngày là đã chắc chắn thành công.

Hay việc tôi tạo ra luật không thể tạo đơn hàng ở thời điểm quá khứ [3], cụ thể nếu hôm nay là ngày 5/8/2017, thì bạn không thể tạo đơn hàng cho ngày 3/8/2017 được.

Nếu như luật [1] và [3] hoàn toàn chính xác, phản ánh thực tế thì luật [2] tạo ra kẽ hỡ.

Giả dụ hôm nay là 5/8/2017. Người tạo vận đơn cần chuyển một đơn từ ngày mùng 4 sang ngày mùng 5 để giao lại, người đấy chuyển thành công đơn có mã là A…Nhưng rồi người tạo nhận ra rằng mình chuyển sai đơn đã giao thành công rồi, đơn cần phải giao lại có mã là B cơ! Vì thời điểm chuyển mới cách mốc 1 ngày so với hiện tại nên luật 2 không được áp dụng và không có vấn đề về cấm chuyển.

Làm thế nào đây vì luật [1] cấm việc chuyển ngày giao lại về quá khứ. Đơn có mã là A không thể chuyển ngày về mùng 4 được.

Thực tế là lỗi như trên có thể xảy ra (mặc dù không nhiều), nếu bạn giả định người nhập không thể thao tác sai lỗi này thì bạn đã rơi vào trường hợp cực đoan rồi.

Để khắc phục lỗi này tôi phải tạo ra đáp ứng ngoại lệ chuyển ngày giao về quá khứ.

Luật [2] cũng cần phải sửa lại. Mục đích của luật [2] là xác định đơn thành công, nhưng nó không chính xác vì dựa trên mốc ước đoán. Nó cần sửa lại là sau khi người giao hàng thành công, người đó xác nhận những đơn nào giao được rồi. Việc đó làm cho đơn hàng điện tử phản ánh sát thực tế hơn và đỡ gây ra lỗi tiềm ẩn. Chẳng hạn những đơn đã giao thành công từ ngày mùng 3 sẽ không thể chuyển ngày giao sang ngày mùng 5 được.

Nhưng bạn có nghĩ đến việc người giao hàng tick nhầm đơn họ giao thành công rồi hay không?

Các quy tắc càng nhiều, các ngoại lệ cũng sẽ càng nhiều theo.

D. Yêu cầu phản hồi

Tôi thấy rằng mặc dù rất cố gắng mình cũng không thể lường trước được các lỗi có thể xảy ra. Vì vậy tôi đã đưa người tạo vận đơn một cuốn sổ để ghi lại các vấn đề mà cô gặp phải cũng như các mong muốn để chương trình thuận tiện với cô hơn.

0 bình luận