Сразу предупреждаю: я не программист 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 осталось совсем мало времени.

Экономьте дальше

(0) > я не программист

А что произошло с теми, кто написал вам немеряно кода для специфического Технологического учета (для работы СЦ)?

Здравствуйте, Dmitry1C.

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

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

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

То о какой экономии Вы говорите?

(0) > я не программист А что произошло с теми, кто написал вам немеряно кода для специфического Технологического учета (для работы СЦ)?

С этими людьми связи нет давно. Мне это предприятие с базой досталось в "наследство" от предыдущего директора (он умер, поэтому все его связи утеряны).

1. Сделайте архив.
2. Проверьте архив.
3. Откройте в личной карточке контакты и вам смогут написать те, кто в состоянии решить вашу задачу.

Спасибо.
Контакты открыл.
Не совсем понял - что значит "проверить архив"?

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

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

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

(1) (2) (5)

Сорри. )))
Сначала не разобрался как писать ответ на пост.
Поэтому просто писал сообщениями.
Теперь понял.

(3) ну сделайте еще обрезку. в чем проблема? А лучше вообще заведите чистую базу и начните с нуля. Мы когда работали в 7.7, каждый год это делали, 2-3 января работники делали инвентаризацию и в новую базу заносили реальные остатки товара. А у вас что-то целых 4 года без обрезки - это конечно круто, но зачем так над собой издеваться?

(8): бред какой. номенклаторы, контриков, прочую нси.
(0): див.мило

(8)
Именно сейчас: обрезка - не вариант. Большой кусок кода - технологический учет. Там есть особенность. В отличии от обычной 1-С, где есть только операция, после которой меняются счета и регистры, тут, в технологическом учете есть ПРОЦЕССЫ. Они растянуты во времени и их обрезать на середине - нереально.
Поэтому предыдущий программист обрезал базу 4 МЕСЯЦА. И то, полностью не обрезал.
И я бы согласился еще на одну обрезку (если бы кто-то сделал ее нормально). Но до 1.10.2021 ее никто не сделает. Поэтому надо сначала применить временное решение, а потом - правильное и глобальное.

Поэтому я и спрашиваю в топике: нормальное ли это временное решение? Не будет ли проблемы с базой от такого действия? Спрашиваю у экспертов.
Спасибо за ответ.

(9)

как можно понять Ваш коммент "див.мило"?

(0)
Огласите размер RA этого регистра

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

ЗЫ: уменьшать разрядность ресурсов нужно с умом, можете запосто нарваться на переполнение разряда в вычислениях, ну или исказить данные.
Сперва нужно было посмотреть, какое мак число содержится в каждом ресурсе.

(8)
уточню.
В данном случае 1-С - не столько 1-С, сколько специфическая CRM, встроенная в 1-С. Мы с 10 лет с ней работали нормально. Все операции, все процессы , вся история доступны и для аналитики, и для сбора статистики.

(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 не перенесется.

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

Если нужна дополнительная информация - подскажите, пожалуйста, куда мне посмотреть и я посмотрю.

(3) наличие старых документов после обрезки не есть признак неправильности обрезки, точно так же как и партии

(14)

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

(14) решение так себе, вы не проверили значения ресурсов в файле перед уменьшением разрядности.

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

(15)
я согласен с Вами. Но там получилось все очень странно. Так как у нас есть еще много документов, которые формируются именно технологическим учетом.

ну а пока, нужны ответы на (12)

И да.. риб есть ?

У вас проблемы в ваших процессах. Отсюда проблема в учете. Отсюда проблема в упомянутом регистре. Это регистр итогов, соответствующий ему с таким же числовым суффиксом регистр движений RA. В норме таблица движений должна быть в несколько раз/на порядок (а то может и больше) быть меньше таблицы итогов.

У вас ситуация когда вы приход пишите по одному набору аналитических показателей (измерения), а расход по другому набору и в вас расход не закрывает приход, что ведёт к эскалации размера файла итогов.

(16)
СПАСИБО!!! Сделаю чуть позже.
Прямо сейчас нет доступа.

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

(19)
что такое "риб"? (((

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

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

Вроде так когда-то делал )

(20)
(21)
Наверняка Вы правы. И я очень хочу сделать НОРМАЛЬНО. Но до 1.10.21 осталось совсем ничего. А работать надо. Так как для нас это не просто учет. Это кровеносная система. Ее останавливать нельзя.

У (21) кстати был отчет смотреть какие регистры не закрываются еще на проклабе, сейчас на инфостарте.

(24) Еще вариант.
Сделать "псевдо закрытие месяца", которое будет закрывать все незакрытые остатки.

Но это костыль.

(18) да и пофиг. Прог сделал обрезку. Итогом обрезки стали некие входные остатки, в которых упоминаются старые документы и партии. А в виду незакрытости регистра такого гуана м.б. тонны. И с этим Программисту ничего не сделать. Вы так построили учет. Криво. Горбатого только могила исправит. Чтобы выправить ваш горб придется либо самому въезжать в ваши процессы и их отражение в базе либо платить денег и вполне возможно много.

(23) (25)

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

Я пытаюсь сейчас продлить "искусственную кому" нашей 1-С, в которой мы все же продолжим работать, и заняться поиском хорошего исполнителя и нормального решения.

Без ответа на (12) всё мимо денег.
Если не знаете, что есть РИБ, значит, у вас его нет.

(22) то что сейчас нет доступа - это очень херово. Грубо говоря куроводству похрен на бесперебойность процесса работы. Поэтому не переживайте, ну не получится 01.10 переползти на новый месяц ди и хрен с ним, за пару дней неделю разберетесь, позерачат ручками вручную, потом поеб соррм потрахаетесь занося данные ща период простоя. Потом куроводству может станет понятно что доступ должен быть всегда. Ибо нехер.

И да, слушайте Ëпрст, он мегагуру

(28) Ну тогда приглашайте специалиста на удаленку.
Тут для знающего человека работа, а не по советам тыкать мышкой )

Как минимум тут 2 специалиста, которые вам точно помогут и им можно доверять.

(28) найдите время. Десять лет времени не было - может пора ч обычно было?

(3) об экономии на переходе на 1с8

(27)
Наверняка учет кривой. Но его надо ровнять. Может не весь сразу. А по частям. Но 15 лет эта база тянула. И одну обрезку пережила (4 года назад). Но кто знал, что через 4 года вылезет новая проблема?
Возможно - найдется кто-то, кто разберется в наших процессах-регистрах. За деньги.

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

(31)
Слушаю. И чувствую уровень.

(29)

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

ответы на 12 - поищу.

(32)
так оно и будет. Но тут главное - не остановиться. Это и пытаюсь сделать: не остановиться и заняться правильным решением

Любое решение которое не ломает систему и позволяет получить отсрочку - нормальное

Возьми несколько архивов базы если они есть и посмотри на сколько прыгал прирост РГ при открытии  месяца. Но с каждым разом прирост при незакрытых регистрах увеличивается

Запасаемся попкорном и колой ;-)

Предполагаю размер RA  в районе 500 Мб

(34)
У нас к 1-С дописан спецучет. Типа CRM. Вес функционал в 10 раз больше, чем 1-С. Переходить на 8-ку - это вырезать весь код и данные по этому спецучету и пришить к 8-ке. Это как отрезать половину тела и пришить к другой половине.

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

Кроме того, так как уважаемые эксперты уже поставили основной диагноз: "криво написанный учет", то какая разница - к чему этот кривой учет пришивать: к 7-ке или 8-ке? Бока останутся те же, так как созданы (судя по всему) этим дополнительным учетом.

(42) тут есть несколько моментов
а) лечить 77 - таких саксаулов уже мало осталось.
б) возможно, грамотные люди подскажут уже готовую конфигурацию на 8, где нужно будет (возможно) расставить только галки в нужном порядке. Хотя (не сочти за наезд) на Украине в учёте может быть всё, что угодно...

(42) вы бюджет на лечение озвучьте, может и врачи найдутся.

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

бюджет, бюджет... все упирается в бюджет

Учёт может и норм, просто в один прекрасный день какой-то поц перестал делать некие действия, напрямую к оперативным процессам они не относятся, но их делать надо. И все, жопа..

>>основной диагноз: "криво написанный учет",

нет, тут тотальная экономия на "Так как для нас это не просто учет. Это кровеносная система"

Распространённая хрень - может и у вас быть - работа от нескольких фирм на базе "общих" остатков.
+100 на одну фирму и -100 от другой фирмы нуля не дают!!! Это как частный пример незакрытого

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

(48) все не так просто может оказаться. +100 и -25 -35 -40 и трындец "взаимности".

а разобрались что эт воще за регистр (парусске)? а вдрух он оборотный?

(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

(29)

Это оно?

(40)
Надеюсь Вы не обиделись на шутку про попкорн? ))

(52) А RG1051 где?

(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      

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


Сорри, буду немного оффлайн.

При таком размере Ра 70 мб размер рг д. Б. Мегабайт 20

Наценку точно можно убрать/перенести, но это не особо поможет.

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

Из решения влоб.
Убрать партии, переделать отчеты с партиями на среднее, списание на среднее или закрытие месяца.

Регистр то простенький, или приход по одним фирмам и расход по другим или приход с указанием партий и списание без. И то и другое вылечить несложно, странно что топикстартер до сих пор не нашел программера, который бы это исправил.

Скорее всего
- многофирменный незакрытый учет
- возможно отключен контроль остатков
- могли ещё и Наценку в ресурс регистра запихнуть

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

(59) с наценкой - очень может быть что это ресурс, который не закрывается, и по ней все эти остатки и накопились

(0) >База 1-С Предприятие 7.7 АБТ 3 ПРОФ (3.5.4) (база ДБФ и переход на скул не предвидится).
Вы бы посчитали на всякий случай, сколько переход на SQL-базу будет стоить.
А то столько усилий, которые можно решить однократной покупкой лицензии

(52) да оно.
Тут или приход с одной фирмой, расход по другой фирме, или партию при расходе неверно указывают. Или приход на один склад, расход с другого склада.



У вас многофирменный учет ?
Всё  это не так и долго проверяется, достаточно посмотреть движения приходных и расходных документов по одному тмц.

И да, при таком размере RA, ваш RG должен быть метров 20 или 10.

Но никак не 2 Гб

И резать ресурсы не обязательно.

(58)
Топикстартер не искал такого программиста. Потому что топикстартер не видел этой проблемы ранее. )))

(63)

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

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

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

(57)

Спасибо за идею. Наверное косяк в партиях.
Но отказаться от партионного учета пока не можем. Это требуется для работы с поставщиками.

(68) поиск проблемы, минут 10. Устранение - это или обрезка или перенос существующей аналитики в реквизит регистра, если останки по неверным измерениям не нужны.
Итого, пол дня на всё с учетом переписывания участков кода.
Обрезать бездумно ресурсы не стоит. Сперва нужно найти в каждом из них максимальное число, чтоб оценить степень урезания. И запас должен быть. Ибо при сложении, например, выйдет 99999, например, т.е переполнение разряда

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

(70)

А Вы можете написать мне в вайбер/телеграм/вацап? я свой номер оставил. Или на почту.

(70): не забудь про переписывание всех(!) запросов по остаткам, в которых юзается разрез измерения, которое переносится в реквизит. а это может оказаться немало кода.

(0) А у вас этот Регистр не оборотный случаем?
Может тогда Периодичность уменьшить? Скажем Если у вас стоит месяц, то поставить Квартал. Размер регистра при этом думаю уменьшится.
Но отчеты, возможно, медленнее формироваться будут.

(74) И у вас остатки в разрезе ваших фирм (не одной?)

И да, периодичность регистра остатков тоже может быть изменена, Если у вас стоит 5,10,15 дней, то можно установить на Месяц

(74) Если бы регистр был оборотный - файл итогов при "максимальном незакрытии" был бы плюс-минус такой же по размерам, как файл движений (добавилось поле период, убавились поля реквизитов).

(0) возьми где-нибудь обработку gerprint.ert, сделай отчет по этому регистру за месяц (любой), и кинь эту простынь на какой-нибудь файлообменник. посмотрим.

(77) Ну тогда стоит проверить (76).
Возможно у (0) стоит не Месяц

(79) судя по тому, что ТС оперирует месяцами - периодичность месяц.
+(78) regprint, конечно же...
https://drive.google.com/file/d/1LKQD33E4lMnBUQPDetbS_zpyYfzGW0Dd/view?usp=sharing, https://drive.google.com/file/d/1R1Ncz7yK1Z48B5VDsOHyPID8TM0ngZmx/view?usp=sharing

И если не ведется многофирменный учет, то возможно попробовать избавиться от измерения "Фирма".
Как вариант попробовать назначить этому реквизиту тип Число(1)

Еще вариант проверить наличие признака "Быстрая обработка движений" так как при его наличии в таблице движений появляется дополнительной поле.

(82) и ? оно появляется табличке движений.
Никакого отношения к итогам.
В итогах, только если стоит отбор итогов в одном из измерений.
И то, на рост RG это особо не повлияет

Есть ещё подозрение что итоги убежали либо за 21 год либо к 0000.
Было раз такое.
Автор сделайте копию.
Удалите на копии все файлы rg*. *
Запустите 1с. Она ругнется на создание файлов. Закройте. Запустите конфигуратор.
В нем тестирование и исправление со всеми галками.


Если после тестирования файл уменьшится то проблема решена. Если нет надо разбираться с закрытием данных

Автор, никогда не делай (84).
Только если у тебя куча свободного времени и не жалко базу терять.

(82) а растут - итоги. Так что "быстаря обработка" не при делах.
(84)  ну вот нахрена так делать?

(85) Потеря базы то причем? На копии делать.

А сделать т.к. раз было, что из-за сбоя Итоги улетели за 2050 год. И файл RG распух.
Еще из-за кривой обрезки могли остаться в нем старые данные.
на 70 мег движений 2гига не закрытых за 4 года плохо верится.

(85), (87) Итоги из движений заново создадутся. Ничего не должно потеряться. Но времени много уйдет, это да.

(88) ну так сначала нужно посмотреть на эти итоги, а уж затем рекомендовать человеку операцию, которая займет фиг знает сколько времени и с неизвестным результатом...

(89) Я предложил это сделать на копии.
И сидеть и пялить в монитор тут не требуется.
Запустил и пытайся найти решение другое.

У автора нет ресурса знаний, а время есть.
Согласен, что результат и сутки может не просчитать, но из опыта, на нормальном десктопном железе не более 2-3 часов.
И будет по крайней мере результат может отрицательный, но может и положительный.

+(90) Согласен.

(91) Иногда неожиданный вариант может дать результат.

Из быстрого решения кидаете мне МД или любому прогу. Пишется обработку или берется готовая выводящую полный отчет по остаткам присылаете остатки.
Согласовываем условие сворачивания измерения. Делается документ который заполняется по этим условиям и сворачивает остатки.
Пишется обработка которая создает данный документ на последние число каждого месяца. Запускаем и через час размер файла в 10 раз меньше.
В течение дня все легко делается. Потом не спеша разбираемся где, что не правильно закрывается и почему как это исправить.
Если этот регистр двигает пару документов и алгоритм не слишком запутанный то можно сразу это сделать.

(85)
Я сам больше ничего делать не смогу (и особо не считаю правильным).
Я бы доверился специалисту. За оплату.

(92) тогда нужно посоветовать посадить за клавиатуру обезъяну. Как известно, есть ненулевая вероятность, что таковая за бесконечное количество времени напишет "войну и мир"...

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

в 77 в таблице итогов удалить все записи с нулевыми ресурсами (почему-то они остаются и не упаковываются).
грохать движения опасно.
ЗЫ
но это должен делать не ТС.

(97) нулевые ресурсы появляются, если в заднем числе залезть и поправить "чтоб закрылось". Штатно открытие периода не переносит на след. период остатки, у которых все ресурсы нулевые. а "почему" - вполне понятно и объяснимо.

(94) надо базу смотреть.... можешь копию показать?

(97) регистр резакрыт, причем тотально. Чистка нулевых итогов ничего не даст  просто потому что там их нет

шо, опять ?

ps: И таки да. Просто имейте ввиду, что вы общаетесь с "директором, который кое-что понимает в программировании".


https://pro1c.org.ua/index.php?act=work&do=details&order=498&tab=0

