11.10.2005, 14:53 | #1 |
Участник
|
Ошибки задания Корр.Себестоимости - Товар операции.
Кто-нибудь сталкивался с этим? Может, подскажите в чем причина? 1) При выполнении периодического задания Корр. Себест. - Товар Операции делаются неправильные операции по закрытию суммы товара, который заканчивается "под ноль". Должна формироваться операция на "лишнюю" оставшуюся сумму (обычно это копейки), чтобы не оставался суммовой остаток при нулевом количестве. А мы имеем операцию на большую сумму и с привязкой к документу поступления товара, а не к документу продажи. Сумма коррекции очень похожа на сумму поступления товара. Почему это может происходить? И как добиться, чтобы операция была привязана к документу продажи и сумма операции была правильная? 2) При выполнении периодического задания Корр. Себест. - Товар Операции делаются неправильные операции по Кредит-нотам по Заказам продажи. Кредит-нота по Заказу продажи должна делать проводки, полностью обратные проводкам Заказа продажи. Мы имеем, что по некоторым позициям проводки по себестоимости правильные, а по некоторым плюсом к правильной формируется еще одна проводка с удвоенной суммой. При этом похоже, что удвоенная сумма получается из-за того, что в стоимостных книгах в поле Оцен.кол-во имеем удвоенное количество. Почему оно там удвоенное и почему задание смотрит на это поле? 3) Ошибка при работе периодического задания Корр. Себест. - Товар Операции (модуль Товары, периодические задания Коррекция Себест. Операций) Ошибка проявляла себя только при запуске на «рабочей» базе одновременно с работой других пользователей (примерно 40 пользователей, в том числе в это время могли учитываться документы Продажи и Покупки). При повторном запуске задания ошибка выпадывала каждый раз на другом товаре. При попытке запустить задание на копии базы (т.е. полностью исключена одновременная работа пользователей) ошибки не возникло. При запуске задания на «рабочей» базе с одновременной работой нескольких пользователей (4-6 сессий, причем учета документов никто не производил и никакой работы с таблицами Товар Книга Операций и Стоимость Операция не велось) ошибки так же не возникло. Скрин ошибки прилагается в аттаче. Примечание: всякий раз сообщение было одним и тем же, т.е. кол-во именно 1 и номер операции именно 1. |
|
11.10.2005, 15:28 | #2 |
Участник
|
1. тут вариантов много... Стандартно всегда привязывается к документу прихода. Это неоднократно обсуждалось и похоже правится только программированием.
Остатки могут быть округлениями. Например товар 1 шт = 7 копеек а вы списали 0,5 и 0,5 Navision выдаст в итоге их стоимости по 4 копейки. (если округление до копеек) и добавит 1 коп к приходу. Кроме того стоит помнить что кроме копеек еще может быть ДОВ. Еще весело бывает когда сумма проводки кооректирующая в ДОВ имеет противоположный знак в отличии от рублеовй. Тогда еще и корреспонденция может глючить. Это было в 3.6. 2. Двойные кол-ва и суммы это глюк. Причину выяснить не удалось на периодически вылазит. Помоему это характерно для SQL версии. Решение - грохать операцию стоимости которая задвоила + все финоперации по ней. Поставить галку для коррекции на товарной операции и опять прогнать коррекцию. Может кто знает как исправить или нужен CU,HF.
__________________
Want to believe... |
|
18.10.2005, 17:21 | #3 |
Участник
|
Цитата:
Сообщение от DA_NEAL
2. Двойные кол-ва и суммы это глюк... Помоему это характерно для SQL версии.
Да, встречали такую ошибку-именно на SQL-версии - и причин найти не удалось. Решение было такое же-стерли лишние value entry. |
|
19.10.2005, 10:11 | #4 |
MCTS
|
Решил здесь спросить, т.к. вопрос про коррекцию, только другой аспект.
Запустил вчера первый раз коррекцию (база в эксплуатации с 27 августа,. 138471 операций стоимости). За 1 час просчитала 107 товаров из 3000. Отсюда вопросы: 1. Она так медленно и должна работать или есть какие-нибудь способы ее ускорить? 2. Блокирует ли данное периодическое задание работу других пользователей (учет перемещений, производства, закупок)? Уж очень это все долго работает... |
|
19.10.2005, 10:23 | #5 |
Участник
|
1.Скорость зависит от железа. Хотя при таком количесве операций стоимости в принципе реальный результат, если предположить что товарных операций равномерно по каждому товару. На сервере 2хXeon 2.4 ГГц ежемесячный расчет на 25000 - 30000 операций стоимости занимал порядка 3 часов, хотя процессоры не загружались на полную... ограничение было у винтов. Для того чтобы побыстрее работало встаривали фильтр по продукции и запускали определенные диапазоны товарных шифров по очереди. Так как много времени уходит на транзакцию записи, а еще если вручную что то правили вылезет какая нибудь ошибка и все откатится...
2. В 3.6 работа пользователей по учету документов действительно блокировалсь. Не думаю что в других версиях что то изменилось.
__________________
Want to believe... |
|
19.10.2005, 10:33 | #6 |
MCTS
|
Спасибо.
У нас XEON 2,8, но один. База родная. А настройки типа Кэш объектов и Кэш СУБД на что нибудь влияют? У меня они по 8000, как по умолчанию. АП |
|
19.10.2005, 11:17 | #7 |
Участник
|
Цитата:
Сообщение от apanko
Спасибо.
У нас XEON 2,8, но один. База родная. А настройки типа Кэш объектов и Кэш СУБД на что нибудь влияют? У меня они по 8000, как по умолчанию. АП
__________________
Want to believe... |
|
31.07.2006, 10:03 | #8 |
Участник
|
Цитата:
Сообщение от DA_NEAL
1. тут вариантов много... Стандартно всегда привязывается к документу прихода. Это неоднократно обсуждалось и похоже правится только программированием.
Остатки могут быть округлениями. Например товар 1 шт = 7 копеек а вы списали 0,5 и 0,5 Navision выдаст в итоге их стоимости по 4 копейки. (если округление до копеек) и добавит 1 коп к приходу. Кроме того стоит помнить что кроме копеек еще может быть ДОВ. Еще весело бывает когда сумма проводки кооректирующая в ДОВ имеет противоположный знак в отличии от рублеовй. Тогда еще и корреспонденция может глючить. Это было в 3.6. |
|
31.07.2006, 14:57 | #9 |
Участник
|
Округление до копеек, как на плане счетов.
Цитата:
Я в общую настройку добавил 2 поля для положительных и отрицательных ошибок округления. |
|
31.07.2006, 15:33 | #10 |
Участник
|
Хорошо наверно не правильно задала вопрос. Я знаю что на "Товары Коррекция Фин. Счет", но это для определенной бизнес группы. Вопрос-а бизнес группа тупо копируется с операции прихода? Или может хоть маленькая надежда-что может где то в настройках есть бизнес-группа для разницы между приходом и расходом??
|
|
31.07.2006, 16:37 | #11 |
Участник
|
|
|
31.07.2006, 16:55 | #12 |
Участник
|
Цитата:
Сообщение от Галина
Хорошо наверно не правильно задала вопрос. Я знаю что на "Товары Коррекция Фин. Счет", но это для определенной бизнес группы. Вопрос-а бизнес группа тупо копируется с операции прихода? Или может хоть маленькая надежда-что может где то в настройках есть бизнес-группа для разницы между приходом и расходом??
Финансы Настройка - Счет Точность Округления |
|
31.07.2006, 17:05 | #13 |
Участник
|
Цитата:
Сообщение от romtex
Цитата:
Сообщение от Галина
Хорошо наверно не правильно задала вопрос. Я знаю что на "Товары Коррекция Фин. Счет", но это для определенной бизнес группы. Вопрос-а бизнес группа тупо копируется с операции прихода? Или может хоть маленькая надежда-что может где то в настройках есть бизнес-группа для разницы между приходом и расходом??
Финансы Настройка - Счет Точность Округления |
|
31.07.2006, 17:22 | #14 |
Участник
|
Цитата:
Сообщение от apanko
Решил здесь спросить, т.к. вопрос про коррекцию, только другой аспект.
Запустил вчера первый раз коррекцию (база в эксплуатации с 27 августа,. 138471 операций стоимости). За 1 час просчитала 107 товаров из 3000. Отсюда вопросы: 1. Она так медленно и должна работать или есть какие-нибудь способы ее ускорить? 2. Блокирует ли данное периодическое задание работу других пользователей (учет перемещений, производства, закупок)? Уж очень это все долго работает... На самом деле не должна сильно медленно работать, т.к. кажды раз корректируются не все записи, а только необходимые. 2. Блокирует. |
|
31.07.2006, 17:27 | #15 |
MCTS
|
Спасибо. Но уже немножко не актуально. :-)
1. сделали. 2. узнал. Еще раз спасибо за заботу. |
|
31.07.2006, 17:30 | #16 |
Участник
|
Цитата:
Цитата:
А что сделали с 1-м? |
|
31.07.2006, 17:39 | #17 |
Участник
|
Если не ошибаюсь (понедельник день тяжелый, лень проверять), то дата берется с операции прихода, если она позже даты закрытого периода, указываемого при запуске задания, иначе берется дата из формы запроса.
|
|
31.07.2006, 17:39 | #18 |
MCTS
|
2Sitizen
Все банально - запускаем чаще. |
|
31.07.2006, 17:54 | #19 |
Участник
|
Romtex спасибо. Но у меня настройка "Учет Склада по Дате Операции"-при такой настройке дату не надо проставлять при коррекции себестоимости. В любом случае придется смотреть код.
|
|
31.07.2006, 18:00 | #20 |
Участник
|
Цитата:
Ой не завидую! В навижене непонятнее кода, чем в этом задании, я не видел |
|