Добавлено: Пт Апр 11, 2008 8:54 am Заголовок сообщения:
А вообще-то все свойства объектов и БД Акцента: и защищенный период и автонумерацию, и параметры с фактами для разных разделителей учета (Моих фирм) должны быть разделены. Иначе весь глубокий смысл ведения нескольких фирм теряется.
При таком раскладе можно было бы ПОЧТИ безболезненно решать и вопросы с различными настройками.
Добавлено: Пт Апр 11, 2008 9:54 am Заголовок сообщения:
fly писал(а):
А вообще-то все свойства объектов и БД Акцента: и защищенный период и автонумерацию, и параметры с фактами для разных разделителей учета (Моих фирм) должны быть разделены. Иначе весь глубокий смысл ведения нескольких фирм теряется.
При таком раскладе можно было бы ПОЧТИ безболезненно решать и вопросы с различными настройками.
Совместный учет нескольких компаний в одной базе имеет смысл только в случае, если : одинаковая метода учета и большнство корреспондентов общие. Иначе нужно делить на разные базы.
Добавлено: Сб Апр 12, 2008 9:48 am Заголовок сообщения:
olimp писал(а):
Совместный учет нескольких компаний в одной базе имеет смысл только в случае, если : одинаковая метода учета и большнство корреспондентов общие. Иначе нужно делить на разные базы.
Хорошо бы было в качестве разделителя учёта сделать поддержку драг-энд-дропа корреспондентов, объектов, отчётов, шаблонов и документов между базами.
Цены бы Акценту не было. Я предлагал когда-то, наверно очень уж давно.
А вообще-то все свойства объектов и БД Акцента: и защищенный период и автонумерацию, и параметры с фактами для разных разделителей учета (Моих фирм) должны быть разделены. Иначе весь глубокий смысл ведения нескольких фирм теряется.
При таком раскладе можно было бы ПОЧТИ безболезненно решать и вопросы с различными настройками.
Совместный учет нескольких компаний в одной базе имеет смысл только в случае, если : одинаковая метода учета и большнство корреспондентов общие. Иначе нужно делить на разные базы.
У меня таких периодических клиентов - пруд-пруди. Они еще и доплачивать будут, если им чужих корреспондентов "доливать".
А холдинговая структура, когда у тебя в одной базе накапливаются данные по всем филиалам или дочерним предприятиям?
Автонумерация и защ.период однозначно должны быть разными!
Добавлено: Вт Дек 14, 2010 11:28 am Заголовок сообщения:
А кто-нибудь решал данную проблему для разных документов?
Пример прост: есть заявления на выплату страховки, по которым документы от клиента могут доноситься хоть несколько лет, а заявления (документы) внесены еще в "позапрошлом году".
Вариант апдейта некоторых полей хранимкой (который я использую в некоторых документах) в данном случае не катит, потому что в общем случае изменяться могут любые параметры документа. А параметров этих, чтобы не соврать, под сотню.
Пока что выкрутился самописными хранимками на апдейт SYS_PARAMS, а между ними RefreshPeriod, но у такого подхода есть очень-преочень существенные недостатки:
1. В промежутке может влезть кто-то, кому открытый период не предназначался.
2. Если (вдруг) в промежутке отвалится Акцент или коннект к серверу, то период так и останется открытым.
Оба события достаточно маловероятны, но статистика вещь упорная...
А кто-нибудь решал данную проблему для разных документов?
Правильная стратегия, имхо, вытаскивать значения параметров - на дату.
Я сейча пишу систему управления договорами. Договор м.б. создан на условиях 1, а в момент ХХХХ поменять свои существенные условия. Приходится вытягивать максимальную дату для непустого значения параметра. Действующие значения договоров таким образом собираются из последних внесенных значений данных параметров.
Это-то понятно, у меня все точно так же организовано по договорам...
Проблема такого рода возникает именно по таким типам документов, как заявление на выплату. Вспомните сами, как быстро вы собираете справки за поцарапанный бок машины если сумма выплаты там пару сотен гривен? А суть именно в том, что это - один документ. Можно, конечно, городить суперпозицию множества документов и т.д., но смысла это не имеет - путает пользователя, дорого стоит в разработке и вообще нафиг никому не надо. Потому что как говорит аварийный комиссар "а вот тут у меня лежит папочка и я докладываю в нее бумажки. принес бумажку через полгода - докладываю. не принес никогда, так она и лежит пока по сроку давности не спишем"
А суть именно в том, что это - один документ. Можно, конечно, городить суперпозицию множества документов и т.д., но смысла это не имеет - путает пользователя, дорого стоит в разработке и вообще нафиг никому не надо.
Ошибаешься.
1.Модификация закрытого периода - суть зло
2.Как быть, если необходимо откатить данные? Принес клиент справку, ее внесли в систему, потом выяснилось, что справка не подходит????? Опять лезть в закрытый период?
3. Я долго искал альтернативу внесения меняющися данных....ничего универсальнее документов - не нашел.
КАк частный случай - заводить аналитику "Разное" на каждый страховой случай, и там в фактах творить все, что вздумается
Добавлено: Ср Дек 15, 2010 9:20 am Заголовок сообщения:
AllexL писал(а):
Ошибаешься.
1.Модификация закрытого периода - суть зло
2.Как быть, если необходимо откатить данные? Принес клиент справку, ее внесли в систему, потом выяснилось, что справка не подходит????? Опять лезть в закрытый период?
3. Я долго искал альтернативу внесения меняющися данных....ничего универсальнее документов - не нашел.
КАк частный случай - заводить аналитику "Разное" на каждый страховой случай, и там в фактах творить все, что вздумается
1. Полностью согласен.
2. В данном конкретном случае - именно так. И от этого ничего принципиально не изменится в учете (подчеркиваю - именно в данном конкретном случае).
3. Я тоже. Как бы юзер не сопротивлялся, все равно по зрелости доходит до этого.
Аналитика в данном случае не очень-то удобоварима, т.к. на данный момент в классе уже есть порядка 150 переменных, включая множество AgentBind, EntBind и т.д. Описать их всех через временную операцию, конечно, можно... Но стоимость возрастет как минимум в несколько раз. А клиент такого не понимает и платить лишнее (по его мнению) не хочет. Вот и выкручиваемся
Добавлено: Сб Апр 28, 2012 10:30 am Заголовок сообщения:
Еще вопрос (или скорее предложение?) по защищенному периоду. Есть Workarea.RefreshPeriod, есть даже Workarea_OnProtectedPeriodChanged (ценность коего, как по мне, - весьма сомнительна). Но нет Workarea.ProtectedPeriod.Start и Workarea.ProtectedPeriod.End. Почему? Очень хочу перед сохранением проверять, попадает ли документ в открытый период и если нет - что-то делать. Не суть важно, что именно делать. Потому что сейчас программно я вижу только Op.Save = (true, false). А почему false - не знаю. Может прав не хватает, а может в закрытом периоде (ну вылетел диалог юзеру, но программа-то его не видит), а может вообще мыши провода погрызли.
Да, пока обхожусь считыванием на Workarea_OnLoad в мап с помощью ap_sysperiod_load, но не красиво как-то.
Добавлено: Сб Апр 28, 2012 11:12 am Заголовок сообщения:
kris писал(а):
Еще вопрос (или скорее предложение?) по защищенному периоду. Есть Workarea.RefreshPeriod, есть даже Workarea_OnProtectedPeriodChanged (ценность коего, как по мне, - весьма сомнительна). Но нет Workarea.ProtectedPeriod.Start и Workarea.ProtectedPeriod.End. Почему? Очень хочу перед сохранением проверять, попадает ли документ в открытый период и если нет - что-то делать. Не суть важно, что именно делать. Потому что сейчас программно я вижу только Op.Save = (true, false). А почему false - не знаю. Может прав не хватает, а может в закрытом периоде (ну вылетел диалог юзеру, но программа-то его не видит), а может вообще мыши провода погрызли.
Да, пока обхожусь считыванием на Workarea_OnLoad в мап с помощью ap_sysperiod_load, но не красиво как-то.
Да, все верно. Должен быть какой-то метод с прототипом а-ля
Код:
errosList() Operation.CheckBeforeSave()
, где возвращался бы список причин, по которым документ не мог быть сохранен в базе. Валидация перед сохранением
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах