發表文章

Domain Know-How_鼎新ERP_採購流程筆記

圖片
以下是鼎新Workflow的採購流程 工程/研發單位會有原物料需求,因此會開立請購單請採購人員採買。 當採購人員收到請購單通知後,突然發現部分料件過去不曾買過,沒有建立過歷史資料,Database不夠齊全,此時就需要進行廠商的詢比議價。 在詢比議價過程,可能還會顧慮到比方食安或包材,塑化劑、瘦肉精議題。 或更白話來說料件不符合規則、法規,請廠商提供文件,建立料件承認資料。 代表此料件拿過認證、有合格的。 當詢完價後會再給主管跟相關人員作審核,覺得和廠商採買,當沒問題才下採購(訂)單。 若後續有交期變更或數量、內容變更等等,則透過採購變更單來異動保存歷史紀錄。 若直接從採購單源頭單據資料異動,會沒有歷史紀錄可追朔。如果後續因供應商交期延後變更,導致公司停線斷料,就會死無對證。 若廠商很棒遵守預交日壓線或提前運送入廠,此時才透過進貨單據作收料。 經過品保檢驗合格才真正入庫,若沒檢驗過關則開立驗退件退回。 如果是入庫或上線才發現瑕疵或其他原因想退,才透過退貨單。 也有一種情況是跟廠商借機台測試,類似試用一段時間。 此時就會透過暫入單借進來公司廠內,當用得很滿意就考慮作進貨採買。 若只是短時間測試,則在歸還給廠商。 與其他系統關聯 就庫存管理層面 會注重在「料品庫存餘額同步更動」 採購系統的進貨單確認後,就會增加庫存數量。 而當退貨單確認時,則庫存數量相應減少。 就訂單管理系統層面 如果交易模式屬於貿易型態的,例如買入商品後再轉手銷售,就可 利用訂單轉請購或訂單轉採購,來減少採購人員key單時間。 就進口系統層面 主要針對向國外廠商下採購單後,舉凡預付購料、報關贖單、進貨費用等等。 都在進口系統模組有關聯 就產品管理系統和採購的關聯 對於料品是屬於有「料件承認管制」時候,在採購日常異動單據輸入料品時,系統會檢查採購的品號的採購廠商是否符合料件承認資料建立中的製造廠商。如不吻合就不能完成該筆品號的採購程序。 另外還有BOM自動請購作業,將需要生產的主件資料按照BOM材料用量資料展開,進而自動產生建議採買的請購需求到採購系統中。

SSO實作參考

  iframe嵌入页面实现免登录思路(以vue为例) https://blog.csdn.net/talentT/article/details/137084940?spm=1001.2101.3001.6650.1&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-1-137084940-blog-41444713.235%5Ev43%5Epc_blog_bottom_relevance_base8&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-1-137084940-blog-41444713.235%5Ev43%5Epc_blog_bottom_relevance_base8&utm_relevant_index=2 前端单点登录(iframe方式) https://blog.csdn.net/m0_62169295/article/details/136347830?spm=1001.2101.3001.6650.1&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-1-136347830-blog-136450552.235%5Ev43%5Epc_blog_bottom_relevance_base8&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-1-136347830-blog-136450552.235%5Ev43%5Epc_blog_bottom_relevance_base8&utm_relevant_index=2 如何在一个系统的页面中嵌入另一个系统的页面并实现免登录 https://blog.csdn.net/qq3293343...

Oracle E-business Suite R12_身份和訪問管理解決方案常見名詞縮寫