(101) Таки да.
Он же ж и пищет что повторно необходимость резать возникает

(102) "Ох уж эти херурги™, всё бы им "резать"... Ты, сынок, попрыгай - они сами отвалятся..."©

(102) резать комплексную (производство плюс зарплата плюс бухгалтерия), да еще комплексную украинскую - это далеко не такое же удовольствие, что резать нашу любимую ТИС.
Да еще не типовую, а в усмерть дописанную/переписанную  комплексную.

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

(99)
я с удовольствием. А как это сделать? На сервер пустить не могу. А так - могу попробовать скинуть на файлообменник. Только она неархивированная - 18 гиг.

(105) лучше всего полностью заархивировать всю папку с базой и выложить на файлообменник, 18 Гиг свернется в мегабайт 300
ссылку на файлообменник имхо лучше в открытом доступе не публиковать, чтобы базу все кому ни попадя не рылись.
скинь ссылку на файлообменник и мне на почту (мыло в личке)

(101) (102)

это таки я.
Но резать или не резать - это не столько мое желание, сколько мое плохое понимание - А что же делать? Если вопрос решается лечением, то я бы лучше лечил, чем резал. Но в предыдущий раз меня программисты сориентировали на обрезание. И я поверил и поставил задачу "подрезать" (к исполнителю претензий нет - он выполнял то, что я просил).
Это сейчас я чууууточку больше понимаю ситуацию (или мне так кажется). И сейчас мне кажется, что проблема больших файлов базы может решиться не обрезанием, а оптимизацией (чему я очень рад, так как для меня обрезание базы - это очень плохо и его надо всячески избегать).

(104)
В базе не считается зарплата. Не считаются налоги. Тут только взаиморасчеты с контрагентами (подотчет в том числе). Учет производства (дописанный технологический учет). Склад, касса, банк. Учет затрат (примитивный) и ОС (без амортизаций). Как бухгалтерия используется мало. В основном - учет производства (и вытекающих из него взаиморасчетов).

Но еще раз: резать не хочу. Для нас это - CRM, и чем больше там история - тем лучше. Поэтому я - за избирательную оптимизацию без обрезания.

(106)
Попробую успеть. Так как в 00 часов запускается "бекапирование" некоторых данных.

(107) Мне тое в почту слей линк на архив - поглядеть.

Поправить в коде регистрацию движений по остаткам ТМЦ с указанием пустой фирмы (вместо конкретной, выше похожий рецепт давали с переводом измерения "фирма" в "число"). В регистре по остаткам будет "пустая фирма". Инфа по остаткам будет только в целом по предприятию. тупо отключить все контроли настройками и перепровести базу. как-то так если делать тупо и быстро. может прокатить..

(108) а чего там успевать? копирнуть папку базу в сторону, и там уже заархивировать.

(109) https://content.screencast.com/users/Che66/folders/Capture/media/71ccaae7-ba4f-4ce7-a784-dbb8696048b2/LWR_Recording.png

(112) Бггг ... Welcome to the real world

(111)
эмммм...   я архивирую средствами конфигуратора 1С
или не так?

(114) Каталог с базой твоей рабочей целиком скопируй куда нибудь.
Это полученную копию заархивируй раром или 7 зипом или зипом, чем ты там пользуешься
Заархивированный файл выложи на яндекс или маил диск или ондрайв или еще куда
Ссылку на вылоенное мне и Злопу на почту

(114) хрен его знает что там понапихано у вас в базу. средствами поифгуратора (хз что у вас там включено в состав копии) - обычно минимальный набор, гарантирующий целостность данных. но это необязательно гарантирует работоспособность базы.

(115) (116)

Понял. Архивирую просто папку целиком.

(115) ладно я, мамонт клюшечный, а тебе-то это зачем? поржать перед сном? ;-)

(118) Эммм ... Ващет я такой же мамонт клюшечный

(119) от жеж повылазило...

(120) А ты чо думал ;)

(115) (116)

https://dropmefiles.com/ - норм?

Сойдет

(115) (116)

ушлО

Пока - спасибо, что решили посмотреть.

Меня сутки не будет (командировка). Реагировать смогу только со среды.

(124) ну и мы не подписывались пока что.. ;-)

(124) ну и мне тогда скинь... Поболтаю ерундой. Тьфу, то есть тряхну стариной...

(125)

я все понимаю. В любом случае - спасибо, так как на меня Вы уже время потратили.

(126)
а куда скидывать? А то я почты не вижу.
Вижу номер, но не понимаю - что это.

(128) мой ник на мэйл.ру

(129)

если я не совсем тупой - должно придти.

всем сочувствующим - большое СПАСИБО.

Всё.. Кинг - отдыхает...
там тотально по регистрам всё незакрыто...
Наценка - в ресурсах...

наценка в ресурсах - м.б. и некритично, если там везде нули...

(133) Наценка там везде 0
по фирме у него не закрывается регистр
приход на пустую фирму, расход со специалиста ...

https://ibb.co/gD1kmC8
Вон в приходе пустая фирма и заполненная фирма, в расходе только заполненная

(134) там все хуже.
по Регистру остатки
Приход на 1. пустую фирму (тороговый учет как я понял) 2. и на конкретную фирму (бухучет как я понял).
расход внутренний - только по фирме.
плюс к этому ресурсы по расходу СуммаГрн/СуммаОсн - совершенно не соответсвуют сумма прихода. СуммаБез НДС в основном та же самая (соответствует), но тоже есть криво. Плюс к этому есть расход больше чем приход, тоже повисает (это не было бы так страшно если иное).
К свертке на конец 2015г - пртензий нет. все отрицательные суммы висят в остатках... ;-)
Регпринтом удалось развернуть движения только за первый месяц после свертки, остальное - регпринт валится по нехватке памяти при выводе, бо все висит в остатках....
.
Второй подбирающийся к пределу регистр.Приемка - там тоже интересно...

