Đồng bộ mã hàng hoá giữa các Sheets

Liên hệ QC
Cái này em mới tìm hiểu. Gọi là dấu vết thay đổi hoặc tương tự, mà nó giống với kỹ thuật blockchain hay bitcoin hơn. Nếu mà nghĩ ra được cách lưu các thay đổi sau mỗi lần sửa thì quá tốt, với những dự án lớn sau này.

Riêng về Audit Trail: cái dấu vết này chắc phù hợp với món lưu trữ trường kỳ như bệnh viện, hợp đồng, ... mang tính thời gian, hơi cao cấp ấy bác.
Hồi trước tôi cũng có làm cái vụ Audit Trail này để lưu vào file Log khi có người thay đổi dữ liệu. Nó chỉ lưu thông tin đơn giản thôi.

CfbPXZr.png
 
Cái này em mới tìm hiểu. Gọi là dấu vết thay đổi hoặc tương tự, mà nó giống với kỹ thuật blockchain hay bitcoin hơn. Nếu mà nghĩ ra được cách lưu các thay đổi sau mỗi lần sửa thì quá tốt, với những dự án lớn sau này.
...
Suy nghĩ xa vời quá.
 
@Chủ bài đăng: Sao không tìm cách khác, mà phải đi sửa mã búa xua làm vậy(!)
Nếu là mình thì mã HH chỉ là : ABCDNTN; Trong đó
A - mã phân loại hàng
B- Nhóm hàng
CD - mã đại diện cho hàng hóa;
N (trước T) chỉ năm nhập
T - Tháng nhập; A chỉ ra nhập tháng 10
N Ngày nhập B ứng với ngày 11,. . . .
Vì là hàng rẻ tiền mau hỏng nên vài ba năm chuyển sang tạo file mới có sao lưu & hủy file trước;
 
@Chủ bài đăng: Sao không tìm cách khác, mà phải đi sửa mã búa xua làm vậy(!)
Nếu là mình thì mã HH chỉ là : ABCDNTN; Trong đó
A - mã phân loại hàng
B- Nhóm hàng
CD - mã đại diện cho hàng hóa;
N (trước T) chỉ năm nhập
T - Tháng nhập; A chỉ ra nhập tháng 10
N Ngày nhập B ứng với ngày 11,. . . .
Vì là hàng rẻ tiền mau hỏng nên vài ba năm chuyển sang tạo file mới có sao lưu & hủy file trước;
Chủ topic thích đùa thôi, nguyên tắc cơ bản của quản trị cơ sở dữ liệu là không dược thay đổi, sửa mã (khóa chính) vì với sơ sót nhỏ là phải vứt toàn bộ file vào sọt rác.
 
Lần chỉnh sửa cuối:
Nếu em siêu thì em nghĩ được hết các khả năng thì quy tắc mã sẽ giữ được duy nhất và đồng bộ 1 lần, nhưng lần 1 dữ liệu ít em đặt thế này, sau dữ liệu thêm thông tin, em lại phải đặt kiểu khác. n lần thì mã như bòng bong.
Em với code chỉ là sở thích thôi chứ không phải chuyên nên sai đâu sửa đấy bác ạ.

Ây dà, em chỉ đùa trong bài người khác thì có bác ạ, còn bài em đăng thì đàng hoàng mà.

Ví dụ trong mấy phần mềm dự toán, thay đổi mã vật liệu, tên vật liệu thì có thể thay được 2, 3 chỗ và mấy chỗ khác chạy theo.
Em tò mò excel có làm được không thôi.

Sự kiện change thì em cũng thử, nó cũng chạy sơ sơ theo ý (mỗi lần change chỉ thay 1 ô chứ không dán cả vùng được), còn phải chỉnh chút chỗ nhập mã mới vào ô chưa có dữ liệu thì bị lỗi.

Bác ongke có thay đổi điển hình là ID 1 -> 11 giống với cách nghĩ của em ấy bác.
Có thể em sẽ làm 1 sheet để ghi chú dấu vết này, càng chi tiết càng rõ.
Em có 2 tính chất đá bôm bốp nhau cùng tồn tại trong bản thân. Đó là lười + cầu toàn. Do đó rất thích tối ưu hóa. Biết là mình không đủ sức, nhưng thích thì cứ thích thôi.
 
Bạn xử lý sự kiện change như thế nào hay vậy?
Bác xem qua clip này giúp em (20s thôi). Với dữ liệu ít thì nó đang như vậy, nhưng nếu nhiều thì em không biết sẽ có lỗi gì nữa.
Bác @huuthang_bd xem giúp em tí.

Em đang mò nốt lỗi khi nhập dữ liệu mới nó không theo ý mình.
 