圖片
Oracle 有一套豐富的身份和訪問管理解決方案,不外乎 涉及和身份管理解決方案的本地部署產品。 https://www.slideshare.net/slideshow/oracle-identity-access-management/66858465 身份治理( Identity Governance ) 和創建用戶、用戶配置、管理責任或身份驗證授權相關的產品服務如下 OIG(Oracle Identity Governance): 帳號配置、對帳 身份治理,之前稱為 Oracle Identity Manager (OIM) 這是一個由 Oracle 從一家名叫 Thor 的公司收購 而來的產品,於 2005 年收購後重新命名為 Oracle Identity Manager,後來改名為 Oracle Identity Governance。 https://www.oracle.com/assets/octetstring-faq-072304.pdf 用戶生命周期管理、角色管理、配置和對賬、合規和自動化等。 包括用戶的創建、角色變更、權限撤銷和用戶離職等。 還維護角色和成員管理,即用戶擁有哪些角色和權限。 提供基於批准的工作流程,舉例來說,如果您需要創建用戶或將其分配到不同的系統或給予責任,請求可以提交給經理或應用程序所有者進行批准。 提供配置和對賬功能,即在企業的多個系統中創建用戶,如 Microsoft Active Directory、e-business Suite 或 SAP。 可以與 Oracle 的另一個組件 GRC 或第三方治理解決方案整合。GRC 是治理、風險和合規,可以讓您控制不將兩個衝突的責任分配給同一用戶。例如,可能有一個採購超級用戶和一個發票審批者,如果您將這兩個責任分配給同一人,那麼這個人可以同時批准和提出發票,這可能是不希望的。 GRC 中有各種模組,例如應用程序訪問控制管理器(ACG)。 OPAM(Oracle Privilege Account Management) 特權帳戶管理,用於管理高權限用戶(如系統管理員等)的帳戶。 https://docs.oracle.com/cd/E52734_01/opam/OPMAG/intro_opam.htm#OPMAG112 https://www.oracle.com/tec...

Is Oracle EBS SSO (single sign-on) possible without purchasing an OAM and OID license?_非侵入式套用SSO解決方案

圖片
根據國外論壇討論上,Oracle EBS原生是不提供關於SSO支援的。 Oracle E-Business Suite (EBS) 本身不支援單一登入 (SSO),除非購買 Oracle Access Manager (OAM) 和 Oracle Internet Directory (OID) 的額外授權。 OAM 是 Oracle 的網頁訪問管理和用戶身份驗證解決方案,而 OID 是 Oracle 的 LDAP 目錄服務。 要在未購買 OAM 和 OID 授權的情況下為 Oracle EBS 實現 SSO,通常需要依賴第三方 SSO 解決方案或自定義開發。然而,Oracle 推薦且支持的方法是將 EBS 與 OAM 和 OID 整合來實現 SSO。 可以在不購買 OAM 和 OID 授權的情況下實現 Oracle EBS 單一登入 (SSO)。 一些第三方SSO供應商如 SSOGen、Okta 等 通過使用 Oracle EBS AccessGate 來實現這一點,但這需要購買 EBS AccessGate 模組。 這些解決方案提供者作為外部身份提供者 (IDP) 和 AccessGate 之間的中介,以實現 EBS SSO。 方案1.SSO Without OAM/OID License-「 miniOrange」 一種不需要購買任何額外的 Oracle 模組來實現 SSO 的替代解決方案是來自 miniOrange。他們的解決方案直接與 Oracle EBS 集成,並作為外部 IDP 和 EBS 之間的中介。您可以在他們的網站上找到有關該解決方案的更多詳情。 Authentication flow for miniOrange Oracle EBS SSO (Single Sign-On) Authentication Oracle EBS SSO solution by miniOrange allows enabling the Single Sign-On between Oracle EBS - 11i, 12.1, and 12.2.x and Active Directory, IDPs and directories without having to buy and install Oracle Access Manager (OAM) an...

Domain Know-How_會計系統中的主要組成部分_總帳和分類帳、明細分類帳

圖片
  總帳 (General Ledger): 指的是大分類會計科目或者相對簡單明瞭好辨別的會計科, 例如: 現金, 銀行存款, 應收帳款, 應付帳款等, 而相對簡單明瞭辨的會計科。記錄了所有交易和會計事項。 它提供企業整體的財務狀況概況,包括資產、負債、權益、收入和費用等。也會被用於製作財務報表(比方資產負債表、損益表),供企業去掌握整體財務概況。 像是銀行存款若有多個銀行帳戶,則可依銀行別設立明細帳,,例如:台北富邦銀行-北投分行, 遠東銀行-北投分行這樣的明細帳。 分類帳 (Subsidiary Ledger): 分類帳是將總帳中的某些科目細分和詳細記錄。便於分析和管理特定類型的交易。 記錄了特定科目中的所有明細交易,如應收帳款明細、存貨明細等。 分類帳為總帳提供更詳細的信息,有助於對特定交易進行更深入的分析。 Ref: 請問總帳及明細分類帳科目 https://accounting.sme.gov.tw/run.php?name=forum&file=post&p=534478 總帳和分類帳:企業會計系統中的重要組成部分 https://vocus.cc/article/6631abd1fd89780001ead156 https://wiki.mbalib.com/zh-tw/%E6%98%8E%E7%BB%86%E5%88%86%E7%B1%BB%E8%B4%A6%E7%B0%BF