Странно что он про остатки ничего не сказал, там дикий трэш должен быть

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

(136) Да суммы эти вторичны, пока не закроются регистры по измерениям и по количеству

(137) по количеству более менее в ноль уходит, а по суммам - ну хз как там отчеты считают...

(136) там еще и спроводками тоже лажа - не смотрел но файло 1SBKTTL 1,3 гб

Чтобы этот треш вычистить - тупо механическими движениями не получится. можно тупо подрезать прямыми запросами или даже тупо фильтрануть в любом редакторе таблицу итогов по значению Количество=0 (суммы ненулевые) и тупо делетнуть эти записи. для этого регистра остатков это будет мегапросто и действенно - приняв командирским решением что остатки ТМЦ где колво = 0 - там и суммы по логике д.б. = 0

(139) ну хотя бы подрежутся по фирме "Сепециалист"

(142) Вариант с реанимацией, но опять копиться будут движняки
Надо дорабатывать базу - или вырезать эту "пустую" фирму в приходе или во внутрянке, в движениях, ее добавлять
Соответственнно логику поднимать - накой она там вообще такая

Чтобы это все нормально закрыть - это надо в весь процесс въехать, там таких регистров распухших - десяток

(144) ну да.

(145) Три регистра и таблица проводок

(144) пустая фирма, это типа УПР учет, "по всем фирмам в целом" - насколько я понял.

(147) остальные регистры не такие большие, но точно такие же распухшие.

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

(148) Никогда не понимаю этот "упр" учет реализованный через жопито
Убрать его нафиг а отчеты строить по всем юрлицам

(150) Рухнула по памяти на момен формирования таблицы выходной, за период 01.07.21 по 30.09.21 он 450к+ записей запросом прожевал у меня

(151) не, имеет смысл, сразу консолидированные данные получаются.

(153) Да сколько не работаю с заказчиками - если и хотят видеть общие суммы то обяязаельно с разбивкой по юрлицам конкретным
так что польза от этой консолидации эфемерна в сухом остатке, а гемора и головняка полно

если остатки хирургически тупо по полевому подрезать - очень быстро вылезет этот регистр.Приемка...

(154) не столь существенно. при нормальных записях движений позволяет легче всякие вещи получать, без вычитания межфирменных движений. то бишь можно и так и так. Вобщем с тобйо согласен, на моей памяти консолидированный учет по холдингу не пригождался. да и в типовых на 77 он после ТиС 8.7 отвалился, в 9.2 его уже не было.

(155) так решение то комплекское должно быть а не только по этому регистру остатков
надо шерстить логику работы базулины, править ее
приводить в порядок итоги по регистрам и накатывать обновление правленное

и фообще непоняоно по этому РГ1051. мне цвиамшуц показл больше 19 млн записей. ограничение вроде на 16 млн...

(157) это понятно, сложного там особо ничего нет. сидеть и тупо долбить процесс. продолбив - прошерстить и поправить движуху по регитсрам, а это уже может вылиться в хз что, например, если по суммам расхода которые не закрываются с сумами прихода строятся какие-то отчеты.. )

(158) там codebase движок, который 1с перезватила у не помню кого для управления базой 7ки после 16 млн уже не гарантирует работоспособность
а как оно там будет по факту ... может и на 17 свалиться и до 20 дотянуть

(159) Ну посмотрим сколько ТС готов отмусолить за ... ;)

из 19 млн записей в итогах тупо хирургически 7.6млн с колво=0

плюс надо смотреть какими доками этот регистр двигается на приход/расход.

(161) смотри, 500 тыс тебе, 400 тыс мне, за 100 тыс - немца наймем...

(164) Ништяк !

По сути - надо делать аудит базы что там как они делают/работают  по процессам, рефакторить код чтобы было правильно, потом пересчитать базу - что может оказаться невозможным по ряду нетихнических в т.ч. причин.
.
я теперь понимаю почему двое взяли аванс и исчезли - весь аванс ушел на лекарства.. ;-)

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

этот еще, с диванами, блин... УТ 11. Купили диваны...

блин, надо было эти пустые записи вырезку - базу на ссд положить...

(166) Забухали чтоль ? ))))))
Я в свое время писал обработку спецуевую и правил модули проведения, на момент лечения
Обработка тупо в файлы в raw выгружала движения документов, типа как файл обмена если есть риб, движения в файлах правились, и документы проводились считывая данные с файлов и формируя движения по ним
потом эта заглушка убиралась, оставалось дернуть ТА взад вперед

(169) ;DDD есть чем заняться в волвторого ночи

(171) не, заради интереса. ща пустые колва зарежу, потом эту пустую фирму.
бухпрводки по разделителю "Фирма" формируются.

(172) эммм ... щас так реанимируешь базу )))

не, все-таки клюшки - зачетная система.
ТиС 9.2 смотришь - ну блин все же понятно. код няшный.
даже тот же самый ПУБ в одной конторе был мне как-то раз попался - тоже в целом все понятно.

по уму надо вопрос с 400, 500 и немцем решить сначала

(174) ПУБ исковеркан по сравнению с Тисом, один общий ЖР что стоит с отборами

1SQlite это все вообще быстро почистить можно (умеет удалять), я тупо пока... плоскогубцами...

