අවුරුදු 10 ක විතර POS ලියපු Experience එකෙන් කිව්වොත් නම් මචො ඔතනට Tigger දාන්න එපා.
උබ ඔය ඇනලයිස් කරපු ව්දියට උබ හිතලා තියෙන්නෙ සාමන්යෙන් පොස් සිස්ටම් එකක රික්වයාමන්ට් එකෙන් 5% ක් විතර, ඉතිරි 95% Develop කරන්න නම් එහෙම කරන්න පුලුවන් විදියට ඉඩ තියාගෙන යන්න ඕන,
ඕක ටිගර් එකක් දාලා හැදුවොත් Stock Table එකෙන් Row එකක් Delete කරන්නෙ කොහොමද ?
Edit කරන්නෙ කොහොමද.
Data Sync වෙද්දි ඕක ගැන වෙනම හිතන්න ඕන,
Distributed system එකක් විදියට එක්ස්පැන්ඩ් කරන්නෙ කොහොමද?
ඒ නිසා කම්මැලි නැතුව SQL Queries දෙකක් ලියන්න,
එතකොට කන්ට්රොල් එක තියෙන්නෙ අපේ අතේ,
නැත්නම් පස්සෙ දවසක කෝඩ් එක දිග ඇරගෙන ඔලුව රිදෙනකල් කල්පනා කරන්න වෙනවා කොහොමද Item Table එක Update වෙන්නෙ කියලා.
කෝඩ් එකේ ඕක තිබ්බා නම් Button එකේ code එක දිගේ ගියාම හැම දෙයක් ම තියෙනවා,
එක ටේබල් එකකට Insert එකක් දෙද්දි අනිත් එකට Update එකක් දෙන්න, වැඩේ ඉවරයි.
එහෙම නැත්නම් Stored Procedure එකක් ලියන්න ඒකට පැරමීටර් ටික දුන්නම වැඩ දෙකම වෙන්න,
සාමාන්ය පොස් සිස්ටම් එකක කරන්නෙ මෙහෙම,
Products කියලා ටේබල් එකක් තියෙනවා ඒකෙ තියෙන්නෙ
ItemCode,ItemDescription,ItemCost,ItemPrice ඔයාගෙ සිස්ටම් එකේ හැටියට එන්නෙ
0001,Apple iPhoneX 256GB Silver,100,150'
ඔන්න ඔන කලම්ස් ටික,
ඊලගට Purchasing වලට ටේබල් එකක් තියෙනවා එකේ තියෙන්නෙ
ItemCode, PurchaseQty සහ අනෙකුත් විස්තර (date,supplier, invoice numbers,)
0001,3
තව Table එකක් තියෙනවා Stock එකට
ඒකේ තියෙන්නෙ
ප්රඩක්ට් එකේ කෝඩ් එකයි, අපේ ස්ටොක්ක් එකයි.
ItemCode,StockQty
00001,1
Purchase කරාම අපි කරන්නෙ මුලින්ම Purcshacing table එකට ඒ විස්තර දාගන්නවා.
ඊට පස්සෙ Stock Table එකේ දැනට ස්ටොක් එකක් තියෙනවා නම් ඒක අප්ඩේට් කරනවා නැත්නම් ඉන්සෙර්ට් කරනවා. ඔය වැඩ 3 ම කරන්න එක Stored Procedure එකක් හදාගත්තා නම් හරි.
සාමාන්ය POS එකක නම් Item Table එකේ තියෙන්නෙ Code එකයි Description එකයි විතරයි.
ප්රයිස් තියෙන්නෙ වෙනම ටේබල් එකක, මොකද එකම අයිටම් එකට ප්රයිස් දෙක තුනක් තියෙනවා කොස්ට් දෙක තුනක් තියෙනවා.
කලර් එක සයිස් එක තියෙන්නෙ වෙන ටේබල් එකක, එකම අයිටම් එකේ සයිස් කලර්ස් වෙනම එනවා වගේම වෙනම තියාගන්න ඕන ඒවගෙ ස්ටොක්ක්.
මේ වගේ ටේබල් බරගානක් තියෙනවා
අන්තිමට Data ඔන වෙලාවට join කරලා ගන්නවා,
image