Вход | Регистрация
    1  2  3   
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: Не переносится точка актуальности. Файл RG1051.DBF - 2ГБ. Очень прошу заключения экспертов

v7: Не переносится точка актуальности. Файл RG1051.DBF - 2ГБ. Очень прошу заключения экспертов
Я
   Валерий111
 
25.09.21 - 12:36
Сразу предупреждаю: я не программист 1-С. Я ее пользователь. И все, что я делал - делал по советам программистов или по информации из форумов. Так что оценивать мой уровень знаний нет смысла ))) .
Прошу экспертное заключение профессионалов по моим действиям.

База 1-С Предприятие 7.7 АБТ 3 ПРОФ (3.5.4) (база ДБФ и переход на скул не предвидится).

Не переносится точка актуальности. Пишет ошибку записи в файл RG1051 и выбрасывает из базы. Файл достиг 2 ГБ.
Сжатие в конфигураторе (поиск и справление) не дало результата. Свертка не проводится - выбрасывает ошибку.

Поискал решение в инете. Нашел на этом форуме идею: "подрезать" вес регистров по остаткам.
В конфигураторе залез в Регистры-Остатки-Ресурсы и для двух ресурсов уменьшил разрядность. (все делаю в копии, чтобы не убить оригинал).
Для "Кво" было 13,3 - сделал 11,1
Для "СуммаГрн" было 13,3 - сделал 12,2.
Дальше - конфигуратор за 1 час внес изменения.
Результаты:
файл RG1051.DBF был 2 086 812 кВ стал - 2 012 283 кВ
файл RG1051.CDX был 387 664 кВ , стал 857 775 кВ

Запустил переиндексацию. Файл RG1051.CDX стал 387 664 кВ.
ТА перенеслась на 2 месяца.
Но не дальше. Потому что RG1051.DBF стал 2 091 957 кВ.

Потом подумал и еще раз уменьшил разрядность. Но уже по всем 5 индексам. Установил:
количество - 8,1
все остальные - 10,2
Опять же переиндексировал.
Теперь
файл RG1051.DBF - 1 898 258 кВ
файл RG1051.CDX - 402 617 кВ

(все делаю в копии, чтобы не убить оригинал).

Я понимаю, что это временное решение. Но теперь у меня есть время на нормальное.

Вопрос к экспертам - насколько я все сделал плохо? Не будет ли теперь проблем с работой базы?
Если это решение нормальное - то можно ли проводить в основной базе?

Буду признателен за быстрые ответы, так как до 1.10.2021 осталось совсем мало времени.
   Dmitry1c
 
1 - 25.09.21 - 13:47
Экономьте дальше
   acht
 
2 - 25.09.21 - 14:17
(0) > я не программист

А что произошло с теми, кто написал вам немеряно кода для специфического Технологического учета (для работы СЦ)?
   Валерий111
 
3 - 25.09.21 - 14:25
Здравствуйте, Dmitry1C.

Спасибо за ответ. Хотя он совсем не ясен.

Что именно экономить?

Если речь идет об оплате программиста, который мог бы за деньги решить проблему, то в этом проблемы нет. Проблема как раз в том, что программисты не могут решить проблему. 4 года назад я нанял программиста, чтобы он сделал свертку базы. Так как в нашей базе много кода дописано под нашу специализацию, то стандартная свертка базы не могла быть использована. На тот момент база уже занимала 18 гиг и сильно тормозила. Программист за деньги обрезал ее до 10 гиг. Но обрезал не до конца. Много документов из обрезанного периода остались в базе. Те же партии товаров остались. Я понимаю, что база сложная. Но я же не против платить. То, что он сделал, помогло, безусловно, на тот момент. Но сейчас проблема опять проявилась. И беглый анализ показывает что предыдущая обрезка была сделана хорошо, но не до конца.
А еще 2 программиста - попросили аванс за изучение ситуации, а после получения аванса - ничего не сделали и пропали.
То есть, вопрос не в деньгах.

То о какой экономии Вы говорите?
   Валерий111
 
4 - 25.09.21 - 14:28
(0) > я не программист А что произошло с теми, кто написал вам немеряно кода для специфического Технологического учета (для работы СЦ)?

С этими людьми связи нет давно. Мне это предприятие с базой досталось в "наследство" от предыдущего директора (он умер, поэтому все его связи утеряны).
   Базис
 