(175) хз, как воспримет это папаша Дорсетт ;-)

(174) у снеговика код лучше, но вот типовые....

Со всей это галиматьи хоть один плюс точно есть - я на рабочий стол себе Rainlendar повесил, давно собирался...

(179) Лучше - в смысле "больше" ;-)

(179) правда и в ТиС типовой есть ошибки, которые за 20 лет не поправили ;-) Одна из них - отчет по остаткам если включить показ остатков у комиссионеров- там кусок кода отсутствует для пересчета юазовые/основные (кривые цифры будут при задании отчета в основных единицах)

(182) клюшечные типовые никому в 1С не сдались... через несколько лет и УПП скоро снимут с поддержки.

Ситуация примерно такая. https://postimg.cc/t1m3pDfW. База не резанная с 2016 года. Обрезана с очисткой 0 количества или нет. Не знаю, видел только мдшник базы и остатки на сейчас. Не сильно вникая и разбираясь с логикой проведения для начала решил просто обнулить суммы там где количество = 0 стандартными 1с-ными методами.
Заполнил такой документ на 31.06.16. документ начал заполняться и проводиться в 20-30 успел он это сделать до 00 не знаю. в 22-30 еще что то считал.
Вижу как минимум, что еще можно схлопывать позиции типа яяя_щеткиремонт_221172 которые приходовались на склад платный, а списывались со склада платные услуги.
Непонятно почему так долго думает или сервак медленный или копия базы лежит на обычном винте, а не ссд.

ну, если тупо почистить записи где колво=0, как я выше описывал, то размер стал 1.2Гб

(185) правда я не особо представляю что при этом будут давать отчеты по остаткам/движениям (?), по идее д.б. все норм...

Плюс к этому остатки тупо жутчайше не закрыты по партиям, типовая картина
https://content.screencast.com/users/Che66/folders/Capture/media/ac977f6e-fb61-4daf-a58f-9d58c1e420fd/LWR_Recording.png
и это не только по группе "удаленные", это (бегло глянул) по всем так, приход на партию, списание с "кривой" партии "по умолчанию"....

(187) ну и сделай update таблички RA на партию по-умолчанию и пересчитай итоги, делов то, один хрен не пользуются партионкой

(188) Это типа комплексная база они там и бухию ведут, могут вести. Хотя если автор на вопрос можете назвать позицию по которой известен остаток говорит, что нужно провести инвентаризацию... То впечатление такое, что они там просто документы печатают и можно не только партии но и склады и фирмами на ноль помножить... сжатие до 1,2 метров даст им возможность спокойно доработать до конца года. А так в целом им нужен постановщик учета на месте который наведет порядки и расскажет, что и как нужно вести и отражать в базе. Основная проблема не в базе, а в том, что документы оформляются как хочется правой пятке.

Граница последовательности не восстанавливалась никогда. Даже при разрешенных отрицательных остатках все было бы гораздо лучше если бы это хотя бы периодически делали.

Проводки по пустой фирме и фирмам настраиваются в базе константой и реквизитом в справочнике фирма. Аналогично партии до средневзвешенных сворачиваются. Но там есть нюансы если это делать заложенными в платформе механизмами за тронутся и взаиморасчеты. А там точно при любом учете нужно знать, что компания "А" холдингу должна 10 тыс. из них 3 тысячи фирме "Х" и 7 фирме "У". Реальные минуса ТМЦ в любом случае закрываются, надо просто пользователей заставить такие документы вводить не когда им хочется, а когда надо. Дав им инструмент помогающий с этим.

(136) Регистр Приемка вообще только в 1 документе используется и выполняется движение приход по нему. Внутри конфигурации отчетов по нему не увидел, может какие то внешние есть. Его тупо в оборотный надо переводить или удалять если нет отчетов по нему то смысл в нем, ну или эти отчеты поправить на оборотном регистре или тупо по 1 документу который его двигает отчеты строить. С учетом, что там у всех реквизитов длинна 1 уже поле 9 документа, по каким то ресурсам он уходит в переполнение и тупо отражает факт Приемки.

(192) Видимо недопиленная попытка вести учет принятого чужого товара

(184) >>Непонятно почему так долго думает

А что там непонятного? Помимо того, что сам код проведения может занять большое время, так ещё твое обнуление надо протянуть через ~60 последующих месяцев с пересчетом итогов по каждому из них. Это если у тебя период итогов "месяц", а если "5 дней" так и все 360.
Если уж типовыми средствами, то сначала ТА на документ лучше было двинуть.

(194) Потом его вперед все равно с пересчетом итогов за тоже самое время в наше время двигать.

(195) Да. Только руками - 60 пересчетов. А автоматом: 60+59+58+...=1770 пересчетов (или типа того). А вот что оптимальнее в твоем случае - это уж смотри. Я попытался объяснить в чем может проблема с долгим проведением.

А вообще возможны же неочевидные варианты: помимо периода итогов, неоптимального кода, железа, незакрытых регистров - есть ещё и галки "Быстрая обработка движений", "Отбор движений" и "Отбор итогов".
И, не знаю, как в ОУ, а у клиента было: 1000 проводок у документа "Начисление амортизации" записывалось за пару минут, а 10000 за 12 часов.

Чувствую все ограничится типа (185) и все. Думать некогда, трясти надо!

(197) Согласен. Или поднять на виртуалке 2003 сервак накатить на него 2000 скл. и базу в скл переделать и забыть. За оставшиеся 36 часов до начала нового месяца, править логику проведения и разобраться как оно должно быть при нормальном учете проблемно.

(198) с учетом что за 10 лет не поправили - провести рефакторинг за оставшиеся 3 месяца - маловероятно.

...база ДБФ и переход на скул не предвидится
---------------------------------------
...То есть, вопрос не в деньгах.
========================================
Точно?

(200) Вы думаете там лицензионный софт, очень сомневаюсь. 1с может и покупали если внедрял кто то из принципиальных франей, винда очень сомневаюсь. У нас лицензионный софт скорее редкое исключение чем правило.

Хотя возможно когда то была попытка и из-за не ровного кода не взлетело.

(161) (175) (175) (200)


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

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

С Уважением, ТС

(203) "4. Из всего, что Вы написали, мне почти ничего не ясно (да и не должно быть ясно, наверное), но обращу внимание на то, что у нас партионный учет и мы от него пока не готовы отказаться, так как это требование партнеров. Мы отслеживаем какую запчасть (из какой партии) установили в конкретный ремонт."
.
нету у вас никакого партионного учета судая по отчету по остаткам с разворотомпо партиям. М.б. какие-то товары комплектующмие вам партионка не нужна, поэтому такая кривизна. Выискивывать в отечте наобум где норм, где криво (а по моему беглому осмотру криво ВЕЗДЕ где есть расход) - так себе удовольствие.

(203) "Из всего, что Вы написали, мне почти ничего не ясно"
- что именно неясно, например. из того скрина по отчету по партионке , что я опубликовал?

(203) "5. Насколько я понимаю наш учет - у нас нет "многофирмовости...".
а зачем у вас в справочнике фирм заведеноа куча фирм (причем каких-то физиков)..?

Для начала разберитесь, почему в суммовом учете остатков у вас приход идет на одну сумму (себестоимость), а расход идет на другу сумму (скорее всего продажная?) - из-за этого у вас в т.ч. и пухнет регистр, т.к. остаток по сумме никогда не закрывается в ноль.

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

Поэтому лично у меня только одно предложение - оперативно купировать проблему - обрезать внештатно заведомо кривые данные по остаткам по регистру RG1051 (с ним более-менее понятно). Это даст время - если вам будет нужно - разбираться со всем ворохом проблем.

"..обрезать внештатно заведомо кривые данные по остаткам по регистру RG1051" - как я сделал в (185)

(203) "Мы отслеживаем какую запчасть (из какой партии) установили в конкретный ремонт."
- продемонстрируйте скриншотами как именно вы отслеживаете, начиная от документа прихода - перемещения по складам (если таковое есть) - передачи в ремонт (или как вы там жэто отражаете) и списанием из остатков по завершению ремонта и передачи клиенту (возможно и дальше где-то числится эти может быть до истечения гарантийного срока). Приведите скриншоты всей цепочки "отслеживания" - по документам и отчетам 9каковыми вы пользуетесь для отслеживания).
.
тогда может быть понятно, есть у вас партионный учет или нет.. Пока - могу ошибаться конечно - не вижу я его )(правда и пристально не смотрел, нахаляву смысла нет глубоко смотреть).

ну и судя по чисто интерфейсным вещам - формы документов выглядят ужасающе - вряд ли стоило ждать что внутри будет что-то аккуратное ;-)

проще всего перейти на sql и не мучатся

(213) угу.
а там или ослик умрет или падишах сдохнет

Обрезать как в (185) - возьму с учетом потраченного времени здесь и на тест - 200$.

Я сейчас перечитаю что Вы написали и попробую осознать (сквозь истерику внука ))).

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

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

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

Сейчас осознАю Ваше предложение. )))) Спасибо за него - в любом случае.

(215)
Еще раз - спасибо за предложение!
Сумма вполне подъемная. И, в принципе, можем сойтись на этом варианте.

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

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

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

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

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



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

Осознавать это не обязательно. Просто я не могу отказаться от партионного учета. (((

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

(217) Для исправления, нужно создать с нуля цепочку документов -  весть процесс: приёмка-че там у вас еще- расход/выбытие. дЛя одной детали/одного склада/одной партии.
на примере этой цепочки исправить код модуля проведения этих доков.
Затем прибить итоги и движуху и перепровести базу. Усё.
И оно само станет как надо.
+исправить доки ввода останков от прошлой обрезки, выкинув лишнюю аналитику и зависший мусор

(216) "Им присваевается значение отпускной суммы из Внутренней Расходной Накладной. И по этим регистрам появляется плюсовой остаток "
- об этом я написал выше.

А кастрировать - это половинчатое решение, на пол года- два..

(217)
п.1 запретит работу без контроля остатков. иначе вы никогда не поймете - вот есть отрицательный остаток - это ошибка или так надо. работа с запретом "не контролировать остатки" - это всего лишь вопрос административно-организационной дисциплины и воли руководства. Выстраивается и лечится достаточно быстро. У меня (в онлайне) обычно на это уходит где-то неделя (с учетом того, что сами алгоритмы работают правильно). Т.е. включается нормальный режим работы. и все. ни вот сеголдня чуть-чуть, завтра -чуть-чуть, воттут вот срочно один раз можно без контроля - нет, так не катит. работать сразу правильно постоянно. Всё. Проблема исчезает. И это параовозом за собой тянет улучшение в связанных процессах.

(217)
п.2 - можно сразу сказать что это ошибка программы. но кто вас знает какие принципы у вас в процессы заложены, может так и надо/был такой замысел, только его не доработали? итого: - как выше я и другие писали - нужен нормальный рефакторинг/пересмотр/просмотр процесов и исправление алгоритмов. и нормализация работы. По тем объемам движенйи которые есть у вас - база у вас до гигабайта не дотянет СУММАРНО. а у вас там дестяток гигабайт. имеено из-за расхлябанности учета.

(217) п.3 - аналогично как п.2 - надо смотреть и понимать/разбираться что у вас задумано было, как оно должно быть (на ваш взягля) и править/делать как надо.

+219 ваш размер базы, перепроведётся весь, за пару часов, или меньше, если все регистры будут правильно закрываться

(217) "1) почему останется так много (1,2Гб)?"
- потому что вглубь не смотрел. 800 МБ - это заведомо неправильные данные, обнаруженные одним взглядом по которым понятно что их не должно быть (должен быть ноль). еще как минимум половина из оставшегося, а может и больше исчезнет, когда будет выправлен партионный учет (см. мой скрин). Плюс к этому еще куча уйдет когда будет исправлено движение по расходу по торговому учету (приход по торговоум есть, по расходу по торгвооум нет - но это навскидку осмотрено было - смотрите осбужденяи выше)

(217) "Это значит, что все ненулевые остатки останутся в том же состоянии? (со спрятанными внутри незакрытыми накоплениями)?" - да. вариант (185) - быстрый, хирургический, для купирования самых болезненных симптомов. основная проблема останется. Но такое купирование вполне может дать дельту времени на нормальные разборкрии и вы сможете проработать в привычной для себя концепции несколько месяцев, а может и год...

(217) "Как будет происходить процесс физически?"
как и происходил, даже базы скорее всего не понадобится. Обрезка по (185) будет сделана достаточно быстро. да, я работаю тогда когда это надо. и полтора дня мы тянуть не будем. Починим оперативно. С этим регистром проблема временно будет снята.
А дальше - как писал я про рефакторинг и как пишет здесь и сейчас Ёпрст - если вам нужно будет приводит в порядок чтобы это всегда работало нормально - это уже все отдельно, это другая работа, потому что там куча всего неприятного, все как писал я и Ёпрст.

(217) "Для справки: Партионность у нас отслеживается не по учету, а в реальности....."
Партионку сейчас не трогаем. Потому что то что вы говорите - это нормально, но то что я видел в базе - это не соответствует тому что вы говорите (возможно ясмотрел кривые варианты ну вот так на них попал почему-то, просто тупо потому что без обрезки мне дажне не удалось получить ваш штатный отчет по остаткам до партий - прога тупо падала из-за нехватки памяти, поэтому я взял часть котоая подвернулась под руку и смотрел по ней - а поней все криво. скорее всего криво и по остальным). Поэтому надо разбираться. Как я выше написал чтобы вы протянули всю цепочку обслуживания по какому/либо материалу/запчасти по партионному учету начиная с прихода и заканчивая полным списанием с торгового баланса. (Епрст в принипе чуть выше то же самое написал).

(217) Вполне возможно, что по основному массиву учета ваших запчастей партионка норпмальная, но это надо смотреть и это отдельная задача.

Как написано в (225) при исправлении косяков алгоритмов при том объеме движенйи которые зарегистрированы в базе - база будет небольшая  и пересчитать ее не представит труда. Но это отдельная задача. так как могут возникнуть административно-организационные трудности - например кривые данные где-то уже зафиксированы и их нельзя исправлять...

Общий процесс "рефакторинга" описан учитиелем (да продлятся его годы на благо клюшечников) в (219)

(219) (225)

понимаю всю правильность и согласен с таким подходом. Но есть 2 "но": 1 - бюджет, 2 - негде взять еще полгода жизни. Так как кроме меня никто в этом разбираться с программистом не будет. Но, вполне возможно, через какое-то время напряги попустят и я смогу этим заняться. Я на прошлую обрезку потратил месяца три на осознание и сотрудничество со специалистом. А тут задача явно покруче. Хотя... может я ошибаюсь.

(233) все что надо для "мпециалиста"с - вменяемое изложение вашего процесса от входа до выхода.
что вы обычно делает, с какой целью/зачем/почему, что на входе каждого шага, что на выходе. найти два раза по полдня чтобы все это описать на уровне рисунков записей от руки на бумаге и/или скриншотами документов/отчетов - вполне возможно. дальше - дело техники, когда понятно "как должно быть" - сделать "что надо" - задача не такая уж и сложная. А спецы которые взяли аванс и сгинули - ну кому приятно в гуано копаться ;-) А аванс забрали как компенсация за моральный ущерб ;-)

Финишный раз - вариант (185) - привести пациента в чувство, чтобы не загнулся по дороге в больницу...
я на связи, личка в профиле.

(222) (223) (224)
согласен с идеологией. Но до этого надо дозреть и по времени, и финансово. Я даже не понимаю бюджета этой задачи (даже если исправлять только баг№3).

(227)
понял

(228)
не понял. Что значит не нужна база? А как же резать? Сорри, я дилетант и не понимаю.

(236) нужен один файлик, его и "порежем".. ;-)

(135) (136)

подскажите, пожалуйста, если это бесплатно: каким отчетом смотреть регистры? А то у Вас так красиво видно состояние регистров....

REGPRINT.ERT

ЛУЧШИЙ ВЫХОД ПЕРЕХОД В SQL

(240) Эстонец ?

Да порезал я ему в декабре ещё если не раньше, там с этого регистра пшик мизерный в итоге остался, плюс он сам с прогом по подсказкам поправили ошибки алгоритма и убили контур упр. Учёта. Там конфига наподобие тис 8.7. Нормально у него всё должно быть, повторно не стучался