...из-за того, что не нашел на карте Берингов пролив?..........

Условие.

Есть учтенная товарная накладная. В ней рядом две стоки с одинаковым количеством - 1(одна) штука - и одинаковой ценой. В экранной форме все ОК. В строках таблицы Sales Shipment Lines все OK - все цены и все суммы в этих двух строках одинаковые.

Вопрос.

Почему в печатной форме сумма НДС в одной строке на копейку отличается от суммы в другой строке? (повторяю в строках таблицы они одинаковые!!!) откуда он это взял?

Мои орлы разработчики непричем, потому что это стандарный (в смысл для России) отчет.

Что крутить то?

Условие 2

Заказ проходит следующие стадии утверждение(выпуск), товарный учет(получаем учтенную накладную), финансовый учет (учтенная счет фактура).

Вопрос 2
Почему на крайних стадиях счет фактуру с номерами ГТД я печатать могу, а вот на стадии товарного учета я такую возможность теряю? То есть в стадии товарно-учтенного заказа счет-фактура не печатается. Нет такой стандарной формы. Более того разработчики утверждают, что это по большому счету невозможно - де это уже не резерв, но еще не всвязь заказов со отгрузками.
Что делать?

То есть сначала ГТД одним механизмом связываются. потом другим, а в промежности никак. У меня возникает законное подозрение, что связь сначала может отличаться от связи в конце. Законно ли это подозрение?

Я фигею с Русского Микрософта, ребята. Их локализации это нечто.

2 фигею2

про бредятину - это в точку. Никак иначе это не назвать. Если хотите могу скрин-шоты этой бредятины приаттачить.

А если подскажите, где в 4-м Navision можно на стадии товарного учета (если финансовый учет еще не прошел) распечатаn счет-фактуру (там где ГТД), буду вам благодарен без меры. Жду вашего совета.

автор Я навижен не видел ниразу , но я думаю, что это сделано для того, чтобы сумма НДС по строкам совпадала с НДС по сумме. На НДС по строкам вылазят округления, которые впихнули в НДС одной из строк.

1)А зачем это делать, если в строках все эти суммы уже корректно подсчитаны

И второй вопрос. Предположим, что он такой умный, что действительно пытается чего то отэтджастить (то бишь выровнять...непонятно зачем). Ну пусть тогда он это делает единообразно - на экране,в документах, в строках в конце концов (что бы НДС у двух одинаковых строк одинаково считался). А то
2) суммы в строках накладной отличаются от того, что печатается на экране....
3)... и в других документах.
Неудобно получается. Клиенты на смех поднимают.

Или вот еще трабла. При переходе на 4-ку полезли сообщения о блокировках. Например, заливают пользователи заказ из excel'я, у другого ошибка "ваши действия были заблокированы....". В предыдущей версии такого не было. По всякому уже - и в свойсвах БД галки ставили, тайм-ауты меняли, и на серваке с эскалациями баловались. По фигу. Причем что характерно - старая версия одновременно на том же сервере пашет (порой тормозит конечно, но все же пашет) без сообщения о блокировках. Причем я даже не хочу чего либо особенного по части быстродействия - я просто хочу, что бы он дожидался момента. когда действие можно выполнить (как это делала и делает старая версия). Пока не выходит.

Да, кстати. при печати накладной он действительно пытаетс эджастить. :). Правда проблему локализовали по другому. Нашли место, где (иногда!) он округлял например, 12.1852 до 12.18 . Сичас работает хорошо.

Чё то мы всегда суммировали построчно посчитанные цифры (сумма без НДС, сумма НДС, сумма с НДС). То есть в "итого" по документу сумма НДС на несколько копеек могла различаться от цифры, какую можно получить в лоб умножив итоговую сумму без НДС на 0.18. Зато всё идет построчно. С учетом того, что мы работаем в белую (белее не бывает), выдерживали многочисленные внутрение и внешние аудиты и налоговые проверки (районные и городские) и по этой части претензий никогда не было, я не думаю, что такое эджастмент нужен вообще.

Хотя могу и ошибаться. :)

В любом случае проблема не в том, как он считает (так или иначе, могут быть оправданы разные подходы), а в том, что он в разных местах делает это по разному.