Погрешность в сумме заказа при частичных отгрузках в случае наличия скидки

[WhiteSwan]

Уважаемые форумчане,

Помогите, пожалуйста, найти ответ на следующий вопрос. Цена товара заданы с учетом копеек. При частичных отгрузках этого конкретного товара (в большом количестве) и наличии скидки строки выходит, что общая сумма отдельных отгрузок не сходится с суммой заказа. Это происходит из-за округлений суммы скидки строки при каждой частичной отгрузке, что выливается в погрешность в 1 копейку (возможно и более). Таким образом, клиенту выставили счет на одну сумму, а по отгрузочным документам - сумма другая. Математически - все верно, но должна же быть какая-нибудь коррекция предусмотрена в программе для учета округлений.

Версия Navision 3.7. Подходящих настроек для решения этой проблемы без программирования я не нашла.

Заранее благодарю.

[WhiteSwan]

Может я не на тот форум написала, конечно...Но любовь к Навижину стала как-то угасать...неужели все эти проверки-корректировки надо вручную прописывать?

[RedFox]

Цитата:

Сообщение от WhiteSwan

Помогите, пожалуйста, найти ответ на следующий вопрос. Цена товара заданы с учетом копеек. При частичных отгрузках этого конкретного товара (в большом количестве) и наличии скидки строки выходит, что общая сумма отдельных отгрузок не сходится с суммой заказа. Это происходит из-за округлений суммы скидки строки при каждой частичной отгрузке, что выливается в погрешность в 1 копейку (возможно и более). Таким образом, клиенту выставили счет на одну сумму, а по отгрузочным документам - сумма другая. Математически - все верно, но должна же быть какая-нибудь коррекция предусмотрена в программе для учета округлений.

Извините, но мне кажется, что рассказ не закончен..

Цитата:

Версия Navision 3.7. Подходящих настроек для решения этой проблемы без программирования я не нашла.

Чтобы найти решение проблемы нужно определиться что нужно в итоге получить. У меня в данной ситуации видится 2 варианта развития событий, а именно:
- выставить единый счет на несколько частичных отгрузок (если опять же конечно их не сразу проводили в системе как Счет);
- скорректировать задолженность по Клиенту
- сторнировать документ на 0.01 руб.

Что в итоге нужно получить то?

[WhiteSwan]

Спасибо за ответ! Попытаюсь объяснить подробнее...
Заранее мы не знаем, будет ли отгрузка товара частичной или нет, и как "ляжет" округление скидки, с погрешностью или без. Нужно, чтобы в итоге (без вмешательства пользователя и необходимости проверки суммы) по отгрузочным документам сумма отгруженного товара была такая же, как и в выставленном счете и которую оплатил клиент. Грубо говоря, чтобы программа в таких случаях (частичные отгрузки при наличии скидки) сама автоматически проверяла сумму уже отгруженного товара, сравнивала ее с суммой выставленной клиенту и соответствующим образом корректировала сумму последующих отгрузок товара, перед тем как очередная отгрузка будет проведена в системе.
Не совсем поняла, о какой задолженности Вы говорили... Здесь ведь нет никакой задолженности, клиент оплатил ровно столько, сколько было в выставленном счете.

[RedFox]

Цитата:

Сообщение от WhiteSwan

Не совсем поняла, о какой задолженности Вы говорили... Здесь ведь нет никакой задолженности, клиент оплатил ровно столько, сколько было в выставленном счете.

Что-то я немного запутался. Счет это документ на оплату партии товара. Огрузка это документ, отвечаютщий за отгрузку товара. У меня был вопрос - КАК вы учитываете операцию частичной отгрузки, с признаком Выставить счет или просто Отгрузить? И Вы так же не ответили на мой второй вопрос - КАК система должна знать что нужно корректировать?
Вы написали

Цитата:

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

Мне нужно отгрузить 10 шт товара по цене 10 грн.
Мы отгружаем 3 партиями и со скидками. {.. дальше операции пишите Вы, так как нужен практический пример ..}
У меня вопрос - КАК система должна знать, что это будет частичная отгрузка, которую нужно корректировать сейчас и ТЕМ БОЛЕЕ в последующем?

P.S. Чтобы Вы поняли почему я спрашиваю - когда то по версии 3.60-3.70 был документ, который описывал певедение системы по себестоимости с округлением 0.33 (точно не помню как называется). Там четко было написано - система корректирует на 0.01 на какой-то стадии.

[Alesha]

Я тут вспомнил, что есть такая настройка, как окрегление при применении. То есть, если при последнем применении у Вас между суммой заказа и счета будет оставаться остаток больше, указанного в настройках, то этот остаться бросается на счет округлений.
кажется это так работает.

[Sancho]

нет. это при применении оплаты к счету. чтобы из-за 10-ти копеек не считать счет неоплаченным.
имхо, в сабже элементарная математическая нерешабельная задача, в которой 100, деленое на 3 части с округлением до двух знаков, превращается в 99,99
вопрос, что с этим делать.
имхо, смириться.
кто мы, по сравнению с математикой? жалкие людишки, создавшие ее и попавшие под ее власть...

[WhiteSwan]

Уважаемый RedFox, специально для Вас разъясняю ситуацию.
Операции частичной отгрузки в моем случае учитываются с признаком Отгрузить. Клиент оплачивает заказ по методу 100% предоплаты, счет ему был выставлен на всю сумму заказа продажи.
Речь идет о суммах двух документов - заказа продажи и товарной накладной. Они должны быть одинаковыми, чего не получается достигнуть в описанной ситуации. То, что Вы меня спрашиваете - КАК система должна знать, что это будет частичная отгрузка, которую нужно корректировать сейчас и ТЕМ БОЛЕЕ в последующем? - это пользователя интересовать не должно. Пользователю необходимо, чтобы все документы были верными и счет не оставался "висеть" в Балансе Счетов.
Вы меня спрашиваете фактически сам алгоритм решения задачи, который, как я недавно надеялась, уже заложен в системе.
Именно поэтому я и обратилась на форум Функционал Navision, а не на форум Программирование.

Я думаю, что Sancho прав, но мириться с этим не хочется...

[RedFox]

Цитата:

Сообщение от WhiteSwan

Уважаемый RedFox, специально для Вас разъясняю ситуацию.

Хоть кто-то иногда уважает

Цитата:

Операции частичной отгрузки в моем случае учитываются с признаком Отгрузить. Клиент оплачивает заказ по методу 100% предоплаты, счет ему был выставлен на всю сумму заказа продажи.
Речь идет о суммах двух документов - заказа продажи и товарной накладной. Они должны быть одинаковыми, чего не получается достигнуть в описанной ситуации. То, что Вы меня спрашиваете - КАК система должна знать, что это будет частичная отгрузка, которую нужно корректировать сейчас и ТЕМ БОЛЕЕ в последующем? - это пользователя интересовать не должно. Пользователю необходимо, чтобы все документы были верными и счет не оставался "висеть" в Балансе Счетов.

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

Если нужно, чтобы Счет (который потом проведет все фин. операции в системе) был сформирован на основании все частычных отгрузок суммарно, то в Счетам лдя этого есть меню "Получить Строки Расх. Н&акладной". Можно насобирать все, что нужно и учесть одним махом.
Но в таком случае будет висеть расхождение в оплате и счета на Клиенте на эту самую преславую дельту (которую по идее можно либо вернуть, либо списать).

P.S. Ну а печатные формы это всего-лишь бумажка для пользователя.

Цитата:

Вы меня спрашиваете фактически сам алгоритм решения задачи, который, как я недавно надеялась, уже заложен в системе.
Именно поэтому я и обратилась на форум Функционал Navision, а не на форум Программирование.

Извините, но мне кажется, что когда не до конца понимаешь что нужно сделать, нужно понять суть вопроса и что делать в таком случае (тоесть определить направление и последовательность возможных шагов). И я обычно пытаюсь разложить для себя все по полочкам, а потом пытаюсь собрать в единую картинку.

[WhiteSwan]

Спасибо всем за ответы.

[rmv]

Насколько я понял речь идет о сравнении сумм в печатных формах документов (ТОРГ-12 к примеру), печатаемых из Расходных Накладных с суммой счета по Заказу Продажи.
Вынужден огорчить -- расчет сумм в печатных формах осуществляется на "лету", отвечает за это кодеюнит Standard Report Management, расходная накладная рассматривается как самостоятельный документ, вне привязки к исходному заказу продажи и уж тем более без коррекции ощибок округления.
В Вашем случае могу посоветовать добавить поля с суммой строки в строки расходной накладной, в строки заказа "Сумма Отгружено", которые
рассчитывать при учете заказа продажи, как предложил Redfox. Также потребуется изменение алгоритма расчета сумм при печати.
Как водится, решая одну проблему, Вы сразу приобрете другую - придется долго объяснять людям алгоритм расчета суммы строки при печати товарной накладной и что сумма строки <> цена * количество из-за ранее отгруженных накладных. Скорее всего уже имеете проблемы с соотвествием сумм НДС по отгрузочным документам и счетом фактурой по заказу (счет надеюсь целиком выставляете и счет фактуру печатате из учтенного счета?).
Возможно стоит пересмотреть подход и окончательный комплект документов для клиента печатать либо из заказа, либо из учтенного счета.