Честно говоря не понял ваш пример.
А вообще суть претензии в том, что название метода сбивает с толку. Запутывает.
Люди обычно привыкли воспринимать либо чистую сумму без налогов, либо сумму со всеми налогами. Это практика жизни. Потому что сумме со всеми налогами соответствует выручка и дебиторка, поэтому она всех и интересует. А отображать в системе сумму которая в одном случае означает одно, в другом другое можно конечно, но по-моему пользы мало. Лишняя путаница в головах пользователей.
Плюс при таком подходе lineAmountTax непонятно что отображает. Для чего знать налог включенный в цену ? Как правило, интересен просто налог. Пользователь хочет знать какой НДС по строке. Не важно включен он в цену или нет. Кого может интересовать величина в одних случаях равная НДС а в других неравная ?
Плюс немного программистское
Посмотрите на методы
\Data Dictionary\Maps\SalesPurchLine\Methods\calcGrossAmountExclTax
\Data Dictionary\Maps\SalesPurchLine\Methods\calcLineAmountExclTax
\Data Dictionary\Tables\SalesLine\Methods\amountExclTax
\Data Dictionary\Tables\SalesLine\Methods\calcGrossAmountExclTax
\Data Dictionary\Tables\SalesLine\Methods\calcLineAmountExclTax
\Data Dictionary\Tables\SalesLine\Methods\lineAmountMSTExclTax
\Classes\Tax\baseAmountExclTax
в этих методах дается сумма без налогов - везде в названии есть ExclTax
В соответствие с правилами наименования полей и методов определенных в BestPractice, логично предположить что метод lineAmountInclTax() вернет сумму с налогом. Особенно если заглянуть в код и увидеть что там идет сумма полей.
Ан нет! Подстава в том что поле с наименованием lineAmountTax не обязательно содержит НДС ! (В то время как custInvoiceTrans.LineAmount всегда содержит сумму без НДС.)
В общем, видишь метод или поле - не верь глазам своим! Все перепроверяй!
P.S.
Если я параноик, то это не значит что за вами не следят !
