|
|
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
Очевидно, что при изменении, скажем, ИНН контрагента, в справочнике контрагентов должен заводиться новый объект. А вот как поступать, когда меняется только название контрагента? Например, ИП Пупкина А.Н. вышла замуж, и стала ИП Васечкиной А.Н., но ИНН переоформлять не стала, ограничившись подачей данных на внесение изменений в базу ИНН. Или некое мунициальное предприятие в результате слияния с другим таким же переименовывается, оставляя ИНН одной из участников слияния в качестве своего. Заводить в этом случае нового контрагента не хочется - не хочется позволять иметь в базе контрагентов, имеющих одно и то же сочетание ИНН/КПП. С другой стороны, если вести историю изменения названия для этого же объекта, это будет усложнять запросы. С третьей стороны, изменение названия объекта без сохранения истории приведет к потере информации о старых названиях. И так нехорошо, и так нехорошо. Вот, решила поинтересоваться, как это у народа сделано, на практике. Какое "меньшее зло" выбрали, и не жалеют ли о сделанном выборе. Или, быть может, есть какой-то идеальный вариант (или, наоборот, подводные камни), которые я не учла... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2007, 18:27 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
Одно из решений: Таблица содержит поле ACTUAL_ID и дату прекращения актуальности, выбрав заранее недостижимое значение для актуальной записи, например 01.01.4012 (Oracle). При изменении реквизитов создавать новую запись с простановкой в старой даты изменения, а в новой - условную бесконечность. Для получения объектов, связанных с актуальным и всеми его предыдущими инкарнациями достаточно в запросах указывать конструкцию Код: plaintext Код: plaintext Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2007, 06:19 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
Сорри, в первом запросе недосказал, что это только часть подзапроса. Еще вариант хранения: отдельная таблица истории изменений, которая имеет свой идентификатор и ключ в виде идентификатора клиента и даты окончания/начала актуальности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2007, 06:43 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
KateryneОчевидно, что при изменении, скажем, ИНН контрагента, в справочнике контрагентов должен заводиться новый объект. И вовсе не очевидно. У Вас справочник ИННов или справочник контрагентов? KateryneА вот как поступать, когда меняется только название контрагента? Вам необходимо хранить историю изменений полей справочника, если это действительно надо. KateryneИ так нехорошо, и так нехорошо. Точнее, и так придется работать, и эдак. Само везде не сделается. KateryneВот, решила поинтересоваться, как это у народа сделано, на практике. Есть варианты, где история не ведется вообще. Есть варианты, где протоколирование изменений навешивается практически на любое поле (в данном случае со строковым полем проблем вообще никаких нет) и в нужных отчетах тащится последнее актуальное значение на требуемую дату. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2007, 10:09 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
Обычно создаётся примерно такая схема БД: Код: plaintext 1. 2. В результает встаёт проблема - при изменении данных контрагента изменяются и данные всех связанных с ним документов, а это как правило не то что нам нужно. Тогда встаёт вопрос хранения истории контрагента. Вариантов может быть много, лично мне больше нравится следующий. Если рассмотреть эту задачу с позиции построения DWH, то таблица "документ" по сути является таблицей фактов, тогда как таблица "контрагент", похожа на таблицу измерений, но в силу своей изменчивости не может быть таковой. Напрашивается решение - завести таблицу контрагентов с теми данными, которые фигурируют или должны фигурировать в документе. По структуре такая таблица может содержать все поля из таблицы "контрагент", плюс идентифицирующее поле конкретной версии данных. В итоге имеем такую схему: Код: plaintext 1. 2. 3. 4. Кто то скажет, а почему бы не слить таблицы контрагент и контрагент_история. Это вполне возможно, но тогда придётся вводить статусы актуальности данных контрагента, отслеживать права на изменение записей, которые могли поучаствовать в документах и т.п. В добавок, в оперативной таблице "контрагент" постепенно будут накапливаться исторические данные, которые уже не нужны для текущих операций, что может негативно сказаться на производительности системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2007, 11:05 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
KateryneА вот как поступать, когда меняется только название контрагента? Старое название контрагента должно фигурировать как минимум при перепечатке старых документов, да и при поиске пригодится. Поэтому от истории никуда не денешься. Вести отдельную "историю изменения названия" - имхо глупо. Я предпочитаю нормальный SCD2 (грубо говоря, object_id, version_id (pk), .. поля данных .., date_from, date_to. Декларативное ограничение на ИНН+КПП можно сделать следующим образом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2007, 12:19 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
Kateryne Посмотрите на задачу немного проще. у Вас есть контрагент, с которым, допустим, Вы выполняете взаиморасчеты и есть множество записей реквизитов, значения которых используются в документах. Запись реквизитов содержит ссылку на запись контрагента, имеет статус (активная в настоящий момент или нет). Некоторые делают период действия записи, но это лишнее, статуса для текущего момента достаточно, позволяет исключить недействительные в данный момент записи при выборе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2007, 16:49 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
Отслеживание истории значения - очень часто бывает крайне полезным. Тут возможны два случая 1) Вы просто ведете историю для протокола - что бы знать, например, кто и когда изменил значение цены и использовать эту информацию в "ручном" режиме. 2) Использосать историю в логике приложения (например курс вылюты на вчера, позавчера и т.д.) Для первого случая достаточно организовать триггер который пишет в отдельную таблицу старое значение, а в основной таблице остается новое значение. Тут главное предусмотреть постоянство или каскадное изменение превичного ключа. Второй случай активно использовался в 1С 7.7. Но в 8.0 от такого решения отказаличь в пльзу регистров сведений. (Конфигурить стало труднее) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2007, 22:49 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
apapacyОтслеживание истории значения - очень часто бывает крайне полезным. Тут возможны два случая 1) Вы просто ведете историю для протокола - что бы знать, например, кто и когда изменил значение цены и использовать эту информацию в "ручном" режиме. 2) Использосать историю в логике приложения (например курс вылюты на вчера, позавчера и т.д.) Для первого случая достаточно организовать триггер который пишет в отдельную таблицу старое значение, а в основной таблице остается новое значение. Тут главное предусмотреть постоянство или каскадное изменение превичного ключа. Второй случай активно использовался в 1С 7.7. Но в 8.0 от такого решения отказаличь в пльзу регистров сведений. (Конфигурить стало труднее) т.е. в 1С 8 уже не используются курсы валют и другие периодические индикаторы? Господа поклонники, вы хоть читайте свои сообщения перед тем, как нажать кнопку Опубликовать p.s. история изменений..., конечно круто. только как связано с обсждаемой темой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2007, 01:33 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
iscrafm apapacy Второй случай активно использовался в 1С 7.7. Но в 8.0 от такого решения отказаличь в пльзу регистров сведений. (Конфигурить стало труднее) т.е. в 1С 8 уже не используются курсы валют и другие периодические индикаторы? Господа поклонники, вы хоть читайте свои сообщения перед тем, как нажать кнопку Опубликовать p.s. история изменений..., конечно круто. только как связано с обсждаемой темой? Возвращаю Вам Ваш же постскрипт. 1) В 8.0 история реализуется по-другому - регистрами сведений. Больше нужно кодировать. В 7.0 история значения реализовывалась заданиям флажка в конфигураторе. Какие могут быть вопросы? 2) ИМХО об истории значений в этом топике и говорится. 3) Критику воспринял - перечитал свое сообщение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2007, 14:01 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
Ну, речь не об истории любых значений - а конкретно об истории неких данных контрагента. Скажем, история цен или история курсов валют - там все понятно, необходимость в подобном несомненна, реализация обычно тоже отличается только деталями... А вот с историей данных контрагента для меня не так очевидно - именно в контексте сочетания "Удобство пользователя - Сохранение истории - Скорость работы запросов". Вариант softwarer, согласна, в целом, более правильный... хотя у нас я не вижу других реквизитов, кроме наименования, которые имело бы смысл хранить хронологически. Я так понимаю, что при этом варианте предлагается хранить ссылку в документах на родительскую запись? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 17:52 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
apapacyОтслеживание истории значения - очень часто бывает крайне полезным. Тут возможны два случая 1) Вы просто ведете историю для протокола - что бы знать, например, кто и когда изменил значение цены и использовать эту информацию в "ручном" режиме. 2) Использосать историю в логике приложения (например курс вылюты на вчера, позавчера и т.д.) Для первого случая достаточно организовать триггер который пишет в отдельную таблицу старое значение, а в основной таблице остается новое значение. Тут главное предусмотреть постоянство или каскадное изменение превичного ключа. Я бы сказал, что во втором случае нас интересует на сам атрибут, а график изменения атрибута. В принципе график можно строить делая срезы текущего значения, но рано или поздно очередное текущее значение будет занесено с ошибкой и эта ошибка станет срезом, причём формально не доступным для исправления. Т.е. тут лучше говорить о редактировании произвольной точки такого графика, ну а срез на текущий момент, это просто одно из представлений таких данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 20:27 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
KateryneВариант softwarer, согласна, в целом, более правильный... хотя у нас я не вижу других реквизитов, кроме наименования, которые имело бы смысл хранить хронологически. Зависит от того, что вы делаете, но в целом даже если сейчас ничего нет - можно ожидать, что появятся. Я бы сказал, как правило очень мало атрибутов, которые ну совсем никогда не потребуются хронологическими. KateryneЯ так понимаю, что при этом варианте предлагается хранить ссылку в документах на родительскую запись? Он не ограничивает Вас. В одном случае можете хранить ссылку на конкретную версию - и получите простые запросы. В другом - хранить ссылку на "родительскую", а версию выбирать условием по дате. Тут уже вопрос бизнес-логики в каждом конкретном случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 20:43 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
Такой вот измышлизм. А зачем вообще конструировать документ из записи "документ" и записи из справочника? Гораздо безопаснее при заведении документа просто скопировать данные из справочник в запись "документ", тогда задача сохранения истории изменений справочника перестанет трогать части системы, которые не относятся к справочникам. Хочешь, сохраняй историю справочника, хочешь, оставляй только актуальные записи. Нашёл ошибку? Исправь. С другой стороны сведения сохранённые в документах могут служить для получения истории изменения реквизитов, правда периоды, когда документальные отношения с клиентом не поддерживались, выпадут из рассмотрения, но они скорее всего и не нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 21:26 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
mcureenabТакой вот измышлизм. А зачем вообще конструировать документ из записи "документ" и записи из справочника? Гораздо безопаснее при заведении документа просто скопировать данные из справочник в запись "документ" сейчас Вас порвут фаны нормализации всего и вся. Рисковый :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 21:33 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
mcureenabТакой вот измышлизм. А зачем вообще конструировать документ из записи "документ" и записи из справочника? Гораздо безопаснее при заведении документа просто скопировать данные из справочник в запись "документ", Гораздо гиморнее, я бы сказал. Как при кодировании, так и - что гаже - при исправлении ситуации "в реквизитах была опечатка". Подчеркиваю: речь идет не об истории реквизитов, а об исправлении ошибки при сохранении "истории как она есть". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 21:40 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
softwarer mcureenabТакой вот измышлизм. А зачем вообще конструировать документ из записи "документ" и записи из справочника? Гораздо безопаснее при заведении документа просто скопировать данные из справочник в запись "документ", Гораздо гиморнее, я бы сказал. Как при кодировании, так и - что гаже - при исправлении ситуации "в реквизитах была опечатка". Подчеркиваю: речь идет не об истории реквизитов, а об исправлении ошибки при сохранении "истории как она есть". Хм. В документах найти ошибку гораздо проще чем в справочнике, особенно, когда документ оформляется электронно, а затем отдаётся на проверку и подпись. Наш справочник клиента (да и вообще никого кроме оператора, который отвечает за ввод документов) никак не бодает, другое дело документ, который он заверяет своей подписью. Хотя наверное нужно различать ситуации. Если ошибка в конкретном документе, который сразу проверяется ответственным лицом, то её проще исправить на месте. Если ошибка бесконтрольно растиражирована во многие другие записи, то тут конечно гемор ещё тот будет полюбому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 21:52 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
mcureenabХм. В документах найти ошибку гораздо проще чем в справочнике, особенно, когда документ оформляется электронно, а затем отдаётся на проверку и подпись. "Документ" в представлении пользователя - вовсе не "запись в таблице" в нашем представлении. С точки зрения "проверки и подписи" пользователю нет разницы, хранятся ли реквизиты в документе или нет, он этого просто не знает, да и знал бы - не думал бы об этом. mcureenabХотя наверное нужно различать ситуации. Если ошибка в конкретном документе, который сразу проверяется ответственным лицом, то её проще исправить на месте. В худшем случае мы при этом получим следующий замечательный вариант: в справочнике ошибка, при каждом копировании она переносится в документ, там ответственное лицо "правит ее на месте" (если не забудет, конечно). Потому как сами знаете - компьютерщики сволочи, помогать не хотят, договориться с ними сложно, лучше я сам буду эту цифирку всегда исправлять. mcureenabЕсли ошибка бесконтрольно растиражирована во многие другие записи, то тут конечно гемор ещё тот будет полюбому. В случае справочника версий - в среднем намного меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 22:46 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
softwarer mcureenabЕсли ошибка бесконтрольно растиражирована во многие другие записи, то тут конечно гемор ещё тот будет полюбому. В случае справочника версий - в среднем намного меньше. Дело скорее не в количестве. Какие проблемы update всех ошибочных записей в таблице выполнить?.. При использовании справочника можно по ограничениям ссылочной целостности оттрассировать документы в которые растиражирована ошибка. Если данные копировать из справочника в документ, то заботится о трассируемости придётся отдельно. Тут похоже хрен редьки не слаще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 23:14 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
softwarer mcureenabХотя наверное нужно различать ситуации. Если ошибка в конкретном документе, который сразу проверяется ответственным лицом, то её проще исправить на месте. В худшем случае мы при этом получим следующий замечательный вариант: в справочнике ошибка, при каждом копировании она переносится в документ, там ответственное лицо "правит ее на месте" (если не забудет, конечно). Потому как сами знаете - компьютерщики сволочи, помогать не хотят, договориться с ними сложно, лучше я сам буду эту цифирку всегда исправлять. Да. Вариант неприятный. Но это тут можно навесить бизнес правило, типа немоги исправлять данные. Т.е. можно запрещать, можно разрешать, можно слать заявку на актуализацию справочника и т.д. А когда ограничение прошито в структуре БД, то порядок остаётся только один. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 23:21 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
mcureenabА когда ограничение прошито в структуре БД, то порядок остаётся только один. Именно так. Надежны только те решения, которые поддерживаются технической реализацией. Например, вместо бизнес-правила "не наступай на мину" - просто взять и разминировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 21:36 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
mcureenabГораздо безопаснее при заведении документа просто скопировать данные из справочник в запись "документ", тогда задача сохранения истории изменений справочника перестанет трогать части системы, которые не относятся к справочникам. Согласен на все 100%. Документ - это Документ. Если запись в справочнике была одна, а завтра стала другая (ошибка или изменение значение - не суть важно) - Ваш документ уже пошел гулять по свету - в налоговую, в банк и т. п. И помнить что там было отправлено, а не то что осталось в справочнике - необходимо. Конечно, позволять редактировать пользователю ключевые (в обычном смыле слова) реквизиты - неправильно. Если заметили ошибку - пусть исправляют правильно и с ведома лиц, отвечающих за ведение справочника (например товароведов или ИТ-специалистов). А что до нормализации - так некторые предлагают и цену из накладной хранить в справочнике - и напрочь убрать из накладной - ищи потом ветра в поле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 22:44 |
|
||
|
Изменение названия контрагента без изменения реквизитов
|
|||
|---|---|---|---|
|
#18+
softwarer mcureenabА когда ограничение прошито в структуре БД, то порядок остаётся только один. Именно так. Надежны только те решения, которые поддерживаются технической реализацией. Например, вместо бизнес-правила "не наступай на мину" - просто взять и разминировать. Но тогда враг безнаказанно пройдёт... Ясен пень, жёсткая система скорее всего надёжнее гибкой конфигурируемой, но и предметная область жёсткой системы меньше чем у гибкой. В общем как всегда идеального решения на все случаи жизни нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 23:40 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1544164]: |
0ms |
get settings: |
9ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
169ms |
get topic data: |
9ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 254ms |
| total: | 517ms |

| 0 / 0 |
