Справочник Виды вычетов ЗиК

"Посмотрел код - мощно.
Особенно подкупает:
Если СпрВидыВычетов.ВыбратьЭлементы()=1 Тогда
Сообщить("В справочнике уже имеются какие то элементы, заполнение не производим, надо рахбираться более детально");

Дело не в грамматике, а в том, что эта обработка для СОЗДАНИЯ И ЗАПОЛНЕНИЯ ПУСТОГО справочника.
Так какого  ***  городить огород, если можно просто установить в базу нормальный файл справочника?!

Правда, если результат работы этой "20"-ки будет адекватен, иначе обеспечен ещё больший геморрр.

ЗЫ
А "что получится" могу сказать сразу: появится именно это сообщение
"

То есть, по вашему выходит, что я не прав? Ок, рассмотрим именно этот конкретный пример. Берем случайно взятую рабочую базу ЗиК. Смотрим в 1cv7.dd и видим, что справочник "Виды вычетов" лежит в таблице SC861.DBF. Вот несколько записей из нее:
ID: 3
CODE: 103
DESCR: 400 руб. на налогоплательщика, пп.3 п.1 ст.218 НК
ISMARK:
VERSTAMP: 4

ID: K
CODE: 107
DESCR: 2400 руб. на ребенка-инвалида одинокому родителю, пп.4 п.1 ст.218 НК
ISMARK:
VERSTAMP: 0

А теперь посмотрим таблицу, в которой есть ссылки на эту. Само собой, это таблица "ВычетыСотрудниковПоНДФЛ", у меня она лежит в файле SC1057. Ссылка осуществляется связкой поля "ВидВычета", идентификатор которого в разных базах может быть разный (у меня он "SP1054"), путем занесения в него значения, соответствующего ID из таблицы "Виды вычетов".

А вот теперь фокус! С чего вы взяли, что значения, занесенные в поле ID таблицы "Виды вычетов" во всех базах одинаково для значений, имеющихся в справочнике? ТЕМ БОЛЕЕ для базы, в которой есть проблема! Откуда мы знаем как вышло так, что там вовсе нет элементов в справочнике? Может нет просто наименований? Может быть базу "обновляли" путем прямой подмены 1cv7.md? Может быть отработала какая то обработка, которая зачистила этот справочник? Да куча нюансов есть! Вдруг у них вообще справочник был доступен для редактирования и туда заносили какие то элементы, а потом их удалили, но в dbf-ах то записи остались, если их не сворачивали, а их 99% пользователей не сворачивают! Так о какой прямой подмене dbf-а может идти речь?
А вообще, если вы такой грамотный, так помогайте тогда сами всем в этом форуме, я больше писать не стану

Про идентификатор SP1054, наверно, волноваться не стоит (если обновление ставили), а вот все остальное верно. Жаль я не успел написать - отвлекли
А вот у ALCOunter чуствуется "полное непонимание ссылочного механизма!". Видимо у него небыло опыта убиения справочника на который многие ссылаются.

А теперь без фокусов: посмотрим как выбираются виды вычетов в реальных модулях ЗиК: это банальный оператор .НайтиПоКоду()
А код - он в любой базе КОД.
И если в документе должен быть выбран вычет "400 руб. на налогоплательщика", то выбираться он будет в любой базе по коду "103" (пока его законодатели не изменят).
А кто что еще навводил (с ДРУГИМИ кодами) - кому это мешает выбрать СТАНДАРТНЫЙ?

ЗЫ
Пишите, помогайте, мне всё равно некогда, это я так, случайно...

ЗЗЫ
Правда интересно - какой вариант прокатит в данном случае?

> А вообще, если вы такой грамотный, так помогайте тогда сами всем в этом форуме, я больше писать не стану

Это вы зря! Сколько раз здесь на форуме появлялись "умники". Ну и что? Где они сейчас? ОБижаться на каждого - смысла никакого! А лучше посмотрите сколько раз вас благодарили! "Спасибо" писали! Скольких людей вы выручили - не сосчитать! По себе знаю! ))
Ради интереса посмотрела профиль ALCOunter- за пять лет "жизни" на форуме практически ничего путнего....

> Что-то похожее, про замену файлов, уже обсуждалось.

А зачем такие "навороты"? "Транрефом" с типовой конфы закачать справочник - слабо?

Нет, нет. Не так. Предопределенный реквизит "Код" в справочниках и поле ID в таблицах базы (внутренний код), по которому организованы связки между ключевыми полями - это разные вещи.
Вот смотрите, пример, который покажет что при подмене dbf-а будет проблема:
Пусть в базе данных имеется сотрудник, для которого заданы сведения о его праве на налоговые вычеты:

Справочник.Сотрудники
Код=00000165, Наименование=Иванов Иван Иванович

Справочник.ВычетыСотрудниковПоНДФЛ
Запись 1:
ВидВычета=400 рублей на налогоплательщика с 01.01.2008 г. (код НДФЛ = 103)
Запись 2:
ВидВычета=на ребенка-инвалида одинокому родителю с 01.01.2008 г. (код НДФЛ=107 до 2009 г., код НДФЛ=112 с 2009 г.)

Соответственно, Справочник.ВидыВычетов
Запись 1:
Код=103, Наименование=400 рублей на налогоплательщика
Запись 2:
Код=112107, Наименование=4000 руб. на каждого ребенка-инвалида до 18 лет, единственному родителю и др.

