1С7.7 ТиС 9.2 Задвоенные движения документа Продажи
!!!SOS SOS SOS!!!
При формирования отчета ведомость по остаткам по Товару "Т1", выводит в отчет два абсолютно одинаковых документа,
(СкринШот в прикрепленном файле.)
т.е. По регистру ОстаткиТМЦ получились задвоенные остатки. Если документ удалить на, то в отчете все равно одна строчка будет отображаться. И если потом опять провести, то опять две.
Пожалуйста подскажите как исправить.
При формирования отчета ведомость по остаткам по Товару "Т1", выводит в отчет два абсолютно одинаковых документа,
(СкринШот в прикрепленном файле.)
т.е. По регистру ОстаткиТМЦ получились задвоенные остатки. Если документ удалить на, то в отчете все равно одна строчка будет отображаться. И если потом опять провести, то опять две.
Пожалуйста подскажите как исправить.
Прикрепленные файлы:
Найденные решения
(28) основной момент, который нужно проверить - задвоение записи в 1sjourn по iddoc. Если есть дубль, то пересчет не поможет.
Надо удалить дубли, а потом сделать пересчет.
Штатный пересчет может пройти быстрее, если перед пересчетом УДАЛИТЬ таблицы итогов (не путать с движениями (: )
Надо удалить дубли, а потом сделать пересчет.
Штатный пересчет может пройти быстрее, если перед пересчетом УДАЛИТЬ таблицы итогов (не путать с движениями (: )
Остальные ответы
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Исправить вручную таблицы БД (SQL или DBF), если есть компетенция. Можно поискать обработки, которые делают это для отдельного регистра/набора измерений, т.е. пересчитывают итоги, но не все целиком, а только нужную часть.
(10) Обработки - нет, не посоветую. Для DBF обычно прямыми запросами находилась проблема, исправлялась либо руками в DBFке, либо запросом VFPOLEDB.
Из редакторов пользовались Advantage Data Architect . Только надо понимать, что делаешь, как 1Ска те же итоги хранит. И проблемы бывают разные, дублирование в 1SJOURN по IDDOC, например.
Кстати (16) дело говорит. Иногда проблема тупо в слетевшем индексе: грохнуть соответствующий CDX и запуститься монопольно, индекс перестроится.
Из редакторов пользовались Advantage Data Architect . Только надо понимать, что делаешь, как 1Ска те же итоги хранит. И проблемы бывают разные, дублирование в 1SJOURN по IDDOC, например.
Кстати (16) дело говорит. Иногда проблема тупо в слетевшем индексе: грохнуть соответствующий CDX и запуститься монопольно, индекс перестроится.
(27) Это один документ, в движениях документа все в порядке, это 1с 7.7 здесь нет регистра сведений. Получилось это после того как из Центральной базы были перенесены почти все файлы dbf (кроме 1sConst, 1sDbset, 1sUpdts, 1SDwnlds, 1sSystem) в Перефирийную базу.
(28) основной момент, который нужно проверить - задвоение записи в 1sjourn по iddoc. Если есть дубль, то пересчет не поможет.
Надо удалить дубли, а потом сделать пересчет.
Штатный пересчет может пройти быстрее, если перед пересчетом УДАЛИТЬ таблицы итогов (не путать с движениями (: )
Надо удалить дубли, а потом сделать пересчет.
Штатный пересчет может пройти быстрее, если перед пересчетом УДАЛИТЬ таблицы итогов (не путать с движениями (: )
Проблема решена, в дбф редакторе в 1sJourn.dbf обнаружил две записи с одним номером документа, но разным iddoc. Как оказалось и в самой 1с-ке в Общем журнале, просто надо было мне внимательнее смотреть. В итоге в одном документе изменил номер и удалил его. Вот и все. Возникает другой вопрос как такое могло получиться, что произошло задвоение документа, причем созданные в разное время.
Очень просто - причин может быть несколько, я думаю что по следующей
Уникальность номеров не проверяется для данного документа (в конфигураторе снята галка уникальность номера) и на этом документе его случайно скопировали в тот же день и провели - номер остался тот же, провести разрешился, вот и все.
А так - может быть и такое - продолжили работать в базе со свалившимися индексами, что вероятно позволило сдублировать запись - док открыт, кто-то покрошил индексы при открытом документе, кто-то тоже открыл тот же док, а записали по очереди, но по сути в разные доки не подозревая о дубляже. Вот и все
Уникальность номеров не проверяется для данного документа (в конфигураторе снята галка уникальность номера) и на этом документе его случайно скопировали в тот же день и провели - номер остался тот же, провести разрешился, вот и все.
А так - может быть и такое - продолжили работать в базе со свалившимися индексами, что вероятно позволило сдублировать запись - док открыт, кто-то покрошил индексы при открытом документе, кто-то тоже открыл тот же док, а записали по очереди, но по сути в разные доки не подозревая о дубляже. Вот и все
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот