第25個冬天

 登入LINE 開發者帳號後台後 創建一個provider 在一個provider底下可以建立多個linebot 接著就是在此provider下產生channel 選擇messaging api 上傳linebot頭貼然後選定國籍跟相關屬性設定 還可設定大分類跟次分類 當建立好LineBot後 會有一個basic ID 使用者可藉由此ID來將此linebot加入為好友 或用QrCode來分享加入 webhook url 主要就是將將訊息跟linebot兩邊整合就是藉由webhook 須等到我們開發好程式後將網址回填 藉此就能將訊息轉接到指定的URL (有點類似公開API) 哪位user發送、發送捨麼訊息等等... 可不需要馬上填，等開發一個段落或有位置轉移在來後續編輯 LineBot如何得知使用者有訊息傳過來? 何謂webhook? 早期作法:定時向Line Platform詢問(Polling , 輪詢)看是否有使用者發訊息來 每隔10秒來向line平台詢問 此種作法會導致 訊息不即時(有可能在10秒內就有訊息) 資源浪費(有可能長達快60秒都沒有訊息那還發請求詢問其實沒必要) 因此Line平台自行開發自動通知 也就是一個開放式API當有訊息進到line platform時候，line platform就經由此API來通知line bot 唯一種訂閱概念，LineBot去訂閱Line Platform，當有訊息進到line platform(中繼站)，就會讓line bot接收到通知，當中透過webhook來勾稽。 Webhook為一種http溝通模式，當某種條件吻合時候就會藉由http post傳送通知給訂用戶。 Channel Access Token的取得 Ref: https://speakerdeck.com/line_developers_tw/line-bot-developer-guideline-chinese 後續更新進階內容為付費家教學員所有 LineBot Messging API串接_Part1._Webhook_Ngrok使用 https://coolmanwinter28.blogspot.com/2023/09/linebot-messging-apipart1webhookngrok.html?zx=e68495cecc2b709

程式 1 2 3 4 5 6 7 8 9 10 11 12 DECLARE @tbl TABLE (Column1 VARCHAR ( 100 )) INSERT INTO @tbl SELECT '1/1' UNION ALL SELECT '1/20' UNION ALL SELECT '1/2' select * from @tbl SELECT SUBSTRING (tbl.Column1, 0 , CHARINDEX( '/' ,tbl.Column1) ), SUBSTRING (tbl.Column1,CHARINDEX( '/' ,tbl.Column1)+ 1 ,LEN(tbl.Column1)) FROM @tbl AS tbl

1 2 declare @string varchar(20)= '0.0775000' Select LEFT (@string,LEN(@string)+1 - PATINDEX( '%[1-Z]%' ,REVERSE(@string))) 上一個版本會將10.00000變成1 用以下這版 declare @string varchar(20)= '10000.0102000' Select LEFT(@string,LEN(@string)+1 - PATINDEX('%[1-Z.]%',REVERSE(@string))) Ref: https://stackoverflow.com/questions/2938296/remove-trailing-zeros-from-decimal-in-sql-server https://stackoverflow.com/questions/46531742/remove-text-within-parenthesis-in-sql https://dba.stackexchange.com/questions/185571/remove-dot-at-end-of-line-of-the-string-in-sqlserver

到政府公開資料平台網站 下載範本 此範本資料量較少但是很好的資料範本 https://data.gov.tw/dataset/164152 主要欄位說明 信用合作社別、總部分支機構別、金融代號、郵遞區號、所在縣市、行政區、住址、電話 將檔案另存成unicode編碼並更名為test.csv(不然讀取會出現中文亂碼!) 存放到DB Server的C槽temp目錄(可自己指定路徑) 開始撰寫SQL 腳本 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 drop table #bulkInsert --CREATE TABLE #bulkInsert (col1 NVARCHAR(MAX) NULL) CREATE TABLE #bulkInsert ( 信用合作社別 NVARCHAR( MAX ) NULL , 總部分支機構別 NVARCHAR( MAX ) NULL , 金融代號 NVARCHAR( MAX ) NULL , 郵遞區號 NVARCHAR( MAX ) NULL , 所在縣市 NVARCHAR( MAX ) NULL , 行政區 NVARCHAR( MAX ) NULL , 住址 NVARCHAR( MAX ) NULL , 電話 NVARCHAR( MAX ) NULL ) BULK INSERT #bulkInsert FROM 'C:\temp\test.csv' WITH ( firstrow=2, FIELDTERMINATOR = N ',' , ROWTERMINATOR =N '\n' ); SELECT * FROM #bulkInsert firstrow代表要從第幾橫列開始讀入，預設若沒指定會以第一橫列開始所以會把表頭也撈近來。 FIELDTERMINATOR = ','指定列之間的分隔符為逗號，ROWTERMINATOR = '\n'指定行終止符為換行符。 Ref: How to BULK INSERT a file into a *temporary* table where the filename is

產品成本控制模組，主要分: 1.產品成本計畫PCP(BOM、工藝路線) 2.成本對象控制OBJ(同步成本核算包刮計畫成本、實際成本，最終成本核算期間關帳) 3.實際成本核算ACT(物料移動、物料分類帳、物料結算實際成本...) 一般主要流程 定義成本核算變式>滾算物料標準成本>發布標準價格 工藝路線(Routing) : 定義生產流程的結構(工序之順序)，是描述物料加工、零部件裝配的操作順序的技術文件，是多個工序的序列。 工序 :表示工藝路線中帶名稱的步驟，如裝配。 一般而言會先將產品成本結構定義出來，以料工費層面來展延。 常見我們接獲到銷售報價成本要涵蓋範圍主要分為 產品製造成本、管理費用、銷售費用 而目前聚焦於「產品製造成本」這一範疇來深度探討， 主要又能往下拆分為「物料成本」、「人工費用」、「折舊費用」 其他還有可能「物料管理費用」、「製造管理費用」 產品成本結構在成本估算階段是一開始最重要第一步，又可分為 「數量結構」與「價值結構」兩個種類探討 A.「數量結構」 =>這邊探討都沒有涉及錢，主要focus耗時、用量。 A-1.料(聚焦於"用量")->BOM的概念帶入 一個成品向下展延可能又分由半成品跟包裝材料，半成品在下拆原材料等等。 A-2.工費(聚焦於"工時")->工藝路線的概念帶入 ->包含人工工時、機器運轉耗時 B.「價值結構」 物料主數據、成本中心計畫費率

成本中心CO-CCA 實際過帳 實際費用過帳至成本中心分很多種形式，包含費用從其餘模組(比方:FI,MM) 或費用是在CO模組內部過帳的類型(比方:費用在成本中心之間轉移，透過分配/分攤、重過帳) 藉由FI/MM過帳 於FI跟MM模組做一些操作時候，系統會自動產生相應的CO憑證。 而且如果成本對象為成本中心則系統會自動把費用過帳到成本中心。 以下為自動產生CO憑證的操作 1.於FI模組手動輸入涉及初級成本要素的會計憑證(例如:日常費用記帳)，系統 會在產生FI憑證(財務會計憑證)同一時間自動也產生CO憑證。 2.於MM模組的採購子模組建立費用採購訂單，收貨時如果採購訂單 有"收貨時評估"屬性，則除了產生物料憑證外，也會產生相應FI憑證、CO憑證。 3.於MM模組的庫存子模組處裡發料任務(例如:對成本中心發料等)時候，系統會 產生物料憑證與FI憑證，若存貨的對方科目屬於成本要素就還會產生相應CO憑證。 成本中心重過帳 表示費用在成本中心之間轉移，成本會在CO內部流動。 比方可能一筆費用先記入A成本中心，後來又轉移到B成本中心。 通常發生在先前輸入有誤或者也有可能希望費用轉由另一個成本中心承擔。 如果發送方和接收方有跨越費用屬性，換言之，兩方屬於不同功能範圍，可藉由後台設置 來確保CO跟FI的統一。 統計指標記帳 對成本中心的統計指標輸入相應的值，一般在月末輸入，用於分配或分攤循環，給 分配或分攤循環提供拆分成本或費用依據。 若分配、分攤循環規則中使用統計指標，則必須要先對統計指標過帳，才能執行分配或分攤。 類別屬於「固定值」的統計指標，一般只需記帳一次後續都能一直適用。 類別屬於「總值」的統計指標，對於特定月份適用，該月可多次記帳。 分配(distribution)和分攤(assessment) 主要就是將費用從一或多個成本中心(發送方)拆分、發送到其他成本中心(接收方)的 兩種手段。其為成本在不同成本對象之間流動的一種方式。當完成分攤、分配後， 發送方成本就減少而接收方成本增加。 分配與分攤循環之間區別 分配:將發送方成本以原成本要素分配到接收方。分配完成後，接收方以原成本要素接收 發送方的成本。 比方企業用電費用，先歸類到能源類成本中心，再去按照各部門用電比例多少進行分配。 可能品保部門用電占比:30%、生產單位:50%、IT部門:20%，互相

Kafka 是一個訊息佇列中間件,使用 Scala 和Java 編寫。 Scala 是一門多範式、多重編程(Multi-paradigm programming language)的程式語言,一種類Java 的程式語言,設計初衷是實現可擴展的語言、集結成物件導向程式和函數式程式設計的各種特性,可運行在Windows、Linux、MacOS主流平台上。 Kafka 提供的是發布/訂閱者的訊息處理模式,訊息生產者(發布)將訊息發佈到topic中,同時有多個訊息消費者(訂閱)消費該訊息,發佈到topic 的訊息會被所有訂閱者消費。 Kafka 最初是由領英 (LinkedIn)開發, 並於2011年初開源,2012年10月23日由Apache 孵化。 https://kafka.apache.org/ Kafka 主要特點是根據 Pull 的模式來處理訊息消費,追求高吞吐量,可達100萬級的消息處理。 Kafka主要 1.支援向一個特定訊息主題發送訊息 2.多個訂閱者接收來自特定主題的訊息 如附圖1.所示，就是一個地方發布訊息，可以被無數訂閱者接收。 圖1. 生產者將訊息發布到 Topic,而在 Topic 中將數據被分配到不同的分區(Partition)中存儲。 在一個分區內,這些訊息被索引並聯同時間戳存儲在一起,消費者可以從分區中檢索消息。 Kafka 運行在一個由一臺或多台服務器組成的集群上,並且分區可以跨集群結點分佈。 如附圖2.所示 Kafka 整體上可以分為三部分: (1).生產者:主要發布訊息的一方,底層在網路上通過 TCP 協議以Socket 的方式與 Kafka 集群進行通信。 (2).Brokers:集群的方式存儲消息,訊息存儲在文件中,通過主題(Topic)和分區(Partition)組織。 (3).消費者:訂閱訊息,獲取訊息,先發送請求,通過指定主題+分區的方式來確定接收對應的數據。 圖3. Kafka集群:相當於一個中間的訊息轉發(運)站 Kafka集群需有一個Leader，負責來去接收client端請求並做相應處理。 此外還要進行集群管理和資料儲存的事物。 圖4. 如附圖4.所示，以上圖為例，Broker0也就是這一集群的Leader。 內部則是用一個控制器概念來和若干個節點共同實踐資料儲存和請求回應。 Kafka 2.8.0以上就可不用安裝Z

https://www.facebook.com/photo/?fbid=3910383255710456&set=pcb.3910383822377066 今天假設網站服務或功能，老闆問你說如果今天要上雲 有捨麼好處跟壞處呢? 針對財務層面其實有很大差異 傳統上於財務層面分兩種，一種是所謂的「資本支出」(CapEx,Capitial Expenditure) 跟所謂的「營業費用」(Operational Expenditure)這兩個部分。 就傳統而言，比方說公司或團隊要自建機房的話。 你就會需要自己去買設備，因此就有所謂資產概念的產生。 所以他就會出現在所謂的 「資產的負債表」 裡面，那某種程度，會提高所謂的商業價值。 因為你有買東西了，所以商業價值會提高，但也 會有相應的稅收 因此就需要去多支付。 那 通常會透過折舊的方式來減稅 。 因此可以瞭解要購買這些資產需提前花比較大筆的費用來購買，比方可能100台server，那可能就是好幾十萬甚至幾百萬的費用，而隨著時間的拉長，它們開始折舊，時間拖越久，它其實就越沒有價值。 另外一種呢，其實就是所謂的營業的費用，那這個費用其實是出現在 「損益表」 的部分。 那它會減少當季的淨利，所以換句話說呢，你收入會變少，所以你的稅其實某程度會變少。 那最大的好處在於 沒有提前費用的概念 ，而是 用多少花多少費用 的概念。 所以假設一家新創或小型公司要創業，難道要先投入1個100萬來準備設備嗎? 通常不會而雲端剛好可以解套，你能夠自由更有彈性去調節所需的資源規格多寡，甚至設定隨時停用跟啟用服務，當服務停用後就不會有相應費用成本支出的產生。

以下用X軸代表時間，y軸是所需的運算用量。 第一種.On & Off / 開關 假設你今天運算是有開跟關的情況 所以他可能開了一段時間，停一段時間再開一段時間。 那如果是雲端的話，因為你關就不用收費！ 這跟傳統機房對比就相對有優勢 因為若為落地機房的機器本身，你可能沒法這麼有彈性On&Off 此外還有電費租用場地的費用 第二種.Growing Fast 就是你可能一開始用的人不多，可是呢，越到後面 生意做起來了，運算量也隨時間增長，比方像是新創的服務，就非常的適合。 很多新創都不會有自己的機房，直接就用雲了。 第三種.Unpredictable Bursting 突然有一天有一個時間點暴走，然後過一段時間又在往下的趨勢。 像是演唱會要搶票，或是有五倍券之類平台申請服務，特定那一段時間會有突然流量大增。 那不可能我為了那個只有無法預期的特定時段的大流量，我去添購多台機器。 所以使用雲就特別合適，因為只有在那個大量時候我需要把它增加。 只有那時候收費，不用的時候關掉我就不用被收費。 第四種.Predictable Bursting 可預期的大量使用 就有段時間很多，有段時間很少。 假捨是個電商服務可能大家都是在週末買東西，那就週末的時候機器多加幾台。 那如果非週末機器就少一點點。 Ref: https://anwaryounus.blogspot.com/2018/11/azure-overview.html

控制模組CO(Controlling):是SAP系統處理內部會計相關業務的模組之一。 通常也被稱作「管理會計」、「成本會計」。 主要管理會計會是去接收來自財務會計資料做相應數據分析及處理。 又細分以下幾個子模組 A.成本中心會計(簡稱CCA,Cost Center Accounting),CO-CCA B.內部訂單(簡稱OPA,Internal Orders) C.產品成本控制(簡稱PC,Product Cost Controlling),CO-PC D.獲利分析(簡稱PA,Profitability Analysis),CO-PA E.利潤中心會計(簡稱PCA,Profit Center Accounting) 成本控制範圍主要會橫跨到 工廠生產端的PP、庫存的MM兩個模組及財務會計模組FI 控制模組CO(Controlling)主要的組織結構 由最上層到最下層 第一層.經營範圍(Operating Concern) 為CO-PA中最高層次結構，一個經營範圍可以被分配給多個控制範圍。 第二層.控制範圍(Controlling Area) 為管理會計中的組織結構單元，用於核算企業收益和費用支出使用狀況。 控制範圍和公司代碼之間存在1對1或者1對多的可能，通常若有一個控制範圍有跨公司 成本分配的情況就屬於1對多。 第三層.公司代碼(Company Code) 為總帳模組中最重要的組織結構，也是實際業務中會計主體。 成本中心會計CO-CCA 1.主要針對企業某一部門(IT部門、產品部門、採購部門...etc)費用進行記帳、拆分(分配/分攤)和分析。 2.費用會以單一個組織區域即成本中心來追蹤，換言之，成本中心是費用控制的責任單位。 3.可用於對成本中心未來費用做化，以此為基礎，比較計畫費用跟實際費用之間差距 去對成本中心的業績進行考核。 管理會計常見名詞觀念 成本流-Cost flow 用於描述「企業內部成本流動」 以技術層面來探討，其為「管理會計憑證」，借用"借/貸"概念，以此反映捨麼性質的成本由哪流向何處。 常見的「管理會計憑證」如:統馭憑證、獲利分析憑證、利潤中心憑證...etc 此外，管理憑證無借貸必相等的概念，允許存在「單邊憑證」。 成本物件(對象) Cost Object 為成本流的源頭和目的地 在SAP中成本對象如下: CTR(成本中心

批號 刻號 BIN等級 特性名稱設定作業(5個頁簽,共51個特性) Operation建立作業 ROUTING資料維護

  開啟swag文檔 比對對應chrome 記得添加debugger; 手剎車 放置再要停頓的地方之後添加監看式比對各自型別 從前端送到後端的要求規範是否一致 像這邊就是 regionPrice 前端用字串call但後端接收型態要求為數值類