УТ 11, изменение валюты заказа клиента
Из года в год наблюдаю за УТ 11 и фундаментальными недоработками, мешающими использовать данную конфигурацию по назначению - для торговли.
Вот уже скоро выйдет версия 11.4.6, а косяк со сменой валюты похоже никто исправлять не собирается.
Создаем заказ клиента. Валюта документа = EUR, цена включает НДС
любой товар, количество = 10, цена произвольная = 1,38.
Меняем валюту на рубли (так иногда бывает надо), происходит пересчет чисел по текущему курсу. Например, на сегодня 16.08.18 сумма документа = 1 038,11 руб. На данном этапе уже можно было бы заподозрить, что 11 копеек на 10 на цело не делятся, но это заметно только в данном конкретном простом примере. Проводим заказ, отправляем клиенту ПФ счета, клиент оплачивает 1 038,11 руб, делаем на основании реализацию - сумма документа = 1 038,10 руб.
Соответственно принцип "продал и забыл не работает". Рано или поздно замечаем расхождение, осознаем, что сумма в счете кривая. Исправляем счет и возвращаем клиенту 1 копейку (или наоборот просим доплатить), или кувыркаемся с цифрами и пытаемся всё подогнать под ту сумму, которая была в кривом счете. Если в счете позиций несколько, то можно намухлевать с ценами.
Почему так происходит - понятно, 1с хотели как лучше, применили хитроумные математические методы для пересчета суммы в заказе клиента, но получилось как хуже :)
Я-то допиливаю/перепиливаю эти косяки, добавляю свои костыли. Но доколе это будет продолжаться?
Писать в поддержку не предлагать. Это не работает.
Вот уже скоро выйдет версия 11.4.6, а косяк со сменой валюты похоже никто исправлять не собирается.
Создаем заказ клиента. Валюта документа = EUR, цена включает НДС
любой товар, количество = 10, цена произвольная = 1,38.
Меняем валюту на рубли (так иногда бывает надо), происходит пересчет чисел по текущему курсу. Например, на сегодня 16.08.18 сумма документа = 1 038,11 руб. На данном этапе уже можно было бы заподозрить, что 11 копеек на 10 на цело не делятся, но это заметно только в данном конкретном простом примере. Проводим заказ, отправляем клиенту ПФ счета, клиент оплачивает 1 038,11 руб, делаем на основании реализацию - сумма документа = 1 038,10 руб.
Соответственно принцип "продал и забыл не работает". Рано или поздно замечаем расхождение, осознаем, что сумма в счете кривая. Исправляем счет и возвращаем клиенту 1 копейку (или наоборот просим доплатить), или кувыркаемся с цифрами и пытаемся всё подогнать под ту сумму, которая была в кривом счете. Если в счете позиций несколько, то можно намухлевать с ценами.
Почему так происходит - понятно, 1с хотели как лучше, применили хитроумные математические методы для пересчета суммы в заказе клиента, но получилось как хуже :)
Я-то допиливаю/перепиливаю эти косяки, добавляю свои костыли. Но доколе это будет продолжаться?
Писать в поддержку не предлагать. Это не работает.
По теме из базы знаний
- Загрузка номенклатуры c картинками (несколько потоков одновременно) и сопутствующими данными в базу и любые документы из yml, xls, xlsx, xlsm, ods, ots, csv для УТ 10.3, УТ 11 (все), БП 3, КА 2, ERP 2, УНФ 1.6/3.0, Розница 2
- Алгоритмы с решениями для экзамена Специалист УТ 11.1
- Печать договоров по шаблонам для УТ 11, КА 2, ERP 2
- Выгрузка УПД из УТ 11.5, УТ 11.4, БП 3.0, УНФ 1.6, КА 2.4 и ERP 2.4 для OZON и Яндекс
- Модуль "Ответственное хранение" или фулфилмент (FBS / FBO) для 1С:УТ 11.5, КА 2.5, ERP 2.5
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) это что, крик души ?
Идеального продукта не будет никогда, это утопия. То что, одному хорошо - то другому плохо. Главное чтобы продукт удовлетворял бОльшую часть пользователей.
А для тех кого не удовлетворяет - для тех существуем мы, гильдия программистов, аналитиков, архитекторов и т.п. целая отрасль этим кормится.
Соответственно, зависимость прямая, чем идеальнее будет продукт - тем менее востребована станет наша профессия.
Так что, наоборот, радоваться нужно.
Идеального продукта не будет никогда, это утопия. То что, одному хорошо - то другому плохо. Главное чтобы продукт удовлетворял бОльшую часть пользователей.
А для тех кого не удовлетворяет - для тех существуем мы, гильдия программистов, аналитиков, архитекторов и т.п. целая отрасль этим кормится.
Соответственно, зависимость прямая, чем идеальнее будет продукт - тем менее востребована станет наша профессия.
Так что, наоборот, радоваться нужно.
(4) Будучи начинающим программистом 1С я конечно же посмотрел что они делают. Они умножают суммы на курс :) То есть для них важно, чтобы сумма "точно" конвертировалось, а то, что цена * количество <> сумма, так это принесено в жертву.
См. общий модуль "ценообразование", Процедура ПересчитатьСуммыТабличнойЧастиВВалюту.
Но если рассматривать программу с точки зрения пользователя как черный ящик, то получается 2 * 2 = 5.
Кроме того, если они так задумали, то должны были позаботиться о том, чтобы на заполнение реализации по заказу эта задумка тоже распространялась.
См. общий модуль "ценообразование", Процедура ПересчитатьСуммыТабличнойЧастиВВалюту.
Но если рассматривать программу с точки зрения пользователя как черный ящик, то получается 2 * 2 = 5.
Кроме того, если они так задумали, то должны были позаботиться о том, чтобы на заполнение реализации по заказу эта задумка тоже распространялась.
(6)В чем проявляется "зависание копейки" и почему оно страшнее, чем 2x2=5? Где описана эта "методология"? Пруфы? Где вы нашли кнопку "пересчитать" в типовой конфигурации?
На практике достаточно передёрнуть цену или количество чтобы правильно пересчитались суммы. Но я-то не про это.
На практике достаточно передёрнуть цену или количество чтобы правильно пересчитались суммы. Но я-то не про это.
(8) Смешно. Я вам конкретный пример косяка дал и указал на место в конфигурации откуда он происходит. А вы мне вместо цифр и ссылок "личный опыт". Так у меня тоже личный опыт, и что?
Ладно, давайте проведём мысленный эксперимент: допустим, что я поверил что так и задумано. Допустим, что конвертация суммы независимо от цены - это нормально. Но тогда всплывает косяк в обработке заполнения реализации товаров и услуг. Как бы вы не выгораживали 1C, один косяк всё равно остается: или смена валюты неправильно просчитывается, или реализация товаров и услуг неправильно заполняется. Выбирайте что вам больше нравится lol
Ладно, давайте проведём мысленный эксперимент: допустим, что я поверил что так и задумано. Допустим, что конвертация суммы независимо от цены - это нормально. Но тогда всплывает косяк в обработке заполнения реализации товаров и услуг. Как бы вы не выгораживали 1C, один косяк всё равно остается: или смена валюты неправильно просчитывается, или реализация товаров и услуг неправильно заполняется. Выбирайте что вам больше нравится lol
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот