Александр Гoлдун Urri
Не совсем так. Она есть, потому что мы (разработчики) сами ее иной раз порождаем. Если в отчете о движениях по бухгалтерскому счету, полученном из БУ, данные не соответствуют данным отчета, полученного из ОУ, о транзакциях, которые порождают движения по тому самому бухгалтерскому счету - это проблема.

Чаще всего эта проблема все же порождается не программистом. Это орг проблема. Если машина с комплектухой пришла с кривыми документами и с колес пошла в производство, а бухгалтерия провести ее не может, то тут никакая программа не обеспечит совпадение цифр ОУ и БУ.Согласен, случаи бывают разные. Но я имел в виду совсем уж вопиющие вещи. Например, в большом проекте отчеты из разных модулей разрабатывают разные сотрудники. Представим также, что в ОУ есть понятие "переоценка", когда транзакция не изменяет количество, но изменяет стоимость. А теперь представим, что разработчик отчета из ОУ о движении материалов забыл о таких транзакциях (или же про них забыли при формулировании функционального дизайна, а может, данный отчет специально разрабатывался с первичной целью отследить только количественные изменения, но какой-то заказчик потребовал, чтобы рядом с количеством стояла стоимость операции, и его желание решили удовлетворить, не приняв во внимание, что стоимость может меняться и другими транзакциями. Теперь в итогах отчета может возникнуть ситуация, когда при нулевом количественном остатке будет ненулевой остаток в денежном выражении. А в БУ отчет о движении по счету подбивает только денежки, и он принимает во внимание все операции, а не только изменяющие количество, и поэтому он выдает правильный остаток на счете по деньгам. А теперь представим недоумение бухгалтера, получившего один за другим результаты этих двух отчетов.
Я могу утверждать, что проблемы такого рода в больших проектах случаются постоянно. И их наличие даже не может являться свидетельством некомпетентности бизнес-аналитиков и системных архитекторов (вернее, может, но только до определенной степени).