1С
Запись не верна! Значение поля «Ставка» не может быть пустым! (Регистр накопления: Расчеты налоговых агентов с бюджетом по НДФЛ; Номер строки 2) БП 3.0
Запись не верна! Значение поля «Ставка» не может быть пустым! (Регистр накопления: Расчеты налоговых агентов с бюджетом по НДФЛ; Номер строки 2) БП 3.0
При проведении РКО на выплату заработной платы программа внезапно взбесилась. Это по всей видимости после обновления.
Мы конечно можем открыть регистр и посмотреть. Но уверяю заранее, ничего интересного или ошибочного в нем нет
Скриншот регистра выкладывать не буду – смотрите свой. ОНО ругается на нечто связанное с НДФЛ, а точнее на ставку 13%. Изучаем программу, находим ошибки.
Ошибки в программе.
Оно конечно не критично, но зачем…?
Да у нас есть документ
Но он отношения к проблеме не имеет
Идем в справочник ФизическиеЛица
Давим Налог на доходы и смотрим Историю
Осталось резидента поставить. Так как период закрыт, кто знает что делать – может дальше не читать.
Собственно и все.
PS. Не исключаю, что у некоторых проблема может быть в справочнике Начисления – Код Дохода 2000 или другие реквизиты в созданных Вами начислениях.
Ошибка SQL Таблица не найдена
Восстановление базы 1С после неудачного обновления.
Часть вторая
Ошибка SQL Таблица не найдена ‘NNNNNNNN’
При написании статьи использовались публикации
https://infostart.ru/public/99809/
http://www.softmaker.kz/1s/oshibka-subd-oshibka-sql-tablica-ne-najdena-reference-kak-ispravit.html
Итак в предыдущем обзоре я писал что восстановил базу используя HEX редактор. Итак ставлю клиенту базу, у него радости выше крыши и довольный ухожу. Через несколько часов звонок
>Спасибо все хорошо, все документы и справочники целые, только в реализацию не пускает.
!? А как ругается?
>Ошибка SQL Таблица не найдена
Опа!
Копия базы осталась, захожу в журнал документов и точно — Ошибка SQL Таблица не найдена ‘ Document351’
Запускаю конфигуратор преревожу запуск базы как обычное приложение и открываю обработку Соответствие всех объектов конфигурации с таблицами.epf (Самая лучшая это ПосмотрМетаданных82_ОНО.epf. Я ее использовал когда базу на SQL подрезал. Ну что что первое было под руками.)
Чет мне стало нехорошо. Звоню и спрашиваю:
А много реализаций было?
> Да были, но не очень много
Запустил Tool_1CD на пару с Hiew, но шапки документа 351 (Реализация) в самом раннем файле испорченной базы не нашел. Есть табличная часть с указанием услуг и суммой документа. Это хоть что-то.
Ладно, но ведь ссылки на документ могут остаться в проводках и хотя бы в РегистреСведений ДаныеПервичныхДокументов _INFORG12800
Хорошо, думаю, сейчас базу проиндексирую и оно восстановит мне. Ага, Щаз! Не надо быть таким наивным по отношению к фирме 1С.
Короче, оно не индексируется, ссылаясь на отсутствие таблицы _ReferenceChngR2473
А это что за справочник? Основные средства. Их у них нет.
Вспомнилась история, как Желдорэкспедиция приобрела погрузчик и отдельно кабину к нему. Пока бухгалтер думала да гадала как его ввести в эксплуатацию да модернизировать – погрузчик сгорел нахрен с кабиной в ангаре. Пришлось сделать списание.
Приступим.
Первое – делаем копию и ничего не боимся. Если таблица отсутствует – нужно удалить объект конфигурации и по любому проиндексировать базу. Вот почему я и люблю SQL. Там бы посоздавал таблицы и голова бы не болела.
Как я делал. Создал пустую базу с идентичной конфигурацией. Из нее я буду копировать справочники и документы Cltr +C и Cltr +V
В раненой базе добавляю буковку «я» впереди документа РеализацияТоваровУслуг. Потом делаю глобальную замену яРеализацияТоваровУслуг на РеализацияТоваровУслуг. В одном модуле потом дорисовать эту буковку «я». Само ругнется. А потом в чистой конфигурации становлюсь мышкой на документ РеализацияТоваровУслуг (Cltr +C) – а в раненой на Документы (Cltr +V)
И помечаю на удаление яРеализацияТоваровУслуг. Выскочит куева туча ссылок
Нужно удалить ссылки. Я ставил на копированный документ, хотя к конце всего этого процесса он удалится при обновлении конфигурации.
Потом у меня вылез документ РеализацияОтгруженныхТоваров
Чтобы быстрее шла работа – используйте фильтр. И момент, про который не все знают
Тут интуитивно понятно.
Итак я удалил два документа, а потом полезли справочники…. Благо что в них изначально ничего не было.
Логика такова – удалять на что ругается, пока не проиндексирует базу.
После того как база проиндексирована – нужно загрузить идентичную нашей, конфигурацию из файла. Оно удалит созданные нами документы и справочники, загрузит оригинальные и самое главное – создаст таблицы. Номера у таблиц будут другие, не такие как у исчезнувших. Итак загружаю конфигурацию из файла и созерцаю.
Я не буду лезть в подробности и грохну содержимое регистра. Ничего интересного там нет.
И по иронии судьбы вылез регистр ДанныеПервичныхДокументов. Я в Tool_CD выгружу из дохлой базы данные таблицы, грохну содержание регистра в новой , обновлю конфигурацию базы данных, а потом загружу в регистр данные. Не забываем про конвертацию с помощью cnvdbfl.exe и Tool_1CD_alpha. Про нее расписано в первой части.
Сделал, как написал выше и запустил индексацию.
Знаете что он удалил? А я знаю. Записи реализации. Эсники без подляны никак не могут.
Что имеем в осадке.
А имеем две таблицы полученные из первоначальной мертвой базы с помощью Tool_CD. Первая – это реализация услуг.
Вторая это регистр
Соответствия есть. И при желании можно в SQL…
Предложение есть и для файлового варианта
https://infostart.ru/public/143704/
Ввиду ограниченности бюджета у заказчика на этом все и закончилось. Документов было немного. Их проще и дешевле забить руками.
И напоследок.
https://forum.infostart.ru/forum105/topic24464/?PAGEN_1=7
Валерий Агеев (awa) разработчик Tool_CD
Восстановление базы 1С Повторяющееся имя таблицы
Восстановление базы 1С после неудачного обновления.
Внимание! Эксперименты всегда проводим на копии! Это первое правило, точнее второе. А первое правило – делаем бэкапы ежедневно автоматом и само собой перед вмешательствами в базу.
Вечно эсники в погоне за наживой постоянно подсовывают нам подлянки. Взять к примеру их доблестное рвение перехода на троечную зарплату с вынужденным обновлением платформы и последующей «нелицензионностью» программы. Эта хрень лечится rbc_icpFor1C. А чего стоит подлый перенос данных из ЗУП 2.5 в ЗУП 3.1 с отсутствием переноса документов. Лечится написанием собственной конвертации данных по переносу. Спасибо Вам огромное! – без денег не останемся!
А теперь непосредственно поделюсь своим опытом восстановления трупа базы после обновления. Обратились ко мне, точнее не обратились, а мимоходом спросили – нет никого, дабы восстановить базу, рухнувшую после обновления (я впоследствии понял что обращались уже много и ко многим но безрезультатно). Говорю – давайте попробую, если не получится, то ничего не теряете. До этого был печальный опыт. Клиент тупо перезатер базу. Как умудрился? Ему только ведомо. Там был стандартный отказ. Опять я отвлекся.
Итак делаю копию рухнувшей базы, запускаю chdbfl.exe и натравливаю на базу
А так? Без галки.
Он много написал. На скриншоте упущена часть ошибок. Короче оно обновлялось, создавало копии страниц и странным образом решило помереть. Забираю базу, дабы препарировать ее дома на нормальном железе, а не на ноутбуке. Архивы, копии, выгрузки отсутствуют напрочь.
Отвлечение. На инфостарте всячески ругают встроенную в 1С утилиту chdbfl.exe, которая при серьезных проблемах либо ничего не делает, либо делает хуже. Я поклонник MS SQL и при возможности ставлю базы на него. Но что имееем… Итак лезу в закрома и открываю Tool_1CD_alpha. Мда, почти три года не использовал, интересно что изменилось за это время?
Изменилось… А обнова есть? Есть!
Итак база открылась. Диагноз товарища Саахова подтвердился.
Таблицы в базе целы, хоть и есть дубли – это хорошо. Версия Tool_1CD только для просмотра. Но ведь я могу копировать из нее таблицы и заносить скажем в чистую базу. Ага, ЩАЗ! 1С не была бы 1С без своих постоянных подлянок. На этот раз подлянка в названии таблиц. Поясню. Мы ставим первый раз ну скажем бухгалтерию предприятия, и в базе данных создаются таблицы констант, справочников, документов, регистров сведений и накопления.
Смотрим
О чем это говорит? Раньше база была БП 2.0. Установлена в 2016 году и впоследствии конвертирована в БП 3.0. Но я не знаю какой был релиз при установке – а это разные таблицы. Во база постарее
А это БП 3.0 начала 2019 года
Кстати на этот релиз умершая база и обновлялась. Получается я не знаю где какая таблица в базе. Что имеем? Я могу скопировать из Tool_1CD любую таблицу погибшей базы и запихать даные из нее в чистую базу на SQL. Но это попахивает нехорошим. А если сконвертировать базу в формат 8.2.14 который можно редактировать в Tool_1CD_alpha. Итак, в командной строке запущенной из папки bin набираем:
cnvdbfl.exe -c -f 8.2.14 C:\Баы1С\Восстановить\1Cv8.1CD
Ага! Разогнался! Хренушки! Не конвертится! Я разозлился и пустил в ход тяжелую артиллерию для реверс-инжиниринга. Это Hiew 7.10
Открываем базу и забиваем нулями дублирующие таблицы, которые нам заботливо будет выдавать chdbfl.exe
Он на эту таблицу первую и ругался. Выходит примерно так
Итак потихоньку забиваю нулями дубли таблиц на которые ругается chdbfl.exe. И, о чудо!
Да неужели?!
Оно запускается!
Эска выжила, ничто не пропало. Вот такие дела.
Выводы.
Делайте бэкапы. А если случилось горе, не следует крыть матом эсников за их недо-chdbfl.exe. Утилита работает. Единственное, эксперименты проводить на копии базы.
Ну мало ли что.
Короче, надо немного понимать что делаешь — и будет счастье. И спасибо Валерию Агееву за Tool_1CD. Его проект https://github.com/e8tools/tool1cd
Я только не пойму одного. Агеев реально умер?
И напоследок о Шурике. Эсникам со своим жестким маркетингом насрать на конечных пользователей. И они могут довести их до помутнения рассудка. Во главе угла стоят только деньги. Я тоже не против зарабатывания денег, но нельзя же так цинично все это делать.
Нетрадиционная подрезка базы БП 2.0 с рассуждениями о железе
В силу своего характера никогда не верю написанному. Потому что на заборе может быть написано х.., а там дрова лежат. Я про работу на SQL 1С и требования к оборудованию. Можно разводиться на дорогое железо, слушать басни эсников и производителей железа, проводить тесты Гилева и на выходе получить ноль или заплатить куеву тучу бабла непонятно за что.
Итак стояла задача в 2013 году приобрести сервер для 4х организаций в торговой сети. 5 магазинов и склад. Учет на Торговля и склад 7.7 и это дело выгружать в БП2.0. Прикинув размер базы 7-ки и разрастание базы за год на 1Gb ничего критичного не почувствовал в ближайшее время. Поэтому купили систему на I3 процессоре с 8Gb оперативы. Мать P8Q77-M Lga 1155на 4 планки памяти и поддерживает разгон. Но руководствуясь прошлым опытом я решил поставить зеркалом новомодные в то время SSD. Тогда тормоза SQL упирались в скорость дисков. Мудрые люди уговорили взять SAS. Со скрипом согласился, они мои клиенты, плохого не посоветуют. Контроллер стоил дороже чем системник с потрохами. Диски тоже не отставали по цене. Бухгалтерия предприятия была сразу установлена на SQL Server 2008R2. Ставить операционкой Server 2012 смысла не видел. Windows 8 с небольшой модификацией реестра на открытие файлов и модификации DLL для доступа по RDP нескольких юзеров ничем не отличается. Уж поверьте! Ну и стало это дело благополучно работать. Не тормозило, пока размер базы не перевалил за 10 Gb. Подкинул серваку оперативы и опять вроде нормуль. Потом, наблюдая за проведением документов в диспетчере задач заметил нагрузку на процессор. Купили I7 2600 у китайских друзей почти задаром. И опять бухгалтерия благополучно работала. А вот месяц назад до написания этого материала начались тормоза. Вся нагрузка шла на жесткий диск. Память на мамке предел – 32 Gb. Но в силу ряда причин размер планок памяти стал немного меньше. В оффлайне DDR3 стоит что реактивный самолет. Планки по 8 Gb успешно заказаны у желтопузиков и едут. Но сейчас что-то делать надо. Ради эксперимента запустил базу на SSD. Прироста скорости – ноль. Но SQL сервер его так грузит что пришлось отказаться от этой затеи. Кстати по этой причине у меня два диска вылетели на других машинах. Диски купленные в оффлайне. Китаезные диски купленные за копейки все живы. Это так, отступление. Делайте выводы сами.
Вывод 1. Для SQL сервера достаточно SAS дисков. Это порадовало.
Вывод 2. Для быстрой работы SQL сервера нужна память и есть закономерность размер базы/объем памяти. Какая? ХЕЗ. Дальнейшее наращивание памяти вроде как не ускорит работу (так пишут в инете…)
Вывод 3. Процессор. Здесь странная ситуация. Если хватает памяти и быстрые диски — то чем больше ядер и выше частота, тем лучше. (Странно если бы было наоборот). Но скажем кассовые ордера и банковские выписки грузят процессор сильнее чем приходные накладные, перемещения товаров и отчеты о розничных продажах.
Итак размер базы в 2018 году почти 40Gb. Начинаем исследования.
Если кратко. Я на копии сделал подрезку базы обработкой с созданием документов ввода остатков и удалил записи бухгалтерских регистров и регистров накопления запросом truncate table. Сжал базу и ее размер стал 4 Gb. Но в в августе месяце мне в облом проводить заново документы с начала года. База стала тормозить месяц назад, и выкинув из нее две организации я дотяну до конца года и подрежу по взрослому.
А пока
Проганяю запрос на SQL дабы выявить что занимает более всего места
select
t.name as table_name,
sum(sz.used_page_count*8) used_size,
sum(sz.reserved_page_count*8) reserved_size,
max(sz.row_count) row_count
from
sys.dm_db_partition_stats sz
inner join sys.tables t on t.object_id = sz.object_id
group by t.name
order by reserved_size desc
Итак видно что это регистры бухгалтерии. Кто-б сомневался! А конкретно
Ага. И в них реквизит организация.
Грохну я для начала две ненужные организации у меня в базе. Начну с регистров. Нет записей регистров – нет проблем документы моментально ставятся на удаление.
Осталось посмотреть идентификаторы, что кому принадлежит
Здесь понятно, идентификатор организации в виде двоичного кода
Мне нужно грохнуть организации с кодами
0x91ABEF95F76A2D0442764BC09100A7B5
0xA163C48C77C3E934460746C72267C993
Пишем запрос
DELETE FROM _AccRgAT37950
WHERE _Fld7917RRef=0xA163C48C77C3E934460746C72267C993;
Перекрестились и нажали Выполнить. Запрос делал на базе которую подрезаю
На мастере выглядит так
DELETE FROM [Account].[dbo].[_AccRg7916]
WHERE _Fld7917RRef=0x91ABEF95F76A2D0442764BC09100A7B5;
GO
GO! – это хорошо! Кстати если хотите грохнуть всю таблицу, то здесь все просто и быстро произойдет
truncate table _ AccRgAT37950 Это делать не рекомендую! Помните как говорил Доцент в Джентельменах удачи: — Опомнитесь! Пока не поздно, опомнитесь!
На крайняк сделайте бэкап.
И далее дело техники
DELETE FROM _AccRg7916
WHERE _Fld7917RRef=0xA163C48C77C3E934460746C72267C993;
И соответствено на другую организацию делаем.
DELETE FROM _AccRgAT37950
WHERE _Fld7917RRef=0x91ABEF95F76A2D0442764BC09100A7B5;
и
DELETE FROM _AccRg7916
WHERE _Fld7917RRef=0x91ABEF95F76A2D0442764BC09100A7B5;
Короче я удаляю на всех бухгалтерских регистрах
Далее хотел грохнуть
Теперь грохнем отчеты о розничных продажах (они много места занимают)
И поступления товаров и услуг
Зачем мелочиться!
А может грохнуть организацию и проверить базу на ошибки? По логике эска в таблицах скуля поудалять должна строки.
Как говаривал Брекодкин из Уральских пельменей: — И что, просто так Delete? Ликвидировать профессора и обеспечить круглосуточную охрану розетки.
Все верно, нужно только было грохнуть организацию.
Сработало!
Однако очень долго конфигуратор висел
Нужно было регистр первичных документов почистить.
Теперь сжатие базы
А после Нового года сверну базу документами, поудаляю записи в регистрах, проведу документы ввода остатков. А может сверну штатной обработкой от 1С. Пока не решил. Как правильно будет формироваться оборотно-сальдовая ведомость после подрезки – на том варианте и остановлюсь.
PS
При подрезке применял обработки с инфостарта. Некоторые из них модифицировал под свои нужды. Позднее выложу их здесь. Если встретите что-то свое, не обижайтесь.
Эсники не были бы эсниками, если бы не навязывали свой агрессивный маркетинг. В БП 3.0 реализован нормальный механизм подрезки Документом корректировки регистров. Мда… Хотя регистры я корректировал еще в 7-ке, потом в УТ-10. Единственнное — запрет на дату ставить чтоб не слетело от действий безумного юзера.