Подскажите, из-за чего такое может быть и как такое устранить.
База файловая, 1c v7.7 "Торговля и Склад 9.2"
В Базе Появилось два документа "Продажа" с разными номерами, и от разных авторов,
но с одной суммой и одним и тем же "содержимым".
Причем если я удаляю док1, то он как был проведён так таким и остался, а док2 при этом удаляется.
И еще в Общем журнале данные по графам для документа док1 отображаются одни, а внутри документа
они другие (например: в док1 в графе Общего журнала "Автор" - Иванов, а в документе - Петров;
в журнале "Фирма" - ООО ПодСервис, а в документе - ИП Валерич).
База файловая, 1c v7.7 "Торговля и Склад 9.2"
В Базе Появилось два документа "Продажа" с разными номерами, и от разных авторов,
но с одной суммой и одним и тем же "содержимым".
Причем если я удаляю док1, то он как был проведён так таким и остался, а док2 при этом удаляется.
И еще в Общем журнале данные по графам для документа док1 отображаются одни, а внутри документа
они другие (например: в док1 в графе Общего журнала "Автор" - Иванов, а в документе - Петров;
в журнале "Фирма" - ООО ПодСервис, а в документе - ИП Валерич).
По теме из базы знаний
- Загрузка номенклатуры c картинками (несколько потоков одновременно) и сопутствующими данными в базу и любые документы из yml, xls, xlsx, xlsm, ods, ots, csv для УТ 10.3, УТ 11 (все), БП 3, КА 2, ERP 2, УНФ 1.6/3.0, Розница 2/3.0
- [Расширение] Загрузка данных из Excel в табличную часть документа с созданием не найденной номенклатуры
- Выгрузка из 1С: 7.7 ТиС 9.2 в 1С:8 БП 3.0
- Как стать матерым штурмовиком, или истории из жизни
- Интеграция 1С с маркетплейсами из одного окна: Озон, ВБ, Яндекс, Сбер, Али - для БП, УНФ, УТ, КА, ERP
Найденные решения
Есть такой метод
(только с копиями и НА СВОЙ СТРАХ И РИСК):
1) запоминаете дату и номер документа
2) выполняете УРБД обмены до тех пор, пока данные в посылках не кончатся
3) удаляете все файлы cdx
4) открываете 1sjourn.dbf таким приложением, которое не изменит версию формата хранения dbf
для этого годятся plugin к far manager-у lookdbf (работает со старыми версиями far 1.75)
либо access 2003 там надо подобрать четвертый dbase.
5) по полям DATE_TIME и DOCNO находите идентификатор IDDOC косячного документа (запомнили в 1)
6) по идентификатору находите дубль
7) удаляете обе эти строки из 1sjourn.dbf
8) по идентификатору IDDOC (или DOCID) находите соответствующие записи в DHXXXXX.dbf и DTXXXXX.dbf, где номера XXXXX - это вид документа, который можно прочитать в 1cv7.dd
9) удаляете все такие записи
10) запускаете 1С монопольно, она восстанавливает индексы. Документов нет ни того, которого надо ни косячного,
надо ввести новый и правильный.
11) Если все удалось, повторяете процедуру для дочерних баз.
В случае ошибки последствия - самые разные.
(только с копиями и НА СВОЙ СТРАХ И РИСК):
1) запоминаете дату и номер документа
2) выполняете УРБД обмены до тех пор, пока данные в посылках не кончатся
3) удаляете все файлы cdx
4) открываете 1sjourn.dbf таким приложением, которое не изменит версию формата хранения dbf
для этого годятся plugin к far manager-у lookdbf (работает со старыми версиями far 1.75)
либо access 2003 там надо подобрать четвертый dbase.
5) по полям DATE_TIME и DOCNO находите идентификатор IDDOC косячного документа (запомнили в 1)
6) по идентификатору находите дубль
7) удаляете обе эти строки из 1sjourn.dbf
8) по идентификатору IDDOC (или DOCID) находите соответствующие записи в DHXXXXX.dbf и DTXXXXX.dbf, где номера XXXXX - это вид документа, который можно прочитать в 1cv7.dd
9) удаляете все такие записи
10) запускаете 1С монопольно, она восстанавливает индексы. Документов нет ни того, которого надо ни косячного,
надо ввести новый и правильный.
11) Если все удалось, повторяете процедуру для дочерних баз.
В случае ошибки последствия - самые разные.
Всем спасибо за помощь самый лучший ответ на мой взгляд (13) . А я пошёл немного другим путем так как база УРБД, и ошибка возникла на одной из периферийных, проверил в центральной там документа "ПРИВЕДЕНИЯ" не оказалось
1. сделал обмен между БАЗАМИ, и
2. с центральной скопировал все дбф-файлы кроме 1SConst, 1SSystem,1SUPDTS, 1SDWNLDS и 1SDBSET, в проблемную
периферийную Базу (ПБ).
3. Далее в ПБ удалил все индексные файлы
4. и восстановил их.
1. сделал обмен между БАЗАМИ, и
2. с центральной скопировал все дбф-файлы кроме 1SConst, 1SSystem,1SUPDTS, 1SDWNLDS и 1SDBSET, в проблемную
периферийную Базу (ПБ).
3. Далее в ПБ удалил все индексные файлы
4. и восстановил их.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Затем - ТиИ, для начала лучше только с одной галочкой (восстановление индексов) - это не изменит информацию в базе, а описанное очень похоже на сбой индексов.
Можно просто удалить все файлы .CDX в папке с базой и запустить 1С в монопольном режиме.
По результатам смотреть - что изменилось, если ничего - тогда более глубокое ТиИ и далее переход к ковырянию в "кишках" базы по советам (4) - он в этом знает толк.
Подскажите, из-за чего такое может быть и как такое устранить.
Сначала надо понять - что случилось и только потом станет ясно (может быть) - как устранить.
В Базе Появилось два документа "Продажа" с разными номерами, и от разных авторов,
но с одной суммой и одним и тем же "содержимым"
Для начала - проверить размер файлов базы: самый большой не должен превышать 1 Gb, потом могут начаться хаотические ошибки чтения.
но с одной суммой и одним и тем же "содержимым"
Затем - ТиИ, для начала лучше только с одной галочкой (восстановление индексов) - это не изменит информацию в базе, а описанное очень похоже на сбой индексов.
Можно просто удалить все файлы .CDX в папке с базой и запустить 1С в монопольном режиме.
По результатам смотреть - что изменилось, если ничего - тогда более глубокое ТиИ и далее переход к ковырянию в "кишках" базы по советам (4) - он в этом знает толк.
(3) не надо делатьТИИ СРАЗУ. это может напрочь привести к тотальному ухудшению ситуации.
.
УРБД используется?
.
0. Сделать бэкап.
1. выяснить, какой документ "лишний".
2. проситать Иды документов.
3. провести подмену Идов с ненужного на нужный в таблицах.
.
УРБД используется?
.
0. Сделать бэкап.
1. выяснить, какой документ "лишний".
2. проситать Иды документов.
3. провести подмену Идов с ненужного на нужный в таблицах.
(4) Можно и со стула упасть, сломав ногу
Где гарантия, что найденная пара единственная? с базой явно что то не то, можно потом находить документы и ситать их вечно
А бэкапы это первое дело в таких ситуациях, и если человек этого не понимает, то ситать иды он явно будет с трудом
Где гарантия, что найденная пара единственная? с базой явно что то не то, можно потом находить документы и ситать их вечно
А бэкапы это первое дело в таких ситуациях, и если человек этого не понимает, то ситать иды он явно будет с трудом
А еще лучше - и проще - завести новый документ.
"заполнить" его данными по старому документу (данные ТЧ можно перенести штатно посредством "Добавить из документа")
и удалить два проблемных старых документа.
использовать в работе новый
"заполнить" его данными по старому документу (данные ТЧ можно перенести штатно посредством "Добавить из документа")
и удалить два проблемных старых документа.
использовать в работе новый
(5)Именно это и было сделано пометили на удаление и создали полностью новый документ, НО на удаление помечается документ Док2, а с док1 ничего не происходит - он как призрак ты его в журнале видишь пытаешься его удалить и на удаление помечается док2.
Если переиндексация не помогает, возможно в журнале документов две записи с одним ид. Тии обычно помогает. Если база очень большая, то имеет смысл скопировать, выполнить тии на копии, сравнить файлы и заменить испорченные файлы в базе на файлы из копии, после чего заново создать индексы.
Есть такой метод
(только с копиями и НА СВОЙ СТРАХ И РИСК):
1) запоминаете дату и номер документа
2) выполняете УРБД обмены до тех пор, пока данные в посылках не кончатся
3) удаляете все файлы cdx
4) открываете 1sjourn.dbf таким приложением, которое не изменит версию формата хранения dbf
для этого годятся plugin к far manager-у lookdbf (работает со старыми версиями far 1.75)
либо access 2003 там надо подобрать четвертый dbase.
5) по полям DATE_TIME и DOCNO находите идентификатор IDDOC косячного документа (запомнили в 1)
6) по идентификатору находите дубль
7) удаляете обе эти строки из 1sjourn.dbf
8) по идентификатору IDDOC (или DOCID) находите соответствующие записи в DHXXXXX.dbf и DTXXXXX.dbf, где номера XXXXX - это вид документа, который можно прочитать в 1cv7.dd
9) удаляете все такие записи
10) запускаете 1С монопольно, она восстанавливает индексы. Документов нет ни того, которого надо ни косячного,
надо ввести новый и правильный.
11) Если все удалось, повторяете процедуру для дочерних баз.
В случае ошибки последствия - самые разные.
(только с копиями и НА СВОЙ СТРАХ И РИСК):
1) запоминаете дату и номер документа
2) выполняете УРБД обмены до тех пор, пока данные в посылках не кончатся
3) удаляете все файлы cdx
4) открываете 1sjourn.dbf таким приложением, которое не изменит версию формата хранения dbf
для этого годятся plugin к far manager-у lookdbf (работает со старыми версиями far 1.75)
либо access 2003 там надо подобрать четвертый dbase.
5) по полям DATE_TIME и DOCNO находите идентификатор IDDOC косячного документа (запомнили в 1)
6) по идентификатору находите дубль
7) удаляете обе эти строки из 1sjourn.dbf
8) по идентификатору IDDOC (или DOCID) находите соответствующие записи в DHXXXXX.dbf и DTXXXXX.dbf, где номера XXXXX - это вид документа, который можно прочитать в 1cv7.dd
9) удаляете все такие записи
10) запускаете 1С монопольно, она восстанавливает индексы. Документов нет ни того, которого надо ни косячного,
надо ввести новый и правильный.
11) Если все удалось, повторяете процедуру для дочерних баз.
В случае ошибки последствия - самые разные.
Всем спасибо за помощь самый лучший ответ на мой взгляд (13) . А я пошёл немного другим путем так как база УРБД, и ошибка возникла на одной из периферийных, проверил в центральной там документа "ПРИВЕДЕНИЯ" не оказалось
1. сделал обмен между БАЗАМИ, и
2. с центральной скопировал все дбф-файлы кроме 1SConst, 1SSystem,1SUPDTS, 1SDWNLDS и 1SDBSET, в проблемную
периферийную Базу (ПБ).
3. Далее в ПБ удалил все индексные файлы
4. и восстановил их.
1. сделал обмен между БАЗАМИ, и
2. с центральной скопировал все дбф-файлы кроме 1SConst, 1SSystem,1SUPDTS, 1SDWNLDS и 1SDBSET, в проблемную
периферийную Базу (ПБ).
3. Далее в ПБ удалил все индексные файлы
4. и восстановил их.
М-да. До сих пор непонятно - что сделал автор для решения проблемы, и что он вообще пытался сделать... кроме попыток удаления несчастного док1.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот
