第25個冬天

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 DECLARE @collist NVARCHAR( max ) ,@ schema NVARCHAR( 128 ) ,@ table NVARCHAR( 128 ); SET @ schema = N 'dbo' ; SET @ table = N 'table name' ; SELECT @collist = STUFF(( SELECT N ', ' + CHAR ( 13 ) + col.name + N ' ' + typ.name + CASE WHEN typ.name IN ( N 'nchar' ,N 'char' ,N 'binary' ) THEN '(' + cast (col.max_length AS VARCHAR ) + ')' WHEN typ.name IN ( N 'nvarchar' ,N 'varchar' ,N 'varbinary' ) THEN CASE WHEN col.max_length = - 1 THEN N '(max)' ELSE CASE WHEN typ.name IN ( N 'varchar' ,N 'va

通常產品對應不同顏色我們習慣設計 將顏色資訊與產品資訊分開存儲，避免了重複儲存顏色描述。 分割成兩個表格，每個表格負責一個特定的資料實體，使得資料庫的維護更加容易。 第二種表格架構中，Product 表格依然負責儲存產品的基本資訊，但不再直接包含顏色資訊。 第二種表格架構需要額外的Product_entry 表格來關聯產品與顏色，產品的顏色資訊儲存在 Product_entry 表格，它關聯了 Product 表格和 Color 表格的外鍵，通過 product_id 關聯到 Product 表格的產品識別碼，ColorId 關聯到 Color 表格的顏色識別碼。 Color 表格獨立存儲顏色資訊，每個顏色都有一個唯一的 ColorId 作為識別碼，並有ColorDescription 來描述該顏色。 第二種表格架構允許你更靈活地處理產品和顏色之間的關聯，例如一個產品可以有多個顏色，或者一個顏色可以用於多個產品，這樣的設計更適合一對多或多對多的關聯關係。 後續延伸 可以試想一下 顏色 尺寸 材質 是既定的一個清單(選單)值域 每一個我們都可分配一個編號對應相應屬性 產品對顏色會存在多對多關係中繼表 產品對尺寸會存在多對多關係中繼表 產品對材質會存在多對多關係中繼表 多對多關係中繼表可同時保有跨兩個以上table的PK主要用於做產品對應不同規格類別的映射 為何不直接將顏色定義於產品table 主要就是因為可能你要維護此顏色 對此產品很多次 而且顏色也不適合直接類似將顏色產品規格直接定義死在產品主檔中 比方雨衣這個產品可能你直接有一個顏色 多對多關係映射中繼表(Many-to-Many)

最近維護系統剛好變數名稱或一些欄位都很常看到他們，就稍微來多認識背後機制好了。 有時註解一部分或多增加一個判斷看似沒捨麼，卻不曉得背後涉及的範圍影響層面水真深。 信用狀L/C (Letter of Credit) 指進口地銀行(開狀銀行)應顧客(通常為買方)的請求與指示，開給第三人(通常為賣方)的一張附有條件的付款保證文書。銀行向第三人承諾，如果該第三人能履行該文書所規定的條件，並提示對應之單據，即可獲得開銀行的付款擔保。 承兌交單D/A (Documents against Acceptance) 此方式與D/P類似，唯代收銀行收到貨運單據及匯票時，僅通知買方在匯票上承兌，即交付單據給買方辦理提貨手續，待規定付款期限到期時，再行付款。 憑單據付款 CAD (Cash Against Documents) /付款交單D/P (Documents against Payment) 賣方按照買賣契約之約定，於貨物裝運後，開出匯票連同貨運單據(如提單、商業發票、包裝單等)，委託其往來銀行寄交進口地的銀行代向買方收取貨款，而買方則必須先付清貨款後，始能取得單據辦理提貨手續。 將貨運單據(如提單、商業發票、包裝單等)於出口地交予買方或其代理人時，即可自買方或代理人處取得貨款。 貨到付款 COD (Cash On Delivery)->這應該比較好理解日常生活很常用。 貨物裝運後，賣方或其代理人將貨運單據(如提單、商業發票、包裝單等)交予買方辦理提貨手續後，始可自買方處取得貨款。此種付款方式風險比較大，適合於金額不大的交易。 國際貿易中採用此種付款方式的甚為少見，一般僅見於空運出口情況。買賣雙方約定以COD方式付款，賣方托運貨物時，委託承運人代收貨款，航空公司將貨物運到目的地後，即通知買方付款提貨，然後再由航空公司將代收貨款轉交賣方。 預付貨款 CIA (Cash In Advance 或 Payment in advance) 買方於買賣契約簽訂後即將貨款之全部或部份直接交付賣方或透過銀行匯給賣方，賣方收到貨款後始安排出貨事宜。 電匯T/T(Telegraphic Transfer),是指匯出行應匯款人申請，拍發加押電報\電傳或SWIFT給在另一國家的分行或代理行(即匯入行)指示解付一定金額給收款人的一種匯款方式。 NET 30 days  這裡的Net指的不是Inte

於該Model類別上標記[NotMapped] 即可忽略 使ViewModel不會同樣一起migrate到DB中 還有一種可能就是去檢查你的DbContext裡面是不是有誤定義DbSet包進ViewModel EF Core Ignore https://www.learnentityframeworkcore.com/configuration/fluent-api/ignore-method ignore one table with ef-core migration https://stackoverflow.com/questions/64979208/ignore-one-table-with-ef-core-migration How to exclude one table from automatic code first migrations in the Entity Framework? https://stackoverflow.com/questions/22038924/how-to-exclude-one-table-from-automatic-code-first-migrations-in-the-entity-fram EF Core 筆記 2 - Model 設計 https://blog.darkthread.net/blog/ef-core-notes-2/

  把驗證的機制去掉，就允許中文了 Ref: https://www.cnblogs.com/wjx-blog/p/14765249.html

  目前chrome跟edge瀏覽器 用早期的解套方式autocomplete="off"讓自動帶出過去有填寫過的歷史資料不要出現 已經無效了 因此需要更改成 autocomplete="new-password" 這邊實測有效果 Ref: How to disable autocomplete of an HTML input field ? https://www.geeksforgeeks.org/how-to-disable-autocomplete-of-an-html-input-field/ disable-form-auto-complete.md Definitive guide → 6 ways to solve https://gist.github.com/eduardo-mior/ad14cab17fb5ab641812bff622534353 https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion 分享autocomplete="off" 不起作用解决方案 https://zhuanlan.zhihu.com/p/265024915 浏览器的记住密码，autocomplete= "new-password"解决 https://blog.csdn.net/aydongzhiping/article/details/81562757 'autocomplete="off"'在Chrome中不起作用解决方案 https://blog.csdn.net/xw505501936/article/details/52129579 input 输入框禁止自动填充-不是 autocomplete="off"不好用，是你没用正确方式打开 https://www.jianshu.com/p/06def8ad2347 解決autocomplete="off" 失效的問題 https://juejin.cn/post/6904199428543315981

摘自:  https://www.100.com.tw/article/1344 無論哪個行業只要有涉及材料，成本估價則必定是一項難題和必定要管控的課題。 可在參考之前文章 何謂商品?可以賣的東西就叫商品嗎?_原料與物料如何區分? BOM產品結構中低階碼的應用與概念 中小型系統家具業主要時常遇到的困難就在於 每一個材料的經銷商、廠商都不同，還涉及需要客製化訂做的問題。 所以資料建檔跟以往可能固定製造商產業PDM系統有固定產品種類對應規格維護比較不同 也跟3C產業製造業固定電腦產品規格組一台一樣，因為每個屋主(客戶)都有不同的空間環境。 所以也沒辦法用類似製造業BOM概念來去思考 因為不像製造業固定規格大量製造，是每次都要訂做的。 而且不同廠牌對應材積價格是會浮動的,稅也是....(稅的問題可能暫時先不考慮進來>~<) 那excel會因為不同權限控管和不同時段維護超多份... 再來資料聯動困難性 系統家具業軟體層面系統導入會涉及到的電子單據-估價單 系統家具業通常於估價單單身中每一筆代表著所謂施作項目(會有對應不同施作工法) 每一個施作項目會有不同建材(在科技、製造業稱為 : 料件、原料) 每一個建材會有不同規格屬性、不同的品牌會去影響其單價 這個產業中會有一些不同設計師權限 總監設計師 店長設計師 (每一間分店會有細分不同小組,每一個設計師會分別去負責不同估價單， 每一個主任設計師負責他那一組的業績) 組1.[主任設計師>專案設計師>助理設計師] 組2.[主任設計師>專案設計師>助理設計師] 組3.[主任設計師>專案設計師>助理設計師] ... 組N.[主任設計師>專案設計師>助理設計師] 裝潢估價通常會有以下SOP Step1.確認施作範圍 Step2.確認公司名稱、地址與聯絡電話 Step3.確認客戶名稱 Step4.確認數量 Step5.確認單位 Step6.確認規格 Step7.確認建材等級 Step8.確認施作工法 Step9.確認單價無誤 所以估價單單頭通常就會列像是 哪位設計師、設計師電話、哪個屋主(客戶)、聯絡方式(電話,Email)、地址 、工地地址(可能需額外訂出來通常不一定就等同聯絡地址)、報價日期等等 以下面估價單單身為例後可能就有 像是衣櫃、書桌等等施作項目各自有對應不同施作單位與

工作中時常遇到的情況就是在跨不同支SP中跟一堆不太熟悉的table混熟 有時還可能遇到SP中再下一層又去call了其他支SP的窘境 層層reference 業務邏輯都寫在Store Procedure情況 不利於debug .... > ~ <||| 但又必須去理解和盤點一些table 的reference情況 資料源頭 各欄位是捨麼定義的時候 就可能需要想一些辦法 沒辦法母公司那裏要幹嘛就多少也要follow 盤點某張table資料insert來源 1 2 3 4 5 SELECT DISTINCT so.name , LOWER (sc. text ) FROM syscomments sc INNER JOIN sysobjects so on sc.id = so.id where LOWER (sc. text ) like '%insert%' and LOWER (sc. text ) like '%{table名稱}%' and ( LOWER (sc. text ) like '%insert {table名稱}%' or LOWER (sc. text ) like '%insert into {table名稱}%' ) 盤點某張table資料delete時機 1 2 3 4 5 SELECT DISTINCT so.name , LOWER (sc. text ) FROM syscomments sc INNER JOIN sysobjects so on sc.id = so.id where LOWER (sc. text ) like '%delete%' and LOWER (sc. text ) like '%{table名稱}%' and ( LOWER (sc. text ) like '%delete {table名稱}%' or LOWER (sc. text ) like '%delete from {table名稱}%' ) 如何去察看某個database objects (可能是table,sp,trigg

如何去找尋某一關鍵字子字串出現在哪幾張table 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 DECLARE @ SearchStr nvarchar( 100 ) = '關鍵字字串或數值也可以' DECLARE @ Results TABLE (ColumnName nvarchar( 370 ), ColumnValue nvarchar( 3630 )) SET NOCOUNT ON DECLARE @ TableName nvarchar( 256 ), @ ColumnName nvarchar( 128 ), @ SearchStr2 nvarchar( 110 ) SET @ TableName = '' SET @ SearchStr2 = QUOTENAME( '%' + @ SearchStr + '%' , '''' ) WHILE @ TableName IS NOT NULL BEGIN SET @ ColumnName = '' SET @ TableName = ( SELECT MIN (QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME( TABLE_NAME )) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE' AND QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME( TABLE_NAME ) > @ TableName

戰略性高科技貨品輸出許可證 EXPORT PERMIT OF STRATEGIC HIGH-TECH COMMODITIES 輸出許可證號碼 :Export Permit No. 轉口港:Transit Port 許可證簽證日期 :Date of Issue 出口管制貨品號碼 : Export Control Commodity No. 貨品分類號列及檢查號碼 : C.C.C. CODE standard Classification of Commodities of the Republic of China 戰略性高科技貨品(SHTC) https://www.facebook.com/boft.gov.tw/posts/1453119258203129/ Ref: https://cfgate.trade.gov.tw/boft_pw/do/PW401ShowFileAction;jsessionid=E7514F375D7467D97C1B35B86CEB71BE?fileName=5&check=1 https://www.tnet.org.tw/Article/Detail/29933 https://fbfh.trade.gov.tw/fh/ap/queryCCCRegFormf.do

 (一)保險大數據與物聯網之應用 保險公司透過多年來累積的大量數據資料，並運用感應裝置結合物聯網技術，發展出「使用基礎保險」(Usage-Based Insurance，簡稱 UBI)。其中 UBI 保險又分別在產險及壽險兩方領域個別發展出新型態之保險商品，分別為 1.UBI車險 保險科技應用於產險之上，則以 UBI 車險為代表。與傳統的汽車保險相比，UBI 車險保單最大之差別在於保費的計算依據，透過行車紀錄器做為感應裝置，蒐集駕駛人之行駛里程、駕駛時段、駕駛習慣等數據，並依據駕駛人對各項車險訂價的因素影響，從而對該車險保單保費與折扣進行計算。 台灣的 UBI 車險市場自從 2016 年由泰安產險推出國內第一張 UBI 車險保單以來，迄今銷售近 6 千張保單。除了泰安產險外，目前尚有富邦產險、國泰產險以及和泰產險共計 4 間保險公司進入該市場。其中泰安產險於 2016 年共推出兩代UBI 車險產品:以里程為計價依據(PAYD)的保單以及與鴻海旗下的創星物聯合作推出的 OBDII 車載裝置，透過 OBDII 裝置蒐集保戶駕駛時段及駕駛習慣(PHYD)的保單，亦是目前唯一一間提供以 OBDII 作為紀錄的保險公司。我國目前所發行的 UBI 保單主要是藉由手機 APP 來蒐集駕駛行為，對於保戶而言相對較容易取得，對保險公司而言開發成本也相對較低。 目前 UBI 車險創新度較高的為和泰產險所開發的以煞車來令片(保養紀錄)為依據的保單。透過保戶定期回廠保養的紀錄來檢視保戶的實際駕駛習慣，除了免除安裝成本之外保戶亦無任何其他負擔。 然而，在臺灣，目前 UBI 車險仍面臨誘因機制不足的問題，進而導致保險公司缺乏足夠數據來做更準確之訂價，故期望未來能建立起車聯網生態系，結合周邊相關服務如停車、道路救援等，以此提升附加價值，乃能吸引更多客戶。業者也應思考如何以客戶的角度出發，建立保費折扣以外的誘因機制。 2.智能健康管理外溢保險 2-1.「健康外溢強體保單」 所謂外溢保單指的就是保單除了有保障功能外，還具有「外溢效果」。 以「保費折扣」、「增加保額」或「回饋金」等方式鼓勵民眾養成規律運動、健康生活的習慣 降低保險公司理賠率、國人罹病率和保戶的保費支出 哪些險種有外溢保單？ 結合外溢機制的險種為「健康險」，如醫療險、癌症險、重大傷病險、長照險 針對身體風險健康強度又細分為: 「健康外溢

  (二)區塊鏈之應用 保險機構負責核保、理賠與再保等，管理與運營成本高，透過智能合約的應用，既無需投保人申請，也無需保險公司批准，只要觸發理賠條件，實現保單自動處理。 就保險之應用面，除了能透過區塊鏈的加密機制，防止登錄於區塊鏈賬本中保險人與消費者間的數據被任意竄改，提升保戶對於電子保單的信任度外，區塊鏈技術也能以「分散式帳簿」概念使用「智能合約」以執行保險運作理賠之方式，藉由智能合約特性清楚記錄中間每一筆交易帳，並保留完整的交易記錄，同時還具有快速理賠之效果。區塊鏈去中心化、透明、不可竄改的特性，在保險營運中亦有多元發展空間，除了可以改善資訊不對稱問題，減少逆選擇及保險詐欺外在實務應用上更是可以協助保險公司優化其保單作業流程，亦同樣適用於在保險業者跨公司之間的整合。以保險業之間的再保險行業為例，現有的再保險締約制度極為繁雜。再保合約往往需花費保險公司及在保險公司數月的時間進行洽談及訂定契約，且多半涉及到超過一家以上的再保險公司。然而，每一間再保險公司的文件及內容標準皆不盡然相同，不同的標準衍生出合約執行上的差異，降低了再保險業交易效率。 2016 年 10 月由安聯保險、慕尼黑再保險、瑞士再保險、Aegon以及蘇黎世保險共同發起的區塊鏈保險聯盟(B3i，Blockchain Insurance Industry Inutiative)目前已有 18 位成員均為保險或再保險業的主要參與者。B3i 所創立的區塊鏈再保平台，針對傳統再保險業的高度中介化、資訊無法 即時更新等痛點透過區塊鏈的分散式帳本技術，讓在保險的各個交易方都可以 維持同一本帳本，減少雙方交易之間的重複動作並即時更新資訊，降低成本並提高交易效率。 傳統的再保險交易需仰賴再保險經紀人蒐集再保險交易中雙方之 間的數據及文件資料，並進行媒合達成合作交易。而以區塊鏈發展為基礎，衍生的智能合約(Smart Contract)則可以優化核保及理賠過程，有效降低人力成本及潛在的人為疏失風險，提升效率及準確率並節省保險公司營運成本。 以產險的旅遊不便險為例，在傳統理賠流程上，過往保險事故發生時，被保險人需自行填寫理賠申請及備妥相關證明文件，並由專業人士鑑定是否屬於承保範圍及損害程度，過程相當耗時。智能合約則可以將傳統的紙本契約轉成自動化契約，透過特殊的程式編碼撰寫方式將理賠程序簡化並自動化，當保險事故發生時由系統主動

應收模組(AR,Accounts Receivable) 此模組主要都跟客戶相關業務處裡 客戶的定義 狹義:從企業購買產品的對方單位 廣義:與企業有債務關係(不管關係是否由一段購買商品互動形成)的對方單位或個人。 (SAP ERP中用的概念是以廣義層面，比方對企業形成欠款的供應商或借款的員工) 客戶基本訊息維護(客戶名,地址,通訊資訊) 客戶財務相關訊息維護(統馭科目,公司代碼,付款條件) T-Code: BP 針對客戶主數據維護 Create Customer (T-Code:FD01) 主要業務流程: 發票開立,收款清帳(客戶,供應商餘額對清),預收訂金,票據處理(貼現,背書,到期承兌) 發票開立方式中，又可細分為兩種 1.財務手工開發票(適用場景:廢品銷售,固定資產銷售)->無前置單據(沒有跟銷售整合) 發票過帳(T-Code:FB70/F-22) -> 收款清帳(T-Code:F-28) 對客戶開具發票(手工陸入發票):FB70 不生成發票憑證，只生成會計憑證。 2.銷售整合開票(適用場景:一般銷售產品、服務) 銷售合同(T-Code:VA41)  -> 銷售訂單(T-Code:VA01)  -> 撿(貨)配 (T-Code:VL01N)  -> 交貨過帳 (T-Code:VL02N)  -> 開發票 (T-Code:VF01)  -> 發票過帳 (T-Code:VF02)  -> 收款清帳(T-Code:F-28) 清帳則又分為以下三種 收款清帳 , 預收清帳 , 票據清帳 Ref: https://blog.csdn.net/weixin_42646630/article/details/121080519

應付模組(AP,Accounting Payables) 負責對供應商的所有財會資料做管理也和採購模組有整合一部分，收貨與發票則可按照供應商單獨進行管理。業務操作完成後，系統會自動更新總帳。 供應商定義 (應付模組的基本，因在處裡發票與付款時候需針對哪個供應商進行發票開立與付款) 狹義:指企業購買物品(材料、辦公用品)的對方單位。 廣義:指對企業而言有債務關係(不管關係是否由一段購買商品互動形成)的對方單位或個人。 (SAP ERP中用的概念是以廣義層面) 供應商主數據維護(財務專用) Create Vendor (Accounting)創建 T-Code:FK01 (只有公司代碼視圖) Change Vendor (Accounting)更改 T-Code:FK02 Display Vendor (Accounting)顯示 T-Code: FK03 Vendor Changes (Accounting) T-Code:FK04 Block Vendor (Accounting) T-Code:FK05 Ref: https://fenginfo.com/920.html https://finance.utoronto.ca/knowledgecentre/s4-hana-business-partner-display-vendor-master-records/ https://skillstek.com/sap-fico-tcodes/

嘜頭(SHIPPING MARK) 印製於貨物外箱的運輸標記，目的為裝貨或領貨時『辨識』之用。 若沒有適當的貨物標記，物流與供應鏈管理就會出現混亂，比如說貨物錯運、上錯船、與不正確的貨群一起被運到不正確的港口，甚至遺失。  “嘜頭”（Mark） 細分的話可以分成兩個部分『正嘜』及『側嘜』 『正嘜』 指箱子或貨物擺放時正面對著外面，也就是最容易看到的那一面，大部分是由一個簡單的幾何圖形(菱形)、英文字母、數字及文字組成。 通常會涵蓋以下資訊: 1.收貨人英文縮寫(搭配圖型) 2.國外目地港口 3.貨物件數箱號 4.原產地標示 『側嘜』 將運輸時的其他細節內容填寫在此 通常會涵蓋以下資訊: 品名、規格、數量、毛重、淨重、貨物尺寸…等。 貨物嘜頭標示應注意事項 出口貨物須於產品外包裝上製作嘜頭標示 輸往美國即有邦交國家，應標示[中華民國製造]或MADE IN TAIWAN R.O.C. 輸往美國以外無邦交地區，應標示[台灣製造]或MADE IN TAIWAN. Ref: https://www.jsc-service.com.tw/article/83 https://www.jsc-service.com.tw/article/86 https://www.jsc-service.com.tw/article/56 https://wan-yo.com/zh-hant/export-mark-types/ http://customs-assoc.org/61.htm https://top.onlinetoknow.com/article/cargo-marking https://jingsourcing.com/b-shipping-marks-in-internatioal-trading/ https://ship.pinpin.tw/shipping-marks-invoice-packing-list/

 會計總帳與其他系統模組關聯 會計系統 一般會計總帳作業流程 首先要先將基本資料維護好 比方像是財務參數、幣別匯率建立、幣別轉換匯率、 會計系統參數、會計期間設定、科目資料建立作業、單據性質設定等等 之後就是日常作業主要分為 會計傳票建立 常用傳票建立 傳票整批過帳 已過帳傳票還原作業 已過帳傳票重新還原作業 其他和日常作業「會計傳票建立」處理有關的管理作業 像是 立沖帳目管理 預算管理 利潤中心管理 遞延收入管理(IFRS) 營運部門管理 此外若有系統中維護屬於開兩家以上公司情況 還包含了「多公司帳務處理」 當中提供公司別傳票複製作業，利於後續會計帳冊有要合併的業務。 當傳票過帳動作完成後 系統就會自動接續將登入過帳到 總分類帳 明細分類帳 帳戶式資產負債表 和會計科目主檔 其餘可能還有其他現金流量表、銷貨成本表、財務分析表 當產生的這些報表核對沒問題後就要進行每月的帳務月結程序 透過月結讓系統自動產生當期的損益 同時也為了避免正確資料有被異動到的問題 可執行關帳作業來把會計帳冊關閉 [基本資料維護-財務參數設定] 主要用於設定會計系統目前作帳年月 會計期制:12,13期 12期:台灣現行稅制，指一年有12期，如歷年制、學校單位的7月制。 13期:外商公司的稅制，指一年有52週，四週唯一期。 會計現行年、月(期別) 1.系統於開帳時只需設定開帳年度與期別 2.若在執行「月底結轉作頁」時候，系統會判斷期別，若為當年度最後一期，則自動將會計現行年度加一。 3.系統允許輸入現行當期及之後的傳票，補入之前傳票後，需執行過帳以確保資料之正確性。 會計關帳年、月(期別) (PS:設定後，不可新增、修改、刪除關帳前期以前的傳票，如有需修改則要調整關帳期別。) 1.會計師已簽核之財務報表，確定不再更動帳務者，則不許修改關帳當期及之前的傳票資料。 2.手動維護關帳年期為送簽資料的最後一個月，或透過「會計系統/指定關帳作業」自動修改。 會計傳票作業流程 會計傳票建立作業目的 用於記錄公司平日交易分錄 會計傳票過帳條件 1.已確認傳票 2.未過帳傳票 3.借貸平衡(借方本幣總金額 = 貸方本幣總金額) 4.傳票日期所屬的年度期別大於會計關帳年度、關帳期別(在關帳年月以前不可執行過帳確認) 通常例行性交易資料事項、非例行性資料交易事項或期末調整事項 都會透過自動分錄拋轉、手動輸入，或送交