5 - 25.09.21 - 14:29
1. Сделайте архив.
2. Проверьте архив.
3. Откройте в личной карточке контакты и вам смогут написать те, кто в состоянии решить вашу задачу.
   Валерий111
 
6 - 25.09.21 - 14:37
Спасибо.
Контакты открыл.
Не совсем понял - что значит "проверить архив"?

Я готов привлекать за оплату специалиста, который возьмется за оптимизацию базы.

Но... Есть ли сейчас мнение по поводу того короткого решения, которое я применил?
Оно сейчас сделано в копии и мне надо сегодня-завтра сделать это в актуальной базе и я хочу быть хоть немного уверенным в данном решении.

Оно даст запас времени, чтобы найти специалиста, договориться со специалистом, и у специалиста будет время на решение.
   Валерий111
 
7 - 25.09.21 - 14:40
(1) (2) (5)
 
Сорри. )))
Сначала не разобрался как писать ответ на пост.
Поэтому просто писал сообщениями.
Теперь понял.
   hhhh
 
8 - 25.09.21 - 15:33
(3) ну сделайте еще обрезку. в чем проблема? А лучше вообще заведите чистую базу и начните с нуля. Мы когда работали в 7.7, каждый год это делали, 2-3 января работники делали инвентаризацию и в новую базу заносили реальные остатки товара. А у вас что-то целых 4 года без обрезки - это конечно круто, но зачем так над собой издеваться?
   серый КТУЛХУ
 
9 - 25.09.21 - 16:04
(8): бред какой. номенклаторы, контриков, прочую нси.
(0): див.мило
   Валерий111
 
10 - 25.09.21 - 16:10
(8)
Именно сейчас: обрезка - не вариант. Большой кусок кода - технологический учет. Там есть особенность. В отличии от обычной 1-С, где есть только операция, после которой меняются счета и регистры, тут, в технологическом учете есть ПРОЦЕССЫ. Они растянуты во времени и их обрезать на середине - нереально.
Поэтому предыдущий программист обрезал базу 4 МЕСЯЦА. И то, полностью не обрезал.
И я бы согласился еще на одну обрезку (если бы кто-то сделал ее нормально). Но до 1.10.2021 ее никто не сделает. Поэтому надо сначала применить временное решение, а потом - правильное и глобальное.

Поэтому я и спрашиваю в топике: нормальное ли это временное решение? Не будет ли проблемы с базой от такого действия? Спрашиваю у экспертов.
Спасибо за ответ.
   Валерий111
 
11 - 25.09.21 - 16:11
(9)

как можно понять Ваш коммент "див.мило"?
   Ёпрст
 
12 - 25.09.21 - 16:14
(0)
Огласите размер RA этого регистра

Огласите перечень измерений и их типы этого регистра.

ЗЫ: уменьшать разрядность ресурсов нужно с умом, можете запосто нарваться на переполнение разряда в вычислениях, ну или исказить данные.
Сперва нужно было посмотреть, какое мак число содержится в каждом ресурсе.
   Валерий111
 
13 - 25.09.21 - 16:15
(8)
уточню.
В данном случае 1-С - не столько 1-С, сколько специфическая CRM, встроенная в 1-С. Мы с 10 лет с ней работали нормально. Все операции, все процессы , вся история доступны и для аналитики, и для сбора статистики.
   Валерий111
 