Теперь смотрим на уровне файлов как реализованы связи.
Справочник.Сотрудники - файл SC16.dbf (имя файла может быть другим)
ID=LJ - внутренний код. На уровне пользователя и конфигурирования его не увидеть никак. Обратите внимание, что именно он является средством для установки связей между таблицами баз, а вовсе не тот код, который мы видем в справочнике, то есть, вовсе не "00000165".
PARENTID=K6 - ссылка на группу, являющуюся "Родителем" данного элемента справочника. Интересно то, что если указать в качестве родителя ссылку "на самого себя", то такая ошибка классифицируется как "неисправимая ошибка базы данных" и не исправляется автоматом через конфигуратор, хотя ничего сложного в том, чтобы поставить ссылку в корневой уровень нет (это разработчикам).
CODE=00000165
DESCR=Иванов Иван Иванович

Справочник.ВидыВычетов
Запись 1:
ID = 3 - вот он код, по которому будет ссылка установлена в таблицах базы, а не "103"
CODE = 103
DESCR = 400 руб. на налогоплательщика, пп.3 п.1 ст.218 НК
Запись 2:
ID = K
CODE = 112107
DESCR = 4000 руб. на каждого ребенка-инвалида до 18 лет, единственному родителю и др.

Справочник.ВычетыСотрудниковПоНДФЛ
Запись 1:
ID = пуст! Поле есть, а значения не будет, так как в конфигураторе указано, что коды в данном справочнике не нужны.
SP1052 = 01.01.2008 - это дата начала, идентификатор поля dbf таблицы может быть иным.
SP1054 = 3 - это ссылка на запись таблицы "ВидыВычетов", причем указано значение не "103", а ID записи, то есть 3, это важно.
Запись 2:
SP1052 = 01.01.2008
SP1054 = K

А теперь возьмем dbf, соответствующий справочнику ВидыВычетов из другой такой же базы. Даже из такого же релиза. И мы там увидим, что ID в dbf-е вовсе не такие как тут!
Справочник.ВидыВычетов
Запись 1:
ID = 4
CODE = 103
DESCR = 400 руб. на налогоплательщика, пп.3 п.1 ст.218 НК
Запись 2:
ID = J
CODE = 112107
DESCR = 4000 руб. на каждого ребенка-инвалида до 18 лет, единственному родителю и др.
Запись 3:
ID = 3
CODE = 105
DESCR = 3000 рублей на налогоплательщика, относящегося к категориям пп. 1 п. 1 ст. 218 НК РФ
Запись 4:
ID = K
CODE = 507
DESCR = Вычет из суммы помощи полученных ветеранами, инвалидами ВОВ и приравненных к ним

Причем это не с потолка взято, я смотрю в реальные файлы баз данных. Одна из них - обновляется с января 2003 года, а вторая = установленная пустышка.
Подменив файл, мы получим, что ссылки в справочнике "ВычетыСотрудниковПоНДФЛ" будут указаны совсем на другие элементы справочника "ВидыВычетов", а часть их вообще окажется "битыми". И это потому, что на самом деле "ссылочный механизм" работает не по кодам, а по внутренним кодам.
Вот вы пишете:
> А кто что еще навводил (с ДРУГИМИ кодами) - кому это мешает выбрать СТАНДАРТНЫЙ
В той базе, в которую я смотрю никто ничего не менял. Она чистая "типовушка", но установленная давно и обновленная раз 20, а вторая - тот же текущий релиз, но установленный с дистрибутива сегодня. Мы же не знаем какая рабочая база у того, кто задавал вопрос. Когда ее ставили? Делали ли в ней что то на уровне конфигурирования? Обновляли ли ее?

одновременный ответ и для Alexandr VA
Обработка, которую я на файлообменник положил задумана была для того чтобы помочь человеку решить его проблему. Я не понял фразу, которую она написала
> Не обновляется справочник Виды вычетов, пустые клетки, редактировать не дает
Подумал о том, что справочник у нее, возможно не пуст и она может перемещатся по форме списка и в вертикальном направлении. Такое возможно, когда элементы в справочнике есть, но наименования и прочие реквизиты визуализации пусты, а поскольку мы не знаем как ее базу поставили, такая ситуация не исключена. Поэтому я сделал так: проверил есть ли у нее в справочнике хоть какие то элементы. Если нет, то запускал алгоритм создания элементов, который просто взял в обработке ОбновлениеИБ и это бы сразу решило ее проблему. Но если элементы там уже есть?! (вот почему не стоит использовать tranref, ведь мы не знаем пуст ли справочник на самом деле, возможно просто убиты реквизиты Код, Наименование и т.п.) И вдруг относительно этих реквизитов описаны права на вычеты 3000 человек? Вы хотите ее заставить заново их описывать? Лучше уж пусть моя обработка скажет, что элементы там уже есть и тогда я бы сделал вторую, которая разобралась бы с тем относительно каких испорченных элементов построены связи и воссоздала бы их наименования, а уж потом дополнила справочник недостающими элементами, которые появились с релиза 288

А я вот не помню - "Транреф" при закачке ориентируется на внутренний идентификатор или на Код? Если на внутренний, тогда создаст новые, зато потом можно изменить все ссылки на эти стандартные.
Хотя, в принципе, можно и закачать, но им явно нужен человек, котороый после этого правильно уберет "пустые клетки".

Большое спасибо всем за советы! Правда с некоторыми долго разбиралась... оказалось все как всегда.... из-за неправильной нумерации документа, обновление не происходило, хотя информация показывала новый релиз... теперь разбираемся в цифрах...

Добрый день.

7,7 ЗиК рел 299. После того как накатил обновление 299 то некоторые элементы в справочнике виды вычетов задвоились. Например сейчас в нем есть два элемента с кодом 307, при этом один из них заполнен в другом пустые клетки. Как можно удалить все эти пустые элементы?

Глянул сразу же SC861 ..там вроде бы все номрально...

Можно ли полностью снести справочник и обновить его?