技術研究_單點登入(SSO)技術實作_基於OpenID Connect的技術IdentityServer4(IDS4)認證與授權

圖片
理論跟概念部分在前幾篇稍微有些消化,大概能知道一些大範圍方向後。 稍微來研究技術實作細節 IdentityServer是根據OpenID Connect協定標準的身份認證和授權程序,它實作了OpenID 和OAuth 2.0 協定。 在 WebAPI 中,由於使用的是 HTTP 協定實現資料的傳輸,因此具有無狀態性,只是透過一個 URL 位址即可取得想要的資源,可供任意客戶端調用,靈活性強並且掩蓋底層的技術實現。 所以,We bAPI 是非常受開發者喜歡的,可連接任意處的客戶端,不受限制用途很廣。 但是,由於客戶端的多樣性,使用傳統根據 Session 和 Cookies已無法滿足身份驗證和授權,此時,基於JWT的身份驗證和授權就出現了。 JWT 只需要在認證伺服器上拿到一個 Token ,這個 Token 包含了用戶身分的聲明,可以用來授權某個使用者, 很像買車票要驗票概念。 OAuth 2.0 主要是用來向第三方應用頒發令牌的,是基於 JWT的授權解決方案。 所頒發的令牌包含使用者和授權訊息,並決定這個令牌可以存取資源伺服器上的哪些資源。 也就是 在「資源伺服器」和「客戶端」之間加一個授權伺服器,負責使用者的授權。 IdentityServer4 是基於 OpenID Connect 和 OAuth2.0 的 JWT身份驗證和授權框架。 Identity Server4 目前最新版本是 V4.x,是專門為 ASP. NET Core研發的身份驗證和授權框架。 目前可以在 ASP.NET Core 3. x 以上版本中整合使用。 https://www.chinatimes.com/realtimenews/20231031001777-260405?chdtv https://www.thsrc.com.tw/ArticleContent/baba745a-d802-440c-b762-3eef37b96b60 於Visual Studio 2022 建立三個專案 (1) 一個是認證授權中心專案,用於頒發 AccessToken。 對於認證授權項目和 API 資源專案,可以使用獨立的伺服器部署,共同給客戶端提供服務。 (2) 一個或多個 API 資源中心專案,用於提供資料資源。 (3) 一個或多個客戶端專案,提供使用者服務,面向使用者。 (1) 一個是認證授權中...

技術研究_單點登入(SSO)不同類型架構介紹_part2.SSO Protocols(SAML/OIDC)補充&OAuth 2.0