Chủ topic thích đùa thôi, nguyên tắc cơ bản của quản trị cơ sở dữ liệu là không dược thay đổi, sửa mã (khóa chính) vì với sơ sót nhỏ là phải vứt toàn bộ file vào sọt rác.
Thớt có nói rõ đây chỉ là ý tưởng, tức "sáng kiến"
Một sáng kiến loại lẻ tẻ này có hai giai đoạn. Giai đoạn thực hiện và giai đoạn áp dụng.
Vì lý do chính là học code cho nên thớt chỉ muốn phần "thực hiện". Phần "áp dụng" hoàn toàn mù tịt.

Cũng như nghiên cứu ra giống gà đẻ 10 trứng/ngày. Gần đến đích rồi vẫn chưa nhận ra con gà ấy bự bằng con heo 1 tạ.
 
Hiện em đang lăn tăn chỗ đổi mã số, vì sẽ có lúc cần bổ sung thông tin và mình phải đặt lại mã sao cho nhìn vào dễ nhận ra ngay.
Việc tạo mã cần có 1 bộ quy tắc (dài khoảng 3 trang A4), 1 quy trình (sơ đồ ít nhất 1 trang, giải thích quy trình 4 trang), 1 bộ định nghĩa thành phần mã.

Bộ định nghĩa thành phần mã phải lường trước tất cả những phát sinh cho ít nhất 5 năm (thời hiệu cho phép hủy chứng từ báo cáo), hoặc 10 năm (đối với báo cáo quản trị). Thêm 1 thông tin thì nó phải thuộc 1 trong các thành phần đã có, và chỉ định nghĩa thêm cho 1 thành phần đó thôi.
Thí dụ bảng định nghĩa thép xây dựng:

1705812134305.png

Nếu quan tâm đến chỉ tiêu độ cứng thép (1 trong các chỉ tiêu chất lượng) thì sẽ có thành phần thứ 6.

Tùy theo mức độ mở rộng của từng thành phần mà cho nó 1, 2 hoặc 3 ký tự. Nếu sử dụng cả ký tự số và ký tự chữ cái thì 2 ký tự cho phép định nghĩa lên tới 1296 mã con, 3 ký tự sẽ là 46.655 mã con.
Bảng 1, bảng 2, ... là các mã con và có thể định nghĩa thêm vào đó. Các bảng này sẽ có quan hệ phụ thuộc sao cho nếu chọn thép tấm chỉ chọn tiết diện là dộ dầy, kích thước là dài x rộng. Nếu chọn tròn chỉ chọn tiết diện là đường kính, kích thước là chiều dài.

Thậm chí tiết diện L, V cũng có thể tách ra 3 thành phần cấp 2.

Đâu phải đồ chơi đâu mà đụng là sửa, sửa mãi tới 5 năm10 năm vẫn còn quay lại sửa quá khứ.
 
Bác xem qua clip này giúp em (20s thôi). Với dữ liệu ít thì nó đang như vậy, nhưng nếu nhiều thì em không biết sẽ có lỗi gì nữa.
Bác @huuthang_bd xem giúp em tí.

Em đang mò nốt lỗi khi nhập dữ liệu mới nó không theo ý mình.
Cái clip đó thì có gì để xem bạn? :D
 
Bảng này thì quá chuẩn luôn, em sẽ vận dụng nó sau này.


Các bác và bác @HieuCD , bác @huuthang_bd ạ:
Đây là sự kiện change em sưu tập và chế biến, thay thế đồng bộ trong 1 file, hiện đang thử áp dụng cho các cột màu vàng.
Thay đổi nội dung ô (bất kỳ sheet) (nhưng từng ô, không paste vùng vào được) là toàn bộ các ô nào đang giống nó đều thay đổi theo (toàn bộ các sheet và sheet chứa nó).

Quan trọng, phải như ảnh thì sự kiện mới có hiệu lực workbook thay vì chỉ activesheet:

1705842817782.png
 

File đính kèm

  • thay doi hang loat.xlsm
    22.2 KB · Đọc: 6
Nếu là mình thì mã HH chỉ là : ABCDNTN
Ngày tháng năm nhập (và cả ngày tháng năm hết hạn sử dụng) không bao giờ cho vào mã hàng. Nếu không thì cùng 1 mặt hàng như nhau có cả trăm cả ngàn mã.
Nhóm hàng phải là 1 bảng riêng và có quan hệ là cha con với bảng mã mặt hàng.
Thậm chí thương mại bán lẻ còn 1 bảng cao hơn đó là ngành hàng: thức uống, thực phẩm, điện máy, ... Một ngành hàng gồm nhiều nhóm chẳng hạn thức uống gồm sữa, bia, nước có gaz, thực phẩm gồm tươi sống, đồ hộp, rau củ, ...
Vì là hàng rẻ tiền mau hỏng nên vài ba năm chuyển sang tạo file mới có sao lưu & hủy file trước;
Bảng mã không bao giờ hủy. Hủy rồi khi cần truy xuất lịch sử giao dịch 5 năm trước thì dữ liệu đã bị hỏng mất rồi. Tương tự là không thể so sánh doanh số từng năm của 5 năm liên tiếp, và nhiều những báo cáo quản trị khác.
 
