Зависают копейки в Управлении торговлей 10.3 в розничных складах
Управление торговлей 10.3.25. Платформа 8.2.19.68.
Подскажите пожалуйста!
В регистре "Товары в рознице" при перемещении между складами зависают копейки в ресурсе "Сумма", в то время как по количеству все списывается в 0. В системе отключен партионный учет по складам.
Пробовал перепроводить документы с включенным партионным учетом - не помогает. Восстановление последовательности не помогает. Перемещений между складами достаточно много. Сначала товары поступают из оптового на один розничный склад, а потом распределяются другим розничным складам.
В скрине пример оборота по регистру. Может кто-нибудь встречался уже с такой ситуацией.
Вариант с Корректировкой регистра пока не рассматриваю. Интересует понять причину проблемы.
Подскажите пожалуйста!
В регистре "Товары в рознице" при перемещении между складами зависают копейки в ресурсе "Сумма", в то время как по количеству все списывается в 0. В системе отключен партионный учет по складам.
Пробовал перепроводить документы с включенным партионным учетом - не помогает. Восстановление последовательности не помогает. Перемещений между складами достаточно много. Сначала товары поступают из оптового на один розничный склад, а потом распределяются другим розничным складам.
В скрине пример оборота по регистру. Может кто-нибудь встречался уже с такой ситуацией.
Вариант с Корректировкой регистра пока не рассматриваю. Интересует понять причину проблемы.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Ребята, вы чего про партии трёте, если автор явно говорит про регистр "Товары в рознице"?
(1) По сабжу.
Обычно есть два источника данной проблемы:
а) Нарушение хронологической последовательности документов. (т.е. перепроведения задним числом). Восстановление партионной последовательности не затрагивает регистры розницы.
б) Наличие дешевых весовых товаров. Т.е. когда двигаем по регистру небольшое количество дешевого весового товара, его стоимость округляется до копеек, при низкой цене в результате округления будут образовываться остатки
Есть несколько вариантов лечения:
1.Нужна отдельная обработка, для перепроведения документов по регистру товары в рознице. Последовательности такой нет, но достаточно легко проверить необходимость восстановления обработкой. Проблему б) простым перепроведением не решишь нужно обрабатывать такие ситуации уже своим кодом.
2. Периодически проводить переоценки товаров на складах где зависили такие суммы.
Также рекомендую написать простенький отчет по наброску приведенному ниже. Он позволит увидеть все текущие проблемные остатки. А не только с нулевым количеством.
(1) По сабжу.
Обычно есть два источника данной проблемы:
а) Нарушение хронологической последовательности документов. (т.е. перепроведения задним числом). Восстановление партионной последовательности не затрагивает регистры розницы.
б) Наличие дешевых весовых товаров. Т.е. когда двигаем по регистру небольшое количество дешевого весового товара, его стоимость округляется до копеек, при низкой цене в результате округления будут образовываться остатки
Есть несколько вариантов лечения:
1.Нужна отдельная обработка, для перепроведения документов по регистру товары в рознице. Последовательности такой нет, но достаточно легко проверить необходимость восстановления обработкой. Проблему б) простым перепроведением не решишь нужно обрабатывать такие ситуации уже своим кодом.
2. Периодически проводить переоценки товаров на складах где зависили такие суммы.
Также рекомендую написать простенький отчет по наброску приведенному ниже. Он позволит увидеть все текущие проблемные остатки. А не только с нулевым количеством.
Выбрать
ТоварыВРознице.Номенклатура
ТоварыВРознице.Склад
ТоварыВРознице.Сумма
ТоварыВРознице.Количество
ТоварыВРознице.Количество*ЦеныАТТ.Цена Как СуммаРасчетная
Из РегистрНакопления.ТоварыВРознице.Остатки() как ТоварыВРознице
Левое соединение РегистрСведений.ЦеныАТТ Как Цены АТТ
по ТоварыВРознице.Номенклатура = ЦеныАТТ.Номенклатура
и ТоварыВРознице.Склад= ЦеныАТТ.Склад
Где ТоварыВРознице.Сумма <> ЦеныАТТ.Цена*ТоварыВРознице.Количество
Итоги
по
Склад Показать
Такое может происходить при не корректном программном списании себестоимости, когда при списании последней партии по количеству не списывается весь остаток по себестоимости (если метод списания ФИФО), а делается попытка рассчитать себестоимость списания или если списание происходит по среднему, то если например мы списываем последние единицы товара, но вместо того чтобы взять готовую сумму из регистра остатка по себестоимости пытаемся себестоимость для списания рассчитать.
(4) podzemelchik, Про этот метод я в курсе. Эти алгоритмы есть в Специалисте по платформе.
Но вот загадка!!! Получается типовые программные продукты в фирме 1С разрабатываются даже не специалистами?
Не переписывать же мне алгоритмы списания в типовой торговле 10.3
Но вот загадка!!! Получается типовые программные продукты в фирме 1С разрабатываются даже не специалистами?
Не переписывать же мне алгоритмы списания в типовой торговле 10.3
(10) kirilka, проблема в округлении. Если назначать цену за кг таким образом, что за 10 г цена будет рассчитываться с точностью до двух знаков, то таких проблем не будет. В рознице стоимость расхода рассчитывается исходя из установленной цены, а не высчитывается из остатка на момент списания.
Спасибо за ответ!
По пункту а). Я подчеркиваю "Пробовал перепроводить документы с включенным партионным учетом - не помогает. Восстановление последовательности не помогает. ". Перепроведение не помогает. Пробовал как восстановлением последовательности, так и общим проведением всех документов.
По пункту б). Уже (11) kasper076, предложил. Возможно как раз вариант, буду анализировать. Только получается даже, если весовой товар будет достаточно дорогим, при многочисленных перемещениях с одного на другие склады, возможно появление "зависших расчетов". Видимо решить проблему можно только корректировкой регистра.
По пункту а). Я подчеркиваю "Пробовал перепроводить документы с включенным партионным учетом - не помогает. Восстановление последовательности не помогает. ". Перепроведение не помогает. Пробовал как восстановлением последовательности, так и общим проведением всех документов.
По пункту б). Уже (11) kasper076, предложил. Возможно как раз вариант, буду анализировать. Только получается даже, если весовой товар будет достаточно дорогим, при многочисленных перемещениях с одного на другие склады, возможно появление "зависших расчетов". Видимо решить проблему можно только корректировкой регистра.
(13) kirilka, если полное перепроведение не помогает тогда да - Только переоценка или правка движений. Рекомендую написать спец обработку по перепроведению которая будет анализировать остатки в рознице и править движения
P.S. Партии тут совсем не относятся к делу. Партии и себестоимость отдельно, розничные остатки отдельно. Совсем разные регистры.
P.S. Партии тут совсем не относятся к делу. Партии и себестоимость отдельно, розничные остатки отдельно. Совсем разные регистры.
Слушай а если принудительно задавать время документов при проведении, а именно все поступления в 9.00 все реализации в 21.00 перемещения в 20.00,и убрать использование метода расчета себестоимости указанном в посте №4 - должно помочь, а актуальность естественно поддерживать перепроведением документов. находясь в реальном произвольном времени доки четко будут фиксироваться и не будет свойства вагон впереди состава мчится.
Никогда не замечали при проведении документов срабатывает округление, связано с налогообложением. Мы корректировали. Бухи отказались что то думать и делать, запилил корректировку и от меня отстали, хотя я им доказывал что это не правильно.
(7) vervolf9, Ну да правильно списывать суммовой остаток в последнем расходе. Но почему то разработчики 1С об этом забыли, хотя сами этому учат.
Нашел ответ на конференции от октября 2012 года. Сказали исправлять корректировкой регистра.
Надо будет проверить в УТ 11 повториться ситуация или нет.
Нашел ответ на конференции от октября 2012 года. Сказали исправлять корректировкой регистра.
Надо будет проверить в УТ 11 повториться ситуация или нет.
Клиенты столкнулись с аналогичной проблемой с копейками, вычитал:
Дата публикации: 27 октября 2009 г.
Описание: При проведении торговых документов по регистру "Товары в рознице" некорректно рассчитывается ресурс "Сумма продажная".
В связи с этим отчет "Ведомость товаров в рознице" некорректно отображает остатки.
По всей видимости ошибку не исправили и по сей день
Дата публикации: 27 октября 2009 г.
Описание: При проведении торговых документов по регистру "Товары в рознице" некорректно рассчитывается ресурс "Сумма продажная".
В связи с этим отчет "Ведомость товаров в рознице" некорректно отображает остатки.
По всей видимости ошибку не исправили и по сей день
У меня такое с копейками происходит при закрытии смены на кассе.
вот пример
продали мармелад по цене 136.00 руб. 0,262 кг получили 35.63 руб.
ещё продали мармелад по цене 136,00 руб. 0,242 кг. получили 32,91 руб.
ещё продали мармелад по цене 136,00 руб. 0,282 кг. получили 38,35 руб.
По итогу должо бы получиться 35,63 + 32,91 + 38,35 = 106,89
В ведомости по товарам в рознице, пока не закроем смену и будут чеки, так и будет.
Но как только закрыли смену, сформировали отчет о рочничных продажах получим сумму уже 106,90 руб.
Потому что если сложить все веса получим 0,786 кг. и на 136,00 руб сумма - 106,896. Округляем до копеек, получаем 106,90 руб.
Естественно имеется расхождение товарного отчета с кассой. Иногда за день и рубль набежит.
Иногда ничего. Потомучно эти копеечные расхождения могут быть и в меньшую, и большую стороны.
Боремся с этим так.
Перед очередной ревизией делаем переоценку товаров по номенклатуре.
Эти ненависные копейки уходят.
1С по этому поводу упорно хранит молчание.
Зодолбался до них стучаться.
вот пример
продали мармелад по цене 136.00 руб. 0,262 кг получили 35.63 руб.
ещё продали мармелад по цене 136,00 руб. 0,242 кг. получили 32,91 руб.
ещё продали мармелад по цене 136,00 руб. 0,282 кг. получили 38,35 руб.
По итогу должо бы получиться 35,63 + 32,91 + 38,35 = 106,89
В ведомости по товарам в рознице, пока не закроем смену и будут чеки, так и будет.
Но как только закрыли смену, сформировали отчет о рочничных продажах получим сумму уже 106,90 руб.
Потому что если сложить все веса получим 0,786 кг. и на 136,00 руб сумма - 106,896. Округляем до копеек, получаем 106,90 руб.
Естественно имеется расхождение товарного отчета с кассой. Иногда за день и рубль набежит.
Иногда ничего. Потомучно эти копеечные расхождения могут быть и в меньшую, и большую стороны.
Боремся с этим так.
Перед очередной ревизией делаем переоценку товаров по номенклатуре.
Эти ненависные копейки уходят.
1С по этому поводу упорно хранит молчание.
Зодолбался до них стучаться.
1 раз в неделю делю переоценку всех товаров в рознице. Сначала "Установка цен",
Заполнить-Заполнить по ценам Номенклатуры,
а потом "Переоценка во всех розничных складах" на основании сформированного "Установка цен номенклатуры".
С тех пор как начали делать, проблем с копейками пока нет.
До этого тоже вылазили цены никакой логике не поддающиеся, ни средние, никакие, в общем ...
Не перестаю удивляться 1С-ке.
Заполнить-Заполнить по ценам Номенклатуры,
а потом "Переоценка во всех розничных складах" на основании сформированного "Установка цен номенклатуры".
С тех пор как начали делать, проблем с копейками пока нет.
До этого тоже вылазили цены никакой логике не поддающиеся, ни средние, никакие, в общем ...
Не перестаю удивляться 1С-ке.
Помню при сдаче на 1С специалист по платформе в 2009 г. в задаче по списанию средней стоимости со складов не учел что при списании (перемещении уже не помню) оставшейся части товара полностью нужно списывать и ее полностью.
Или ее вообще не нужно было списывать, т.к. официальный ответ был "Ресурс сумма при многоскладском случае лишний, т.к. не выходит в ноль".
А сами вот в УТ 10.3 недоработку оставили.
Или ее вообще не нужно было списывать, т.к. официальный ответ был "Ресурс сумма при многоскладском случае лишний, т.к. не выходит в ноль".
А сами вот в УТ 10.3 недоработку оставили.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот