Вход | Регистрация
    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 осталось совсем мало времени.
   uno-group
 
201 - 29.09.21 - 14:09
(200) Вы думаете там лицензионный софт, очень сомневаюсь. 1с может и покупали если внедрял кто то из принципиальных франей, винда очень сомневаюсь. У нас лицензионный софт скорее редкое исключение чем правило.
   uno-group
 
202 - 29.09.21 - 14:11
Хотя возможно когда то была попытка и из-за не ровного кода не взлетело.
   Валерий111
 
203 - 29.09.21 - 19:58
(161) (175) (175) (200)


1. На бесплатно я не рассчитываю.
2. Прошу написать Ваши предложения на почту.
3. В предложениях прошу дать пару вариантов на выбор по цене. Причем, учитывая Ваш высочайший уровень профессионализма, я понимаю, что полное лечение мне может быть не по зубам (а может даже и частичное).
4. Из всего, что Вы написали, мне почти ничего не ясно (да и не должно быть ясно, наверное), но обращу внимание на то, что у нас партионный учет и мы от него пока не готовы отказаться, так как это требование партнеров. Мы отслеживаем какую запчасть (из какой партии) установили в конкретный ремонт.
5. Насколько я понимаю наш учет - у нас нет "многофирмовости". Расчетных счетов разных ФОПов-ООО - да, несколько, но весь этот учет (как я уже писал) - в первую очередь CRM-ка. И у нас нет процессов, где мы анализируем движения по разным ФОПам-ООО. Только деньги заходят по разным расчетным счетам, чтобы видеть в базе актуальные остатки на счетах. Все остальное - единый процесс и привязки к конкретной фирме в учете - не нужны.
6. Поскольку я не мог рисковать, я уже скорректировал индексы Кво и СуммаГРН. И мы работаем в такой базе. Перенос ТА сделал на 30.11. Поэтому времени немного есть. Буду искать компромиссное решение по сложности, правильности, срокам и бюджету.
7. А также, понимаю, что этим РГ1051 вопрос не ограничится. Поэтому буду рассматривать варианты решения и по другим регистрам.
Скорее всего - поэтапно (поскольку не Газпром и не Сбер).

Жду Ваших предложений (или отказа - как Вы решите). Только очень прошу - дайте знать, чтобы я понимал - чего мне делать дальше.
Спасибо.

С Уважением, ТС
   Злопчинский
 
204 - 29.09.21 - 20:05
(203) "4. Из всего, что Вы написали, мне почти ничего не ясно (да и не должно быть ясно, наверное), но обращу внимание на то, что у нас партионный учет и мы от него пока не готовы отказаться, так как это требование партнеров. Мы отслеживаем какую запчасть (из какой партии) установили в конкретный ремонт."
.
нету у вас никакого партионного учета судая по отчету по остаткам с разворотомпо партиям. М.б. какие-то товары комплектующмие вам партионка не нужна, поэтому такая кривизна. Выискивывать в отечте наобум где норм, где криво (а по моему беглому осмотру криво ВЕЗДЕ где есть расход) - так себе удовольствие.
   Злопчинский
 
205 - 29.09.21 - 20:05
(203) "Из всего, что Вы написали, мне почти ничего не ясно"
- что именно неясно, например. из того скрина по отчету по партионке , что я опубликовал?
   Злопчинский
 
206 - 29.09.21 - 20:07
(203) "5. Насколько я понимаю наш учет - у нас нет "многофирмовости...".
а зачем у вас в справочнике фирм заведеноа куча фирм (причем каких-то физиков)..?
   Злопчинский
 
207 - 29.09.21 - 20:08
Для начала разберитесь, почему в суммовом учете остатков у вас приход идет на одну сумму (себестоимость), а расход идет на другу сумму (скорее всего продажная?) - из-за этого у вас в т.ч. и пухнет регистр, т.к. остаток по сумме никогда не закрывается в ноль.
   Злопчинский
 
208 - 29.09.21 - 20:10
"Жду Ваших предложений"
- по уму чтобы было нормально - надо всю вашу базу и процессы переколбасить и переписать на нормальный учет. а для этого надо разбираться с вашими процессами - что, зачем, почему, как. и почему у вас такой трэш в учете. возможно на этот трэш никто не смотрит а какие-то отчеты собираются тупо по документам и этого хватает.
   Злопчинский
 
209 - 29.09.21 - 20:14
Поэтому лично у меня только одно предложение - оперативно купировать проблему - обрезать внештатно заведомо кривые данные по остаткам по регистру RG1051 (с ним более-менее понятно). Это даст время - если вам будет нужно - разбираться со всем ворохом проблем.
   Злопчинский
 
210 - 29.09.21 - 20:14
"..обрезать внештатно заведомо кривые данные по остаткам по регистру RG1051" - как я сделал в (185)
   Злопчинский
 
211 - 29.09.21 - 20:19
(203) "Мы отслеживаем какую запчасть (из какой партии) установили в конкретный ремонт."
- продемонстрируйте скриншотами как именно вы отслеживаете, начиная от документа прихода - перемещения по складам (если таковое есть) - передачи в ремонт (или как вы там жэто отражаете) и списанием из остатков по завершению ремонта и передачи клиенту (возможно и дальше где-то числится эти может быть до истечения гарантийного срока). Приведите скриншоты всей цепочки "отслеживания" - по документам и отчетам 9каковыми вы пользуетесь для отслеживания).
.
тогда может быть понятно, есть у вас партионный учет или нет.. Пока - могу ошибаться конечно - не вижу я его )(правда и пристально не смотрел, нахаляву смысла нет глубоко смотреть).
   Злопчинский
 
212 - 29.09.21 - 20:20
ну и судя по чисто интерфейсным вещам - формы документов выглядят ужасающе - вряд ли стоило ждать что внутри будет что-то аккуратное ;-)
   opus70
 
213 - 29.09.21 - 20:32
проще всего перейти на sql и не мучатся
   Злопчинский
 
214 - 29.09.21 - 21:01
(213) угу.
а там или ослик умрет или падишах сдохнет
   Злопчинский
 
215 - 29.09.21 - 21:08
Обрезать как в (185) - возьму с учетом потраченного времени здесь и на тест - 200$.
   Валерий111
 
216 - 29.09.21 - 21:23
Я сейчас перечитаю что Вы написали и попробую осознать (сквозь истерику внука ))).

А сейчас - просто информация.

Это какая-то жесть!!
Я посмотрел историю запчастей яяя_щетки_218191 и яяя_щетки_213731.  
Получается, что даже если пересорта по складу или партии нет, то в регистрах СуммаГрн и СуммаОсн остается НЕНУЛЕВОЙ остаток. И такой остаток возникает при КАЖДОЙ отгрузке. (регистры Кво и СуммаБезНДС - закрываются нормально).

Судя по всему, в базе как-то настроено так, что бухучет оперирует с индексом СуммаБезНДС и поэтому в бухучете никаких излишков ни по количеству, ни по сумме нет (при правильно выбранной партии). А в технологическом учете (в регистрах) при отгрузке со склада почему-то меняются значения индексов СуммаГрн и СуммаОсн. Им присваевается значение отпускной суммы из Внутренней Расходной Накладной. И по этим регистрам появляется плюсовой остаток (тогда как по регистру Кво и СуммаБезНДС - все нормально закрывается).
Надо анализировать код в документе Внутренняя Расходная Накладная. (и возможно - поправлять).
И потом перепровести все Документы "Внутрення расходная накладаная". Сразу много боков исчезнет (сорри за идиотскую идею - это я так, не думая сказанул).

Сейчас осознАю Ваше предложение. )))) Спасибо за него - в любом случае.
   Валерий111
 
217 - 29.09.21 - 22:24
(215)
Еще раз - спасибо за предложение!
Сумма вполне подъемная. И, в принципе, можем сойтись на этом варианте.