14 - 25.09.21 - 16:26
(12)
А вот тут мне уже чересчур сложно. )))
Я не понимаю - что такое размер RA этого регистра.
И перечень измерений и типы - тоже не понятно.
И что такое мак число в ресурсе - тоже.
((((
Все это мне не понятно. Ибо я не программист.
Я всего лишь изменил настройки в конфигураторе.
Я сделал следующие изменения для регистра остатков во всех 5 индексах:

Кво: было 13и3 - стало 8и1 (из всех сотен тысяч позиций в ТМЦ мы только в 8 позициях используем цифры после запятой и то, не юзаем этот товар уже более 5 лет).
СуммаГрн: было 13и3 - стало 10и2
СуммаБезНДС: было 12и2 - стало 10и2
СуммаОсн: было 12и2 - стало 10и2
Наценка: было 12и2 - стало 10и2

Больше ничего не делал и никуда не смотрел. Сделал в копии базы.

И все что могу сделать сейчас: либо сделать то же самое в актуальной базе. Либо найти кого-то, кто быстро и гарантированно сделает что-то другое и изменит ситуацию до 1.10.21 (с учетом того, что есть полтора выходных и еще пара дней вечером, с 19-00 до 23-00). Иначе ТА на 1.10.21 не перенесется.

На второй вариант я особо не рассчитываю. Я пытаюсь запустить временное решение и тут же перейти к нормальному, но не останавливая работу компании. Именно поэтому и свожу все к вопросу: нормальное ли это решение как временное? Или все плохо?

Если нужна дополнительная информация - подскажите, пожалуйста, куда мне посмотреть и я посмотрю.
   Злопчинский
 
15 - 25.09.21 - 16:29
(3) наличие старых документов после обрезки не есть признак неправильности обрезки, точно так же как и партии
   Ёпрст
 
16 - 25.09.21 - 16:30
(14)

1.RA - RA1051.DBF
2. Открыть словарик (*.dd) в каталоге базы, найти там название регистра RA1051
3. Открыть пофигуратор, в дереве метаданных найти этот регистр, раскрыть дерево, огласить список измерений и их типы
4. мак - макс (это очепятка)
   Ёпрст
 
17 - 25.09.21 - 16:33
(14) решение так себе, вы не проверили значения ресурсов в файле перед уменьшением разрядности.

А так, у вас наглухо незакрытый регистр. Тут нужно не временными решениями баловаться, а смотреть, из-за каких измерений он не закрывается и почему. И потом, либо выкинуть нах эту левую аналитику совсем, или сделать так, чтоб наборы измерений прихода и расхода стали одинаковым
   Валерий111
 
18 - 25.09.21 - 16:34
(15)
я согласен с Вами. Но там получилось все очень странно. Так как у нас есть еще много документов, которые формируются именно технологическим учетом.
   Ёпрст
 
19 - 25.09.21 - 16:34
ну а пока, нужны ответы на (12) 

И да.. риб есть ?
   Злопчинский
 
20 - 25.09.21 - 16:35
У вас проблемы в ваших процессах. Отсюда проблема в учете. Отсюда проблема в упомянутом регистре. Это регистр итогов, соответствующий ему с таким же числовым суффиксом регистр движений RA. В норме таблица движений должна быть в несколько раз/на порядок (а то может и больше) быть меньше таблицы итогов.
   Злопчинский
 
21 - 25.09.21 - 16:36
У вас ситуация когда вы приход пишите по одному набору аналитических показателей (измерения), а расход по другому набору и в вас расход не закрывает приход, что ведёт к эскалации размера файла итогов.
   Валерий111
 
22 - 25.09.21 - 16:39
(16)
СПАСИБО!!! Сделаю чуть позже.
Прямо сейчас нет доступа.

(17)
на 1000% согласен с Вами и немного понимаю о чем речь. Однозначно хочу сделать так, чтобы этот регистр правильно закрывался.

(19)
что такое "риб"? (((
   Mihenius
 
23 - 25.09.21 - 16:39
(14) Достаточно будет проанализировать регистр.
По тем ресурсам, по которым не закрывается - нужно сделать оборотный регистр.
А отчеты по 2 регистрам.
Или убрать эти ресурсы в реквизиты

Другой вариант сделать так, чтобы регистр закрывался по всем реквизитам.

Вроде так когда-то делал )
   Валерий111
 
24 - 25.09.21 - 16:41
(20)
(21)
Наверняка Вы правы. И я очень хочу сделать НОРМАЛЬНО. Но до 1.10.21 осталось совсем ничего. А работать надо. Так как для нас это не просто учет. Это кровеносная система. Ее останавливать нельзя.
   Mihenius
 
25 - 25.09.21 - 16:41
У (21) кстати был отчет смотреть какие регистры не закрываются еще на проклабе, сейчас на инфостарте.
   Mihenius
 
26 - 25.09.21 - 16:42
(24) Еще вариант.
Сделать "псевдо закрытие месяца", которое будет закрывать все незакрытые остатки.

Но это костыль.
   Злопчинский
 
27 - 25.09.21 - 16:45
(18) да и пофиг. Прог сделал обрезку. Итогом обрезки стали некие входные остатки, в которых упоминаются старые документы и партии. А в виду незакрытости регистра такого гуана м.б. тонны. И с этим Программисту ничего не сделать. Вы так построили учет. Криво. Горбатого только могила исправит. Чтобы выправить ваш горб придется либо самому въезжать в ваши процессы и их отражение в базе либо платить денег и вполне возможно много.
   Валерий111
 
28 - 25.09.21 - 16:46
(23) (25)

Вполне возможно - это правильные решения. Но для грамотных исправлений пока нет времени. И их должен делать не я, а специалист и за деньги.
Для меня "проанализировать регистр", "убрать в реквизиты" и "псевдозакрытие месяца" - как нейрохирургия или балет. Я тут - мимо. )))

Я пытаюсь сейчас продлить "искусственную кому" нашей 1-С, в которой мы все же продолжим работать, и заняться поиском хорошего исполнителя и нормального решения.
   Ёпрст
 
29 - 25.09.21 - 16:48
Без ответа на (12) всё мимо денег.
Если не знаете, что есть РИБ, значит, у вас его нет.
   Злопчинский
 
30 - 25.09.21 - 16:48
(22) то что сейчас нет доступа - это очень херово. Грубо говоря куроводству похрен на бесперебойность процесса работы. Поэтому не переживайте, ну не получится 01.10 переползти на новый месяц ди и хрен с ним, за пару дней неделю разберетесь, позерачат ручками вручную, потом поеб соррм потрахаетесь занося данные ща период простоя. Потом куроводству может станет понятно что доступ должен быть всегда. Ибо нехер.
 
 
   Злопчинский
 
31 - 25.09.21 - 16:49
И да, слушайте Ëпрст, он мегагуру
   Mihenius
 
32 - 25.09.21 - 16:50
(28) Ну тогда приглашайте специалиста на удаленку.
Тут для знающего человека работа, а не по советам тыкать мышкой )

Как минимум тут 2 специалиста, которые вам точно помогут и им можно доверять.
   Злопчинский
 
33 - 25.09.21 - 16:51
(28) найдите время. Десять лет времени не было - может пора ч обычно было?
   Dmitry1c
 
34 - 25.09.21 - 16:52
(3) об экономии на переходе на 1с8
   Валерий111
 
35 - 25.09.21 - 16:58
(27)
Наверняка учет кривой. Но его надо ровнять. Может не весь сразу. А по частям. Но 15 лет эта база тянула. И одну обрезку пережила (4 года назад). Но кто знал, что через 4 года вылезет новая проблема?
Возможно - найдется кто-то, кто разберется в наших процессах-регистрах. За деньги.

(30)
Доступа нет в конкретную сию минуту (потому что стою на улице). Дойду домой - доступ будет.
И если другого решения не будет, то все равно реализую это. Даже с риском. Просто минимизирую его путем редактирования 1-2 индексов.
И буду искать специалиста для нормального решения. Поэтому и спрашивал - нормальное ли это решение для получения небольшой отсрочки в 1-2 месяца.

(31)
Слушаю. И чувствую уровень.
   Валерий111
 
36 - 25.09.21 - 17:00
(29)

Прочитал про РИБ. Скорее всего у нас этого нет. Все грузят 1 базу с конкретного диска-директории.

ответы на 12 - поищу.
   Валерий111
 
37 - 25.09.21 - 17:01
(32)
так оно и будет. Но тут главное - не остановиться. Это и пытаюсь сделать: не остановиться и заняться правильным решением
   Злопчинский
 
38 - 25.09.21 - 17:01
Любое решение которое не ломает систему и позволяет получить отсрочку - нормальное
   Злопчинский
 
39 - 25.09.21 - 17:03
Возьми несколько архивов базы если они есть и посмотри на сколько прыгал прирост РГ при открытии  месяца. Но с каждым разом прирост при незакрытых регистрах увеличивается
   Злопчинский
 
40 - 25.09.21 - 17:04
Запасаемся попкорном и колой ;-)
   Злопчинский
 
41 - 25.09.21 - 17:06
Предполагаю размер RA  в районе 500 Мб
   Валерий111
 
42 - 25.09.21 - 17:08
(34)
У нас к 1-С дописан спецучет. Типа CRM. Вес функционал в 10 раз больше, чем 1-С. Переходить на 8-ку - это вырезать весь код и данные по этому спецучету и пришить к 8-ке. Это как отрезать половину тела и пришить к другой половине.

Если никто сейчас лечить не берется, то кто возьмется за создание этого нового гибрида?

Кроме того, так как уважаемые эксперты уже поставили основной диагноз: "криво написанный учет", то какая разница - к чему этот кривой учет пришивать: к 7-ке или 8-ке? Бока останутся те же, так как созданы (судя по всему) этим дополнительным учетом.
   ДенисЧ
 
43 - 25.09.21 - 17:10
(42) тут есть несколько моментов
а) лечить 77 - таких саксаулов уже мало осталось.
б) возможно, грамотные люди подскажут уже готовую конфигурацию на 8, где нужно будет (возможно) расставить только галки в нужном порядке. Хотя (не сочти за наезд) на Украине в учёте может быть всё, что угодно...
   Dmitry1c
 
44 - 25.09.21 - 17:11
(42) вы бюджет на лечение озвучьте, может и врачи найдутся.

>>кто возьмется за создание этого нового гибрида?

бюджет, бюджет... все упирается в бюджет
   Злопчинский
 
45 - 25.09.21 - 17:11
Учёт может и норм, просто в один прекрасный день какой-то поц перестал делать некие действия, напрямую к оперативным процессам они не относятся, но их делать надо. И все, жопа..
   Dmitry1c
 
46 - 25.09.21 - 17:12
>>основной диагноз: "криво написанный учет", 

нет, тут тотальная экономия на "Так как для нас это не просто учет. Это кровеносная система"
   Злопчинский
 
47 - 25.09.21 - 17:14
Распространённая хрень - может и у вас быть - работа от нескольких фирм на базе "общих" остатков.
+100 на одну фирму и -100 от другой фирмы нуля не дают!!! Это как частный пример незакрытого
   Lazy Stranger
 
48 - 25.09.21 - 17:22
Вполне возможно что там достаточно сделать регламентный документ, который взаимно схлопнет незакрытые измерения и работы там (вместе с изучением базы) всего-то на полдня. В идеале нужен MD базы и отчет по остаткам этого регистра по всем измерениям (их универсальных много) чтобы что-то советовать.
   Злопчинский
 
