Добавлено: Сб Сен 24, 2011 11:20 am Заголовок сообщения:
Jeck писал(а):
как в реальности происходит оплата? приходит клиент и спрашивает у менеджера, за что я вам еще должен? вот пусть менеджер возмет деньги и не морочит голову какой акт (счет) оплачен.
у меня оплачивается всегда более старый, в этом случае ничего ненадо делать дополнительно при возвратах и оплатах.
а как в ваших схемах начнет работа с возвратами денег и товара? городить перезачеты?
я же говорю, что не сразу к этому пришел, тоже написал схему руками закрывать. но потом предложил автомат.
самое главное, очень легко проверить, но кропотливо я в одном отчете могу расчитать задолженность по всем клиентам и расписываю по документам (т.е. за что) скорость при этом меньше минуты. также делал по менеджерам и объектам учета.
В нашем случае оплата по разным направлениям имеет разные характеристики, как-то срок и вид отсрочки либо предоплаты. Например, из всего пула доп.соглашений и/или спецификаций к договору одна из спец-й имеет особые условия, хотя договор у них - один, и отслеживание оплат по этой спец-и имеет особый, чуть ли не сакральный смысл для финансистов и контролеров. Метод распрделения оплат (даже с привязкой к продукции) по FIFO реализован еще в далеком 2006 году, но он не отражает существующей картины для потребителей отчета. Кроме того, посчитать реальный срок задолженности по периодам для разных покупателей/потребителей м.б. затруднительно при автоматическом распределении.
Добавлено: Сб Сен 24, 2011 5:49 pm Заголовок сообщения:
это только так кажется. мой первый клиент проверял больше полу года пока не согласился, что все правильно. теперь даже не смотрят на промежуточные таблицы, сразу на итог. у них с одним клиентом разрыв отношений был, так пришлось расчитать просрочку по каждой отгрузке за последние три года красивая сумма получилась в итоге
а если РЕАЛЬНАЯ необходимость в разных договорах по одному клиенту - то миски нам помогут
смысл таков: итого по сч.361 на начало периода, затем ищете точку отсчета и закрываем каждый последующий документ. захотите подробнее - распишу.
повторяю, это всего лишь отчет. его можно строить за любой период.
промежуточные таблицы делал только один раз для сохранения данных по видам продукции, чтобы потом посмотреть за весь год помесячно.
Последний раз редактировалось: Jeck (Сб Сен 24, 2011 6:01 pm), всего редактировалось 1 раз
Добавлено: Сб Сен 24, 2011 5:52 pm Заголовок сообщения:
AllexL писал(а):
Метод распрделения оплат (даже с привязкой к продукции) по FIFO реализован еще в далеком 2006 году
я не привязываю оплаты к продукции (объектам)
упрощая схему учета делаем более тяжелые отчеты.
зато в учете предусмотрены реализация, оплата, возврат товара, возврат денег, взаимозачет и вступительный баланс
для расчета З/П сотрудникам еще подкинул предоплаты по з/п, это для перехода с обычной схемы начисления. пришлось менеджеров мотивировать не выбивали деньги из клиентов
Добавлено: Сб Сен 24, 2011 10:13 pm Заголовок сообщения:
Jeck писал(а):
я не привязываю оплаты к продукции (объектам)
Естесственно, я не привязываю оплаты к ОУ, а, также как и пул документов, распределяю оплаченную часть накладной на содержащуюся в документе номенклатуру.
Добавлено: Сб Сен 24, 2011 10:16 pm Заголовок сообщения:
Jeck писал(а):
это только так кажется. мой первый клиент проверял больше полу года пока не согласился, что все правильно. теперь даже не смотрят на промежуточные таблицы, сразу на итог. у них с одним клиентом разрыв отношений был, так пришлось расчитать просрочку по каждой отгрузке за последние три года красивая сумма получилась в итоге
а если РЕАЛЬНАЯ необходимость в разных договорах по одному клиенту - то миски нам помогут
смысл таков: итого по сч.361 на начало периода, затем ищете точку отсчета и закрываем каждый последующий документ. захотите подробнее - распишу.
повторяю, это всего лишь отчет. его можно строить за любой период.
промежуточные таблицы делал только один раз для сохранения данных по видам продукции, чтобы потом посмотреть за весь год помесячно.
Использование мисков - не очень хорошая идея. Структура документа - сложна, в документе и так уже используются 4 миска. К сожалению, требуется не с помощью отчета распределять оплаты, а именно создавать связи.
Добавлено: Вс Сен 25, 2011 6:47 am Заголовок сообщения:
AllexL писал(а):
К сожалению, требуется не с помощью отчета распределять оплаты, а именно создавать связи.
Бог в помощь, но делать связи на фактах документа - мне кажется, не лучшая идея.
AllexL писал(а):
Создать foreignKey Для DOC_FACTS - и ок.
Alter table, create table - где экономия, в чём удобство?
Вдобавок факты ведут себя довольно сложно, воспользоваться op.Facts врядли получиться, но придётся предусмотреть возможность их ручного изменения пользователем через системный диалог свойств операции.
В своей таблице можно добавить примечание к связи, добавить поле со ссылкой на справочник "вид связи" - оплата, первое событие, хинты опять же хранить надо где-то итд.
Добавлено: Вс Сен 25, 2011 11:43 am Заголовок сообщения:
[quote="Юров Ю.С."]Бог в помощь, но делать связи на фактах документа - мне кажется, не лучшая идея.
[quote="AllexL"]
Лучше - добавить vbs-прослойку для заполнения несвойственной для стандартной схемы БД Акцента таблицы с зычным именем DOC_Prepayment_links ? Или воспользоваться стандартной моделью:
Код:
for i = Lbound(docLinks,2) to UBound(docLinks,2)
Op.Facts(i).Item("PAYMENT_DOC_ID" ).Value = docLinks(0,i)
Op.Facts(i).Item("PAYMENT_DOC_SUM").Value = docLinks(1,i)
Next
либо вызывать хранилку, которая вставит эти же данные средствами SQL? Причем в случае SQL можно хранить код документа с предоплатой в FA_LONG, а сумму - в FA_CY...
Кстати, щаз глянул структуру DOC_FACTS
Код:
.....
FA_FDATE datetime
....
FA_DATE datetime
Кто подскажет, для чего - FA_DATE? Шоб було?
Юров Ю.С. писал(а):
Alter table, create table - где экономия, в чём удобство?
Foreign key - вот удобство
Юров Ю.С. писал(а):
Вдобавок факты ведут себя довольно сложно, воспользоваться op.Facts врядли получиться, но придётся предусмотреть возможность их ручного изменения пользователем через системный диалог свойств операции.
А можно поподробней, почему "врядли получиться"? Я ни разу не пробовал воспользоваться Op.Facts, поэтому буду рад любой информации об "особенностях использования" (с) данного объекта.
Юров Ю.С. писал(а):
В своей таблице можно добавить примечание к связи, добавить поле со ссылкой на справочник "вид связи" - оплата, первое событие, хинты опять же хранить надо где-то итд.
Ну, в вышеописанном подходе информацию можно хранить следующим образом:
Код:
FA_FDATE - индекс (0,1,2,3,4,......N)
FA_LONG - DOC_ID ссылка на документ-предоплату
FA_CY - сумма, которую отщипывает от предоплаты данный вводимый документ
FA_STRING - примечание
Добавлено: Вс Сен 25, 2011 10:39 pm Заголовок сообщения:
Схема с использованием таблицы DOC_FACTS жизнеспособна, но разве это жизнь!
Свои хранимые процедуры здесь все пишут, наверняка временные таблицы в них задействованы. Почему создать свою таблицу в базе данных считается чем-то из ряда вон выходящим? Берёте struct_74_404.sql из дистрибутива, ищете в ней создание DOC_FACTS, пишите на её основе скрипт создания своей таблицы, с foreign keys если хотите, ссылочной целостностью DRI, своими названиями полей (FA_DATE - это факт типа date). Обратитесь к Jeck, у него очень серьёзно проработана и отлажена тема автоматичской разноски. Отчёт из его системы будет заполнять вашу таблицу, сделайте её показ и редактирование в диалоге. Объектная модель абсолютно не нужна, достаточно функции, которая возвращает массив связанных операций, и несколько процедур для показа таблицы в форме отчёта по клиенту за период и для добавления-удаления записей. Если интересно, могу выслать свой диалог связей. Про хинты на время забудьте, формируйте автоматом только новые связи. Я так предлагаю. Удачи!
Добавлено: Вт Сен 27, 2011 1:22 pm Заголовок сообщения:
А вобще, по связям документов - если с ними серьёзно работать, то первым делом нужно добавить в таблицах FRM_LINK и TML_LINK поля "наименование связи", "сценарий установления связи".
Добавлено: Чт Сен 29, 2011 12:57 pm Заголовок сообщения:
если интересно, очень давно был вариант, если приходит оплата сразу нескольких счетов (количество счетов неважно), то механизм разбивки одной оплаты на несколько пустышек с тем же номером + через дробь порядковый номер.
таким образом по бух. счетам оплата одна, а по документам в связях оплат несколько с разными суммами.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах