跳到主要內容

[Issue]網路標錯價 業者須出貨

參考的資料
---
討論主題:[電子商務]網路標錯價 業者須出貨
時間:2010/11/18       發表人: ◎張佳瑜律師
  
  隨著電子商務的興起,網路標錯價事件時有耳聞,近兩年來發生的幾起重大事件,例如2009年6、7月間連續二起戴爾電腦標錯價事件、2009年7月易 遊網大阪自由行產品標錯價、2009年9月特力屋禮券標錯價、2010年7月蘋果電腦標錯價事件等等,引起眾人對於網路標錯價爭議處理的注意及關切。事件 發生之後,一些消費者為維護自身權益,也透過訴訟程序請求業者依網路標價履行契約,訴訟結果則是消費者與業者各有勝負(註一)。

  有鑑於網路交易活動日趨熱絡,經濟部在今年6月21日以經商字第09902412200號函文公告「零售業等網路交易定型化契約應記載及不得記載事項」,並將於明年 1月 1日生效(註二),其中,與網路標錯價爭議處理較為相關之規定則在應記載事項的第五項及第六項。

  按照應記載事項第五項「確認機制」之規定:「消費者依據企業經營者提供之確認商品數量及價格機制進行下單。企業經營者對下單內容,除於下單後二工作日 內附正當理由為拒絕外,為接受下單。但消費者已付款者,視為契約成立。」,故在網路標錯價之情形,業者可以持正當理由,於2天內拒絕消費者下單,但若消費 者已付款完成(此付款完成主要指轉帳和匯款,不包括信用卡付費之情形,因信用卡公司付款予業者通常須1週以上之時間,絕對超過2天),契約即成立,業者就 不得取消交易。至於何謂「正當理由」,消保會則表示業者最常掛在口中的錯標原因是「Key in錯誤」,這類漫不經心的情況,不會被認為是正當理由,所謂正當理由是指外力影響,譬如程式被駭客入侵。

  另外,應記載事項第六項「商品訂購數量上限」之規定:「企業經營者於必要時,得就特定商品訂定個別消費者每次訂購之數量上限。消費者逾越企業經營者訂 定之數量上限進行下單時,企業經營者僅依該數量上限出貨。」,即係為避免消費者趁著業者標錯價之際,故意大量下單,從中圖利,造成業者重大損失。



創建國際法律事務所

留言

這個網誌中的熱門文章

[WEB]連線 HTTPS 網站發生驗證失敗導致基礎連接已關閉

某支透過 WebClient 物件去呼叫第三方API的程式,突然有天無法使用 經過測試出現下列的錯誤 基礎連接已關閉: 傳送時發生未預期的錯誤。 InnerException : 驗證失敗,因為遠端群體已經關閉傳輸資料流。 原來是第三方的服務已經不支援 TLS 1.0 我方的程式是用.net Framework 4.0開發了 得強制讓webclient改用 TLS 1.1 或 TLS 1.2 感謝黑大提供解決方法 在程式中加入 ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12  的設定就解決了這個問題 WebClient wc = new WebClient(); ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; 參考資料:暗黑執行緒

[SQL] SQL依照你的排序條件 找出目前資料的前一筆與下一筆。 Find Pre and Next DataRows of current Datarow by your order condition

有時候需要用SQL找出前一筆跟後一筆資料 用SQL的TOP是沒有辦法做到 這個時候就可以這個語法 select * from ( SELECT TOP 1 * FROM [Article] where Poid<{CurrentPoid} order by CreateDate desc) t union select * from ( SELECT TOP 1 * FROM [[Article] where Poid>{CurrentPoid} order by CreateDate ASC) t2 找出目前PK id前一個與後一個的資料(依照想要排序順序) 那如果指示想要一個資料行呈現的話 可以改用下面的SQL語法 讓這兩筆資料join在同一筆 select Pre.*,Nex.* from (SELECT TOP 1 * ,1 tID FROM [dbo].[Article] where Poid<{CurrentPoid} order by CreateDate desc) Pre left join (SELECT TOP 1 * ,1 tID FROM [dbo].[Article] where Poid>{CurrentPoid} order by CreateDate ASC) Nex on Pre.tID=Nex.tID

[IIS]IIS - ASP.NET 網站基本優化設定 --筆記

運行 ASP.NET 基本上都是掛載在 IIS 上面,但 IIS 預設的設定,並不適合 24 小時不中斷的營運系統。 如果沒有適當的調整,可能會造成使用者的感受不佳,而你又偏偏不會遇到。 本篇將介紹 IIS 運行 ASP.NET 網站的基本優化設定。 應用程式集區 打開 IIS 管理員,到應用程式集區,選擇網站後,開啟進階設定: 1. 一般 (General) 佇列長度 (Queue Length) 預設值是  1000 ,當封包數量在同一時間到達該指定值,之後的 Request 都會變成 HTTP Status 503 Service Unavailable。 例:當有同時間有 1001 個 Request 一起送到 IIS,第 1001 個 Request 會直接回傳 503,不會進到 ASP.NET 處理。 也不是無限大就好,也是要看伺服器等級。 假設調成 10000,也真的有同時 10000 的量,可能會演變成  CUP High  的問題。 因此,這個欄位沒有建議值,網站封包量很大才有需要調整這個欄位。 啟動模式 (Start Mode) 預設值是  OnDemand ,當網站執行回收後,會等到第一個 Request 進來,IIS 才會把網站啟動。 所以第一個連上來的使用者會等到比較久的時間,ASP.NET 初始化完成後,使用者才會得到回應。 建議設定成  AlwaysRunning ,當網站執行回收後,IIS 就會直接啟動 ASP.NET。 2. 回收 (Recycling) 固定時間間隔 (Regular Time Interval) 預設值是  1740 ,也就是每隔 29 小時 IIS 就會把該網站重啟。 很可能重啟當下使用者正在操作,對於要 24 小時不中斷的系統來說,這真的是很不妥當的事情。 如果 ASP.NET 的 Session Mode 是用 InProc,網站重啟使用者就全被登出了。 建議設定成  0 ,也就是關閉定期重啟網站的設定。 如果網站真的需要定期重啟,可以在 特定時間 (Specific Times)  設定,固定每天哪些離峰時間做重啟的動作。 3. 快速失敗保護 (Rapid-Fail Protection) Enabled 預設值是