圖片
1.Secure Client-Side Credential Caching ( 基於用戶端的單點登錄/ 安全的客戶端憑據緩存) 特性&優點: 基於客戶端的SSO解決方案。 所有與身份驗證相關的信息都保存在客戶端的憑據存儲中。 只要用戶提供的憑據有效,就可以實現透明的身份驗證,用戶與其他應用程序服務器之間的互動更加方便。 允許用戶只需要身份驗證一次後,對於後續請求的其餘信息將自動由系統提供,無需用戶干預。 缺點: 缺乏靈活性,所有憑據都存儲在客戶端,可能會導致用戶在不同工作站上登錄時遇到問題。 需要定期更新客戶端憑據緩存中的信息,尤其是在新增應用程序服務器時,管理和維護成本較高。 不宜在便攜客戶端設備或存在安全問題的操作系統中使用,可能存在信息泄露風險。 可能導致安全性方面的風險,因為緩存的憑據可能會被不當使用或盜取。 在 .NET C# 和 Java 各自可能會採用那些第三方整合solution,套件或是library? .NET C# Microsoft Identity:用於身份驗證和授權的完整解決方案,支持OAuth和OpenID Connect。 Auth0:一個靈活的身份驗證和授權平台,提供多種身份驗證協議支持。 IdentityServer4:開源的OpenID Connect和OAuth 2.0框架,專為ASP.NET Core設計。 Java Spring Security:提供全面的身份驗證和授權支持,支持多種身份驗證協議。 Keycloak:一個開源身份和訪問管理解決方案,支持SAML、OAuth2和OpenID Connect。 Auth0:與.NET相同,Auth0也提供對Java的支持。 OpenID Connect (OIDC) 2.Secure Server-Side Credential Caching ( 基於伺服器的單點登錄/ 安全的伺服器端憑據緩存) 特性&優點: 所有的身份驗證詳情都存儲在一個中央存儲庫中,快取則存儲在伺服器端。 管理所有不同密碼並將所需信息直接提供給請求應用程序的任務由中央伺服器完成。 中央集中式管控,便於統一管理和維護 簡化了憑證管理流程,減少了多點管理的複雜性。 憑證快取存儲在伺服器端,減少了憑證洩露的風險。 缺點: 中央存儲庫成為單點故障(SPOF,Single Point of F...

技術研究_單點登入(SSO)名詞解釋_MFA介紹_SSO不同類型架構_part1.

圖片
https://www.pinmeto.com/blog/secure-single-sign-on 單點/單一登入(SSO, Single-Sign-On) 用戶只需一次登錄,即可訪問多個應用程式,優點就是在於 減少了需要記住多個帳號和密碼的負擔,也可能間接改善登入不同系統每次都跳出登入畫面問題,能夠簡化密碼的管理,省去了用戶在登入各個功能之前,輸入大量的帳號和密碼這樣的繁瑣工作。但用更客觀層面來看,凡是都有一體兩面。 在之前SSO機制還沒有普及的時候,人們每個月要在輸入密碼和重置密碼的時間上花費平均48分鐘,而在使用了SSO機制以後,能夠極大的縮短其中不必要的登陸時間,用戶可以在短時間內完成對大量登錄程序的操作,同時也能夠為企業減少生產力的損失。  缺點 1.當發生單點故障,則可能牽動全部應用都無法登入存取,日常業務大大地被耽擱。 2.有很多SSO廠商根據功能單獨收費。其中也有不少的核心功能是疊加收費。 3.單點入侵可能造成資安問題。 單一登入(SSO)架構有不同類型 具有多組憑證集(credential set)的SSO,如下: Secure Client-Side Credential Caching(安全的客戶端憑據緩存) Secure Server-Side Credential Caching(安全的服務器端憑據緩存) 更詳細可詳閱 「技術研究_單點登入(SSO)不同類型架構介紹_part2.」 僅有單一組憑證集的SSO(SSO with Single Set of Credentials),如下: Public Key Infrastructure based SSO(基於公鑰基礎設施的SSO) Token based SSO(基於令牌的SSO) MFA,Multi-factor Authentication(多重要素驗證): 是指兩個或多個驗證因素的任何用法。如果僅使用兩個驗證因素,則MFA 也稱為雙重驗證或兩步驗證。三重要素驗證是MFA 的另一種形式。通常帳密輸入登入後,如果有看到跳出捨麼手機收簡訊、或識別號碼點選、指紋、生物識別,都屬於確認是否為你本人這些都算。 Combination of SSO with MFA https://www.researchgate.net/figure/Combination-of-SSO-...

Oracle EBS_Multi-Org多組織和相關名詞解釋

