様々な調整表は、要約と共有するためのドライシュウRPA

温家宝| E登ります

最近行わからRPAのプロジェクト、自動調整プロセス産業は要約をしたいです。

  • 最初のカテゴリ:銀行を両立し、旅行やその他の費用を支払います。(銀行や企業)

  • 第二のカテゴリー:本社と支店和解のビジネス取引に関連する銀行口座に支払わ。(内部の本社と支店)

  • 第三のカテゴリー:オンラインバンキング銀行の調整レポート

最初のカテゴリ:ビジネスフローバンク和解

銀行と和解の必要性は、以下の点に集中します:

1、顧客が情報セキュリティを確保するので、もし彼らがU盾のWeb版×××終わり、に登ることができます前に、必要なときに銀行の書類をダウンロードしているため。

だから、この部分は、無人モードを作っ自動的に和解のためにトリガされたチェックの日付を設定し、会計期間も設定した日付に応じて自動的に実行するように構成することができますすることができます。

あなたが保証することはできません場合は、セキュリティや顧客がへの必要性を全く感じないし、それは事前に構成マニュアルの有人モードであり、結局、時にはそれは必ずしも和解の会計月ではありません。

2、和解のデータ処理時間、銀行の書類や企業の文書が一致するように、ユニークなIDを持っていない可能性があるため。

だから、調整するテキストの銀行内の口座情報や企業のERP文書に基づいてファジー・マッチングの必要性はなく、その前に借りて最初のチェック根拠の日付にする必要があります。

ステップは、前記されているため3は、そうであってもチェックスクリーニングの層を介してユニークIDを、一致する結果がない、にはチェックがありません。

支払うために数分の特にアカウント、それをチェックするアカウントに集約統一困難であり、結果は人工的な二次効果に残るする必要はありませんでした確認してください。

しかし、全体として、マッチング率80%以上、まだ保存ほとんどの時間とは、前と比較します。

第二のカテゴリー:銀行和解のフローチャートの枝と

総銀行支店の和解で最も重要な点に焦点を当てる必要があります:

作られたいくつかの手動処理ビジネスの人々のダースの枝の内部買掛金情報、マニュアル書かれた理由の任意の支店で、そこにマッチがないので、柔軟な情報テーブルを設計する必要が三つにぼやけするように構成することができます試合。

その文字列が3つの原則に従って、上記の3つのモードのビュー内では、顧客が一緒にのみ、文字列を持っているだろうが、手書きのため、ためため、多くの場合、軽微な変更との試合は上一致しない場合スプリット、あいまい一致の原則、その後、複雑な問題を解決するための和解。

以上可以看出,对金额进行核对的话主要分两类:银行与企业以及企业内部。另一方面,也有系统内部直接打通不需要进行数据处理就可以对账的,比如下图:

第三类:银企网银上报对账

这个对账流程里面是SAP系统内部自动对账,所以不需要进行数据处理。

但是从银行里面下载的网银明细,是需要进行格式处理的,包括列顺序的调正和删除,以及日期格式化等,处理完达到模板标准,才能成功导入SAP里面进行对账。

而数据格式处理是这个流程里面人为操作时最耗时的步骤,所以这一部分实现流程自动化是能节约大量时间的。

おすすめ

転載: blog.51cto.com/14470190/2444242