相談の広場
当社では、今月からワークフロー(電子決済)を導入しました。これを機に、今まで各部署で起票していた伝票(当社では各事業部門で自部門の業務にかかる入出金伝票を起票し、それを経理に回付して仕分のチェックを行っています)を、電子決済(支払の承認)に基づき、全て経理で起票するようにフローを変更します。
電子決済フローは、発注を例にとると、申請者→上長→決裁者(発注の承認)→経理(ここで仕分伝票起票)→「納品ならびに請求書受領後」→申請者→上長→決裁者(支払承認)→経理(支払)→総務(決済を紙出しして保存)にする予定です。
電子決済を導入されている他社での運用事例をご教示頂ければ幸いです。
スポンサーリンク
ぽっぽ290さん、こんにちは。
まず、仕分ではなく仕訳ですよね?
意味が違ってしまいますので仕訳としてお話します。
ワークフローは、フローをシンプルにした方がよいです。
思っている以上に、例外のフローがあるので、統合的なフローを作ると運用が耐えられなくなってきます。
参考までに、私の手がけたケースを記載します。
①購入申請と支払フローを分ける。
1つの申請で支払先や支払期日が2つ以上の場合があるため
発注後に金額変更や案件の取消などがあるため
②申請には見積書を添付する。
申請根拠を明確にするため
③支払には、納品書(or作業完了報告書)及び請求書を添付する。
正当な手続きの支払かを確認するため
会計監査で証憑が必要なため
④支払には、申請ID(稟議番号など)を明記する。
正当な申請に基づく支払かを確認するため
簡単ですが、参考まで。
> ぽっぽ290さん、こんにちは。
>
> まず、仕分ではなく仕訳ですよね?
> 意味が違ってしまいますので仕訳としてお話します。
>
> ワークフローは、フローをシンプルにした方がよいです。
> 思っている以上に、例外のフローがあるので、統合的なフローを作ると運用が耐えられなくなってきます。
>
> 参考までに、私の手がけたケースを記載します。
> ①購入申請と支払フローを分ける。
> 1つの申請で支払先や支払期日が2つ以上の場合があるため
> 発注後に金額変更や案件の取消などがあるため
>
> ②申請には見積書を添付する。
> 申請根拠を明確にするため
>
> ③支払には、納品書(or作業完了報告書)及び請求書を添付する。
> 正当な手続きの支払かを確認するため
> 会計監査で証憑が必要なため
>
> ④支払には、申請ID(稟議番号など)を明記する。
> 正当な申請に基づく支払かを確認するため
>
> 簡単ですが、参考まで。
しろてん さん
早速有難うございます。
仕分は仕訳の変換ミスです。
仰せのとおり、購入の申請と支払の申請を別フローにすると、
柔軟な対応が可能ですよね。私個人もその方が良いとは思うのですが、
社内では、購入後の処理を忘れるので、購入と支払のフローを一つにすべきとの意見となっており、それを前提にフローを設計している次第です・・
とても参考になりました。有難うございました。
ぽっぽ290さん、こんにちは。
> 社内では、購入後の処理を忘れるので、購入と支払のフローを一つにすべきとの意見となっており、それを前提にフローを設計している次第です・・
私のときもそのような意見がありました。
現場を交えて議論していくと、システムをどのようにしたら良いかが見えてきます。
(私のときはその結果が、この前の回答です)
①複数の支払先があるケース(出張時の飛行機+特急+ホテルなど)
②複数の支払期日があるケース(①のケースで発生)
③承認後に、総額は変化しないが、支払日が分かれるケース(システム開発等でたまに発生)
④承認後に金額が増額になるケース(レイアウト変更等でたまに発生)
⑤承認後に金額、支払先が変わるケース(同じものをもっと安く手に入れる方法があったときに発生)
など、事前に検討しておかないと、実務が例外処理に追われて、かえって使いづらくなることが多いです。
現場の方にどのようなケースがあるか、また、今後どのような例外ケースが想定されるかをヒアリングしたほうが良いと思います。
参考まで。
> ぽっぽ290さん、こんにちは。
>
> > 社内では、購入後の処理を忘れるので、購入と支払のフローを一つにすべきとの意見となっており、それを前提にフローを設計している次第です・・
>
>
> 私のときもそのような意見がありました。
> 現場を交えて議論していくと、システムをどのようにしたら良いかが見えてきます。
> (私のときはその結果が、この前の回答です)
>
> ①複数の支払先があるケース(出張時の飛行機+特急+ホテルなど)
> ②複数の支払期日があるケース(①のケースで発生)
> ③承認後に、総額は変化しないが、支払日が分かれるケース(システム開発等でたまに発生)
> ④承認後に金額が増額になるケース(レイアウト変更等でたまに発生)
> ⑤承認後に金額、支払先が変わるケース(同じものをもっと安く手に入れる方法があったときに発生)
>
> など、事前に検討しておかないと、実務が例外処理に追われて、かえって使いづらくなることが多いです。
>
> 現場の方にどのようなケースがあるか、また、今後どのような例外ケースが想定されるかをヒアリングしたほうが良いと思います。
>
>
> 参考まで。
しろてん さん
ご丁寧な解説誠に有難うございます。
そうですよね。2周回しは経営サイドの意向なのですが、実際にオペレーションするのは現場ですので、現場の意見を吸い上げて、
極力使い易い設計にしたいと思います。
ホンとに参考になりました。
重ねて御礼申し上げます。
どのカテゴリーに投稿しますか?
選択してください
1~5
(5件中)
お知らせ
2024.4.22
2023.11.1
2023.9.1
スポンサーリンク
スポンサーリンク
[2022.7.24]
[2019.11.12]
[2018.10.10]