49 - 25.09.21 - 17:25
(48) все не так просто может оказаться. +100 и -25 -35 -40 и трындец "взаимности".
   серый КТУЛХУ
 
50 - 25.09.21 - 17:31
а разобрались что эт воще за регистр (парусске)? а вдрух он оборотный?
   Валерий111
 
51 - 25.09.21 - 17:32
(38)
Согласен. Вот и спрашиваю - нормальное ли оно, это временное решение? ))))
(с учетом вопросов-замечаний от Ёпрст).

(39)
Идея про оценку прироста хорошая. Архивов нет. Копия вчерашняя есть. А копия (ближайшая) за 19.11.2019
Размер файла RG1051.DBF на вчера - 2 086 856 кВ
Размер его же на 19.11.2019 - 1 916 016 кВ

(47)
Вполне возможно.

(41)
посмотрел в базу. Размер файла RA1051.DBF - 70 521 кВ (на утро сегодня)
попкорна много оказалось? ;) 


(12)
посмотрел в базу. Размер файла RA1051.DBF - 70 521 кВ (на утро сегодня) 

# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RA1051  |Регистр (Дв.) Остатки         |A          |RA1051     |1        
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=IDDOC     |ID Document's       |C   |9     |0        
F=LINENO    |LineNo              |N   |4     |0        
F=ACTNO     |Action No           |N   |6     |0        
F=DEBKRED   |Flag Debet/Kredit   |N   |1     |0        
F=SP1855    |(P)Фирма            |C   |9     |0        
F=SP1053    |(P)ТМЦ              |C   |9     |0        
F=SP1052    |(P)Склад            |C   |9     |0        
F=SP1054    |(P)Партия           |C   |9     |0        
F=SP1055    |(P)Кво              |N   |14    |3        
F=SP1056    |(P)СуммаГрн         |N   |14    |3        
F=SP1057    |(P)СуммаБезНДС      |N   |13    |2        
F=SP1058    |(P)СуммаОсн         |N   |13    |2        
F=SP1059    |(P)Наценка          |N   |13    |2
   Валерий111
 
52 - 25.09.21 - 17:34
(29)

Это оно?
   Валерий111
 
53 - 25.09.21 - 17:37
(40)
Надеюсь Вы не обиделись на шутку про попкорн? ))
   Djelf
 
