JDEの自動支払時の決済勘定科目は、次のようなタイミングで、その取得及び変更が可能なものとなります。このため、各々の企業の業務内容に合わせてどのような設定を行うことが良いか検討を行う必要があります。
〜決済銀行を取得するタイミング〜
　[STEP1]自動仕訳（デフォルトの決済銀行）
　[STEP2]仕入先マスタ（元帳クラス）
　[STEP3]債務伝票計上時（相手勘定（元帳相殺））
　[STEP4]スピードリリース（相手勘定（元帳相殺））
　[STEP5]グループ作成（処理オプション決済科目）
　　※各ステップにおいて、ひとつ前のステップの決済銀行勘定科目を引き継いでいます。

①決済銀行を支払時に毎回指定したい場合
　この場合には、支払処理直前まで決済銀行勘定科目が確定しないため、
　”[STEP5]グループ作成”
のタイミングに依存しなければなりません。
　銀行の分グループ作成のバージョンを作成し、メニューに張り付けるもしくは、バージョン一覧名称で決済銀行勘定科目を分かるようにして運用することができます。
　（※システム的に慣れている場合には、処理オプションで毎回値を変更することも可能ですが、間違える可能性が高くなります。）

②決済銀行があらかじめ仕入先毎に決まっている場合
　この場合には、仕入先マスタの登録時点で決済銀行勘定科目が確定しているため、
　”[STEP2]仕入先マスタ（元帳クラス）”
で元帳クラスを利用することにより決済銀行勘定科目を確定することができます。
　ただ、元帳クラスの数が増加するというデメリットが生じますので、他の方法も考えられます。
これは、住所録マスタのカテゴリーと”[STEP5]グループ作成（処理オプション決済科目）”を組み合わせて運用するなどが考えられます。

③決済銀行があらかじめ仕入先毎に決まっているが時々変更を行いたい場合
　この場合には、仕入先マスタの登録時点で決済銀行勘定科目が確定しているため、
　”[STEP2]仕入先マスタ（元帳クラス）”
で元帳クラスを利用することにより決済銀行勘定科目を確定することができます。
　さらに、時々の変更ということなりますので、伝票入力時に決済銀行勘定科目を打ち変えるか、スピードリリース時に決済銀行勘定科目を打ち変えるという運用となります。
　イメージ的には、次のようになります。
　”[STEP2]仕入先マスタ（元帳クラス）＋[STEP3]債務伝票計上時（相手勘定（元帳相殺））”
　”[STEP2]仕入先マスタ（元帳クラス）＋[STEP4]スピードリリース（相手勘定（元帳相殺））”

④決済銀行があらかじめ仕入先毎に決まっているが支払直前に急遽変更を行いたい場合
　この場合には、仕入先マスタの登録時点で決済銀行勘定科目が確定しているため、
　”[STEP2]仕入先マスタ（元帳クラス）”
で元帳クラスを利用することにより決済銀行勘定科目を確定することができます。
　さらに、支払直前に急遽変更ということなりますので、スピードリリース時に決済銀行勘定科目を打ち変えるという運用が良いでしょう。稀なケースとなりますので、グループ作成での変更は望ましくないように思います。
　イメージ的には、次のようになります。
　”[STEP2]仕入先マスタ（元帳クラス）＋[STEP4]スピードリリース（相手勘定（元帳相殺））”

決算に際して、経過勘定項目や、引当金の計上を行いますが、当該処理に際して、”逆仕訳”を用いて入力することが可能です。
　”逆仕訳”機能とは、一般会計（GL）の伝票入力パターンの一種で、入力した仕訳伝票を、翌月に振り戻す処理を自動的に実施する機能となります。
※翌月での振り戻しですが、古いJDEのバージョンですと、翌会計月の初日を振戻日として、逆仕訳計上を行いますが、最新のバージョンでは、翌会計月初日もしくは月末日を選択することが可能となっています。 

〜仕訳入力の例〜
元帳日付 [2012/3/31]で入力を実施
　 （借方）前払利息　5,000     （貸方）支払利息　5,000

上記の仕訳を”逆仕訳”機能を用いて入力し、転記処理を実施すると、自動的に次の仕訳が作成されます。
元帳日付 [2012/4/1]  
　 （借方）支払利息　5,000     （貸方）前払利息　5,000     
　※ 最新バージョンでは、逆仕訳の日付については、翌会計月の末日にすることも可能です。

 

　従業員の経費精算処理のオペレーションと、仕訳の計上及びその支払のための未払金を計上するという部分をシステム化するのは、最近は一般的なことのようです。この経費精算のシステム化をJDEで実現するためには、次の方法が考えられます。
【実現方法】
　①JDEの経費精算モジュールを用いる
　②JDEのシステム上でアドオン機能として追加開発を行う
　③任意の経費精算システムを利用しJDEとインターフェースを行う
ただ、これらについては、それぞれメリット・デメリットがあります。
これらを簡単に述べますと、

①JDEの経費精算モジュールを用いる
　JDEに標準についている機能を用いるので、連携等を考慮せず、そのまま、利用することができます。ただし、経費精算を行うすべての従業員について、ユーザーIDが必要となります。また、JDEの経費精算機能が自社の経費精算業務をカバーしている必要があります。
②JDEのシステム上でアドオン機能として追加開発を行う
　JDE上に機能を追加しますので、連携等を考慮する必要がありません。また、追加開発となりますので、自社の業務要件にあった経費精算のシステムを構築することができます。ただし、追加の開発コストがかかり、要件定義等が必要となりますので、自社の経費精算業務を理解した内部の人材の時間を要します。さらに、開発の仕方にもよりますが、ユーザーIDの問題が生じます。
③任意の経費精算システムを利用しJDEとインターフェースを行う
　自社業務に適応した、任意の経費精算システムを選定し、経費精算業務を実現できますので、自社業務に適した経費精算のオペレーションが実現できます。JDE上のユーザーIDの問題は生じません。ただし、インターフェースを通して、経費精算の仕訳と債務の計上から支払いを行いますので、下流システムとなるJDEを意識した経費精算システムの構築と、インターフェースの開発をしなければなりません。

以上、がメリット・デメリットとなりますが、最近は、”③任意の経費精算システムを利用しJDEとインターフェースを行う”ケースが多くなっているようです。
次回は、”③任意の経費精算システムを利用しJDEとインターフェースを行う”場合の留意点について記載したいと思います。

 

coming soon...