Список форумов Акцент Акцент
официальный форум разработчика программы Акцент
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 

Защищенный период
На страницу Пред.  1, 2, 3
 
Начать новую тему   Ответить на тему    Список форумов Акцент -> Акцент 7.0
Предыдущая тема :: Следующая тема  
Автор Сообщение
fly



Зарегистрирован: 31.05.2005
Сообщения: 108

СообщениеДобавлено: Пт Апр 11, 2008 8:54 am    Заголовок сообщения: Ответить с цитатой

А вообще-то все свойства объектов и БД Акцента: и защищенный период и автонумерацию, и параметры с фактами для разных разделителей учета (Моих фирм) должны быть разделены. Иначе весь глубокий смысл ведения нескольких фирм теряется.
При таком раскладе можно было бы ПОЧТИ безболезненно решать и вопросы с различными настройками.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
olimp
Site Admin


Зарегистрирован: 10.03.2005
Сообщения: 2661

СообщениеДобавлено: Пт Апр 11, 2008 9:54 am    Заголовок сообщения: Ответить с цитатой

fly писал(а):
А вообще-то все свойства объектов и БД Акцента: и защищенный период и автонумерацию, и параметры с фактами для разных разделителей учета (Моих фирм) должны быть разделены. Иначе весь глубокий смысл ведения нескольких фирм теряется.
При таком раскладе можно было бы ПОЧТИ безболезненно решать и вопросы с различными настройками.

Совместный учет нескольких компаний в одной базе имеет смысл только в случае, если : одинаковая метода учета и большнство корреспондентов общие. Иначе нужно делить на разные базы.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Юров Ю.С.



Зарегистрирован: 11.03.2005
Сообщения: 383
Откуда: Павлоград

СообщениеДобавлено: Сб Апр 12, 2008 9:48 am    Заголовок сообщения: Ответить с цитатой

olimp писал(а):
Совместный учет нескольких компаний в одной базе имеет смысл только в случае, если : одинаковая метода учета и большнство корреспондентов общие. Иначе нужно делить на разные базы.

Хорошо бы было в качестве разделителя учёта сделать поддержку драг-энд-дропа корреспондентов, объектов, отчётов, шаблонов и документов между базами.
Цены бы Акценту не было. Я предлагал когда-то, наверно очень уж давно.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
AllexL



Зарегистрирован: 10.03.2005
Сообщения: 434
Откуда: Donetsk

СообщениеДобавлено: Пн Апр 14, 2008 9:16 am    Заголовок сообщения: Ответить с цитатой

Ага, еще и множественное выделение сущностей, хотя-бы для целей КОПИ_ПАСТА
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
fly



Зарегистрирован: 31.05.2005
Сообщения: 108

СообщениеДобавлено: Вт Апр 15, 2008 1:15 pm    Заголовок сообщения: Ответить с цитатой

olimp писал(а):
fly писал(а):
А вообще-то все свойства объектов и БД Акцента: и защищенный период и автонумерацию, и параметры с фактами для разных разделителей учета (Моих фирм) должны быть разделены. Иначе весь глубокий смысл ведения нескольких фирм теряется.
При таком раскладе можно было бы ПОЧТИ безболезненно решать и вопросы с различными настройками.

Совместный учет нескольких компаний в одной базе имеет смысл только в случае, если : одинаковая метода учета и большнство корреспондентов общие. Иначе нужно делить на разные базы.


У меня таких периодических клиентов - пруд-пруди. Они еще и доплачивать будут, если им чужих корреспондентов "доливать".
А холдинговая структура, когда у тебя в одной базе накапливаются данные по всем филиалам или дочерним предприятиям?

Автонумерация и защ.период однозначно должны быть разными!
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
fly



Зарегистрирован: 31.05.2005
Сообщения: 108

СообщениеДобавлено: Вт Апр 15, 2008 1:19 pm    Заголовок сообщения: Ответить с цитатой

Paul писал(а):
Кто-нибудь решил проблему отдельных защищенных периодов для разных пользователей в общем виде?


У меня это работает без применения T-SQL. Если едешь в "Пограничник" в этом году, могу показать.
Very Happy И всем желающим тоже Very Happy

Но решение будет нормально работать, если есть общий модуль обработки событий для всех или большинства форм. Остальных, я думаю, не заинтересует.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
kris



Зарегистрирован: 12.01.2006
Сообщения: 371

СообщениеДобавлено: Вт Дек 14, 2010 11:28 am    Заголовок сообщения: Ответить с цитатой

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

Пока что выкрутился самописными хранимками на апдейт SYS_PARAMS, а между ними RefreshPeriod, но у такого подхода есть очень-преочень существенные недостатки:
1. В промежутке может влезть кто-то, кому открытый период не предназначался.
2. Если (вдруг) в промежутке отвалится Акцент или коннект к серверу, то период так и останется открытым.
Оба события достаточно маловероятны, но статистика вещь упорная...
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
AllexL



Зарегистрирован: 10.03.2005
Сообщения: 434
Откуда: Donetsk

СообщениеДобавлено: Вт Дек 14, 2010 12:46 pm    Заголовок сообщения: Ответить с цитатой

kris писал(а):
А кто-нибудь решал данную проблему для разных документов?

Правильная стратегия, имхо, вытаскивать значения параметров - на дату.
Я сейча пишу систему управления договорами. Договор м.б. создан на условиях 1, а в момент ХХХХ поменять свои существенные условия. Приходится вытягивать максимальную дату для непустого значения параметра. Действующие значения договоров таким образом собираются из последних внесенных значений данных параметров.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
kris



Зарегистрирован: 12.01.2006
Сообщения: 371

СообщениеДобавлено: Вт Дек 14, 2010 3:31 pm    Заголовок сообщения: Ответить с цитатой

Это-то понятно, у меня все точно так же организовано по договорам...
Проблема такого рода возникает именно по таким типам документов, как заявление на выплату. Вспомните сами, как быстро вы собираете справки за поцарапанный бок машины если сумма выплаты там пару сотен гривен? А суть именно в том, что это - один документ. Можно, конечно, городить суперпозицию множества документов и т.д., но смысла это не имеет - путает пользователя, дорого стоит в разработке и вообще нафиг никому не надо. Потому что как говорит аварийный комиссар "а вот тут у меня лежит папочка и я докладываю в нее бумажки. принес бумажку через полгода - докладываю. не принес никогда, так она и лежит пока по сроку давности не спишем"
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
AllexL



Зарегистрирован: 10.03.2005
Сообщения: 434
Откуда: Donetsk

СообщениеДобавлено: Вт Дек 14, 2010 5:15 pm    Заголовок сообщения: Ответить с цитатой

kris писал(а):
А суть именно в том, что это - один документ. Можно, конечно, городить суперпозицию множества документов и т.д., но смысла это не имеет - путает пользователя, дорого стоит в разработке и вообще нафиг никому не надо.

Ошибаешься.
1.Модификация закрытого периода - суть зло
2.Как быть, если необходимо откатить данные? Принес клиент справку, ее внесли в систему, потом выяснилось, что справка не подходит????? Опять лезть в закрытый период?
3. Я долго искал альтернативу внесения меняющися данных....ничего универсальнее документов - не нашел.

КАк частный случай - заводить аналитику "Разное" на каждый страховой случай, и там в фактах творить все, что вздумается
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
kris



Зарегистрирован: 12.01.2006
Сообщения: 371

СообщениеДобавлено: Ср Дек 15, 2010 9:20 am    Заголовок сообщения: Ответить с цитатой

AllexL писал(а):

Ошибаешься.
1.Модификация закрытого периода - суть зло
2.Как быть, если необходимо откатить данные? Принес клиент справку, ее внесли в систему, потом выяснилось, что справка не подходит????? Опять лезть в закрытый период?
3. Я долго искал альтернативу внесения меняющися данных....ничего универсальнее документов - не нашел.

КАк частный случай - заводить аналитику "Разное" на каждый страховой случай, и там в фактах творить все, что вздумается

1. Полностью согласен.
2. В данном конкретном случае - именно так. И от этого ничего принципиально не изменится в учете (подчеркиваю - именно в данном конкретном случае).
3. Я тоже. Как бы юзер не сопротивлялся, все равно по зрелости доходит до этого.

Аналитика в данном случае не очень-то удобоварима, т.к. на данный момент в классе уже есть порядка 150 переменных, включая множество AgentBind, EntBind и т.д. Описать их всех через временную операцию, конечно, можно... Но стоимость возрастет как минимум в несколько раз. А клиент такого не понимает и платить лишнее (по его мнению) не хочет. Вот и выкручиваемся Sad
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
kris



Зарегистрирован: 12.01.2006
Сообщения: 371

СообщениеДобавлено: Сб Апр 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, но не красиво как-то.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
AllexL



Зарегистрирован: 10.03.2005
Сообщения: 434
Откуда: Donetsk

СообщениеДобавлено: Сб Апр 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()
, где возвращался бы список причин, по которым документ не мог быть сохранен в базе. Валидация перед сохранением
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
Показать сообщения:   
Начать новую тему   Ответить на тему    Список форумов Акцент -> Акцент 7.0 Часовой пояс: GMT + 2
На страницу Пред.  1, 2, 3
Страница 3 из 3

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах


Powered by phpBB © 2001, 2005 phpBB Group