圖片
  Oracle的ERP組織模式(多組織)定義的組織結構和企業組織的關係. 決定如何透過不同的組織和組織之間相互影響的流程。 多組織模型提供了系列層次結構,決定在不同的業務單位 如何交易流程,這些業務單位是如何相互作用的。 所謂的 Multi-Org,是指能夠使多個業務部門和企業使用一次性安裝的 Oracle 應用程式產品,同時保持各自交易資料的獨立性和安全性。 Oracle ERP伺服器端的配置,使用單一安裝可以使企業在多個業務單位中應用。 在一個Oracle ERP軟體安裝下可以考慮所有操作,您的資料保持在單一的資料庫,但保持獨立和邏輯範圍內的個體經營單位的安全交易數據。 多組織的優勢 在單一的安裝的多個財務帳套 經營單位,確保全球相整合的數據的安全訪問 全球的客戶和供應商統一註冊 自動公司之間會計的處理 減少ERP應用軟體的維護 跨多個經營單位的報告 多組織定義和特性 多個使用者可以共享一個責任,一個使用者可能有多個責任。 會有很多不同畫分模式 讓我們考慮一個大型企業的實例。假設您有一個紐西蘭的商業集團,該集團在澳洲、新加坡、印度和中國設立了多個子公司。雖然這些子公司各自進行業務運營,但您不希望不同國家的用戶能夠看到彼此的數據。例如,澳洲的用戶不應該能夠查看或存取紐西蘭的交易數據,反之亦然。 因此,所有這些業務單位都可以在一次安裝的 Oracle E-Business 中進行配置,並確保用戶只能訪問其所屬業務單位的數據。 該資料庫還以組織為基礎進行存儲。例如,澳洲的交易資料會存儲在與澳洲業務單位相關的區域。同樣,與單板業務相關的交易資料也會存儲在對應的業務單位中,以供參考。這種結構確保每個國家/地區的數據都能夠獨立且安全地管理。 不僅僅是數據的保護,後端的架構設計也確保了這些業務單位之間的獨立運作。舉例來說,在紐西蘭,您可能只有一個營運單位,而在澳洲,則可能有 21 家公司在其中運作。 因此,在更大規模的增強中,您可以在一個國家/地區內擁有多個企業,每個企業可以有多個配送中心和架構,這樣能夠在面對複雜的業務需求時繼續擴展。 在中國工廠完成的製造,該工廠是中國的法人實體。然後,將成品運送到屬於不同法人實體的其他配送中心,這是一種情況。 因此,可以定義多重架構比方針對製造配送單位劃分開來,便您可以擷取所有製造作業 以及指定在中國工廠進行的交易。 但一旦中國...

Oracle EBS側錄背後SQL方式_確認某個UI對應程式及Form名稱

圖片
Information silo/ Information island 記得之前在公司通靈鼎新Workflow GP過程也是十分艱難,畢竟無對外程式介面可以介接。 使用SQL Profiler來側錄鼎新ERP 底層SQL_通靈的過程 T-SQL筆記36_如何側錄軟體背後執行的SQL 不像 Tiptop 可能還多少有提供程式介面能做二次開發。 最近在研究Oracle EBS如何得知某一個介面底層查詢邏輯、介面程式檔案位置諸如此類問題。 話說Oracle EBS 一整包68G下載解壓到安裝真的有夠久.... Oracle ENS中有所謂「列表值」 (LOV, List of values) Step1.Help  --> About Oracle Applications. 可確認Form Name、Form Path、登入使用者名稱 Step2.對於UI 輸入篩選條件並點擊“查找”按鈕 Step3.打開連接到EBS資料庫模式的資料庫Session後,執行下面的SQL。 檢索由特定用戶名稱在module名稱包含 特定表單名稱的會話中執行的上一個SQL語句。 SELECT ( SELECT to_char(sql_fulltext) FROM v $ sqlarea WHERE sql_id = ses.prev_sql_id) FROM v $ session ses, v $ sqlarea sq WHERE ses.module LIKE '%&form_name%' AND client_identifier = '&user_name' AND sq.sql_id(+) = ses.sql_id; 這部分子查詢 SELECT (SELECT to_char(sql_fulltext) FROM v$sqlarea WHERE sql_id = ses.prev_sql_id) 從v$sqlarea視圖中檢索sql_fulltext,並將其轉換為字符串,對應於ses.prev_sql_id的SQL語句。 sql_fulltext包含SQL語句的全文。 sql_id是SQL語句的標識符。 v$session是一個包含當前會話信息的視圖。 v$sqlarea是一個性能視圖,提供當前...