Тема избитая. Прочитал несколько веток по этому поводу но все же.
На этой неделе при попытке расчитать ЗП в ЗиКе начал вываливаться SQL с ошибкой о нехватке памяти или разрядности...вообщем слишком большие числа. "Хмм" - подумал я и решил попробовать расчтать зп по группам. все бы ничего - но нашелся некий товарищь - у которого заодлежнность и начальное сальдо ббыли более чем 999999999999.99.
Расчечики естественно не удивились данной сумме. Они все прекрасно знают. Знают что программа не работает правильно, и считает она почему то неверно. Знают что и документ накопленная задолженность работает неправильно.
И когда они были на старой программе - все работало, а в новой - все нероаботает.
Поискав в интернете решения данной проблемы - нашел обработку по корректировке данных сум - но что то она делает не так, как я ожидал - да и расчетчики, смотря на те суммы, которые появляются после работы обработки, говорят, что это все мягко говоря УГ и давай мол исправляй как хочешь нам месяц набо закрывать.
А как я исправлю - яж понятия не имею из чего эта задолженность складывается.
Умные люди говорят, что нужно и можно править прямо в ЖР или документе о накопленной задолженности в течении 2 месяцев - и все станет более менее.
Подскажите мне - как нужно править эти 9999999999.99 (чтобы их). Как расчитать сумму, которую. должено сотрудник и предприятие? Из каких отчетов их можно вытащить?
А я уж расчетчикам накапаю на мозг чтоб сидели правили.

Расчетчики куйней страдали хрензнаетсколько времени  дай им редактор ЖР и пусть выправляют

Если это ЗиК, а это ЗиК пусть смотрять док уж не помню как он называется, формируется при закрытии месяца, задолженность предприятия что-то такое

Есть еще вариант, откати период и пусть все выплаты ЗП ставят с нормальным периодом

Попробуй воспользоваться вот этой ссылкой https://1cers.ru/find.php
Уже было это :)

>>> ЗиКе начал вываливаться SQL....
О_о вы ребята БОЛЬНЫЕ, особенно тот, что перевел ЗиК на SQL, т.к. он не работает под сим продуктом.
Почему не могу сказать, но всплывают ошибки, которых и быть не должно.
...Совет: переводи ЗиК в DBF формат и все у тебя заработает :)

(5) Ну например у нас была зик на sql. Всё работало.. Что-то быстрее чем на dbf, что-то медленнее. Но в общем, попытка откатиться на dbf привела к недовольству расчетчиков медленными отчетами.
PS Перешли на ЗУП, уже года 4 работаем в ней.

Больше года назад была такая ситуация. Причем на фирме, которую веду года 4. Каждым месяц гудел, пинал зарплатчиков, ГБ - и когда ЭТО случилось - ко мне вопросов не было. Нормальной обработки, которая решала бы данную проблему - не нашел. Изменил
"Документ.НакопленнаяЗадолженность.Сумма" - с 15 на 19
"ЖурналРасчетов.Зарплата.ДлинаРезультата" - с 15 на 19
Предупредил, что это месяца на три. Так и вышло, последние 2 месяца 2010г несколько сотров вели уже в экселе. В ноябре создал новую пустую базу, перенес туда только спр. Сотр и их льготы по НДФЛ. Все остальное - ручками. Забили все приказы и т.д. на 1200 сотров, с НГ работают в новой базе - полет нормальный, сальдо идет. Через руки - оно быстрее доходит...

Вот здесь есть обработка, метлаЖР которая:
http://1c.proclub.ru/modules/mydownloads/personal.php?cid=5&lid=5064

Пару лет назад помогла, только подряд два месяца с ней прошелся.

(7)У нас тоже около 1К сотров - 1 расчетчик.
Вариант с изменением  "Документ.НакопленнаяЗадолженность.Сумма" - с 15 на 19
"ЖурналРасчетов.Зарплата.ДлинаРезультата" - с 15 на 19
Обдумывал - но это отсрочит неизбежное.
(8)Интересно..посмотрим...

Это ситуация когда сальдо с "+", а задолженность с "-" примерно на такую же огромную сумму?

ох уж эти любители зику к sql загнать...

(11) ниче так работает... правда после обработки напильником)

(12) напильник = 1С++?

(13) адо))

(14) не запарился переписывать свод по проводкам?
основная проблема у моих именно это под sql. Но пока терпят, своды на копии мучают :) Штат около 2К

(15) парился... но таск такой был на аутсорсе... полетело