Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
AllexL
Зарегистрирован: 10.03.2005 Сообщения: 434 Откуда: Donetsk
|
Добавлено: Вт Сен 20, 2011 12:03 pm Заголовок сообщения: Помощь в формировании связей между документами |
|
|
Уважаемые коллеги,
Ищу помощи в моделировании ситуации в Акценте:
Исходные данные
1. Есть база счетов на оплату и предоплату (на отдельном плане счетов, на разных счетах, но для упрощения берем отдельный субсчет для предоплатных счетов, отдельный - для оплат по факту.)
2. С привязкой счет-Первичный документ проблем не возникает, т.к. все данные имеются уже на момент создания счета.
3. С привязкой уже существующего счета на предоплату к вводимому в данный момент первичному документу - проблема, ибо связи - неоднозначны, и чаще всего - много ко многим (Х счетов на предоплату могут закрываться Y первичными документами)
Как вариант - можно хранить в двух разных фактах первичного документа псевдотаблицу, с данными по DOC_ID, SUM, где DOC_ID - ид-р документа (счет на предоплату) и Сумма, которую мы "отщипываем" от общей суммы счета н предоплату в данном первичном документе.
Минус данной схемы - неудобный контроль при удалении документов.
Дополнительные условия
Выходить за рамки объектной модели Акцента - не хочется (только лишь как крайняя мера).
Связи должны формироваться в момент введения первичного документа....
В связи с этим - вопрос.
Кто-то решал подобную задачу?
Каким образом хранить данные? |
|
Вернуться к началу |
|
|
Юров Ю.С.
Зарегистрирован: 11.03.2005 Сообщения: 383 Откуда: Павлоград
|
Добавлено: Вт Сен 20, 2011 5:54 pm Заголовок сообщения: Re: Помощь в формировании связей между документами |
|
|
AllexL писал(а): | Как вариант - можно хранить в двух разных фактах первичного документа псевдотаблицу, с данными по DOC_ID, SUM, где DOC_ID - ид-р документа (счет на предоплату) и Сумма, которую мы "отщипываем" от общей суммы счета н предоплату в данном первичном документе.
|
Какая версия Акцента?
Код: | tr.ParentDocId Возвращает или устанавливает ID родительского документа или операции.
При удалении родительского документа ИЗ КОРЗИНЫ очищается.
JOURNAL.PDOC_ID ИД РОДИТЕЛЬСКОГО ДОКУМЕНТА
Индексированное поле с условием сохранения целостности.
tr.Link Возвращает или устанавливает ID связанной (родительской) операции или проводки.
JOURNAL.J_LINK ИД РОДИТЕЛЬСКОЙ ПРОВОДКИ
Индексированное поле БЕЗ условий. |
Делал привязку платёжных документов к финансовым (счетам) или материальным.
В проводке платёжного документа в поле PDOC_ID ссылка на идентификатор родительского товарного документа.
Кроме того (это не основная связь) - в платёжном документе в поле DOC_LINK ссылка на тот же идентификатор.
В платёжке (ПКО) сделана табличка со ссылками на родительские документы.
Сумма платежа бьётся на части (автоматически в момент привязки) или изначально состоит из нескольких частей - платёж, пеня и др.
К каждой строке с суммой - в параметре краткое описание родительского документа.
Диалог для привязки с двумя списками, вызывается из селектора с кратким описанием родителя.
1. Список привязок (один-ко-многим, счета-накладные на части не бьются)
" № ", "Дата", "Наименование товарного документа", "№ док", "Сумма", "Дата опл.", "№ плат.", "Сумма", "Задолж", "Задолж на дату нк"
Второй список "Неразнесенные платёжные документы по корреспонденту"
"Дата опл.", "№ плат.", "Сумма", "Назначение платежа"
Кнопка "расписать" с простеньким алгоритмом автоматической росписи.
Платёжку можно открепить, щёлкнув по её строке в первом списке, она добавится в список свободных.
Свободные платёжки можно привязать вручную. Для первоначальной разноски удобнее оказался комбинированный метод - процентов 70 из кучи неразнесеных берёт автоматика, несколько платежей привязываются вручную, после снова пускается автоматика.
Основной вопрос - будут пользоваться или не будут.
Сейчас заглянул в базы - пользуются, одни через раз, другие все платёжки разносят. |
|
Вернуться к началу |
|
|
Jeck
Зарегистрирован: 17.05.2005 Сообщения: 171 Откуда: Донецк
|
Добавлено: Ср Сен 21, 2011 10:47 am Заголовок сообщения: |
|
|
я смог уговорить почти всех клиентов, кто отслеживает оплаченные счета, на автоматическое закрытие счетов оплатами.
+ никаких дополнительных действий со стороны пользователя и как следствие - нет вообще ошибок
- не все быстро соглашаются, лучше идти напрямую к руководителю. с менеджерами и рядовыми бухгалтерами об этом нет вообще смысла разговаривать.
для одной фирмы вставил задолженность по счетам прямо в бланк заказа очень удобно в их случае.
если интересно могу рассказать смысл. |
|
Вернуться к началу |
|
|
AllexL
Зарегистрирован: 10.03.2005 Сообщения: 434 Откуда: Donetsk
|
Добавлено: Ср Сен 21, 2011 9:23 pm Заголовок сообщения: |
|
|
Ребят, спасибо большое за ответы, но ситуация немного другая.
Упрощу ситуацию, насколько это возможно:
В системе уже существует платежка, отражающая сделанную предоплату.
Требуется при внесении первичного документа (например, Акта приема-передачи услуг), "закрывающего" выданную предоплату, создать такие связи, котороые позволили бы однозначно идентифицировать все взаимоотношения.
На практике - все намного сложнее - существует довольно навороченная база договоров с условиями оплаты, сотрудники вводят счета на предоплату и оплату по факту.
Например, требуется обеспечить выполнение работ для фирмы на 1000 грн и их оплату. Оплата осуществляется путем выдачи аванса в 200 грн до начала работ, и 800 грн - после подписания акта приема передачи работ.
Порядок создания документов
а) 01.10.11 ПП - предоплата на 200 грн
в) 10.10.11 АктППУ - 1000 грн
с) 11.10.11 ПП - оплата по факту
связи между документами в) и с) создаются без проблем, так как на момент ввода ПП с) Акт уже существует в системе, со связков а)-в) - проблема.
Пока планирую в момент ввода АктППУ в) анализировать наличие незакрытых предоплат и предлагать пользователю выбрать в существующем списке предоплаты. При этом, если предоплат было несколько - придется разбивать построчно весь АктППУ |
|
Вернуться к началу |
|
|
Юров Ю.С.
Зарегистрирован: 11.03.2005 Сообщения: 383 Откуда: Павлоград
|
Добавлено: Чт Сен 22, 2011 8:34 am Заголовок сообщения: |
|
|
AllexL писал(а): | котороые позволили бы однозначно идентифицировать все взаимоотношения.( |
Родительский документ - счёт, подчинённые - оплата. Независимо от порядка создания. Последовательность определяется датой связанных документов, но никак не направлением связи. Счёт не бьётся на части: неоплаченная часть на сегодня и на дату документа всегда поддаются вычислению. |
|
Вернуться к началу |
|
|
AllexL
Зарегистрирован: 10.03.2005 Сообщения: 434 Откуда: Donetsk
|
Добавлено: Чт Сен 22, 2011 6:06 pm Заголовок сообщения: |
|
|
Юров Ю.С. писал(а): | AllexL писал(а): | котороые позволили бы однозначно идентифицировать все взаимоотношения.( |
Родительский документ - счёт, подчинённые - оплата. Независимо от порядка создания. Последовательность определяется датой связанных документов, но никак не направлением связи. Счёт не бьётся на части: неоплаченная часть на сегодня и на дату документа всегда поддаются вычислению. |
Проблема в том, что Акт может "закрывать" две и более предоплаты, либо закрывать предоплату не полностью
Предоплата - 1000 грн, Акт - 200.
Затем акт на 1800
Затем оплата по факту на 1000.
Либо:
Предоплата А 50,00
Предоплата В 500,00
Акт1 200,00
Акт2 350,00 |
|
Вернуться к началу |
|
|
Юров Ю.С.
Зарегистрирован: 11.03.2005 Сообщения: 383 Откуда: Павлоград
|
Добавлено: Чт Сен 22, 2011 7:49 pm Заголовок сообщения: |
|
|
У меня ваш пример выглядит вот так.
Не буду хвастаться, что легко получилось их разнести, если не знал или забыл особенности. Ещё 2-3 заказа этой тематики, и будет доведено до совершенста... Не уверен что удобна последовательность документов в порядке убывания дат итд.
Но сам принцип связки документов меняться не будет, он даёт всю необходимую информацию.
Последний раз редактировалось: Юров Ю.С. (Чт Сен 22, 2011 7:53 pm), всего редактировалось 1 раз |
|
Вернуться к началу |
|
|
Jeck
Зарегистрирован: 17.05.2005 Сообщения: 171 Откуда: Донецк
|
Добавлено: Чт Сен 22, 2011 7:51 pm Заголовок сообщения: |
|
|
именно поэтому я и предложил автомат. в отчете я решаю это оплата или предоплата, а все возможные связи по клиенту (если надо, можно добавить миск или биндер)
правда долго писал и выискивал всевозможные подводные камни.
зато работает железно и никаких дополнительных связей между документами |
|
Вернуться к началу |
|
|
Jeck
Зарегистрирован: 17.05.2005 Сообщения: 171 Откуда: Донецк
|
Добавлено: Чт Сен 22, 2011 7:55 pm Заголовок сообщения: |
|
|
особенно круто морочить голову пользователю перенаправлением предоплат и постоплат при важности направлений деятельности (т.е. договоров)
я одним дал возможность делать это руками, после одной недели перешли на автомат (благо оплатили всю работу ) |
|
Вернуться к началу |
|
|
Юров Ю.С.
Зарегистрирован: 11.03.2005 Сообщения: 383 Откуда: Павлоград
|
Добавлено: Пт Сен 23, 2011 6:38 am Заголовок сообщения: |
|
|
Jeck писал(а): | особенно круто морочить голову пользователю перенаправлением предоплат и постоплат при важности направлений деятельности (т.е. договоров)
я одним дал возможность делать это руками, после одной недели перешли на автомат (благо оплатили всю работу ) |
Очень интересен вариант полностью автоматической разбивки. Ты парсишь назначение платежа на предмет даты/номера счёта? У тебя просто отчёт и никаких реальных связей?
Хорошая идея сделать отдельную таблицу связей с дроблением сумм, обновляемую автоматически и с возможностью задать отдельные хинты вручную. |
|
Вернуться к началу |
|
|
AllexL
Зарегистрирован: 10.03.2005 Сообщения: 434 Откуда: Donetsk
|
Добавлено: Пт Сен 23, 2011 7:57 am Заголовок сообщения: |
|
|
Юров Ю.С. писал(а): |
Хорошая идея сделать отдельную таблицу связей с дроблением сумм, обновляемую автоматически и с возможностью задать отдельные хинты вручную. |
Вот-вот-вот....и держать ее я собираюсь в DOC_FACTS.....
Автомат - заманчив, но, заказчик хочет "ручки" |
|
Вернуться к началу |
|
|
Юров Ю.С.
Зарегистрирован: 11.03.2005 Сообщения: 383 Откуда: Павлоград
|
Добавлено: Пт Сен 23, 2011 10:40 am Заголовок сообщения: |
|
|
AllexL писал(а): | ....и держать ее я собираюсь в DOC_FACTS..... |
Есть хоть один аргумент, кроме "не хочу выходить за рамки объектной модели Акцента"? |
|
Вернуться к началу |
|
|
AllexL
Зарегистрирован: 10.03.2005 Сообщения: 434 Откуда: Donetsk
|
Добавлено: Пт Сен 23, 2011 11:27 am Заголовок сообщения: |
|
|
Юров Ю.С. писал(а): |
Есть хоть один аргумент, кроме "не хочу выходить за рамки объектной модели Акцента"? |
Каковы преимущества выхода за ОМ?
Создать foreignKey Для DOC_FACTS - и ок |
|
Вернуться к началу |
|
|
Jeck
Зарегистрирован: 17.05.2005 Сообщения: 171 Откуда: Донецк
|
Добавлено: Пт Сен 23, 2011 3:38 pm Заголовок сообщения: |
|
|
я смог убедить директоров в том, что не важна надпись в примечание! важен сам факт получения расчета.
т.е. вообще не обращяю внимание за что получили оплату и что продали (какие услуги).
исключением является только когда существует реальная необходимость в разных договорах с одним и тем же клиентом, например в строительстве.
дошло до того, что крупные клиенты начали по этой методике своим сотрудникам зарплату отдавать, а мелкие считают реально полученную прибыль
чем проще схема учета - тем она стабильней |
|
Вернуться к началу |
|
|
Jeck
Зарегистрирован: 17.05.2005 Сообщения: 171 Откуда: Донецк
|
Добавлено: Пт Сен 23, 2011 3:50 pm Заголовок сообщения: |
|
|
как в реальности происходит оплата? приходит клиент и спрашивает у менеджера, за что я вам еще должен? вот пусть менеджер возмет деньги и не морочит голову какой акт (счет) оплачен.
у меня оплачивается всегда более старый, в этом случае ничего ненадо делать дополнительно при возвратах и оплатах.
а как в ваших схемах начнет работа с возвратами денег и товара? городить перезачеты?
я же говорю, что не сразу к этому пришел, тоже написал схему руками закрывать. но потом предложил автомат.
самое главное, очень легко проверить, но кропотливо я в одном отчете могу расчитать задолженность по всем клиентам и расписываю по документам (т.е. за что) скорость при этом меньше минуты. также делал по менеджерам и объектам учета. |
|
Вернуться к началу |
|
|
|