54 - 25.09.21 - 17:37
(52) А RG1051 где?
   Валерий111
 
55 - 25.09.21 - 17:41
(54)

Даже не знаю - что сказать...
меня спросили про RA1051 - я ответил.

#==TABLE no 241    : Регистр Остатки
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RG1051  |Регистр Остатки               |A          |RG1051     |1        
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=PERIOD    |Period Registr      |D   |8     |0        
F=SP1855    |(P)Фирма            |C   |9     |0        
F=SP1053    |(P)ТМЦ              |C   |9     |0        
F=SP1052    |(P)Склад            |C   |9     |0        
F=SP1054    |(P)Партия           |C   |9     |0        
F=SP1055    |(P)Кво              |N   |14    |3        
F=SP1056    |(P)СуммаГрн         |N   |14    |3        
F=SP1057    |(P)СуммаБезНДС      |N   |13    |2        
F=SP1058    |(P)СуммаОсн         |N   |13    |2        
F=SP1059    |(P)Наценка          |N   |13    |2      

наверное - вот это?


Сорри, буду немного оффлайн.
   Злопчинский
 
56 - 25.09.21 - 17:51
При таком размере Ра 70 мб размер рг д. Б. Мегабайт 20
   Mihenius
 
57 - 25.09.21 - 17:52
Наценку точно можно убрать/перенести, но это не особо поможет.

Судя по реквизиту партия, косяк именно в нем )
Сколько в партиях элементов?

Из решения влоб.
Убрать партии, переделать отчеты с партиями на среднее, списание на среднее или закрытие месяца.
   Lazy Stranger
 
58 - 25.09.21 - 17:52
Регистр то простенький, или приход по одним фирмам и расход по другим или приход с указанием партий и списание без. И то и другое вылечить несложно, странно что топикстартер до сих пор не нашел программера, который бы это исправил.
   Злопчинский
 
59 - 25.09.21 - 17:52
Скорее всего
- многофирменный незакрытый учет
- возможно отключен контроль остатков
- могли ещё и Наценку в ресурс регистра запихнуть
   Mihenius
 
60 - 25.09.21 - 17:58
(59) Кинь им ссылку на свой отчет, точно помню у тебя он был.
Там же сразу будет все видно.
 
 
   Lazy Stranger
 
61 - 25.09.21 - 18:36
(59) с наценкой - очень может быть что это ресурс, который не закрывается, и по ней все эти остатки и накопились
   1Снег
 
62 - 25.09.21 - 20:56
(0) >База 1-С Предприятие 7.7 АБТ 3 ПРОФ (3.5.4) (база ДБФ и переход на скул не предвидится).
Вы бы посчитали на всякий случай, сколько переход на SQL-базу будет стоить.
А то столько усилий, которые можно решить однократной покупкой лицензии
   Ёпрст
 
63 - 25.09.21 - 23:01
(52) да оно.
Тут или приход с одной фирмой, расход по другой фирме, или партию при расходе неверно указывают. Или приход на один склад, расход с другого склада.



У вас многофирменный учет ?
Всё  это не так и долго проверяется, достаточно посмотреть движения приходных и расходных документов по одному тмц.
   Ёпрст
 
64 - 25.09.21 - 23:02
И да, при таком размере RA, ваш RG должен быть метров 20 или 10.
   Ёпрст
 
65 - 25.09.21 - 23:02
Но никак не 2 Гб
   Ёпрст
 
66 - 25.09.21 - 23:02
И резать ресурсы не обязательно.
   Валерий111
 
67 - 26.09.21 - 00:10
(58)
Топикстартер не искал такого программиста. Потому что топикстартер не видел этой проблемы ранее. )))
   Валерий111
 
68 - 26.09.21 - 00:41
(63)

я завтра (уже сегодня) попробую посмотреть как делается приход и расход в разрезе фирм (и делается ли разделение по фирмам).
Уточню, что у нас 1-С для сервисного центра по ремонту техники, и прикол в том, что ТМЦ (детали) приходуются от поставщиков на склад (счет 20.7). А расход делается со склада в производство. И там, где-то в производстве, эти детали "теряются".
А вот используется ли при этом многофирменный учет - не знаю.

Огромное Вам спасибо за то, что помогаете найти реальную проблему и правильно ее решить.
Но я думаю, что корректно будет сделать это на платной основе. Даже если там все относительно просто решается.

Только я опасаюсь, что времени на корректное решение совсем мало и поэтому предлагаю сделать это в 2 этапа:
1) быстрое, временное решение: типа укорочения ресурсов (хотя бы на 2 месяца переноса ТА). Делаю сам.
2) правильное решение: поиск проблемы, обсуждение решения, оплата, выполнение работы (по согласованным срокам).
   Валерий111
 
69 - 26.09.21 - 00:43
(57)

Спасибо за идею. Наверное косяк в партиях.
Но отказаться от партионного учета пока не можем. Это требуется для работы с поставщиками.
   Ёпрст
 
70 - 26.09.21 - 09:58
(68) поиск проблемы, минут 10. Устранение - это или обрезка или перенос существующей аналитики в реквизит регистра, если останки по неверным измерениям не нужны.
Итого, пол дня на всё с учетом переписывания участков кода.
Обрезать бездумно ресурсы не стоит. Сперва нужно найти в каждом из них максимальное число, чтоб оценить степень урезания. И запас должен быть. Ибо при сложении, например, выйдет 99999, например, т.е переполнение разряда
   Ёпрст
 
71 - 26.09.21 - 10:00
Ну и если так нужна залипуха, то можно обрезать только этот регистр на 1 января, например, текущего года, и дальше продолжать смотреть, как пухнут итоги с геометрической прогрессией.
   Валерий111
 
72 - 26.09.21 - 10:14
(70)

А Вы можете написать мне в вайбер/телеграм/вацап? я свой номер оставил. Или на почту.
   серый КТУЛХУ
 
73 - 26.09.21 - 13:16
(70): не забудь про переписывание всех(!) запросов по остаткам, в которых юзается разрез измерения, которое переносится в реквизит. а это может оказаться немало кода.
   Volodja
 
74 - 27.09.21 - 08:18
(0) А у вас этот Регистр не оборотный случаем?
Может тогда Периодичность уменьшить? Скажем Если у вас стоит месяц, то поставить Квартал. Размер регистра при этом думаю уменьшится.
Но отчеты, возможно, медленнее формироваться будут.
   Volodja
 
75 - 27.09.21 - 08:19
(74) И у вас остатки в разрезе ваших фирм (не одной?)
   Volodja
 
76 - 27.09.21 - 08:24
И да, периодичность регистра остатков тоже может быть изменена, Если у вас стоит 5,10,15 дней, то можно установить на Месяц
   Mikeware
 
77 - 27.09.21 - 08:26
(74) Если бы регистр был оборотный - файл итогов при "максимальном незакрытии" был бы плюс-минус такой же по размерам, как файл движений (добавилось поле период, убавились поля реквизитов).
   Mikeware
 
78 - 27.09.21 - 08:30
(0) возьми где-нибудь обработку gerprint.ert, сделай отчет по этому регистру за месяц (любой), и кинь эту простынь на какой-нибудь файлообменник. посмотрим.
   Volodja
 
79 - 27.09.21 - 08:35
(77) Ну тогда стоит проверить (76).
Возможно у (0) стоит не Месяц
   Mikeware
 
80 - 27.09.21 - 08:42
(79) судя по тому, что ТС оперирует месяцами - периодичность месяц.
+(78) regprint, конечно же...
https://drive.google.com/file/d/1LKQD33E4lMnBUQPDetbS_zpyYfzGW0Dd/view?usp=sharing, https://drive.google.com/file/d/1R1Ncz7yK1Z48B5VDsOHyPID8TM0ngZmx/view?usp=sharing
   Volodja
 
81 - 27.09.21 - 08:57
И если не ведется многофирменный учет, то возможно попробовать избавиться от измерения "Фирма".
Как вариант попробовать назначить этому реквизиту тип Число(1)
   Volodja
 
82 - 27.09.21 - 09:02
Еще вариант проверить наличие признака "Быстрая обработка движений" так как при его наличии в таблице движений появляется дополнительной поле.
   Ёпрст
 
83 - 27.09.21 - 09:15
(82) и ? оно появляется табличке движений.
Никакого отношения к итогам.
В итогах, только если стоит отбор итогов в одном из измерений.
И то, на рост RG это особо не повлияет
   Alexor
 