Но хочу кое-что уточнить (сорри за дилетантизм, но прошу понять).

Если я правильно понял, то в процессе работы не закрывается ряд регистров (скорее всего при отгрузке, но не факт).

И если я правильно понял, есть, как минимум, 3 причины почему это происходит:
1) Наши сотрудники косячат и выбирают не ту партию. То, что разрешены отрицательные остатки, очень этому попустительствует. Эта проблема у нас известна давно и я вижу что нет другого пути, чем запретить отрицательные остатки. Это достаточно частая проблема, но это больше ошибка, чем правило.
2) Наши сотрудники косячат и выбирают не тот склад. Также связано с разрешенными отрицательными остатками. Но есть и другая причина. Замечено, что при выборе неосновного склада в Расходной накладной происходит следующее: По бухучету запчасть списывается со склада, указанного в накладной, а по регистрам, почему-то, она списывается с основного склада. Эта проблема чуть менее частая.
3) Самая большая проблема, что при КАЖДОЙ отгрузке запчасти на платный ремонт (есть ее гарантийный) в индексах СуммаГрн и СуммаОсн подменяются данные. В результате: индексы Кво и СуммаБезНДС закрываются нормально, а в индексах СуммаГрн и СуммаОсн происходит накопление (на сумму наценки, по ходу). И это - не ошибка сотрудников. Это такой код написан. Почему - сложно сказать. Но ведь, если было получено 100 тыс деталей и потом отгружено 100 тыс деталей (на платный ремонт), то получается, что на каждой отгрузке
возникает запрограммированное накопление на двух индексах.

Наверняка, есть и другие причины. Но я, как минимум, вижу уже эти. И последняя из них должна создавать огромное количество незакрытых индексов.

У меня теперь есть такие вопросы по варианту "185" (ну, если тупо почистить записи где колво=0, как я выше описывал, то размер стал 1.2Гб)
1) почему останется так много (1,2Гб)?
2) Это значит, что все ненулевые остатки останутся в том же состоянии? (со спрятанными внутри незакрытыми накоплениями)? В том числе по позициям, в которых общее количество равно 0, но есть пересорт по партиям и сами партии ненулевые?
3) Как будет происходить процесс физически? Сколько времени он займет? При условии, что доступа на сервер нет и мы можем действовать только так: я архивирую базу, кидаю Вам, Вы фиксите проблему, архивируете базу, возвращаете мне. Если успеваем - я заливаю ее в актуальную директорию на сервере. Так можно? за 1,5 дня выходных (пол-субботы-воскресенье до 23:59) успеем? Вы работаете в выходные?



Для справки: Партионность у нас отслеживается не по учету, а в реальности. То есть: мы берем на складе запчасть, которая пришла по конкретной партии и ее же списываем по учету. Так делается не со всеми запчастями, но с бОльшим их числом. Так как нам на запчасть дают определенную гарантию. И в случае проблемы с этой запчастью устраиваются разборки. При разборках поднимается информация о партии.
Кроме того, некоторые бренды ведут у себя партионный учет (внимание!) НАШЕГО СКЛАДА. И мы в их учете (имеем доступ и обязаны) выбираем партию для запчасти, которую списываем. Поэтому вынуждены у себя в учете списывать ту же партию. Чтобы наш учет и учет бренда был синхронизирован по партиям.

