| 0
- 21.06.2016 - 15:35
|
В доке отпуска по уходу не была проставлена дата окончания выплаты пособия. Мягким откатом открыл период, поставил дату нужную и жамкнул ОК. Все начисления за 1,5 года пособий пропали. Как теперь наименее безболезненно вернуть их?     | | |
| 1
- 21.06.2016 - 15:45
| никак, если не было архива. Или спецсредствами, навроде универсального редактора журнала расчётов. Открываешь и в каждый месяц добавляешь нужную сумму. Муторно, но работает. | | |
| 2
- 21.06.2016 - 17:59
|
0-SergeyY > 1. Делаем копию БД с этой бедой. 2. Рабочую БД поднимаем из архива. 3. И "девочки", поглядывая на копию с хладными останкамы БД, вводят недостающии данные. Непременно сами. Непременно своими ручками. За свое время. Иначе дурь никак не выбить. Проверено. Кстати, умение думать о последствиях благотворно скажется на последующей жизни. Они еще и благодарить должны. | | |
| 3
- 21.06.2016 - 18:52
| (0) можно попробовать для начала док Начисление зарплаты с видом переначисление за период по этой сотруднице, но скорее всего придётся помесячно мягким перекатом вводить 15 доков Начисление зарплаты. | | |
| 4
- 21.06.2016 - 19:21
| Цитата:
| | |
| 5
- 21.06.2016 - 20:14
|
4-Странный аттрактор > Ну, если это его дурь, то "девочек" жалко, конечно. И править ему. Стратегия зависит от дальности бэкапа: как часто делают. Нулевой вариант: бэкапов нет, потомушто "было не надА". стратегия: Распечатать и повесть на стенку: "Нуб!! Бэкапы делают, когда они не нужны!" Потом откатываемся штатно (да, да, именно штатно) на эти самые полтора года, и начинаем восстанавливать руками, поглядывая на копию трупа БД, и поднимая все-все бумажки с отчетами. Ежемесячными и годовыми. Включая "по НДФЛ", и "по ПФР". Не пропуская периоды. Вариант 1. Бэкап более чем за полтора года. На самом деле, это "нулевой вариант". Вверх. Вариант 2. Бэкап есть, не полтора года, раньше, но все равно далеко. Хоть что-то... Бэкап будем использовать для контроля, и как банк трансплантации. Копия трупа (сохраняем, уже ученые) переносим в новый каталог: это будет наша будущая восстановленная база. | | |
| 6
- 21.06.2016 - 20:31
|
(продолжение №5) Итак, все готово для реанимации. Первое, что делаем, это из бэкапа выдергиваем Журнал Зарплата и Журнал расчета страховых взносов. Переносим как файлы ДБФ. Сопутствующие файлы CDX убиваем нафиг (в базе восстановления). Открываем базу монопольно (что индексы восстановит), и все документы, что делают записи в вышеупонянутых журналах делаем непроведенными. Чем ближе бэкап к сегдняшнему дню, тем быстрее все пройдет. Возвращаемся (штатно, штатно!) на период, с которого сняб бэкап, и начинаем восстанавливаться, глядя на месяные отчетв (Расчетные ведомости, Своды...). Если итоги совпадают- по людям не смотрим. И т.д., и т.п. Быстрее? Надо хорошо ориентироваться в структуре, и понимать алгоритмы расчета. Еще быстрее? Надо иметь навык работы с ДБФ. Год, в принципе, вполне реально восстановить за день ;) | | |
| 7
- 21.06.2016 - 20:35
| +(6) Поправка: "все документы, что делают записи в вышеупонянутых журналах делаем непроведенными" --> "все документы (от месяца бэкапа по текущую дату), что делают записи в вышеупонянутых журналах делаем непроведенными" | | |
| 8
- 21.06.2016 - 21:23
|
На самом деле (1) достаточно. Если не трогал "Начисление зарплаты", то "Включая по НДФЛ..." - не надо, его скорее всего и не было, "Включая по ПФР..." - не надо, его скорее всего тоже не было. К тому же страховые взносы начислениями не вытесняются, так что они остались на месте. Достаточно ввести через "Универсальный редактор журнала расчетов" помесячно "Пособие по уходу за ребенком до 1,5 лет" и "Пособие по уходу за ребенком до 3-х лет", лучше копированием из первого периода, только аккуратно, с верными суммами и со последовательной сменой расчётного периода. Год вполне реально восстановить за полчаса. Но в следующий раз быть аккуратнее, а то может Валера и правильный способ предложил - чтобы надолго запомнилось. | | |
| 9
- 21.06.2016 - 22:22
|
страсти какие ужасти на самом деле, если база dbf и автор от большого ума ничего с базой не сотворял, то никуда они, записи ЖР, не делись. лежат себе родименькие , ждут, когда с них пометку на удаление снимут. не ту пометку, которая 1С-ная, а ту, которая dbf-ная. но для этого, как сказал Валера, надо Цитата:
| | |
| 10
- 21.06.2016 - 23:41
|
(3) Геннадий спасибо. Взял за основу ваш вариант. Отключил временно проверку на дубль начисления зп по сотру в доке начисления. Делал мягкий откат на месяц, вводил док начисления, рассчитывал. И так все 15 месяцев. В журнале все красиво - как в архиве (он месячной давности, поэтому не стал его использовать). Осталось решить вопрос по сальдо. Пособие должно было закончиться 20.04.16. Но по факту было начислено и выплачено за весь апрель, май. Сейчас за апрель начислено только за 20 дней, за май 0. Т.е. сальдо введенное доком "Ввод нач.сальдо" не верное. Это как нужно "по-правильному" поправить? Бух предполагает что излишне выплаченная сумма будет удержана из текущей июньской ЗП. | | |
| 11
- 22.06.2016 - 08:10
| (10) заведите новый ВР-начисление "излишне начисленное пособие", настройте не обложение НДФЛ и взносами | | |
| 12
- 22.06.2016 - 09:17
|
(11) оуу..не понятно. можно тогда чуть подробнее. Сейчас сальдо на май введено доком "ввод начального сальдо". По идее этот документ уже в закрытом периоде. Можно конечно вернуться в май и все пересчитать, но вдруг где что выползет по другим сотрудникам (их там около 1000). Хотя наверно же можно ручками исправить в журнале эту запись, так? | | |
| 13
- 22.06.2016 - 09:26
|
(12) нет, пособие должно остаться в сумме до 20.04, т.к. это необходимо для 4-ФСС... Я другое сказал. Для выравнивая переначисленных сумм достаточно добавить излишки в апреле и мае в "+" и убавить их в июне в "-" доками ввода расчёта сотруднику Иначе, если править тупо суммы напрямую в ЖР, то ошибочные суммы залезут в 4-ФСС | | |
| 14
- 22.06.2016 - 15:30
|
(13) все равно не понял. что значит "остаться в сумме до 20.04"? Он щас и стоит в журнале как до 20.04. Сумма 5000 руб. На май сальдо начальное введено 8000. В мае выплачено 8000. Вот и надо исправить майское начальное сальдо, чтоб вышло только 5000. Выплачено 8000. Июнь открыт и можно пересчитать сальдо спокойно. Выйдет за ней долг 3000. Начислим ЗП 10000 и уйдет к выплате 7000. Или я чегото не понимаю? | | |
| 15
- 22.06.2016 - 16:54
|
(14) хм... я плохо объясняю то, что много раз делал... в мае (мягкий откат) вводим расчёт сотруднику в сумме +3000: пособие ... 5000 новый ВР "излишки" ... 3000 выплачено ... 8000 сальдо на конец = 0 в июне вводим расчёт сотруднику в отрицательной сумме -3000 сальдо на начало ... 0 новый ВР "излишки" ... -3000 Зарплата ... 10000 НДФЛ ... 1300 Выплачено ... 5700 сальдо на конец ... 0 | | |
| 16
- 22.06.2016 - 16:57
| Это если непременно требуется соблюдение ежемесячного сальдо по 70-му счёту в ЗиКе. Если нет - то оставить как есть: переплата в мае и недоплата в июне | | |
| 17
- 22.06.2016 - 18:26
| Баланc и др. расчёты ещё не сданы. Спокойно мягко откатываемся и пересчитываем только одну запись начального сальдо по этому сотру. И перезаполняем накопленную задолженность, если вводилась. Общий расчёт не делаем. По другим сотрам не должно проплыть, если больше ничего не перекосило. Выплаты тоже можно править спокойно. Вперёд продвигается штатно. На всякий, перед всеми манипуляциями резервная копия. | | |
| 18
- 22.06.2016 - 18:29
|
Да,проводки с апреля придётся перегрузить. 16-Гена > где может требоваться? Если помесячно что-то куда-то сдавалось? | | |
| 19
- 22.06.2016 - 18:41
| (18) да, есть такие фирмы, где запрещают менять прошлый месяц по 70-му счёту | | |
| 20
- 22.06.2016 - 22:52
|
Откатил на май мягким. Напрямую в журнале править сальдо не дает. Пришлось док начисления нач сальдо перезаполнить. Вроде только по одному этому сотруднику сумма изменилась. Провел. Вернулся на июнь. Опять-же перезаполнил док начального сальдо. Вроде пока все красиво. Всем БОЛЬШОЕ спасибо. Особенно как всегда Геннадию. | | |
| 21
- 23.06.2016 - 13:31
| Цитата:
Док.НайтиДокумент(ВыбДок); Док.ПолучитьСтрокуПоНомеру(НужнаяСтрока); Док.Сумма=НужнаяСумма; Док.Записать(); А сумму в журнале расчетов поправь Универсальным редактором журнала расчетов. Надёжно и просто. Ну ладно, сделал и сделал. Хоть без ковыряния dbf обошёлся и то ладно) | | |
| 22
- 23.06.2016 - 18:32
|
я и с самого начала чегой-то сомневалась, а теперь вот решила проверить. Цитата:
перешла на полтора года вперед. мне и без всякого мягкого без отката дает исправить дату окончания выплаты. Точнее, не исправить, а ввести, если она (дата) пустая. Исправить как-раз таки не дает. Такимо бразом возник естественный вопрос - а напуркуа было делать мягкий откат? | | |
| 23
- 23.06.2016 - 19:15
| Цитата:
| | |
| 24
- 23.06.2016 - 23:35
|
(22) а я даже не попробовал :) по привычке уже - если док в прошлом периоде, то надо откатиться чтоб его поправить :))) Спасибо. Буду иметь ввиду. | | |
| 25
- 24.06.2016 - 00:31
| Цитата:
ЗЫ: только паре самых адекватных клиентов дала "мягкий откат", но на самый крайний случай, о последствиях предупреждены, наличие копии перед сим действием обязательно. если кто-то полез неправильно и без разрешения - восстановление стоит дорого, об этом тоже предупреждается.... | | |
| 26
- 24.06.2016 - 10:17
| Цитата:
У меня многие клиенты пользуются (пользовались). Док "Ввод расчета сотруднику"- если дата окончания не установлена (пустая) то ее легко установить в любой момент. Т.е. вместо того, чтобы делать"Временное прекращение..." они просто прекращают "Ввод расчета" проставлением даты окончания. короче говоря - пока ДатаОкончания пустая - это контрол редактируемый. Как только Датаокончания заполнена - этот контрол становится нередактируемым. Вот такая вот фишка ... Так что не всегда мягкий откат нужен. | |
Интернет-форум Краснодарского края и Краснодара |
