Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
Есть список контрагентов Некоторые (треть) из них используются 1-3 раза, В конце года бухгалтера (обязательно) будут требовать почистить справочник, как делали раньше в программе на FoxPro, а я не буду соглашаться. Раньше начала каждого года всех вводили и нумеровали (кодировали) заново. Решил всех скрыть добавив поле ... и показывать по мере надобности. Но ходелось бы знать, как делают другие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 11:39 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
Срок подачи исков - 6 месяцев, срок сдачи бухг. баланса - 1 год. Зачем хранить дольше, если можно ненужное отрезать от боевой базы и перенести в архив? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 18:23 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
А налоговая проверяет все со времени прошедшей проверки. (примерно 3 года). Поди непохрани. А сверку с контрагентами делают не каждый год... to 12333 Перекодировать - не совсем верно. Во-первых надо поставить кучу проверок дабы не плодить дубли, во-вторых при обнаружении (сразу) перекидывать сальдо с неправильного кода на правильный, в-третьих помечать неправильный код как "не использовать". И еще можно воспользоваться принципом "плательщик - грузополучатель". То есть выбирается одна организация правильная - а во все другие она проставляется как плательщик. После чего во всех отчетах показываем только основную организацию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 19:47 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
Добавить поле "видимости" в справочник, при выводе старых отчетов и документов это поле не учитываеться, при заведении новых документов и не административном просмотре справочника показывать только "видимые" элементы ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 23:49 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
авторВ конце года бухгалтера (обязательно) будут требовать почистить справочникА зачем это вообще-то делать? Что им нравится ежегодно набирать одни и те же данные? Что не нужна история взаимоотношений с контрагентами? ИМХО: такой подход очень вреден. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2004, 09:29 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
Делать "слияние" - берешь 2 ID, один удаляешь, все FK с удаляемого перевешиваешь на оставшийся, пересчитываешь балансы, если хранятся срезы. Все достаточно просто реализуется, если нет извращенного хранения балансов или первичные документы на одного контрагента проведены с разными именами и должны в дазе совпадать с печатными версиями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2004, 12:18 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
автор..берешь 2 ID.. ага и в рукопашную пошел сравнивать значения справочников.. и потом потребуется доработка модуля, изменение структур (и т.п.), что в таком случае делать с архивами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2004, 13:56 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
IMHO Делается 2 таблицы. Первая - нормальный справочник со всеми атрибутами, вторая - год, ссылка на первый справочник и что-нибудь еще на свой вкус, например, номер в текущем году, суррогатный идентификатор. При добавлении контрагента в текущем году можно предложить выбрать из первой таблицы или ввести новый, при этом по одной записи добавляешь в каждую таблицу. При удалении, удаляешь только из второй. При изменении, выбор - меняешь для всех прошлых, то есть в первой таблице, либо создаешь новую в первой и второй. Можно подумать о хранении истории изменений, но это другая песня. Везде где нужно ссылаться на контрагента, ссылаешься на вторую таблицу, по этой ссылке, естественно, всегда легко достать данные из первой. Главное в этой схеме, контрагенты не могут быть удалены, пока на них существуют ссылки из второй таблицы. Теперь по вопросу видимости, вариантов много, в зависимости от области применения. Разным пользователям по тем или иным соображением часто нужны разные контрагенты, а не весь список, соответственно, желательно иметь таблицу, в которой есть идентификатор пользователя, и ссылка на вторую таблицу, и пользователь сам делает свой индивидуальный справочник. Можно даже добавить четвертую таблицу, в которой будет жить деревья групп, привязанных к пользователям. При этом в третью таблицу можно добавить ссылку на узел этого дерева для каждого контрагента конкретного пользователя. В общем были бы необходимость и желание, а наворотить можно много чего... В том числе - security, и т.д., и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 04:11 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. Вообще, при правильной организации работы этот второй справочник является справочником договоров с поставщиками/покупателями. А т.к. у любого договора есть дата начала и дата окончания, то это и будут условия для отображения конкретного контрагента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 06:43 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
12333 В конце года бухгалтера (обязательно) будут требовать почистить справочник, Если нет желание чистить справочники, нужно сделать все чтобы их не гадили. По данной теме можно предлогать много решений. Но по сути если у вас загаживаются справочники - то попросту бордак в работе и ее организации. Автоматизация бардака приводит только к одному - к автоматизированному бардаку И выход только один - устранить бордак в работе и ее организации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 08:42 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
рубльЕсли нет желание чистить справочники, нужно сделать все чтобы их не гадили. Вы не правильно поняли, в справочники никто и не гадит, ведутся образцово (допустим). Дублей нет. Вопрос в том, что делать со старыми организациями (допустим N-летней давности), которые давно не появляются, а может и нет их давно, НО, может и приедут за продукцией через неделю. Архивы как копии таблиц даже не хочу начинать делать, может стоит сделать отдельную базу-архив.. Так, отвлекся. Собственно склоняюсь к пути olk с полем видимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 15:24 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
Вы не правильно поняли, в справочники никто и не гадит, ведутся образцово (допустим). Дублей нет. Извиняюсь если обидел, коллегу разработчика. Собственно склоняюсь к пути olk с полем видимости. Правельно. Можно также добавить поля даты последней операции с контрагентом (в справочник), каторое будет вестись (прописываться) документом автоматически при формировании. А запрос по контрагентам формировать с учетом: "дата последней операции" > "рабочяя дата" - "один год (к примеру)". При данном подходе нет необходимости проставлять признак "видимости в ручную", а если нужно выбрать за больший период предусматреть либо отмену ограничения или раздвинуть диапазон. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 16:44 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
olkДобавить поле "видимости" в справочникЯ сталкивался с такой проблемой и подошел к ее решению точно таким же способом. Однако, вскорее отказался от такого подхода из-за проблем с интерфейсом. Если, например, во всех экранных формах, комбобокс "Контрагенты" построен на одном и том же базовом запросе, в котором данные фильтруются по флагу "активности", то при открытии такой формы с уже "неактивным" контрагентом, комбик будет пустым, что не очень-то красиво. Опять-таки, надо пробежаться по всем формам и явно переопределить источник данных. А если таких форм много? 12333В конце года бухгалтера (обязательно) будут требовать почистить справочникАга, а потом сами будут дико возмущаться "Куда подевались данные?" Вообще, идти на поводу у пользователей, - это значит обрекать себя на решение множества ненужных проблем. Своим пользователям я запретил не только удалять данные там, где есть подчиненные записи (никаких delete cascade!), но и в некоторых справочниках даже редактировать. Покричали, поворчали, как положено, мол, "в старой программе было лучше", а потом ничего, привыкли, даже стало нравиться. Почему они хотели избавиться от "неактивных" записей? Да просто потому, что выбор осуществлялся мышкой из комбика. Их просто раздражало их количество и то обстоятельство, что с каждым днем мышкой выбирать становится все труднее! Работайте с клавиатурой! Я просто их приучил вводить сразу числовой код, и, хотя по началу было очень много крика: "Я, что, должна, все коды наизусть помнить?!", на практике выснилось, что эти коды запоминаются куда быстрее, чем наименования (имеется ввиду, как они записаны в базе данных). А уж если и не вспомнить никак, то уж тогда и открыть справочник, да и поискать в нем... Пользователя воспитывать надо, а не потакать ему! :-) Если же подходить к решению данного вопроса на уровне системы, то здесь можно попробовать такой способ, основанный на ведении учета по периодам. 1. Создается таблица "контрагенты" - "кубышка", в которой хранятся абсолютно все контрагенты со всеми реквизитами. 2. Создается таблица "контрагенты_текущего_периода", представляющая собой relation на таблицу "контрагенты". Далее все просто. В текущем периоде в эту таблицу заносятся (выбираются из таблицы "контрагенты") только необходимые записи (если таковые отсутствуют в главной таблице, то ручной ввод). Неудобством такого подхода является тот факт, что при открытии каждого следующего периода таблица "контрагенты_текущего_периода" всякий раз будет пуста. Впрочем, вот здесь-то как раз и нужен какой-нибудь флажок "активности", чтобы процесс заполнения таблицы "контрагенты_текущего_периода" по максимуму автоматизировать при закрытии/открытии периода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 16:53 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
Ну дыкть.. если база позволяет хранить старые периоды, если при этом ее увеличение не влияет на работоспособность - о чем тогда речь. А если будет как у меня - 6Гиг биллинга в месяц - придется резать и архивировать, резать и архивировать :) По контрагентам - IMHO было бы удобно создать бизнес-правило, определяющее рейтинг(или вообще видимость) конкретного контрагента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 16:57 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
G0b1inА если будет как у меня - 6Гиг биллинга в месяц - придется резать и архивировать, резать и архивировать :) А почему это должно относится к контрагентам? Если резать, то уж данные, а не справочники. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2004, 11:03 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
Всем спасибо. Я удовлеворен. :) Все понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2004, 12:05 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
Dik76А почему это должно относится к контрагентам? Если резать, то уж данные, а не справочники. Логично. Просто справочники достаточно активно редактируются, а нужна возможность легко восстановить состояние базы на любой момент времени, поэтому раз в месяц полный бэкап базы, и данные, и справочники, архивируются, после чего ненужная часть данных удаляется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2004, 15:22 |
|
||
|
А что вы делаете с такими записями ?
|
|||
|---|---|---|---|
|
#18+
авторЕсть список контрагентов Если Вы - юридическое лицо и работаете с юридическими лицами, то думаю нет смысла денормализовывать ваш справочник контрагентов для системы OLTP ведением собственной кодировки. Сделайте первичным ключ - Атрибут ИНН. +небольшая процедура по генерации левых ИНН на случай временного отсутствия информации по нему +административное давление на операторов по обязательному вводу данной информации ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2004, 07:50 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32516491&tid=1546482]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
181ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 540ms |

| 0 / 0 |
