【クラウド】JDLユーザー集合!!その14【組曲】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
JDL(株式会社 日本デジタル研究所)のユーザーが集まるスレです。 前スレ 【クラウド】JDLユーザー集合!!その13【組曲】 http://echo.2ch.net/test/read.cgi/tax/1401702209/ >>608 わかりました、検討してみます ありがとうございました >>609 ぜひぜひ 私にとって使いやすい製品である Major をもっと皆さんにも使って貰いたいです そして将来JDLの主力商品がソフトウェア商品になり、中身がもっと発展充実することをずっと願ってます。 >>604 ありがとうございます。 やってみます。 >>611 もう一つやり方があります。 ローカル環境にMajor をインストールします。 その上で、どちらの環境からでもCRM上で、一般ファイルとして登録すれば 他の環境でも見えると思います。 私は先に紹介した2つの方が簡単なのでそっちを主に使ってますが。 すごくおもしろい稼ぐことができるホームページ 参考までに書いておきます みんながんばろうねぇ『羽山のサユレイザ』で WBK JDL営業 乙 お前は創業社長の子分だな(大爆笑) 専用機の最新機種、HCシリーズってやつでは、ソフトの内容が旧機種より機能追加があるんだな。 同じ会計データで、元帳と仕訳計(試算表)、元帳と消費税集計表などを複数ウィンドウで開くことができる。 法人税では別表4と5-1を横に並べることができる。 スキャナを使って通帳のOCR読み込みができるなど。 JDLはハード馬鹿だから、「最新のハードウェアでのみこういう新機能が使える」と 言うことを売りにしたいようだ。 同じウィンドウズ機、たいしてスペックに違いもないものだし、何が買わったかといえば ソフトが変わっただけなので、旧機種にもバージョンアップで新機能提供できるに決まってるのに 会計、税務システム屋なのに、そういう新しい機能を全面に出して新製品ですと いうのではなく、「HCシリーズという新しい機種です」とハードウェアの 新製品をアピールするのって本当に馬鹿だなあというしかない。 ソフトウェアのことがわからない経営陣なら、わかる若い人にさっさと代替わりして欲しい。 もちろん、今回の新機能は、組曲Major には提供されないよ。 スキャナ連携だって、JDL純正スキャナ(中身はただの富士通製)を買わなきゃ使えないし 専用機でしか使えない。 組曲だけ、マルチウインドウに対応ってことになると、じゃあなんでHC未満の 旧専用機では使えないんだってことになっちゃうしね。 そのうち組曲Major も、組曲Major HC とか名付けて「別製品です」とか言って リニューアルするんじゃないだろうか? ユーザーに馬鹿みたいな手間暇かけさせないで欲しい。 Microsoft を見習うべきだ。Windows はもうずっと10のまま バージョンアップを続けていくんだぜ Microsoftの収益の柱は クラウドサービスである Azure に移行しつつある JDLはいつまで「新製品です!」とか言って自己満足してハード売り続けるんだろうか? >>617 創業社長が葬り去られるまで 創立記念日の午後は休みなんか会社、今どきあるんか?(大爆笑) ハードウェアの新製品ですって言い張りたいだけのために、わざわざ金かけて新しい筐体作成して、「新製品」の本体であるソフトウエアの新しいバージョンを旧機種や組曲には提供しないって本当にすごいよな 狂ってるとしか言いようがないよ 客舐めてまで無理矢理ハード売った結果、客離れしてるんでしょ?時代錯誤なハード至上主義も限界だね。 多分JDL勘違いしてる。 いいハード作れば売れると思ってるんだろうけど、こちらとしてはもう専用ハードは「要らない」だから。 サーバーはクラウドで良いし、PCも市販のでいい。 そろそろ重い腰あげてソフト部門に力入れないと、JDLに将来が無いだろうから不安。 特に操作性とデザインに力を入れて欲しい。 MacOSにも対応して欲しい。 まぁ、従業員がバカばっかだからな。 つうか、時代錯誤のバカ社長の太鼓持ちしかいない。 朝チャイム鳴り、夕方チャイム太鼓持ち鳴り、土日は同じ会社の烏合の集とクラブ活動。社内でしか人間関係作れない奴の集まり。 ハードウェア部門抱えてる事で無駄なコストがかかってるし、利益率だっていくら馬鹿高くハード売ってるといってもソフトウエアの方が良いに決まってる 利益を得るためではなく、単にハードウェアメーカーであると言う拘りを捨てられないからハードを作り続けていると言う馬鹿馬鹿しさ 上場廃止したのは、ハード部門捨てるためなのかなと思っていたがどうやらそうでは無かったらしい 法人税等で二枚ウィンドウ開けるようにということは以前から要望していた。 4と5-1、またそれぞれの申告調整項目の別表は横に並べてみたいからね GroupDataBox(サーバーの領域を分割し、それぞれに適切なアクセス制限を付加する) のような機能も実装前から私は要望していた これらが実現したってことは、私の出したようなものと同じ要望が他にも出ていたと 言うことだし、JDL内部でもそういう機能の必要性は認識していたということだ で、何度も要望したけど、いまだに対応されてないことはもういくらでもある つまりソフトウェアの改善でやるべきだけど放置されてる項目はどっさりあるってことだ ここをよくすれば格段に良くなるということがいっぱいある リニューアルすべきなのはハードウェアではなくソフトウェアなのだ ソフトウェアこそがJDLの商品であるはずなのだ ミロクもクラウドサービスの提供始めたようだし、A-SaaSの財務のリニューアルも、予定通り1月末くらいだとしたらもう3か月ちょいだ A-SaaSの財務がきちんとリニューアルされてまともに動くものになったら、JDL財務の優位性が かなり失われるよ JDLはいつまでも「専用機」売りたいという単なる我儘を捨てて、早くソフトウェアで 他社より優位に立たないと、10年後は無くなるよ ただでさえ先行きの見通しがくらい税理士業界だけを相手にしている商売なんだから せっかく法人税で複数ウィンドウを開くことができるようになったなら、 他の事業年度のウィンドウも開くことができるようにすべきだったね。 だいたい毎年同じような税務調整やるわけなので、他の事業年度のデータを参照したいと いうニーズは必ずあるのだから。 申告調整を去年の見ながらじゃないとできないようなやつはTKCってシステム使いなさい おい、JDLの創業社長さん、みんなの意見聞いているかw 「ソフトの内容が古過ぎて恥ずかしい」ということを経営陣が分かってないことが痛い 何百回も指摘してきたことだが、どうして減価償却の資産一覧の画面は、 800×600(あるいはもっと小さい)の解像度のモニタ時代に設計されたまま 20年以上(あるいはもっと)放置されているのか HC だけに50年間変わってないのかもね ところで、信頼性・安全性を極めたネットワークサーバーということを売りにしてるなら、 当然データセンターのサーバーも他社製品じゃなくて、自社製品なんだよね? 「サーバーサービスを止めない」「サーバーユニットを多重に搭載」「2基のHDDで大切なデータを多重保管」 を実現するには、独自開発の自社製ハードウェアが必要なんだもんね まさか、他社のブレードサーバーとか使ってないよね? JDLってNumLock押しちゃって、数字が入力できねえよ!って騒ぐお爺ちゃんを対象にしてるんでしょ? はーい、ざんねん。 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財務など条件が揃わないとできないね ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる