일단 3개만이 있다고 하자. 노력, 성공, 보상

노력 > 성공 > 보상

이게 인과관계가 아니라서 노력한다고 성공하는 거는 아니고, 성공한다고 보상이 반드시 있는 건 아니다.

부잣집 도련님은 노력 > 성공의 단계가 없더라도 애초에 주어진 보상이 있다. 노력 > 성공의 단계를 거치지 않았다면, 잘 산 거는 아니다. 노년에 비참함이 없겠지만, 노력 > 성공이 주는 기쁨을 한 번 사는 인생에서 경험하지 못했다면 잘 살았다고 할 수 없다.

가난한 집에서 태어나서 할 수 있는 건 노력밖에 없어서 노력 > 성공을 했으나 보상이 없다면, 말년이 비참하다. 역시 잘 살았다 할 수 없다.

노력 > 성공 > 보상 이 3개가 맞춰져야 잘 산 인생이 되는 것이다.

어차피 한 번 살고 다시는 돌아오지 않는 인생이고, 잘 산 인생이 되는 건 나만의 노력만으로는 되지 않는거니 왜 나는 잘 산 인생이 못될까 쓸데없이 고민하지 말자.

잘 산 인생은 내 뜻만으로 되는 건 아니다. 그래도 노력이라도 하자. 절반만이라도 잘 사는 셈이다.

자회사가 불균등배당을 실행한 경우 모회사는 지분법손익으로 할 것인가 지분법이익잉여금변동으로 회계처리할 것인가?

지분법이익잉여금변동의 사례는 자회사가 중요한 오류수정사항을 변경하므로 인해 전기오류수정손익을 이익잉여금에 반영하였을 경우 필시 모회사 역시 오류가 발생하였을 것이므로 지분법이익잉여금변동을 통해 모회사도 오류수정을 하고자 하는데 있다.

한편, 배당은 회사로부터 주주에게로 부의 이전을 실현하는 것을 잉여금처분을 표시로 하는 것으로 주주와 회사와의 거래를 나타내는 것인데, 불균등배당효과를 만일 지분법이익잉여금의변동으로 회계처리하게 되는 경우, 자회사와 모회사와의 부의 이전이 모회사의 지분법이익잉여금의변동이라는 회계처리를 통해 모회사의 잉여금의 처분의 형태에도 나타나게 되어 경제적 실체에 대한 reporting 이 부적절하게 표시되는 문제가 있다.

과거 기업회계기준에서는 자회사의 불균등배당의 경우 지분법손실 또는 이익으로 반영하여 자회사와 모회사와의 거래로 회계처리를 종결하도록 하였는데, 이러한 회계처리방식이 회계기준의 체계에 부합한 회계처리이지 않나 싶다.

-----------------------------------------------------

2017년 11월 20일(한국회계기준원)에 종속기업의 차등배당에 대한 지배기업(연결대상인 경우)는 모기업과 자기업간의 자본거래로 보아, 지분법자본잉여금변동으로 회계처리하도록 하였음.

관계기업이 차등배당을 하는 경우라면, 기존처럼 지분법손익으로 해야할 듯.

firebird 를 활용하고 있다. 무료이고, 사용에 제한이 없는게 가장 큰 장점이라고 하는데.., 사실은 제일 먼저 접한 디비이고 다른 거는 사용해 본적이 없기는 하지만, (원산지증명 관련 프로그램개발을 하고 있다는 어떤 프로그래머의 얘기로는 select * 가 다른 디비에 비해 무척 빠른 디비라고 하는데.. 만일 그게 팩트라면 나의 필요에 무척 적합한 디비이다.) 아마 다른 db 들도 크게 다르겠나.. 암튼,

db 를 사용하여 분석툴을 만들다 보면 데이터 구조의 정의를 필요에 따라 실시간으로 바꾸어 사용하게 되기 때문에 필연적으로 만날 수 밖에 없는 문제상황이다.

unsuccessful metadata update... table ..... too many versions..

이게 나타난 이유는 데이터를 설계하고.. 이후에 추가하거나 삭제를 할 경우 firebird 는 TABLE 당 256 번까지만 허용하고 있다. 해결책으로 firebird 홈페이지(FAQ)에서는 backup 과 restore 를 해주라는 것인데, 이 방법말고, 실시간으로 해결할 수 있는 방법이

RDB$FORMAT 의 값이 255 개인지를 점검을 해서 추가적으로 갱신해야할 것을 포함하여 255 개 이하이면 갱신을 하고 255개 이상이면 기존 table 을 DROP 후 새로 CREATE 를 하는 것이다.

이렇게 만들면 아마도 필연적(?) 만나게 되는 두번째 문제상황이 있는데, 실시간으로 table 을 drop 할 때, 어쩌면 만날 수도 있는 문제상황으로(물론, 만나지 않을 수도 있고(테이블 설계할 때 삽입 삭제등의 sql문장을 일단 clear 해 놓는 습관을 갖고 있었다면)).. 이게 create 에서는 안나타나고 drop 할 때만 나타난다.

unsuccessful metadata update.. table ..... is in use 이다.

commit 을 해버리면 문제가 아니지만 commitretaining 을 할 때가 문제이다. commit 을 해 버리면 기존에 갖고 있던 모든 연결을 몽땅 해제해 놓으므로 분석중에 있는 과정에서 다시 재 연결해야 하고 몹시 번거롭게 된다. 대개 삽입삭제 등 일반적인 sql 문장은 별도 컴포넌트들에 설정해 놓고, 데이터구조의 갱신은 또 다른 컴포넌트들을 사용하기 때문에 발생하는 것이고.. 이러한 상황을 알면 매우 간단한 문제인데.. 이걸 눈치채기가 .. 만만치 않더라. in use 라니 난감하지.. 아무튼 해당 테이블과 관련된 기존에 정의해 놓은 sql 관련 문장을 모두 clear 해 놓고 commitretaining 을 하면 깔끔하게 문제가 해결된다.