๒๑/๓/๕๒

Windows Fundamentals for Legacy PCs

Windows Fundamentals for Legacy PCs




ไม่น่าเชื่อว่าพวกเราส่วนใหญ่ ขนาดที่อยู่ในแวดวงไอทีเอง ใช้ Windows XP หรือ Windows Vista บางคนอาจได้ลองสัมผัส Windows 2008 แล้วด้วยซ้ำ แต่กลับไม่คุ้นหูเจ้า Windows ตัวนี้ ถ้าไม่ได้อยู่ในแวดวงของ Terminal-Server หรือ Thin Client

 

ชื่อย่อของ Windows รุ่นนี้คือ WinFLP ถ้าจะอธิบายอย่างง่ายๆ ก็บอกว่า นี่คือ Windows XP รุ่นพิเศษ สำหรับใช้กับคอมพิวเตอร์เก่า ที่เคยใช้ Windows 98 ได้ มีประสิทธิภาพไม่สูงพอที่จะติดตั้ง Windows XP เช่น อาจจะมี Memory ไม่มาก หรือ CPU ไม่เร็ว 

 

WinFLP กิน Resource น้อย สามารถติดตั้งแทน Windows 98 ได้ โดยไม่ต้อง upgrade Hardware เพราะจะตัด module และ service หลายๆ ตัวที่ไม่จำเป็นออกไป ออกมาครั้งแรกเมื่อปี 2006 หรือ 4 ปีก่อน ประมาณช่วงเดียวกันกับ Windows XP SP2

 

เนื่องด้วยกระแส Virtual Machine ที่มาแรงในช่วงนี้ ทำให้มีความต้องการ OS ที่ใช้งานง่ายและเก่งแบบ Windows XP แต่กิน Resource น้อยแบบ Windows 98 ทำให้ WinFLP นี้เหมาะสำหรับ นำไปใช้เป็น Guest OS ใน Virtual Machine ด้วยเหตุผลที่เป็นสายพันธุ์ Windows XP ที่เบาและเร็วนั่นเอง



Spec ต่ำสุดที่ WinFLP สามารถทำงานได้คือ Memory แค่ 64MB และ CPU Pentium 233 MHz

Spec ที่แนะนำสำหรับใช้ WinFLP คือ Memory 128MB และ CPU Pentium 300 MHz

 

Software ที่ถูกตัดออกไปคือ บรรดาเกมส์ต่างๆ และ Outlook Express แต่ก็ยังมี Calculator, Notepad รวมทั้งความสามารถเรื่อง Remote Client และ Network นอกจากนี้ software บางตัวอาจทำงานไม่ได้เช่น Adobe CS4

 

ล่าสุด WinFLP มี Service Pack 3 ออกมาให้ upgrade หรือเทียบรุ่นกับ Windows XP SP3

 

สาเหตุที่ WinFLP ไม่แพร่หลาย เนื่องจาก Microsoft ไม่ได้จำหน่ายโดยทั่วไป ไม่ว่าจะเป็น Retail หรือ OEM มีใช้เฉพาะกลุ่มที่ทำสัญญารับประกันการใช้งานซอฟต์แวร์และยังไม่หมดสัญญา ที่มีปัญหาเพราะ Spec เครื่องเดิมใช้งานกับ Windows 98 ได้ แต่ Microsoft เลิก support Windows 98

 

ผมได้รู้จัก WinFLP เนื่องจากบังเอิญได้เจอน้องที่ทำงาน SAP Support ได้กล่าวถึง ตอนที่กำลังปรึกษากันเรื่องที่จะย้ายระบบบัญชี Scraft ของเราขึ้นไปไว้ใน Virtual Machine นั่นเอง เมื่อได้รู้จักชื่อแล้ว ในโลกอินเตอร์เน็ต ไม่มียากนักที่เราจะสืบค้นลึกลงไป จนเจอรายละเอียดหรือตัวจริงให้ทดลองใช้ รออีกไม่นาน ถ้าได้ทดสอบแล้วจะได้เล่าให้ฟังเทียบกับ MicroXP

 

ขอบคุณ รูปภาพตัวอย่างได้มาจาก gallery http://bink.nu/photos/news_article_images/category1021.aspx

จากบทความ http://bink.nu/Article7745.bink

 

แนะนำ link WinFLP ที่น่าสนใจ



 

 

๑๗/๓/๕๒

Stock with lot number

Stock with lot number


 

สืบเนื่องจากแนวคิดของ adm ที่ว่า 



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

 

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

 

เราสามารถดูสถานะของสินค้า ไม่ว่ายอดคงเหลือ หรือ ที่เก็บสินค้า ได้ทั้งจาก ชื่อสินค้าจริง (สต็อกรวม) หรือ เลขล็อต

สามารถกด F8 จากชื่อสินค้าจริง เพื่อดูรายชื่อที่เป็นเลขล็อต และสามารถกด F8 จากเลขล็อต เพื่อดูชื่อสินค้าจริง

 

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

 

ประเด็นเนื้อหาที่สำคัญ ประกอบด้วย


 

 

บิลซื้อ - การป้อนข้อมูลรับสินค้าที่มี lot no. เข้าสต็อก


 

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

 



-- ? (*1) ยกเว้นกรณีเป็นผู้ผลิตเอง จะต้องออกเลขที่ lot เอง run no. ? (หยุด ยังไม่คิด)
 

กรณีนี้ เมื่อผ่านรายการเข้าสต็อก โปรแกรมจะต้องเพิ่มเลขล็อตนั้น เข้าเป็นชื่อสินค้าในสต็อก อัตโนมัติ

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

 


ตรงจุดนี้ adm ยังแนะนำเพิ่มเติมว่า



"...อย่าลืม mod เวลาผ่านต้นทุน ให้เข้าต้นทุนทั้ง 2 ชื่อพร้อมกัน ช่วยให้ดูต้นทุนได้ทั้งจาก เลขล็อต และชื่อสินค้า..."
 

แต่ก่อนที่จะถึงขั้นตอนผ่านรายการนั้น...

 

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

 

กรณีสินค้าล็อตเดี่ยว 1:1


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


 

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

 

1. เลขล็อตอยู่บน, จำนวนและราคา อยู่กับเลขล็อต


2. เลขล็อตอยู่บน, จำนวนและราคา อยู่กับชื่อสินค้า


3. เลขล็อตอยู่ล่าง, จำนวนและราคา อยู่กับเลขล็อต


4. เลขล็อตอยู่ล่าง, จำนวนและราคา อยู่กับชื่อสินค้า

 

note: ข้อ 1 และ 3 ปิดไม่ให้ใช้ลักษณะดังกล่าว เพื่อให้สอดคล้องกับกรณี 1:N (ดูเรื่อง 1:N ข้อถัดไป)

 

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

 

แล้วโปรแกรมจะแยกแยะ บรรทัดที่เป็นชื่อสินค้าจริง กับบรรทัดที่เป็นล็อตได้อย่างไร คำตอบก็คือ ต้องกำหนด format หรือ notation ที่จะช่วยให้โปรแกรมตีความบรรทัดว่า เป็นเลขล็อต เช่น ใช้เครื่องหมาย # นำหน้า เรื่องนี้ต้องสรุปให้ชัดเจนอีกครั้งตอนท้าย หลังจากได้คิดถึงรูปแบบการป้อนข้อมูลต่างๆ ได้ครบเสียก่อน มีเรื่องต้องคำนึงอีกเรื่องหนึ่งคือ การป้อนเลขล็อต โดยใช้ barcode หรือ RFID reader

 

กรณีสินค้าหลายล็อตต่อหนึ่งชื่อสินค้า 1:N


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

 

ในชื่อสินค้า จะต้องระบุจำนวนรวม, ราคาต่อหน่วย และ จำนวนเงิน เพื่อคิดเงินให้ถูกต้อง ในเลขล็อต ต้องระบุจำนวนของล็อต เพื่อผ่านรายการเข้าสต็อกตามล็อตให้ถูกต้อง

 

แนวคิดเรื่อง เว้นบรรทัดว่าง เพื่อคั่น ระหว่างชุดล็อตที่เป็นสินค้าเดียวกัน ก็ยิ่งต้องเน้น ให้เป็นเงื่อนไขสำคัญ ในการป้อนข้อมูลในบิล ขณะที่ เรื่องของลำดับบน-ล่าง ระหว่างเลขล็อต กับชื่อสินค้าจริงนั้น ไม่ใช่ประเด็นปัญหาในการตีความ เนื่องจากเลขล็อตเป็นเลขใหม่ ต้องอาศัยการป้อนเลขเข้าไปเอง หรือใช้อุปกรณ์อ่าน barcode หรือ RFID reader อ่านจากตัวสินค้าจริง

ไม่จำเป็นต้องกด F1 เลือกจากข้อมูลในสต็อก



-- ? (*2) กรณีแบ่งล็อต (split lot) เพื่อแยกที่เก็บสินค้า ? (หยุด ไม่คิด)
 

หากเราคิดไกลออกไปอีกนิด กรณี 1:N สามารถใช้ได้กับกรณีของสินค้าที่มี serial number ซึ่งคำจำกัดความของ serial ก็คือ ล็อต ที่มีจำนวนเป็น 1 เสมอ

 

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

 

แนวคิดในการออกแบบ การป้อนข้อมูล ในบรรทัดเลขล็อต ก็คือ

1. กรณีชุดบรรทัดสินค้าล็อตนั้น มีการระบุเพียงหนึ่งล็อต

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

 

2. กรณีชุดบรรทัดสินค้าล็อตนั้น มีการระบุมากกว่าหนึ่งล็อต

จะต้องใช้วงเล็บ (...) หรือเครื่องหมาย = เพื่อระบุจำนวนของ lot ถ้าไม่ระบุจำนวนแปลว่าจำนวนเป็น 1 (ใช้กรณีเป็นแบบ serial ได้) ในบรรทัดอาจระบุมากกว่า หนึ่งล็อต โดยใช้ space หรือ , เพื่อแยกระหว่างล็อต เช่น

#12345(10),#111111 #123456=15

 


 

ครั้งหนึ่ง เคยเห็นบิลส่งของ เครื่องโทรศัพท์มือถือ จากตัวแทนจำหน่าย ค่อนข้างหลอน ตรงที่มีรายการ โทรศัพท์มือถือ 100 เครื่อง ถัดจากนั้น ก็เป็นเลข serial ตามมาเป็นพรืด บรรทัดละ 4-5 serial จนเต็มหน้าบิล และก็เคย คิดเขียนโปรแกรมให้รับ serial แบบใส่ว่าเลขไหน ถึงไหนได้ด้วย เช่น #NK32-0001...100 เพราะฝังใจกับเจ้าบิลใบนั้น

    



mod1: บิลซื้อ


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


 

mod2: ผ่านรายการบิลซื้อ

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



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


1. ใช้สูตรส่วนประกอบ ข้อมูลเลขล็อต มีส่วนประกอบเป็นชื่อสินค้าจริง


2. ใช้ชื่อแทน ข้อมูลเลขล็อต มีชื่อแทนเป็นชื่อสินค้าจริง


3. เก็บเลขล็อต ใน transaction เข้า-ออกสต็อค


ขออธิบายเหตุผลที่คิดถึงข้อ 3 ก็คือ เราต้องไม่ลืมเรื่องข้อจำกัดที่ว่า ในบิลใบเดียวกัน สินค้าตัวเดียว ไม่สามารถแบ่งเก็บไว้หลายที่เก็บหรือหลายโกดัง ปัญหาที่อาจจะเป็นปัญหากรณีสินค้าหลายล็อต และแต่ละล็อตแยกเก็บคนละที่ ถ้าแก้ปัญหานี้ได้ เราก็สามารถตอบโจทย์เรื่อง split lot ได้ด้วย ผลพลอยได้ที่ตามมาก็คือ เราสามารถปรับส่วน รายการเข้า-ออกสต็อค ที่เดิม มีแค่ที่เก็บหรือโกดัง ให้มีเลขล็อตได้ด้วย วิธีนี้ ช่วยให้แฟ้มสินค้าไม่เกิดอาการข้อมูลล้น เนื่องจากมีรายการเลขล็อตมาสะสมเพิ่มขึ้นเรื่อยๆ ขณะเดียวกันเราสามารถกด space ที่ชื่อสินค้าเพื่อดู info ว่า มีสินค้าเหลืออยู่เป็น ล็อต/ที่เก็บไหนบ้าง แต่ข้อเสียก็คือ เสียเวลาในการ scan เลขล็อต **? (ยังคิดไม่ลงตัว)


 

บิลขาย - การป้อนข้อมูลเพื่อตัดสต็อกหรือขายสินค้าที่มี lot no.


 

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

 

นอกจากนี้ ยังต้องพิจารณาลักษณะการขายสินค้าของกิจการ ว่าเป็นแบบ ยกล็อต หรือแบ่งล็อต หรือขายทีละหนึ่ง แบบ serial

 

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

 


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

 

ป้อนข้อมูลแบบใช้เลขล็อตนำ


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

 

ป้อนข้อมูลแบบใช้ชื่อสินค้านำ

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

 

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

 

ประเด็นอื่นๆ


ความไม่สะดวก กรณีเครื่องหมาย # นำหน้า กับการ input ด้วย barcode 

ความสับสน กรณีสินค้านั้น มีการผ่านรายการแบบไม่มีเลขล็อต ปนกับแบบมีเลขล็อต

รายงานสต็อก กับการคำนวณต้นทุนสินค้า แบบตัดสต็อคตามล็อต

 


แนวคิด MODIFY เก็บเลขล็อตใน transaction สต็อกเข้า-ออก

 

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

"#เลขล็อต,ที่เก็บ"

 

ข้อดีคือ เราสามารถใช้กลไกโปรแกรมเดิม ในส่วนโปรแกรมที่มีการคำนวณซับซ้อนได้ ในหลายส่วน เช่น

- กด space ที่ชื่อสินค้าเพื่อดูยอดสต็อกที่แยกแต่ละที่เก็บ ซึ่งจะกลายเป็นยอดสต็อกตามล็อตอัตโนมัติ

- กลไกรายงานสต็อกเดิม สามารถใช้ wildcard ในเงื่อนไขเฉพาะที่เก็บได้อยู่แล้ว ทำให้เราสามารถเลือกดูข้อมูลได้ทุกมิติ ทั้งเลขล็อต และที่เก็บ

 

แต่สิ่งที่เราจะต้องปรับเปลี่ยนก็คือ 

1. ขยายฟิลด์ข้อมูล ที่เก็บ จากเดิม 16 ตัวอักษร เป็นให้รับได้ 40 ตัวอักษร

2. ปรับการผ่านรายการบิลซื้อ และบิลขาย เป็นส่วนที่ยุ่งยากซับซ้อนอีกส่วนหนึ่ง แต่ไม่ว่าจะเลือก Modify แนวทางไหน ก็หนีไม่พ้นที่จะต้องปรับโปรแกรมในส่วนนี้ สำหรับแนวทางนี้ จะต้องสามารถผสาน คำสั่งที่เก็บ [/.../] และ คำสั่งเลขล็อต #xxxxx ให้กลายเป็นรูปแบบที่เก็บตามตัวอย่างข้างต้น ก่อนที่จะใช้บันทึกใน transaction

3. ปรับแก้ ข้อจำกัดการบันทึก transaction จากเดิม ที่ไม่สามารถบันทึก รายการที่มีเลขที่บิลเดียวกัน แต่มีที่เก็บต่างกัน (ดูเพิ่มเติมหัวข้อต่อไป) การปรับส่วนนี้ ได้ประโยชน์กับผู้ที่ไม่ได้ใช้เลขล็อตด้วย คือช่วยแก้ปัญหาข้อจำกัด ในการทำบิลกระจายสินค้าไปหลายที่เก็บในใบเดียวกัน อีกด้วย

 

แนวคิด MODIFY สต็อกเข้า-ออกหลายที่เก็บ ในบิลใบเดียวกัน


เลขที่อ้างถึง ใน transaction สต็อกเข้า-ออก มีความสำคัญ ใช้เป็นคีย์ในสำหรับการสั่งคืนรายการบิลซื้อ หรือบิลขาย

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

 

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

 

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

 

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



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

 

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

 



หลักการของโปรแกรมก็คือ เมื่อพบว่า มีการทำรายการที่อาจเกิด error ข้อมูลซ้ำ (วันที่เดียวกัน, เลขที่อ้างถึงเดียวกัน, สินค้าชื่อเดียวกัน แต่ที่เก็บต่างกัน) โปรแกรมจะตรวจสอบว่า เลขทีอ้างถึงนั้น มีที่เหลือด้านหลังหรือไม่ ถ้ามีโปรแกรมจะพยายาม running โดยเติมตัวอักษร A - Z ให้ หมายความว่า ถ้าเราเว้นเลขที่บิลด้านหลังไว้ 1 หลัก เราสามารถทำรายการสินค้าชื่อเดียวกัน แต่ที่เก็บต่างกันได้เพิ่มอีก 26 รายการ ซึ่งน่าจะเพียงพอที่รองรับการทำงาน กรณีสินค้าหลายล็อตในบิลใบเดียวกัน

ถ้าไม่พอ เราก็สามารถเว้นเลขที่บิลด้านหลังเป็น 2 หลัก ก็จะได้ส่วนขยายเพิ่มเป็น 26 x 26 หรือ 676 รายการ

 

 

 

 

 

 


Google