Осознавать это не обязательно. Просто я не могу отказаться от партионного учета. (((
   Злопчинский
 
218 - 29.09.21 - 22:45
(216) "(регистры Кво и СуммаБезНДС - закрываются нормально)"
.
в большинстве случаев - да.
но у вас есть и отрицательные остатки по количеству, они тоже зависают незакрытыми (скорее всего таких мало и это некритично, т.е. это проблемы собственно не самого учета а дисциплины учета, или где-то мелкий косяк)
.
СуммаБезНДС - толде не всегда закрывается корректно (по беглому осмотру - в большинстве случаев - норм, но есть и кривые).
.
плюс к этому есть суммы зависшие в размере 0.001 - это уже конкретно косяк алгоритма.
   Ёпрст
 
219 - 29.09.21 - 22:46
(217) Для исправления, нужно создать с нуля цепочку документов -  весть процесс: приёмка-че там у вас еще- расход/выбытие. дЛя одной детали/одного склада/одной партии.
на примере этой цепочки исправить код модуля проведения этих доков.
Затем прибить итоги и движуху и перепровести базу. Усё.
И оно само станет как надо.
+исправить доки ввода останков от прошлой обрезки, выкинув лишнюю аналитику и зависший мусор
   Злопчинский
 
220 - 29.09.21 - 22:46
(216) "Им присваевается значение отпускной суммы из Внутренней Расходной Накладной. И по этим регистрам появляется плюсовой остаток "
- об этом я написал выше.
   Ёпрст
 
221 - 29.09.21 - 22:47
А кастрировать - это половинчатое решение, на пол года- два..
   Злопчинский
 
222 - 29.09.21 - 22:50
(217)
п.1 запретит работу без контроля остатков. иначе вы никогда не поймете - вот есть отрицательный остаток - это ошибка или так надо. работа с запретом "не контролировать остатки" - это всего лишь вопрос административно-организационной дисциплины и воли руководства. Выстраивается и лечится достаточно быстро. У меня (в онлайне) обычно на это уходит где-то неделя (с учетом того, что сами алгоритмы работают правильно). Т.е. включается нормальный режим работы. и все. ни вот сеголдня чуть-чуть, завтра -чуть-чуть, воттут вот срочно один раз можно без контроля - нет, так не катит. работать сразу правильно постоянно. Всё. Проблема исчезает. И это параовозом за собой тянет улучшение в связанных процессах.
   Злопчинский
 
223 - 29.09.21 - 22:52
(217)
п.2 - можно сразу сказать что это ошибка программы. но кто вас знает какие принципы у вас в процессы заложены, может так и надо/был такой замысел, только его не доработали? итого: - как выше я и другие писали - нужен нормальный рефакторинг/пересмотр/просмотр процесов и исправление алгоритмов. и нормализация работы. По тем объемам движенйи которые есть у вас - база у вас до гигабайта не дотянет СУММАРНО. а у вас там дестяток гигабайт. имеено из-за расхлябанности учета.
   Злопчинский
 
224 - 29.09.21 - 22:53
(217) п.3 - аналогично как п.2 - надо смотреть и понимать/разбираться что у вас задумано было, как оно должно быть (на ваш взягля) и править/делать как надо.
   Ёпрст
 
225 - 29.09.21 - 22:56
+219 ваш размер базы, перепроведётся весь, за пару часов, или меньше, если все регистры будут правильно закрываться
   Злопчинский
 
226 - 29.09.21 - 22:56
(217) "1) почему останется так много (1,2Гб)?"
- потому что вглубь не смотрел. 800 МБ - это заведомо неправильные данные, обнаруженные одним взглядом по которым понятно что их не должно быть (должен быть ноль). еще как минимум половина из оставшегося, а может и больше исчезнет, когда будет выправлен партионный учет (см. мой скрин). Плюс к этому еще куча уйдет когда будет исправлено движение по расходу по торговому учету (приход по торговоум есть, по расходу по торгвооум нет - но это навскидку осмотрено было - смотрите осбужденяи выше)
   Злопчинский
 
227 - 29.09.21 - 22:59
(217) "Это значит, что все ненулевые остатки останутся в том же состоянии? (со спрятанными внутри незакрытыми накоплениями)?" - да. вариант (185) - быстрый, хирургический, для купирования самых болезненных симптомов. основная проблема останется. Но такое купирование вполне может дать дельту времени на нормальные разборкрии и вы сможете проработать в привычной для себя концепции несколько месяцев, а может и год...
   Злопчинский
 
228 - 29.09.21 - 23:02
(217) "Как будет происходить процесс физически?"
как и происходил, даже базы скорее всего не понадобится. Обрезка по (185) будет сделана достаточно быстро. да, я работаю тогда когда это надо. и полтора дня мы тянуть не будем. Починим оперативно. С этим регистром проблема временно будет снята.
А дальше - как писал я про рефакторинг и как пишет здесь и сейчас Ёпрст - если вам нужно будет приводит в порядок чтобы это всегда работало нормально - это уже все отдельно, это другая работа, потому что там куча всего неприятного, все как писал я и Ёпрст.
   Злопчинский
 
229 - 29.09.21 - 23:06
(217) "Для справки: Партионность у нас отслеживается не по учету, а в реальности....."
Партионку сейчас не трогаем. Потому что то что вы говорите - это нормально, но то что я видел в базе - это не соответствует тому что вы говорите (возможно ясмотрел кривые варианты ну вот так на них попал почему-то, просто тупо потому что без обрезки мне дажне не удалось получить ваш штатный отчет по остаткам до партий - прога тупо падала из-за нехватки памяти, поэтому я взял часть котоая подвернулась под руку и смотрел по ней - а поней все криво. скорее всего криво и по остальным). Поэтому надо разбираться. Как я выше написал чтобы вы протянули всю цепочку обслуживания по какому/либо материалу/запчасти по партионному учету начиная с прихода и заканчивая полным списанием с торгового баланса. (Епрст в принипе чуть выше то же самое написал).
   Злопчинский
 
230 - 29.09.21 - 23:07
(217) Вполне возможно, что по основному массиву учета ваших запчастей партионка норпмальная, но это надо смотреть и это отдельная задача.
 
 
   Злопчинский
 
231 - 29.09.21 - 23:09
Как написано в (225) при исправлении косяков алгоритмов при том объеме движенйи которые зарегистрированы в базе - база будет небольшая  и пересчитать ее не представит труда. Но это отдельная задача. так как могут возникнуть административно-организационные трудности - например кривые данные где-то уже зафиксированы и их нельзя исправлять...
   Злопчинский
 
232 - 29.09.21 - 23:11
Общий процесс "рефакторинга" описан учитиелем (да продлятся его годы на благо клюшечников) в (219)
   Валерий111
 
233 - 29.09.21 - 23:12
(219) (225)

понимаю всю правильность и согласен с таким подходом. Но есть 2 "но": 1 - бюджет, 2 - негде взять еще полгода жизни. Так как кроме меня никто в этом разбираться с программистом не будет. Но, вполне возможно, через какое-то время напряги попустят и я смогу этим заняться. Я на прошлую обрезку потратил месяца три на осознание и сотрудничество со специалистом. А тут задача явно покруче. Хотя... может я ошибаюсь.
   Злопчинский
 
234 - 29.09.21 - 23:23
(233) все что надо для "мпециалиста"с - вменяемое изложение вашего процесса от входа до выхода.
что вы обычно делает, с какой целью/зачем/почему, что на входе каждого шага, что на выходе. найти два раза по полдня чтобы все это описать на уровне рисунков записей от руки на бумаге и/или скриншотами документов/отчетов - вполне возможно. дальше - дело техники, когда понятно "как должно быть" - сделать "что надо" - задача не такая уж и сложная. А спецы которые взяли аванс и сгинули - ну кому приятно в гуано копаться ;-) А аванс забрали как компенсация за моральный ущерб ;-)
   Злопчинский
 
235 - 29.09.21 - 23:25
Финишный раз - вариант (185) - привести пациента в чувство, чтобы не загнулся по дороге в больницу...
я на связи, личка в профиле.
   Валерий111
 
236 - 29.09.21 - 23:31
(222) (223) (224)
согласен с идеологией. Но до этого надо дозреть и по времени, и финансово. Я даже не понимаю бюджета этой задачи (даже если исправлять только баг№3).

(227)
понял

(228)
не понял. Что значит не нужна база? А как же резать? Сорри, я дилетант и не понимаю.
   Злопчинский
 
237 - 29.09.21 - 23:33
(236) нужен один файлик, его и "порежем".. ;-)
  1  2  3

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