Проблемы с остатками и движениями по регистрам. #135689

Типовая ТиС.1.Есть приход товара ,его перемещение и списание.Только если удалить приход -будет отрицательный остаток. Это естетственно. Но если его опять провести ,то остаток есть (ведомость по остаткам) и при этом стаются отрицательные движения по регистрам в списании. Например колво "-5" цена "100 р." сумма "-500р." В печатной форме такое лезет.И пока не перепроведешь доки за период так он и остается отрицательным.2. Если забраться в задние числа по отгрузке товара ,то летят эпизодически проводки по документам отгрузки. Отчет по бух проводкам дает кол-во и нет суммы на некоторых позицыях номенкл-ры на 90 счет. В бух выгрузка гонет то же самое. Помогает перепроводка доков.В чем макая проблема. 1С+SQL 2000 ТиС 9.2

Проблема в нарушении последовательности. Просто подставить нужное количество мало. В регистрах есть масса другой информации, зависящей от той, которую ты правишь.Либо перестань работать через заднее мест..., пардон, число. Липо регулярно восстанавливай последовательность.

Твои слова да богу в уши.Я забибикался уже ее восстанавливать. Все программеры твердят мне ,что последовательность на остатки не влияет при методе "по среднему".Я уже вам в форум пишу от того ,что сомневаться в соем опыте начал. Значит все -таки зависет? Тут бага с УРБД. Стоит единая последовательность на всех базах в параметрах миграции основной последовательности. И при этом при перегрузке центральной базы в периферийную она так и остается на месте. Хотя должна сместиться на нашу дату границы. При этом при получении выгрузок с периферийных баз они может улететь куда угодно. Месяца на два назад без проблем.

Зависит.Закрывай период на изменения и работай нормально.)))

Так пытаюсь! Только нужно разобраться с тем ,почему последовательность прыгает сама по себе. Нашел ссылочку http://softpoint.ru/article.php?id=11Только у меня в базе все оки. Кто -нить с подобным встречался?База УРБД. Все в один голос говорят что не могут залезть в закрытый период. И таки последовательность прыгает.

Кстати! Слышал в форуме про проблему с последовательностью. Сама может прыгнуть куда угодно на УРБД. Но ничего конкретного. У кого была похожая проблема -как решали?

1С вроде утверждает, что при списании по среднему партионный учет не ведется, а об остатках ни слова. Может программеры твои партии с остатками путают?

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

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

Граница - дело серьезное и просто так сама она не прыгает. Значит кто-то программно или интерактивно лезет в старые документы. А актуальные остатки только до ТА включительно можно уверенно получать.

Хм. Что-то я не видел в ТиС 9.2 метода "по среднему"...

При помощи установки значения реквизита "Метод расчета себестоимости" всправочнике "Свои юридические лица" для каждого юридического лица, конфигурация"Торговля+Склад" позволяет настроить партионный учет по одному из трех методов:"FIFO", "LIFO" или "По среднему".Если метод списания себестоимости задан "По среднему", то все купленные товары,продукция и материалы зачисляются как бы на одну партию ("пустую"), поэтомусебестоимость от разных приходов усредняется.

Я то же так думал пока сегодняшняя звгрузка с периферии не сместила последовательность на 03.08.2004 г.

Я бы по п.1 проверил движения регистров по всем измерениям. Видно при повторном проведении Поступления движения формуруются не совсем такие какие были у первоначального документа. Потом посмотреть какие движения формирует СписаниеТМЦ до перепроведения и после. Вероятно одно из измерений закрывается при повтором проведении СписанияТМЦ.

Похоже так. Только дела в том ,что модули проведения доков не тронуты никем. Остается только смотреть целосность базы.

Кстати вопрос. Есть "ручное" распроведение документов (как это делает ТиС),а есть автоматическое удаление движений (крыжик в свойствах документов). В чем отличие?

IMHO Автоматическое - значит в самом начале модуля проведения у документы уже нет движений, а ручное - значить в модуле нужно саомостоятельно прописать удавление движений. При ручном удалении движений можно при желании ускорить повторное проведение документа, если не удалять движения те которые не изменяются, чтобы их заново не формировать. Я такой оптимизации в Тис'е не заметил, хотя это может где и есть..

При автоматич - при проведении старые движения удаляются сами и формируются новые, если галки нет - новые движения добавляются к старым, т.е. не удаляются уже существующие.

Получить таким образом ускорение не реально. Так как будет отъедаться время на проверку изменений каждой строки.Проще ставить галку и не париться.

"Я то же так думал пока сегодняшняя звгрузка с периферии не сместила последовательность на 03.08.2004 г."ЗНАЧИТ кто то в периферии правил док за 03.08.04. Ты че паникуешь. Кто то тупо открывает док (посмотреть), а потом "закрывает" кнопочкой окей. ГП сама как попало вести себя не может. Тут уж все железно проверено.". В любом случае "метод научного тыка" показал ,что регистры будут держать актуальные остатки (т.е. кол-ный учет) только при соблюдении границы основной последовательности"При чем тут ГП и количество???

Самое интересное что на периферии она осталась на месте. Там стоит датаЗапретаРедактирования - на 07.11.05Баз периферии много. На всех меня не хватит. Поэтому буду искать через второго автора -кто последний раз трогал док.

"При чем тут ГП и количество???"Вот вот! Не причем! А практика показывает обратное. ГДЕ ИСТИНА???

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

Истина в противоположном - кто то правит количество, и слетает ГП, а ты думаешь, что все наоборот.

Кстати, если имеется ввиду количество в разрезе конкретной партии, то да, действительно оно плывет. Естественно. Поэтому у тебя в списании каша из минусов и плюсов. Все правильно.

Я как раз так и думаю! ГП летит в данном случае сама по себе. Такое у меня впервые. Поэтому в недоумении. Пока решение сделать новые переферийки и проверять второго автора на изменение доков. Поскольку журналы регистрации лежат локально для каждой базы нет возможности узнать причину. К тому же на периферийках ГП на месте. Если они и залезли в Зад...ние числа у себя - она съедет на этот док. А она на месте... печально.