Мимопроходящийв больших системах хранят единожды вычисленные значения, а не считают по каждому чиху заново.У нас об этом сразу не сообразили, теперь переделываю. Собственно уже на внедрении, но, блин, "нуевонах". Мороки с переделкой по самое "небалуйся". Делать надо сразу, чтоб хранить первичку цельно. Взял из справочника периодический реквизит (ака ставка НДС), положил его в списочную табличку накладнушки, сосчитал и округлил до копеек требуемые суммы и тут же их и зафиксировал. Если что-то округлять на этапе печати-агрегации-отчетов, то это, доложу я вам, полная ж***.

KreatorXXIСкорее не комильфо держать базу ставок НДС для каждого наименования товарабред. более того у меня были прецеденты, когда одна товарная позиция в зависимости от доп пареметров имела разные ставки (одна и та же модель школьной формы в зависимости от рост-размера шла с разным НДС).
KreatorXXIнагрузка на сервер будет при расчёте ого-гобред в квадрате. Если одно индексное чтение это нагрузка, то мне уже давно пока "утопиццо".
KreatorXXIХранить одну ставку НДС на документ тоже неправильнонеправильно.
KreatorXXIв документе могут быть товары с разными ставками.на прежней работе был написан "реверанс", который делил такие накладнушки на 2 по одной кнопкой оператором, просто так было удобней бухгалтеру, хотя если просили выделить транспортные расходы(18%) на детский ассортимент(10%), то было все в куче.

KreatorXXIПри наличии вот такой сложнопостановочной схемы "Товар-Дата-Ставка" одним индексным чтением не обойтись.Если сделать грамотно, то ничего страшного.