toàn bộ các ô nào đang giống nó đều thay đổi theo
Chưa nói đến các vấn đề khác, nếu lỡ tay xóa 1 ô thì chuyện gì sẽ xảy ra? Hoặc nặng hơn là đang có A và B, muốn sửa A thành C nhưng sửa nhầm A thành B sau đó sửa lại thành C thì hết cứu luôn.
 
Chưa nói đến các vấn đề khác, nếu lỡ tay xóa 1 ô thì chuyện gì sẽ xảy ra? Hoặc nặng hơn là đang có A và B, muốn sửa A thành C nhưng sửa nhầm A thành B sau đó sửa lại thành C thì hết cứu luôn.
Thì ở trên tôi đã nhắc hai điều:
1. Bài này cần biết về Audit Trail. Đơn giản những thớt lại đi nghĩ đến những từ dao to búa lớn đâu đâu.
2. Bài này quy trình áp dụng quan trọng hơn code kiếc thực hiện. Dân chuyên nghiệp sẽ tưởng tượng là mình đã có phần mềm, tức là viết một cái prototype (mẫu) đơn giản rồi xem nó làm việc ra sao trong hệ thống của mình.
 
Em thêm điều kiện không cho xóa là được bác ạ (em đã thử) hoặc lặp qua từng sheet rồi cho xóa hết (nếu mong muốn là xóa dòng). Cái này đúng là em chưa nghĩ đến.

Còn A B C như bác nói thì lúc đầu em cũng đã nghĩ, mong muốn code sẽ có list lựa chọn thay thế đúng từ cần thay. Hoặc thông báo cho người dùng mã đã tồn tại. Cái này em chưa code được nhưng em nghĩ lặp qua các sheet, liệt kê cảnh báo thì không phải quá khó (nếu biết code).

Loại này thì chuyên rồi, em cũng đã dùng thử mấy phần mềm mà nó có thể hiệu chỉnh lung tung chỗ mà vẫn đồng bộ rồi. Nhưng nó có vị trí lưu riêng được quản lý bởi phần mềm. Còn em nói đang bên excel, và dữ liệu nó nằm trên bảng tính chứ có kho cất giữ đâu. Cái Audit Trail bác nói thì phần mềm nó phải có file gì gì gì .data hay chấm gì đó đi kèm rồi.

Bảng mã bác Mỹ gợi ý thì nếu lường trước hết các khả năng thì chuẩn luôn, nhưng giả sử sau này phát sinh thì vẫn phải thay đổi.
Bác code siêu thì có bảng mã để tra, còn em thì làm sao nhìn vào mã nhận biết ra đủ thông tin luôn thì thích hơn, thậm chí nếu may mắn, thay vì mã thì đặt cái QR ở đấy (QR thì số và chữ nó dài cả cây số ấy), quét cái nó hiện ra cái bảng của bác cũng tốt.
 
Bảng mã bác Mỹ gợi ý thì nếu lường trước hết các khả năng thì chuẩn luôn, nhưng giả sử sau này phát sinh thì vẫn phải thay đổi.
Đã lường trước các khả năng (thành phần) thì làm gì có chuyện phát sinh thêm thành phần? Chỉ có phát sinh thêm chi tiết, và chi tiết thì đã cho phép khai báo thêm còn gì?

Có biết "cán bộ quản lý" cấp nào, trình độ và kính nghiệm cỡ nào mới được đưa vào "Ban quản lý dự án tạo mã" họp hành cả tháng để viết ra "Bộ thuộc tính sản phẩm" không? Làm gì có chuyện phát sinh, mà phát sinh thêm thành phần là lôi ra kỷ luật mấy ông đó ngay. Trong thí dụ mẫu trên, nếu quan tâm đến độ cứng thép, hoặc tiêu chuẩn thép, là phải thêm vào bộ thuộc tính ngay từ đầu. Cán bộ quản lý phải biết phải quan tâm cái gì và đưa vào.

Ghi chú:
- "Bộ thuộc tính sản phẩm" của 1 sản phẩm (hoặc các sản phẩm cùng loại) gồm các thành phần của mã sau này
- Sản phẩm khác nhau có thể có những thuộc tính khác nhau chẳng hạn như thức uống có cồn thì có nồng độ alcohol, nhóm khác không có.
- Nhóm sản phẩm khác nhau có thể có số lượng thành phần trong bộ thuộc tính khác nhau, thành phần có thể có số ký tự khác nhau sinh ra độ dài mã cũng khác nhau.
 
Bảng mã chuẩn thì sau vậy. Giờ em đang cố xử lý A B C thay đổi thế nào đây. Chỉ có kiểm tra trước xem có trùng không thì được, chứ ghép lại 1 code change thì không đá này thì đá kia.
 
Web KT
Back
Top Bottom