84 - 27.09.21 - 09:17
Есть ещё подозрение что итоги убежали либо за 21 год либо к 0000.
Было раз такое.
Автор сделайте копию.
Удалите на копии все файлы rg*. *
Запустите 1с. Она ругнется на создание файлов. Закройте. Запустите конфигуратор.
В нем тестирование и исправление со всеми галками.


Если после тестирования файл уменьшится то проблема решена. Если нет надо разбираться с закрытием данных
   Ёпрст
 
85 - 27.09.21 - 09:22
Автор, никогда не делай (84).
Только если у тебя куча свободного времени и не жалко базу терять.
   Mikeware
 
86 - 27.09.21 - 09:24
(82) а растут - итоги. Так что "быстаря обработка" не при делах.
(84)  ну вот нахрена так делать?
   Alexor
 
87 - 27.09.21 - 09:27
(85) Потеря базы то причем? На копии делать.

А сделать т.к. раз было, что из-за сбоя Итоги улетели за 2050 год. И файл RG распух.
Еще из-за кривой обрезки могли остаться в нем старые данные.
на 70 мег движений 2гига не закрытых за 4 года плохо верится.
   Volodja
 
88 - 27.09.21 - 09:35
(85), (87) Итоги из движений заново создадутся. Ничего не должно потеряться. Но времени много уйдет, это да.
   Mikeware
 
89 - 27.09.21 - 15:12
(88) ну так сначала нужно посмотреть на эти итоги, а уж затем рекомендовать человеку операцию, которая займет фиг знает сколько времени и с неизвестным результатом...
   Alexor
 
90 - 27.09.21 - 15:20
(89) Я предложил это сделать на копии.
И сидеть и пялить в монитор тут не требуется.
Запустил и пытайся найти решение другое.

У автора нет ресурса знаний, а время есть.
Согласен, что результат и сутки может не просчитать, но из опыта, на нормальном десктопном железе не более 2-3 часов.
И будет по крайней мере результат может отрицательный, но может и положительный.
   Volodja
 
91 - 27.09.21 - 15:28
+(90) Согласен.
   Volodja
 
92 - 27.09.21 - 15:29
(91) Иногда неожиданный вариант может дать результат.
   uno-group
 
93 - 27.09.21 - 16:01
Из быстрого решения кидаете мне МД или любому прогу. Пишется обработку или берется готовая выводящую полный отчет по остаткам присылаете остатки.
Согласовываем условие сворачивания измерения. Делается документ который заполняется по этим условиям и сворачивает остатки.
Пишется обработка которая создает данный документ на последние число каждого месяца. Запускаем и через час размер файла в 10 раз меньше.
В течение дня все легко делается. Потом не спеша разбираемся где, что не правильно закрывается и почему как это исправить.
Если этот регистр двигает пару документов и алгоритм не слишком запутанный то можно сразу это сделать.
   Валерий111
 
94 - 27.09.21 - 17:02
(85)
Я сам больше ничего делать не смогу (и особо не считаю правильным).
Я бы доверился специалисту. За оплату.
   Mikeware
 
95 - 27.09.21 - 17:14
(92) тогда нужно посоветовать посадить за клавиатуру обезъяну. Как известно, есть ненулевая вероятность, что таковая за бесконечное количество времени напишет "войну и мир"...
   Mikeware
 
96 - 27.09.21 - 17:16
(94) я дал ссылку на обработку вывода регистра. делаете отчет за месяц, и выкладываете. кто-нибудь да посмотрит, и даст реальное заключение, а не фантазмы...
   НЕА123
 
97 - 27.09.21 - 17:18
в 77 в таблице итогов удалить все записи с нулевыми ресурсами (почему-то они остаются и не упаковываются).
грохать движения опасно.
ЗЫ
но это должен делать не ТС.
   Mikeware
 
98 - 27.09.21 - 17:20
(97) нулевые ресурсы появляются, если в заднем числе залезть и поправить "чтоб закрылось". Штатно открытие периода не переносит на след. период остатки, у которых все ресурсы нулевые. а "почему" - вполне понятно и объяснимо.
   HawkEye
 
99 - 27.09.21 - 18:37
(94) надо базу смотреть.... можешь копию показать?
   Злопчинский
 
100 - 27.09.21 - 19:01
(97) регистр резакрыт, причем тотально. Чистка нулевых итогов ничего не даст  просто потому что там их нет
  1  2  3   

Список тем форума
 
Ошибка? Это не ошибка, это системная функция.
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.