アカウント名:
パスワード:
.NETならまだマシ。VB6+Windows2000とかまだゴロゴロあるよ
消費税対応で今頃になって「どうにかしてー、でも安くしたいから作り直しはしない！」ってのばっかりで、みんなしねばいいのに、と本気で思う
○月○日からパチッと8%に切り替わるよー、という、簡単に予想されうる消費税変更なのにiniファイルに1行足すだけとか、DBのレコードを1行insertするだけとかそれで対応できる作りになっていないのもちょっとあれだし。安くしてさしあげりゃいいよ。
// 税率が変わったときはここに追加var TAXES = [ ['0000/1/1', 0.00], ['1989/4/1', 0.03], ['1997/4/1', 0.05], ['2014/4/1', 0.08] ];
// 円周率が変わったときはここを変えるvar PI = 3.1415926535;
// グラハム数 FIXME:誰か入力してvar GURAHAMU = Number.NaN;
> ○月○日からパチッと8%に切り替わるよー、という、簡単に予想されうる消費税変更なのに
消費税が対象により変化するとしたら、とか対象によっては一部除外されたら、とか考慮すべき点は山ほどあります。結果として設定箇所は膨れ上がりロジックも複雑になります。これは長年国家レベルで運営されてきた主体に付随する銭勘定はみんなそうです。分からないなら勘定系を10年やってきてください。
それらを「していたら批判する」のに「していなかったら批判」するなら、それはただの魔女裁判ですね。
実際、○月○日からパチッと8%に切り替わるよー、という、簡単に予想されうる消費税変更だったのに何言ってんだこいつ・・・
> 実際、○月○日からパチッと8%に切り替わるよー、という、簡単に予想されうる消費税変更だったのに> 何言ってんだこいつ・・・
意味不明。
アプリを作りこんだのはずっと昔なわけです。その時点で、あなたの言う
> 実際、○月○日からパチッと8%に切り替わるよー、という、簡単に予想されうる消費税変更
が将来に渡り成立するとしていた政府などのお墨付きの資料はどこにありますか？是非ご提示ください。
それがないのに、もっとも単純なケースだけが成立するためにアプリの拡張性や柔軟性を犠牲にし続けることが正解とあなたは叫んでいますが、典型的な「結果論で他人を攻撃するだけの役に立たない人」ですよね、それって。
ちなみに、今回から見ての将来もどうなるかはわかりません。
そんなに簡単にいくもんかね。零細事業でも、リース、キャンセル再発注、追加発注、未払い金なんかを考慮すると一筋縄でいかないが。
とりあえず、東日本をカバーしてる程度のそれなりの勘定系を数年やった事があるけど適用年月日と税率を持った「税率マスタ」は持ってるねえ。過去、0%,3%,5%と単純に上がってきたんだから、そこに今度は8%を追加するだけだわ。
勘定系じゃなくて、まあ、ちょいウェブスクレイピングもやったけどやっぱり税率マスタっぽいの使ってるよ。こちらも8%を加えるだけでいいはず。
もちろん、それで対応できない変更だったのであれば、それなりの対応が必要になるけどさ。イギリスとか面白いね。「あったかい食事」代だとまた税率が違ってくるんだって？
でも今回、単純な追加で対応できないのは、どういう実装になってんの？0%,3%時代とは無縁で、5%固定で持ってんの？
> でも今回、単純な追加で対応できないのは、どういう実装になってんの？> 0%,3%時代とは無縁で、5%固定で持ってんの？
たとえば科目ごとに個別設定できるなどでマスタの設定箇所が分散している場合や、グループ社内取引での特別処理の有無を考慮する必要がある、複数の勘定系の連携において特定の科目は外部システム側で計算するからこのシステムでは「考慮してはいけない」なんてのがある、とか山ほどありますね。
あなたがやったところが極端にシンプルだっただけです。ここからは推測ですが、あなたがやったところは本当のコアの部分だけ(何も考えずただ計算するだけ程度)で周辺サブシステムが必死に頑張ってたんでしょう。
業務システムの関わり方によって今回の消費税対応が単純に乗数の変更だけに思える人たちと費目や契約時期など細目を法令の指示によって考慮しないといけないことを実装する人たちの認識の差は大きい感じがしますね。正直、半年前に実施判断されてからシステム対応しても立ち行かない規模と思いますよ。
多分だけど、単純に複数税率対応はできてたんだけど「そもそも軽減税率とか対応できんの？」とか「外税、内税分けたいな」とか「既存長期契約や貸借系は契約毎、請求毎に税率適用年月日を任意で持ちたい」とか単純に税率UPだけ見てて、それ以外何も考えてなかったツケがいま一気に回ってるんじゃないかと
既に税率マスタによる税率変更にはとっくに対応してるんだけどそれしか対応してなかったんだよね、昔は。だから結局不十分なの
暫定措置で、たとえば有名なのは9月中に契約した住宅は引渡しが4月以降でも５％で計算、とかは困りますね。（売上＝引渡し日となっているようなシステムでは）
そこでDI/IoCですよ。感情系勘定系にそんな観念自体が存在するのか知らんけど。
そんな機能要らないから安くして！という案件がどれだけ多いか
HTMLやJSPに価格ベタ書きの、なんと多いことか…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
甘いよ (スコア:5, 興味深い)
.NETならまだマシ。VB6+Windows2000とかまだゴロゴロあるよ
消費税対応で今頃になって「どうにかしてー、でも安くしたいから作り直しはしない！」
ってのばっかりで、みんなしねばいいのに、と本気で思う
Re:甘いよ (スコア:0)
○月○日からパチッと8%に切り替わるよー、という、簡単に予想されうる消費税変更なのに
iniファイルに1行足すだけとか、DBのレコードを1行insertするだけとか
それで対応できる作りになっていないのもちょっとあれだし。
安くしてさしあげりゃいいよ。
// 税率が変わったときはここに追加
var TAXES = [ ['0000/1/1', 0.00], ['1989/4/1', 0.03], ['1997/4/1', 0.05], ['2014/4/1', 0.08] ];
// 円周率が変わったときはここを変える
var PI = 3.1415926535;
// グラハム数 FIXME:誰か入力して
var GURAHAMU = Number.NaN;
Re:甘いよ (スコア:1)
> ○月○日からパチッと8%に切り替わるよー、という、簡単に予想されうる消費税変更なのに
消費税が対象により変化するとしたら、とか対象によっては一部除外されたら、とか
考慮すべき点は山ほどあります。
結果として設定箇所は膨れ上がりロジックも複雑になります。
これは長年国家レベルで運営されてきた主体に付随する銭勘定はみんなそうです。
分からないなら勘定系を10年やってきてください。
それらを「していたら批判する」のに「していなかったら批判」するなら、
それはただの魔女裁判ですね。
Re: (スコア:0)
実際、○月○日からパチッと8%に切り替わるよー、という、簡単に予想されうる消費税変更だったのに
何言ってんだこいつ・・・
Re: (スコア:0)
> 実際、○月○日からパチッと8%に切り替わるよー、という、簡単に予想されうる消費税変更だったのに
> 何言ってんだこいつ・・・
意味不明。
アプリを作りこんだのはずっと昔なわけです。
その時点で、あなたの言う
> 実際、○月○日からパチッと8%に切り替わるよー、という、簡単に予想されうる消費税変更
が将来に渡り成立するとしていた政府などのお墨付きの資料はどこにありますか？
是非ご提示ください。
それがないのに、もっとも単純なケースだけが成立するために
アプリの拡張性や柔軟性を犠牲にし続けることが正解とあなたは叫んでいますが、
典型的な「結果論で他人を攻撃するだけの役に立たない人」ですよね、それって。
ちなみに、今回から見ての将来もどうなるかはわかりません。
Re: (スコア:0)
そんなに簡単にいくもんかね。
零細事業でも、リース、キャンセル再発注、追加発注、未払い金なんかを考慮すると一筋縄でいかないが。
Re: (スコア:0)
とりあえず、東日本をカバーしてる程度のそれなりの勘定系を数年やった事があるけど
適用年月日と税率を持った「税率マスタ」は持ってるねえ。
過去、0%,3%,5%と単純に上がってきたんだから、そこに今度は8%を追加するだけだわ。
勘定系じゃなくて、まあ、ちょいウェブスクレイピングもやったけど
やっぱり税率マスタっぽいの使ってるよ。こちらも8%を加えるだけでいいはず。
もちろん、それで対応できない変更だったのであれば、それなりの対応が必要になるけどさ。
イギリスとか面白いね。「あったかい食事」代だとまた税率が違ってくるんだって？
でも今回、単純な追加で対応できないのは、どういう実装になってんの？
0%,3%時代とは無縁で、5%固定で持ってんの？
Re: (スコア:0)
> でも今回、単純な追加で対応できないのは、どういう実装になってんの？
> 0%,3%時代とは無縁で、5%固定で持ってんの？
たとえば科目ごとに個別設定できるなどでマスタの設定箇所が分散している場合や、
グループ社内取引での特別処理の有無を考慮する必要がある、
複数の勘定系の連携において特定の科目は外部システム側で計算するから
このシステムでは「考慮してはいけない」なんてのがある、
とか山ほどありますね。
あなたがやったところが極端にシンプルだっただけです。
ここからは推測ですが、
あなたがやったところは本当のコアの部分だけ(何も考えずただ計算するだけ程度)で
周辺サブシステムが必死に頑張ってたんでしょう。
Re:甘いよ (スコア:1)
業務システムの関わり方によって今回の消費税対応が単純に乗数の変更だけに思える人たちと費目や契約時期など細目を法令の指示によって考慮しないといけないことを実装する人たちの認識の差は大きい感じがしますね。正直、半年前に実施判断されてからシステム対応しても立ち行かない規模と思いますよ。
Re: (スコア:0)
多分だけど、単純に複数税率対応はできてたんだけど
「そもそも軽減税率とか対応できんの？」とか「外税、内税分けたいな」とか
「既存長期契約や貸借系は契約毎、請求毎に税率適用年月日を任意で持ちたい」とか
単純に税率UPだけ見てて、それ以外何も考えてなかったツケがいま一気に回ってるんじゃないかと
既に税率マスタによる税率変更にはとっくに対応してるんだけど
それしか対応してなかったんだよね、昔は。だから結局不十分なの
Re: (スコア:0)
暫定措置で、たとえば有名なのは9月中に契約した住宅は引渡しが4月以降でも５％で計算、とかは困りますね。
（売上＝引渡し日となっているようなシステムでは）
Re: (スコア:0)
そこでDI/IoCですよ。
感情系勘定系にそんな観念自体が存在するのか知らんけど。Re: (スコア:0)
そんな機能要らないから安くして！という案件がどれだけ多いか
Re: (スコア:0)
HTMLやJSPに価格ベタ書きの、なんと多いことか…。