【クラウド】JDLユーザー集合!!その14【組曲】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
JDL(株式会社 日本デジタル研究所)のユーザーが集まるスレです。 前スレ 【クラウド】JDLユーザー集合!!その13【組曲】 http://echo.2ch.net/test/read.cgi/tax/1401702209/ はーい、ざんねん。 JDLの財務キーボードには、NumLockキーはありません >>634 そうやってJDLユーザーをディスってマウント取ろうとしてるなら、自分のところがどれだけ素晴らしい構成のシステムつかってるか説明してみて データサーバーがどうなってるか、クラウドとどう連携してるか、社内のセキュリティはどうなってるかとか データのバックアップ体制がどうだとかさ まさか、データを USB メモリに保存して、電子申告用の端末に申告の時だけ持ってくるとか LAN があっても単なる Peer to Peer でアクセス制限ちゃんとかけることのできない 共有フォルダに会計、税務データがごっそり入ってるとか、暗号キーがルーターの デフォルトのままの適当な運用だとか、そんなレベルの事務所はないと信じたいけどね >>634 地方に行くほどJDLのシェアは高いよな さすれば爺専用機と言ってもいいかもなw 月に40万円支払っている先輩を知っているが、次はMJSを検討中らしい。 JDLだと5年間のリース料で田舎なら自社ビルが建つwww 確かに新規リースの度に2000万の契約してるけど他社に替えるの面倒だし 儲かってるから別にいいや >>639 稲盛和夫氏の「実学」でも読め その低学歴的な発想は経営者には向かない JDL信奉者に一流の税理士はいない >>637 システムばかり立派でも、入っちゃ辞めての担当が、次から次へと客の個人情報を持って出ていき、 マイナンバーの取扱者の定めなんぞ知りもせずに全職員がマイナンバーを取り扱う。 入所に際して身元保証人も取らず、本人の住民票すら取らず。来客スペースは話し声が丸聞こえのパーティションで仕切っただけ。 酷いのは、ベランダ伝いで入れちゃう住居型マンション。こんな事務所じゃ意味ないよね。 JDLのマイナンバーは、あの出来が悪い会社DBをベースにしているから使いにくいところも多いけど とりあえず権限のあるユーザー以外は一切触れなくなってるからね。 達人はどうなってるんだろうと思ってみてみたらさすがにマイナンバーはクラウド側で管理ってことになってるんだね。 ローカル側で単なるファイルとしてマイナンバーデータが存在してたら目も当てられないなと思ったけど JDLって使いづらいよ ハード屋だったから細かい配慮がなく使うたびにちょっとしたことに不満が数多くある。機械の仕様にユーザーが合わせろって上から目線なんだよね。機械に使われてる感じ。TKCのちょっと使いやすくなった版って印象。 会計入力の時になぜあそこの位置に終了があるのか意味不明。間違って押すこと多々あり。 それに電話問い合わせで2000円の課金でサービスが悪くなるし。 このリース終わったらミロクとかにしようかなと考え始めてる。 私がJDL(財務)で評価するのは「切れ味の良さ」なんです 表示(仕訳一覧) 補助別仕訳計(試算表) 元帳表示 を素早く行き来し、必要な確認と修正を、項目訂正や置換を駆使し あるべき残高、処理に落とし込んでいくということを素早く行うことができる 特に発生処理された売掛金、立替金を確認しながら、補助の置換と確認を 繰り返しながら残高を合わせるような作業は私はJDL財務がないとできない 切れ味の良い、ハサミ、ナイフ、包丁みたいなものですね >>617 JDL純正スキャナって、ピックアップローラー?が違うんだって。富士通社製とはそこが違うらしいよ。 >>647 言いたいだけだと思いますけどね よしんばそうだとしても、重送防止性能はコピー複合機にかなうわけもない どこの事務所にだってあるはずのコピー複合機からのスキャン取り込みに対応すればよいだけのことなんですよ 独自仕様のOEM製造のスキャナを販売したって、そのハードウェア販売で たいして儲かるわけもない だったら、汎用スキャナで使えるように機能開放して、実利用ユーザー増やして ソフトウェア側で稼ぐ方がずっと良い ソフトウェアの開発コストは同じだからね もちろん汎用スキャナで利用可能にすることでの導入、サポートコストは かかるんだけど、それが自分でできないユーザーからは手数料取ればよいだけのこと JDLはハードメーカーだって言い張りたいだけのために損してるわけなんです 要望していて実現していないこと 財務の補助コード回り @補助の名称文字数の拡張 A補助コードを変更可能なようにする(親コード同様に変更しても入力済みのデータに影響しない) B補助コードを数字だけじゃなくて、アルファベット、カナ等も許容できるようにし、また文字数も拡張する @はいわずもがな。今の文字数は少なすぎる Aができると売掛金、買掛、未払等で使わなくなったものを下の方に追いやることができる Bができると、関与先側で売掛管理システムから貰うデータとコードを合わせることできるので、 補助コード部分の返還、加工が不要になる AはA-SaaS財務ではできる(私が開発当初に提案していた) 弥生等ではできるのだろうか? >>651 前に客の都合でJDL使ったことあるが、使わなくなった補助を削ると自動で繰り上がったりしないので、 番号が飛びになり、見づらかった。決算終わったら入れ換え作業やったりして、マジウザだったが、これのこと? >>652 そうね 現在は期中で補助コード変更するなら、新規にコード作って既存の仕訳は置換で補助コードを新しいものに変える必要がある これを例えば 補助1001を直接 2005に補助設定画面で変更すれば入力済みの仕訳も自動で2005に変わっていれば楽でしょ 補助コードの変更の話だけど、今の設定にしないと補助科目の過去比較とかできなくなるからでは? 過去との比較を無視して、当期分からの変更ならたやすいだろう。 >>654 親科目はコード変更しても比較比較表などに影響出ませんよね。つまり集計などに使う内部コードと操作で使う表面上のコードが分離された設計になっているはずなんです。 補助コードも同様の実装にして貰いたいのです A-SaaSはそうなってます >>655 なるほど。変更は一回までしか追えない気がするが、過去の補助科目を変更したコードに毎年ひもづけてくれる仕組みなのかな。 補助科目三期比較だと、相当重くなるだろうね。エーサスは使ったことないが、重そう。 具体的にどうやって実装するかはわかりませんが、 最初に補助コード作った時点で、内部コードが例えば 1001 などのように割り当てられ、 これはその後繰り越していっても、コード消されても内部的には残り、操作上(入力等 に使う)コードは、205 と最初に設定し、その後 308 と変えても集計等は内部コードの 1001で行われるので、複数期比較等も矛盾は生じないという感じでしょうか? この実装にしても、特に何かが重くなるってことは無いと思いますよ。 本当は会計ソフトや売掛金管理ソフトの「繰越」という作業で年単位でデータが 分断されてしまうという仕様もそろそろ変わってもいいのではないかと思っている。 大昔のソフトでは端末のリソース(CPU、メモリ、ストレージ)の限界から、 「月次繰越」で実際に扱うデータの単位を分断する必要があった、もっとひどいと 日単位で仕訳データを確定、翌日に繰り越したらもう変更できないなども。 現在のマシンリソースなら既に、年単位でデータを分割する必要もなく、 事業年度をまたぐデータもシームレスに扱うことは可能なのではないかと考えてる。 月次でやってる関与先の年次決算処理と、その翌月の月次決算処理を並行して作業していると、 期をまたぐ売掛金(決算期末で残った残高)が翌月に入金していることを確認することは 結構面倒。期中は前月の発生、翌月の入金と連続して処理できるけど、 期をまたぐと同じデータ内では処理できない。 ミロク、エプソン財務応援、A-SaaSなどでは、期をまたぐ処理ができるが、これらの 実装も、翌期分の仕訳は、同一データなのではなくて、繰越作業のたびに翌期の仕訳と してコピーしているだけと思われる。 つまり繰越のミスがあるとデータの整合性はなくなるだろう。 データを持つ単位は一か月づつとした上で会計データは年次に縛られるシームレスな 状態で保持できれば、実際の決算期末にかかわらず比較集計資料などが出せる 決算期変更した会計データでは、前期比較等を出すのができなくなるが、決算期にかかわらず 「XX月末時点での三期月次比較」のような資料を柔軟に作ることができるはず。 A-SaaSの年度またぎ処理は、「月次処理」状態にした時に、決算期後三か月の処理ができるように なるというだけであって、例えば3月決算データで、3月〜5月にまたいだ元帳表示などは できない。 これじゃ駄目だとずっとA-SaaSにも言い続けたけど、リニューアル版のスクショを見る限り このあたりの仕様は元のままとなる模様。せっかく決算期またげるのにこの仕様では意味が半減してしまう。 関与先に出納帳ソフト使って貰っていると、初年度によくあるミスとして 「決算期の翌月を入力しようとして繰越作業を行わず、前年の同月の仕訳を 入力してしまう」ということがよく起きる。 私たちは会計データには繰越という作業が付きまとうことを当然と思っているが、 関与先にとっては、決算期末の月とその次の月でデータが分断している(する必要がある) ことなど意識してないってことだ。 会計ソフトならともかく、売掛管理ソフトなどでは、それこそ年単位で繰越意味なんて 使う側からしたら何もないよね。10年分の売掛元帳を一回の操作で出力することなんて 現行のソフトの仕様ではできないけど、そんなことだって使う側からしたら できてあたり前だと思う。 なるほどね。 俺は事業再生やってる会計士だけど、たしかに、まずはじめにやることは仕訳データをExcelで5年分から10年分つなげる作業だ(笑) >>662 なるほど、やはり複数年度を一回で 見る機能にはニーズあったのですね 複数年の(補助)元帳を一気に参照、印刷する機能は、標準の会計ソフトの 外部からでも作ろうと思えば作れるはずだよね。 会社と科目コード(補助コード)と対象事業年度を指定したら、それぞれのデータを 読み込んでつなげてくれれば良い 会計ソフトなんて、データの持ち方も処理も単純なんだけど、使う側としてみたら やって欲しいけど、既存のソフトで実装されてないことなんていくらでもある >>663 まあ、俺はそうだけど、普通は前期データさえ閲覧できれば99パーセント事足りると思うよ。 俺は仕訳入力できない、閲覧専門だけど。 >>559 販売ソフト使ってないのか?販売ソフト使う規模じゃなければエクセルでいいだろ。 会計ソフトは収支のためのもの。 個々の科目の管理は別にすべき。たまに売り掛けで数百の補助作って残高管理しているとかある。 大企業とかやったことないんだろうな。 大企業は合計転記だよ。 売上、仕入は一行だったりする。販管費で打ち出しも飾ってあるけど、ファイル10冊とか。 >>666 アンカーがあってないけど多分私宛だよね 会計システムと連動できない独自の業務システムから発生仕訳データで取って会計側で合わせるとかね これやると販売管理側(複式じゃないから不正確な場合あり)で間違った処理してて回収漏れになってた売掛とかいくつも見つけて感謝された事あるよ 大企業ってどの規模かわからないけど、まともなとこならそもそも事務所側で会計処理なんてしないでしょ >>668 アンカーミス。失礼。 まさにそういう感じで、売り掛けとかは他で管理して、会計は収支面から全体のチェックをする。って位置づけ。 会計ソフトはそうやって使うものだから、期末に翌期の入金見て売掛なんて使い方する方が悪い。 入金状況だけなら通帳見ればいいだけ。 >>販売管理側(複式じゃないから不正確な場合あり)で間違った処理してて回収漏れになってた売掛とかいくつも見つけて感謝された事あるよ 会計士的には、これが一番興味がある。 一部入金で全額回収のフラグをたててしまったとか販売管理システムの重大な欠陥しか思いつかない。 結局それを正として会計システムに流し込んでも発見ってできるのか。 月末の入金口座が合わなくて、日別に帳簿残高と通帳を照合し、発見していくってことかな? >>670 まず大前提で中小零細の会計処理では 買掛未払決済は相手の方が大きい会社が多いから発生で処理していけばたいてい合う 次に売掛は自社の資金に関係することだからまともにやっているところはまあまあまとも だけど、消込や売上の重複、請求先間違いなどが紛れ込む 最後に会計は手書きでもパソコン使っていても、販売管理と連動させることができている ところは少ない。独立した経理部があってそこに専従で4〜5人ぐらいはいるところでないと。 (続く) 小売や卸売りならまだいいけど、例えば宿泊業や自動車整備販売業などで中小零細が 利用できる管理システム+会計システムなんて提供されてない。私が知らないだけかも 知らないけど少なくともうちのお客では使ってない。 で、記帳代行(これはどの範囲を分担するかは幅がある)の中で、売上の発生データ等が 業務管理システムから貰える場合、これをJDL財務に取り込める仕訳に加工する その上で会計データ側で合わせていくと合わない部分が発見されるってこと。 こんなイメージね。 販売管理システムって例えば商奉行とかでも、売上の発生立てて、回収立ててそれらが閉じた システムの中で管理されているだけであって、複式ではない。入金先口座の処理を 間違えたり、本来の売上、実際の入金額と異なった処理をしていても、複式で 預金の残高と照合できる形には販売管理システムの中ではならない 商奉行なら勘定奉行と組み合わせれば、販売管理→会計にデータ渡せるけど、 「会計を一所懸命やったって中小零細にはメリットない。そこは税理士側でやるでしょ」 ってことになる。 市販ソフトじゃなくて、さっき書いたような宿泊業向け、自動車整備工場向けのシステムでは 当然、財務管理までは考慮されてない。 こんな感じかな その話すげぇ分かる 特に整備工場は小さい額で数は多いし、立替やら仮受やらも絡んでくるから、その請求書起こすソフトでどうにかならんかと常々思うが何も引っ張れない 月々の売上グラフ出るんだぜ、それ >>674 うちのお客の所のは幸い勘定奉行連携の形式でCSVが出るのでそれを出して加工してJDL財務で受け入れてる これで売掛を合わせるだけで無く立替(重量税、自賠責、車両仕入時の諸費用なんか)まで個別に合わせる事が出来てる 毎月会社側では気がついてない請求書のミスまで発見できる で、この作業は私はJDL財務を使わないと絶対に出来ない >>675 車屋の諸費用なんて立替、預りなんだから売上仕入れにして課税処理でいいんだよ。 大した額でもないし、結局合わなきゃ売上仕入れで調整するんだから。 こういう無駄なことに時間費やしていたら稼げないよ。 現場では立替や預りの管理をしなければならないのは当たり前のこと。会計に反映させる必要まではないってことね。 >>676 消費税どうなるのよ? 重量税、自賠責も課税売上、課税仕入で両建てだから良いとでも? 少なくとも課税売上割合が過大になるよね? 損益の期間比較可能性も随分と失われるし >>677 わかってないな。君、仕事できないね。 預かったら売上、払ったら売上のマイナス。 差が出るとしても、決算時に預かっていてまだ払ってないもの、または立替中のものくらい。 精算済みのものは相殺処理されているから課税売上には影響しない。 全体の何割になる?重要性の原則って知ってる? 職員から社保預かったら法定福利費のマイナス処理するのと一緒で何ら問題ない。 >>678 立替等を細かく合わせるのが枝葉末節だといいたいようだけど、 たぶんそこを合わせないでやるなら、車両販売の売上と原価の対応も 月ごとには合わせたりしてないんじゃない?そこはさすがに重要でしょ? それとたぶん、そういう処理だと今の宿泊業なんて一切まともにはできないよ 事前決済、カード決済、宿泊システム利用料、ポイントなどが複雑に絡むから 個別の発生の数字を見ながら、細かく合わせていく前提でやらないとどこまでも 大雑把になる 細部をおろそかにすると結局全体もぼやけたものにしかならないと私は思っている まあこれ以上は仕事のやり方のポリシーの問題だからもう良いよ >>679 商品の売上仕入の対応はしているよ。 葬儀屋も立て替え多いが、こっちは額が大きいから合わせている。 TKCにありがちだが、仕事である以上、メリハリが重要。 数字合わせしている時間で、その客や他の客に提供すべきものが全部できているなら良いが。 ありがちな、そんなのいいから、相続対策ちゃんとやって欲しかった。って流れてくる客。 だいたい元税理士は数字合わせばっかに必死な帳簿屋さん。 零細の会計はキャッシュであり収支。損益は参考だよ。 >>680 まあそういうことなら良いけどさ ちなみにこの整備工場、他の事務所から来たんだけど、前の事務所の仕事のひどかったこと 月次でやってても会社が切った伝票そのまま確認無しに入力して試算表作るだけで なんの説明もしないで、FAX で生の試算表送ってくるだけで終わりだったんだって 当然発生処理なんてしてないし、売掛買掛未払は全部年次決算の時だけ 極めつけは会社との連絡が悪くて、会社が作った資料の見方が分かっておらず 年次決算処理で収益、費用の二重計上が毎年起こっていた 翌年振り返るのでその分消えるんだけどね うちで丁寧な発生処理することでやっと月次比較が意味があるものになってきたから 感謝されてるし、その意味ではニーズにあったものを提供できてると思っている >>677 会計士で税務はあまりわかっていない前提で質問だが、課税売り上げ割合が変わるという話で、どういう方向に変わるのか興味がある。 結局95パーセントに吸収されるから意味ない気がする。 記帳経験がなく、整備工場にタッチした経験もないが、どうせ売上5億行かないと思うので、記帳代行しろって言われたら俺もえいやってまとめて売上、仕入で計上しちゃう気がする。 >>682 個別の話になっちゃうから詳しくは書かないけど、土地の貸付があったり 有価証券取引がある場合だってあるよね このスレ的な話題に戻すと、AIだなんだで、税理士要らなくなるとか、会計士も 要らなくなるとかって話があるけど、現行の各システムのレベルで、業種別に 綺麗に対応できてる会計システムなんてないってことなんだよ グダグダやる部分はいっぱいあるし、グダグダをしかしスムースに作業するためには JDL財務は役に立つってこと 整備工場って車検と販売には常に立替が伴うから、収益・費用を発生でやろうとした 場合、さすがに手打ちで伝票は入れられない。会計の外のシステムからデータ貰えるなら それを使うけど、どうせデータからやるなら、消費税区分も立替処理もそんなに過大な 手間にはならずにやれるからやるってことだね ちなみに車検取引で自賠責と重量税合わせれば、売上本体より大きくなることが多いからね それをざっくり収益/収益の減、消費税区分も課税でいいやとは私にはできないな >>684 まさに正論で反論できない。 俺も会社にはそう伝えるはずだけど、諸費用の割合が大きければ、万が一記帳代行を受けるとしたら、売上諸費用管理シートを作ってもらって、月次で諸費用を相殺する仕訳を一行入れて終わりにするわ。 ここのスレはつい最近のぞき始めたが、これから参考となることが多くて心地いいね。 >これから参考となることが多くて心地いいね ホントよ 同業とやり方や手法について話す機会ってないから役立つわ スレの趣旨とはちとずれるが 来年軽減が始まり、その後インボイスが始まると、「課税事業者の個人のラーメン屋が、コンビニでタバコと卵と洗剤買って PayPayで払ってるんだがどうするんだこれ スレ20」みたいなのが冗談じゃなく必要になるね 課税売上にかかる消費税を積み上げでやる事業者は課税仕入も完全積み上げで税額はインボイスと一致させる必要があるってホント? 怖すぎて条文確認してないけど この場合一括税抜が駄目で全取引個別税抜きになるのか? 参考になるかわからないけど、立替金をJDL財務で合わせる具体的な方法を紹介する まず会社側では立替金の支出処理は個別に仕訳を切って貰っておく 立替金-1-重量税 / 現金 39,500円 株式会社JDL 江東340さ5152 車検 立替金-2-自賠責/ 未払金 40,800円 株式会社JDL 江東340さ5152 車検 業務システムから出力された発生のデータはこんな感じ 売掛金-10-月分 / 立替金-1-重量税 39,500円 株式会社JDL 江東340さ5152 車検 売掛金-2001-A-SaaS商事 / 立替金-1-重量税 15,000円 A-SaaS商事 品川100あ1053 車検 売掛の補助は個別のものと月単位のものを分けるようにしてる (支払いが二か月以上にわたるものや取引件数が多いものだけを個別補助にしてる) で補助元帳で 立替金-1-重量税 を表示し、金額で絞込み、摘要でマッチするものを探す [END]ボタンを押して、(重)などのマークを付ける つまり確認が取れたものだけを抽出できるようにする [表示]で 科目 立替金-1 摘要 (重) のような条件で一覧表示し、貸借が一致していることを 確認し、補助科目を 立替金-11 (重量税照合済) のように一括置換する 同じようなことを繰り返す、自賠責等でも同じことをやる。これで照合済みの立替金の 補助の残高は常に0になる。 照合が取れなかったものは個別に請求書見たり、支払いを確認してもらったりして確認する。 立替で説明したけど、売掛も同じ感じね。 JDL財務でなければこれができないというのは、元帳、補助元帳表示から 簡単な操作[END]キー押すだけで、簡単に適用にマーク文字列付けることができることと キーボード操作だけで必要な仕訳一覧を抽出し、またキーボード操作だけで 置換操作ができること もちろんJDL財務の最大の特徴の「仕訳入力の基本は単一仕訳」だということが 前提になっている。 操作の対象となるデータ(一行づつの仕訳)を簡単な操作で表示し、そこに置換を 簡単、高速にかけることができ、適切な処理がされたかどうかも補助仕訳計、 補助元帳で確認できるってこと 今説明した通り、仕訳を自分で手入力することは必要最小限であって、 関与先で入れて貰ったデータ+CSVから取り込んだデータなどに対して 自分でやる作業は「適切な残高になっているか」という確認と「なってないなら 適切な修正を行う」ということが中心。 検索しても伝票単位でヒットしたり、表示されている仕訳を直接、ピンポイントで 修正できない会計ソフトではこのような作業を素早く行うことはできない。 >>684 諸費用支払時 諸費用100/現金100 陸運局重量税 諸費用入金自 現金100/諸費用100 車検諸費用入金 課税売上割合なんて変わらないし、損益も変わらないから。 税金→不課税って頭のバカだらけな業界だから、この発想は理解不能だと思うが。 自動車整備で製造原価報告書作って立替も合わせてる。だが仕掛在庫が載ってない。 こういう全体見れないで、立替合わせて仕事した気になってるバカだらけだからねぇ。 温い業界だし、ハード屋に鴨られるのも仕方ないな。 >>692 いちいち人の仕事ここでディスんなくてもいいよ 「これで十分」って単に「最終の確定決算が少々不正確でも許容範囲でしょ」って 言ってるにすぎないじゃん そういう雑な処理なら現金主義前提なんだろうけど月次で損益ぶれるし、 比較可能性が失われるでしょ 立替金合わせるの諦めるとしても「立替金/現預金」「現預金(売掛金)/立替金」で 立替金の合わない分だけを収益費用とすべきでしょ 会計処理の話中悪い。 議論と関係ないけど、自動車整備業のはなしで、作業完了時に売上計上で、同時に入金だったら立替金なんて出ない気がする。 後日振り込み入金でも、諸費用くらいは作業完了前にもらっておかないとだめ。 長期売掛もたまりやすくなる気が。基本的に貸倒はあってはならない。 俺はこっちの方が心配。 会計処理をするなら前受金。 言いたかったのは業務フローの話でした。 話の流れを切っちゃったようで申し訳ない。 俺はミロクなので、一旦退散します。 それではまた。 諸費用の立替処理と現金・発生処理がどうして結び付くのかわからん。 どんな仕訳をイメージしてるんだ? 諸費用の支払や預かりは普通現金だろ。陸運局に締めで払えるのか? 得意先は掛で諸費用が工賃と一緒に後払いっていうのはあるが、売掛立てる時に諸費用も計上するんだから 諸費用も発生処理だよな? ダメダメ帳簿屋が、必死にできる税理士をdisろうとしているようにしか見えない。 こんなヘボ助はどうせ所得2,000も無いだろう。 立替処理しか認めない頭の固い爺さんが、専用機メーカーにいつまでも御布施を続けているんだね。 >>698 最初に「車屋の諸費用なんて立替、預りなんだから売上仕入れにして課税処理でいいんだよ。 」 って言ってたから売上の内容を区分せず、現預金/売上 の 諸費用/現預金 でもちろん発生じゃなくて入出金時の現金主義なのかと思ってた 最終的には 売掛金/売上 /諸費用(費用科目) 諸費用(費用科目)/現預金 ってやるんだってことが分かったけど、内容区分して発生処理するなら >>693 で書いた通りで、費用科目じゃなくて立替金処理で良いでしょってこと 立替金の内訳合わせないで、差が出たら収益、費用で構わないから この話題、前の事務所の処理があまりに雑だったから私の書いてることも それをベースで考えてたからね なお、重量税は都度現金支払いだけど、自賠責は代理店も当然やってるだろうから まとめて支払うから月末は月をまたぐよ。払う時には自分のところの手数料 を控除して支払うしね。 それから補助分けて細かく内訳管理していって処理するってのは何も 整備工場の立替金だけに限らない 例にあげたように宿泊業は事前カード決済、それの手数料、そこでのポイント利用 チェックアウト時の支払いもカード決済が多いし、それぞれの予約サービスの 手数料などが複雑に絡むから、かなり細かく丁寧にやらないと合わない、 そもそも雑にやりようがない 私はこれも元データをCSVに加工したものをベースに作業することが多いけど、 補助元帳ベースで内訳、残高を見ていって処理を追い込んでいく作業は JDL財務がないとたぶんできない。 売上が大きいところは宿泊業専用システム入っててそれで対応できるかもしれないけど 5,000万未満なんてところじゃコストが合わないからそういうのも使えない いずれ予約サービス側から API でデータ貰えて連携する会計システムが クラウド提供されるかもしれないけど現行では多分ないね >>694 業務フローの見直しもそれはそれで必要だろうけど、 会計処理は現状に合わせるしかないからね メーカー直のディーラーだと、諸費用もクレカ支払できたり する 残高が残るかどうかってことと、入出金をどう会計処理するかってことも別だし >>702 立て替えにするってことは、差額の内容確認するってことだろ?そこが手間じゃん。 やってる客いたけど、客ごとに補助作ってるから、常時複数台受けてると、合わせるのが大変。 やるなら車両でやりな。ってことで見たら、年間で数百の補助になる。 立て替えにしなければそれすら不要。 数字が合う前提の葬儀とかなら良いが、車は合わない前提の部分があるからな。 旅館とかは知らんが、ポイントや前受けあるなら専用ソフトだろ。 >>706 内訳見ないでも定期的に立替の残高が帳簿と業務の管理台帳で合わない部分だけ損益の勘定使って処理すれば良い 私は合わせてるけど顧客や車ごとの補助じゃなくて、重量税、自賠責、諸費用などで補助分けてるだけだよ もちろん私だって立替処理を全部会社側でやって貰ったり、記帳代行でも手入力なら無理だと思う。 会社側の処理(きちんとした事務員さん)+業務システムのデータの仕訳への加工が可能+JDL財務など条件が揃わないとできないね 会計システムに全てを集約したいという人と、業務システムで全てを管理して、会計へは結果を記帳すればいいやという人はお互い歩み寄らないと議論が散らかるよ。 まあ、俺は後者の人間だけど、会計システムに集約したいという人の話がとてもためになってるから感謝してる。使うかどうかは別として。 摘要の入れ方一つで作業効率が変わってくると言うのは最近判明した。 >>709 まとめてくれてありがとう みんな関与先と自分のニーズと かけられるコストのバランスの中で仕事してる んだからそれぞれの判断で何をやって何をやらないか決めればいいんだよね ところでちょうど先日、関与先で作業中にワイアレスマウスが使えなくなったことがあった。 電池はあるのに電源自体が入らない こんな時でもJDL財務を使う分にはほぼ困らない。通常のPCキーボードの場合で マウスを使わないとできない操作はただ一つだけ、検索操作で一致と不一致を 切り替える操作だけなんだ この操作以外は普段、ほぼマウスを使わずにJDL財務を操作している 私はエクセル等でも結構ショートカットキーは使ってる方だと思うんだけど、 飛び飛びの範囲選択などはやはりマウスを使わないときつい JDLの良いところは、そういうところにもあると思うんだけど、 最近の若い開発者はそれがわかっていないので、新しい機能やアプリは 平気でキーボード操作をどうするかってことを無視してくる 財務、税務システムに限らず、マウス操作でもキーボード操作でもユーザーが どちらでも好きな方を選べるのがよいシステムだと思うんだけどね まあユーザー側も別にJDL財務式のキーボードでほぼ全てが完結できると いうところへのこだわりがない若い人が増えてきてるから、「別に会計ソフトなんて どれだっていいじゃん」ってことになるのかもね。 >>707 なんかどんどんグダグダになるな。 もはや比較とか言っていたのもどこへやらw そんなラフなら最初から立替を通す意味ないよ。 無理しないで損益にしな。 最初に戻るが、無駄な仕事していても稼げない。 実務は正しいことをするのでなく、問題ないことをする。 とりあえず立替え通して差額は盲目的に損益へ振替えなんて、正しさの欠片もないけど(問題は無い)。 >>712 だから私は合わせるけど、あなたはどうぞ好きにすれば?ってことだよ。最初から損益科目使ったら、月末費用、翌月費用の取り消しとなる取引が生じて必ず損益がぶれるでしょ? 私はそれは気持ちが悪いからやらない まだ補残高合わせない立替処理の方がマシだってこと だいたいが立替を合わせる事はJDL財務使えば 別に過大な作業でなくさもなく出来ること 会計ソフトが手伝ってくれず確認がより面倒で 時間がかかるのは車両販売の売上と原価の 対応月を合わせる作業だ 新車でも仕入れ日と実際の納車が月をまたぐことは普通にある 買掛と売掛を細かく合わせたってそれだけじゃ駄目で、月がずれる事があるから私は仕入時は一度在庫計上して、販売日に原価に振り替えてる この作業の方がずっと大変だよ 中古なら販売時に個別の原価を計上できるようにしないと月次損益計算書作っても何も意味がない帳票になる 粗利までは業務システムの数字を合計転記で仕訳切ればそれで十分って会社ならばそんなに楽な事はないが、それで貸借合うような会社なら、俺らの出番無いでしょ >>714 職人さんだね。仕訳をろくに切れない会計士の俺には遠い存在だわ。 業務でオーダー番号ごとに受注、発注、検収、売上計上、引き渡し、請求を業務システムでやって、情報を月一回会計に流して、BS、PLで確認、ってくらいしか経験ないわ。 ちなみにオーダー番号ごとに諸費用前受けは業務システムの売掛金の赤算で期中は表示されてる。 車屋は業務システムさえしっかりしていれば、フロントも整備さんも経理も喜ぶはずだよ。俺だったらここに力入れて整備させて、会計で楽をしたいなぁ。 >712はなんか棚卸弄って銀行用の決算書作成とか普通にやってそう >>715 そうだね。本来は業務システムの役割だと思うよ でも業務システムも中小零細向けだと車屋さんの場合、主にお客に出す請求書発行までが主な機能で、それが会計にどう反映するかまでは面倒見てくれない。 原価面の機能も少しは持ってるみたいだけど、そんなのフロントとか現場は使ってくれないしね >>715 さんが見るようなところはメーカー直の系列の地域販社とか、それこそコバックレベルのところかな? 日々の記帳処理は、金かけてその業種、その会社に特化したシステム作り込めばそれこそ「AIで税理士いらなくなる」みたいな社会になるかもしれないけど、実際はそんな素晴らしいシステムは誰でも使えるほど安くはないね だから「軽減税率?そんなの今時IT、AIで事務処理なんかは手間かからないだろ?」みたいな事を言う評論家、政治家はぶん殴ってやりたいね その素晴らしいITシステムどこにあるのかと、そこにかかる金、お前が出してくれるのかと >>714 全部エクセルで楽勝。 実はエクセル苦手でしょ?会計事務所って、意外とエクセルできないからなぁ。 難しい算式やマクロ・ピボット使ったりするわけじゃないけどな。 立替えが合う合わないは、ソフトではなく、現場の問題。 そりゃ、絶対合う前提で収支組んでるなら合わせるが、なんか話がどんどん変わってきているな。 >>719 エクセルは iferror と vlookup 程度なら使うし、 ちょっとだけならマクロも組むよ そもそもCSV職人だし CSVの加工はエクセルじゃなくてデータベースソフト使うけどね 弥生もAEなら単一仕訳処理モードあるんだっけ? 弥生では元帳、補助元帳上で、JDLの項目訂正のように、 そこから直接各項目を変更する操作はできるようになったのかな? 立替金の話は、私はJDL財務を使えば普通に合わせることはできる だけど、他の会計ソフトでそれができる自信はないってこと >>720 だから、操作の話じゃないって。 操作なんて四則演算と罫線にセルの塗りつぶしだけで十分。 業務のフローの中のどの部分にエクセル使って、どういうフォームにして、どういう集計とチェックにして、 日常業務に使えて負担のない形にして、それを会計に移植するってことだよ。 客も事務所も会計のための作業をできるだけ減らすということ。これができてないのがすごく多いんだわ。 >>722 じゃあここで是非紹介、提案して下さいな ここのやりとりでは、お互いにどんな作業してるのか なんて情報はないわけだし、どうせろくに使ってないだろ とかディスられても反応できないから 関与先とのやり取りということだと、私はJDLにセキュアなメッセージングアプリを 提供して貰いたいと思ってる。 パーソナルなやり取りなら、LINE や FB Messenger で行けるけど、関与先の 各担当者と仕事のやり取りするのには、業務に特化したものが欲しいんだ。 まさかそのために事務の若い女の子にLINE聞くわけにもいかないし そういうメッセンジングツールと業務の記録、各データの管理を総合的に 行うことができるシステムをJDLが提供できれば、それをベースに業務始めたら もう絶対他社には移行できないと思う。 Postbox で一部プリミティブなメッセージ機能(単にファイルに書き込んでいるだけ) 提供されてるけど、あれじゃさすがに不十分だよね。普通にスレッド表示できないと。 チャットワークがいいけど、いずれも先方に否認されて終わり。 メールだよ、やっぱり。こちら側で振り分け機能を使うしかない。 >>725 Chatworks にせよSlack にせよ汎用ツールの導入はハードル高いと思うんだよね 書類やデータのやり取りのためにPostbox 導入して貰うのは比較的容易だと思う。 で、そこにプラスアルファでちゃんとしたメッセージング機能が搭載されるのが良いと思うんだ >>723 ずっと書いてるじゃん。君のやらない(できない)意見にきちんと反論している。それが証拠。 会計ソフトべったりの感覚の人には理解できないと思うから、いくら話をしても無駄。 売上の入金と他口座への資金移動しか無い通帳。入金は販売ソフトで管理している。 合計記帳でいいじゃんって言っても、 頭の固い人は、元帳で動きがわからないと、最悪青取消だ!とか言うからね。 「売上の入金と他口座への資金移動しか無い通帳。」は良いと思う。 みんな通帳持ちすぎてるし、用途もバラバラだったりする。 これなら、月ごとに (入金用)預金/売掛金 (支払用)預金/(入金用)預金 みたいな感じで、販売管理システム側との整合性取りやすいね 確かにそれなら合計転記でもいけるかもね 販売管理システムの弱点は複式じゃない(現金・預金との残高の整合性を システム側で把握できない)部分だからね そういうこともっと聞かせてよ >>728 そういう発想力が無いのが士業だからね。 昭和の頃のやり方を延々と続けているわけだ。 立替えと聞いたら資産、預かりと聞いたら負債みたいな。 案外素人の方が、これって最後0になるので売上にしておいたらダメですか? とか聞いてくるんだわ。 例えば「従業員の平成29年分の源泉徴収票が欲しい」(既にとっくに渡してあるはずなんだけど) レベルの依頼はどこでもあると思うんだけど、みんなこういうのちゃんと記録してるんだろうか? 誰が受けて、誰が送った(郵便で、メールで、手渡しで)とかまで含めて 最悪、何か作業中に電話で受けたけど、他のことやってる間に忘れちゃうことだってあるよね だから、このレベルの依頼でも「受け付けて、処理が完了して」みたいなことを 統合システムの上で管理できるといいなとずっと思ってる。 世の中にTODO管理サービスはいくつでもあるし、自分で使うだけでなく グループ管理できるものもある。 だけど、「誰に(どの関与先に)関するTODOだったのか」ということと 完了した後に整然と(関与先ごと、時系列、処理した人ごと)などに一覧で 把握できるものってなかなか見つからないんだ。 CRMシステムも Salesforce など各社から提供されてるけど、営業管理的なものが 多いからね。 会計事務所に特化したこういうシステムに、関与先とのメッセージング機能が 融合したものが欲しい。書類を渡す案件なら、その渡した書類そのものも 同じシステム上で添付ファイル的に直接参照できる形ならベスト こういうものをJDLなどの専用システムメーカーが税理士事務所に提供してくれて、 それをベースに事務所が運営されていくようになれば、おいそれとは他社の システムに移行できなくなると思うんだよね JDLは一つ前は、クライアントカルテ、HCからまた別のシステムに変わって しまったようだけど(パートナーズなんたら)、一応そういうシステムはある。 だけどこれって確か関与先単位で記録していくだけだし、日ごと、担当者ごとに 横断して「今日の作業記録」みたいなものは見れない。 現在継続中の調査一覧みたいな形でもデータは見ることができないと思う。 そういうシステム自体へのニーズはあると思う。 ミロクはそこまでではないけど近いものはあるよ。 今あるものでいかに一元管理していくかが重要。 クラウド組曲Majorへの移行を検討中なんだけど、IBEX出納帳(顧問先指導版)みたいなの入ってますか? 関与先にIBEX出納帳か出納帳netを導入済みなので、問合せなどで操作指導したい時がある。 それとも、組曲Majorには無くて、監査依頼かけてPOSTBOXに入れてもらい、会計データ入力での処理しかできませんか? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる