エントリー

2015年の記事は以下のとおりです。

年末年始の稼働状況

本年の営業は本日、12月28日までとなっております。年始は翌1月4日から稼働予定です。本年中にお世話になった方々には(特段お世話にならなかった方々にも)厚く御礼申し上げます。新しい年を迎えましても一層のご厚情を賜りますことを切に願います。ありがとうございます。

by 千田

 

宣伝
税務LANには、給報や年金をパンチエントリーするツール(独立ツール)があります。
イメージを見ながらの連続入力が出来るので、紙資源を庁外に持ち出さずに済みます。(イメージは暗号化して伝送出来ます。)

VDI仮想サーバーでパフォーマンスが出ない?

仮想サーバーでバッチ処理やチェッカーのパフォーマンスが出ないところに朗報となるか?

ポイントは、ホストOSの電力設定。
大概ゲスト側の電力設定は見ていると思うのです。ホスト側は盲点です。
あとはBIOSでの省電力管理です(有ればですが)。ハードが勝手に処理する省電力管理はOSが検知出来ない場合があるようです。
今のOSは、CPUへの負荷に敏感かも知れませんが、I/Oへの負荷に関してはあまり敏感では無いようです。
上記設定で、チェッカーの速度がになったと言う所もありました。VDI環境でバッチ処理が遅いと感じている所はこの辺の設定を見直してみて下さい。ホストOSは必ず高パフォーマンスにて。ちなみに最低CPUの率をデフォルトの5%から25%→50%→75%などと上げるだけでジグザグの山が小さくなり、全体のパフォーマンスが向上します。つまりバランス設定のままでも改善は見られると言うことです。負荷の掛かるサーバーは、そんなに頻繁に省電力に落ちられても困ると言う事です。

h**p://d.hatena.ne.jp/ogawad/20120521/1337554729
h**p://www.school.ctc-g.co.jp/columns/microsoft/microsoft13.html
h**p://www.atmarkit.co.jp/ait/articles/1308/22/news087_3.html
上記リンク先の話しにも出ていますが、頻繁なスイッチは、それだけで平均を落とします。 又、従来は余裕だったネットワークスイッチが10倍もビジーになる事など、OS設計者も予期しないハードウェアの劇的な進歩も要因の一つなのかも知れません。
ちなみにネットワークが遅いと、CPU占有率が低いのにパフォーマンスが出ない現象が起こります。同じくHDDが遅い場合も同様になります。
SATAなどのI/Fの場合には、I/Oウェイトを入れるので、CPUが待ちに入ります。
昔からサーバーにはSCSIを使用していたのは、HDDの待ちの間、CPUが他の作業を行うことが出来たからです(厳密にはDMAなども利用してCPUを開放する機能も有るのですが)。バスレートが高くなって、ハードも高速化し「待ち」が無くなったので、その部分を疎かにしたハード構成が出回っています。ある組合わせでは成功しているかも知れませんが、業務の形態(I/Oの頻度)によっては、これが破綻するケースが出てきます。チューニング、バランスはとても大切ですね。
かく言う私は、昔々、SCSIやATAのHDDのI/F設計を行っていました。デバドラも組んでいたので、OSがどの様にアクセスするのかも知っています。昔の話しなので、今のハードとOSの仕組みには暗いです。でも基本は変わらないと思うので、少しはこの知識も役に立つ時もあると言う事で。知っている人居るかな?NINTENDO64のDDシステムの設計には千田と蟻坂も関係していたことを。

by 千田

「個人の住民税の給与支払報告書及び公的年金等支払報告書の光ディスク等化について(通知)」における「住宅借入金等特別控除区分」等の取扱いについて

について(通知)」における「住宅借入金等特別控除区分」等の取扱いについて。


なんですとぉー!(T_T) な仕様が出回っています。給報の特定取得の区分コード、11,12,13を取りやめて、今年だけ01,02,03+「特定」と記すことになりました。ここに来て、税務LANの当初仕様に回帰する事になるなんて。H28年分は本則通りに。誰ですか?拡張コードに対応出来ないから、仕様を変更してくれと言った事業所(はたまた自治体か?)は。
と言うか、仕様を出すのが遅いんですよ!ぷんぷん。

取り敢えず旧仕様を残しておいて良かった。V8-2016版は両方作動しますから。
給報エントリーに「特定」の認識ルーチンを噛ましておきましょう。
ちなみにe-Taxの場合、適用条文欄に「特定」が記されることは想定済みで対応済みでした。

2015.12.11追記
と言う事で
「個人の住民税の給与支払報告書及び公的年金等支払報告書の光ディスク等化について(通知)」における「住宅借入金等特別控除区分」等の取扱いについて
の追加事務連絡が届きました。11,12,13でも良いって事で。
迷走してますね。このぐらいのブレは税務LANには水素の次の元素でもないです。
それよりも大変なのが給報年報の第17号様式の変更です。カナ氏名や扶養区分コード等の追加は問題無かったですが(税務LANは生年月日まで持っていましたから)、レイアウトが随分と変わりましたね。画面設計終わっていたので、配置換えに思いの他時間を要しました。今回プレ稼働するお客様には、給報のレイアウト違いでご迷惑を掛けるだろうな…。

by 千田

新規稼働ユーザー様の

番号整形の設定の季節となりました。事業所番号、住基宛名番号、世帯番号の3つは、入力フォーマット(ハイフン区切り)、前スペゼロパディング、桁数指定が出来ます。無償対応です。
稼働途中から整形が入る場合には、前年までのデータの番号変換を伴います。(ツールはリリースされています。)
お早めのご対応をお願いします。
設定が掛かると全年度のモジュールが再構築されます。過年度の動作にはご注意を。

それから、他社システムからの移行に関して、広い視点で判断しないとあちこち連携が取れなくなる物が出てきますので、再三言いますが広い視点で影響の度合いをご判断下さい。
税務LANに切り出されているのは何なのか、コピペで他システムに持って行けるのか?
課税切り出しツールでも、前ゼロ付加を行っていたりしますので要注意です。

ITはインプット→処理→アウトプットの世界です。ルールさえ明確になれば常に噛み合います。
ここのルールが噛み合わないと、すいませんの世界になります。

余談。
今回、DLLを更新しましたが、2014年版以前は関係無いとアナウンスしていましたが、常に最新を適用しているところは関係無い。と言う事でした。古いままだと2014年版でも起動出来なくなります。
今現在アップされている資源で動きますので差し替えを。2013年版以前はDLLのチェックをしていません。更新ドキュメントに過年度分にも適用が有るものは、なるべく差し替えを行って下さい。

by 千田

マイナンバーと住基地課税について

GW前にも少しだけ触れたが、マイナンバー制度が活用されることで、本来の住基地への課税資料の配付が可能となり、住登外課税処理に関する不均一さが解消されると期待されています。元々が、個人の税情報を正しく管理する為に始まった制度と考えると、住基地じゃない所で課税されるとて、その方の課税情報が正しく管理されない事は本意ではありませんね。となると294通知を出して課税する事も無くなると言う事でしょうか。他市回送処理がそもそも不要になるのでしょうか?メリットデメリット両方有ると思われますので、有効性をしっかりと判断して戴きたいものです。

ここに来て住民税申告書に記載している「個人番号」欄に関するカスタム要求が高まっています。ここで言う個人番号はマイナンバーでは無く、住基宛名番号です。2016年課税に向けて、市申等に「個人番号」と記載されているとマイナンバーが印字していると勘違いする住民が居るのではと言う事を懸念しての対応でしょう。確申はマイナンバーが記載されてくるのは2017年からなので、勘違いする方は居るでしょうかね?(居ないとは言い切りませんが。)
今の印刷モジュールは、ここの部分は埋め込み設定なので、ユーザー別にカスタムしないと変更も容易ではありません。V9版は、端からパラメータ化されているので問題無いですけれど。あまりに要望が多いようだと、カスタムフォームの差し替え対応もしなければならないです。保守では対応しきれません。もう少し早い時期に仰って貰えれば、無償対応も可能だったと思うのですが、今からでは作業者の工数が確保出来ません。北上支社にはそんなに人員は居ません。マイナンバー版プレリリースもあるので手一杯なのです。

by 千田

やっと出た!

OCR帳票仕様書が本日午後にリリース開始。

2015.11.25追記
FA0111とFA0121、FA0035になっていますね。何処が変わったのか摺り合わせを行います。XML拡張では幾つかの変更は確認していたのですが、1表に「国出」が増えたのはB申告書だけだしな…一応、平成27年分以降用となっては居るが…、ん~間違い捜し見たくなってきた。

by 千田

特定肉用牛の収支計算書の印刷書式の件

いわゆる免税牛の収支計算書ですが、熊本国税局管内の税務署用に特別な書式の収支計算書を印刷しています。幾つかのユーザーからは、その書式で出して欲しいとの事で、書式対応していますが、同じ局管内でも標準書式で対応されているところもあります。(標準とは、一般農業収支計算書式を免税分で別途出力する方式です。)

免税牛に関しては、その棚卸の書き方などもまちまちで(そもそも収支計算書が非対応、申告システムが非対応などの理由が一般的です)、その不完全な運用に合わせると面倒な事が起こります。
税務LANはこれらに対応しているので、従来書式を工夫して記載する必要もありません。

本題から逸れましたが、熊本国税局管内のユーザー様で、肉用牛の収支計算書の独自様式出力を希望される場合には、声を上げて下さい。ユーザー設定登録するだけで出せるように対応出来ますので。追加費用は要りません。標準機能です。

by 千田

とあるFacebookのリンクから紹介

Ura-Cima チームウラシマのFacebookのリンクに松尾鎌倉市長のFacebookの紹介があった。

www.facebook.com/matsuonet/posts/782045238543637

収入部門が真っ先に支出を削減する取り組みを賞賛するコメント多数。
こう言うモチベーションの高い所と一緒に仕事がしてみたいものだ。もちろんこのリンクを張っているBPOWGを運営しているところ然り。
いやいや、昨今契約を結んだお客様方も業務効率化の為に非常に意欲的だ。俄然やる気が出る。まずはこちらを成功に導かなくては。東急は下高井戸で京王線に乗り換えるのだな。ふむふむ。
果たして税務LANは効率化のお役に立てるツールとして機能していますでしょうか?我々も暗中模索なのであります。
あるお客様から、「リードコナンと距離が近いお客様は、税務LANを上手く使っている」と言われたことがあります。それは販社SEに対して税務LANの設計意図・思想、噛み砕いて運用の仕方を上手く伝えられていないのだと言われている様なもの。
ドラスティックな改善は望めなくても、1mmでも良いから右肩上がりに(志村けん氏の言葉)伸びていければ良いと思うこの頃。

by 千田

給報のレイアウト変更について

遅い遅いと思っていましたが、やっと出てきましたね。給報の住借控除区分の特定取得対応。5、6、7となるかと思いきや、11、12、13となりました。
益々、ここのチェックが疎かに出来なくなったと思われます。今まで見たいな未記載云々の話しでは無いです。しっかり記載ルールを守って貰わなくては。
給与システムとかの改修って間に合っているんですかね?老婆心ながら…。

ところで、先週に新給報レイアウトをリリースして、やむなく特定取得のフラグを追加して合算等の対応まで行いましたが、○住レイアウトを含めて改修すべきですかね?
コード11、12、13は温存し、対象に対して、追加した特定取得フラグを立てる処理を行って処理しますかね?○住パンチレイアウトは、昨年の実績もある事から、下手に削ると大変な事になりそうなので、両方インプットされても作動するようにしておきます。給報はこれからなので、修正も視野に入りますが、既にパンチ業者と仕様固めたところもありますよね。
でも、でも、ですよ、そもそも此所の拡張は間違いないと皆さん判っていた訳ですから、仕様が出る前に勇み足したところは、修正もやむなしなのですかね?いずれ今週中には最終仕様を決定いたします。

さて、何処ぞの市では他市回送分給報を大事に金庫にしまっていた為に、対象市区町村で課税漏れが多発したようです。大事ですね他市回送。税務LANだったら漏らさなかったでしょうね。どうですかね?データで管理出来ていますから。(給報はパンチに委託している規模の市なので紙で管理していたから…と言うのは無いと思います。)いずれこう言う事の無い様に日々気を付けていないといけない業務を行っていると言うこと。
税務LANのデモを行うと大概言われる事、「機能が多すぎて覚えられない、難しい」。そうです。それほど難しい複雑な仕事をしておられるのです。我々が提供するのは全自動マシンでは無いです。それぞれのやり方に合わせて使い方を選べる道具を提供しています。使い方を誤らなければ良い仕事をしますよ。(自動化出来ないわけでは無いです。自動化は100%の処理では無いと言う事なのです。)

by 千田

仙台局に行ってきました。

本日、仙台国税局に行って、色々と貴重なお話しを伺ってきました。わざわざ時間を割いてくれたご担当者様方々、誠にありがとうございます。今後ともよろしくお願い致します。

さて、本日伺った用件は、税務LANで受けた申告のe-Tax電子送信に関わる部分。
既に各局から説明されている部分と、未公開な部分とありまして、既に公になっている部分としては、e-Tax送信ソフトがLGWAN対応になり、複数のファイルを一括で送信出来る機能が実装されるようです。そうすると、申告受付時に利用者識別番号を登録してあれば、吐き出したファイルを特定のフォルダに蓄積しておいて、一括で送信が可能になります。

もひとつ、利用者識別番号は申告者個人毎に必要である要件には変更は無く、それを取得する方法が改善されそうであると言う事。H29.1申告時の電子送信を普及させる為に、H28.2申告受付時に利用者識別番号を取得する為の案内を一緒に印刷させるとか、紙での申請書をその場で書かせてしまうなどの処置をしておくと、来たるべき時にはスムーズに事務が遂行できそうです。その為の機能を実装しなければならないと切に感じた次第です。

ちなみに、e-Tax送信ソフトで申告データを送信する為には、申告システムが、e-TaxのXML形式のデータを正確に吐き出す必要があります。税務LANは既にXMLで吐き出しているので、CSV→XML変換などの必要がありません。中間ソフトの利用無しに、そのまま送信可能となっています。

さて、各自治体におけるこれらの電子送信テストが来夏に控えているという事の様ですので、それまでの間に出来る事を洗い出して、出来る対策は処置していこうと思うのであります。

追記
 マイナンバー利用が始まると、紙で提出する申告書には、マイナンバーのコピーを必ず添付する事になります。面倒ですよね。郵送までの管理も今まで以上に気を遣います。

by 千田

ページ移動

ユーティリティ

カレンダー

2015年1月
- - - - 1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

検索

エントリー検索フォーム
キーワード

過去ログ

Feed