... хоть куда-нибудь! Захлебываюсь от обилия информации.

Задача: Конкретно для 1С SQL
1. получить "БыстрыеРегистры" без Регистров, с большим запасом прочности по производительности
2. реализовать дополнительную функциональность для этих регистров. (очень надо движение регистров на дату отличную от даты документа)

Хочу написать это сам. Хотя опыта работы с SQL и 1С++ маловато.
Приветствую любые посылы, главное чтоб аргументированно.

Может кто-то уже разрабатывает подобное? Я не нашел и готов подключиться.
Может не стоит изобретать "велосипед"?

leshik писал(а) 14. Января 2008 :: 18:05:

Где? Где посмотреть,  мил человек?


leshik писал(а) 14. Января 2008 :: 18:05:

Расчет "просроченной задолженности" клиента. Отсрочка платежа может зависеть от всевозможных условий.

leshik писал(а) 14. Января 2008 :: 18:15:


Нет. Движения именно от этого документа, но от другой даты.

Вкратце, то как я представляю:
РАСЧЕТ задолженности клиента будет производиться при проведении документа. Пример:

Накладная от 02/01/08
НАИМЕНОВАНИЕ КОЛВО СУММА
товар1________10 шт__100р
товар2________20 шт__333р

По первому товару отсрочка 6 дней
По второму - 10 дней
Запись как минимум в два "регистра" : Общей задолженности и Просроченной задолженности
В "Общий" пишем сумму 433 от 01/01/08
А вот в "просроченный" пишем:
07/01/08 - 100р
11/01/08 - 333р

Все!
А в доках по 1С++ я не нашел подобного. Есть работа с 1С-кими регистрами, но они не позволяют сделать такого, насколько я знаю. И есть возможность прямых запросов к БД плюс метапарсер, что я и собираюсь использовать для реализации собственных регистров.

Или такую задачу можно решить другими способами?!

Примерные объемы данных:
в год 2 500 000 строк реализации
в документе в среднем 11 строк
230 000 документов в год
19 000 документов в месяц
650 документов в день
т.е. примерно 1500 фактов возникновения фактической(и позже просроченной) задолженности в день.

Цитата:


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

Если делить еще и по срокам.... будет странно если реализация 10 наименований будет на трех накладных.... не говоря о расходах на расходники.

Кроме того, все это реализовано довольно странно, на коленках, "быстро и дешево", на бухитогах.
И на Оперативный учет контора не будет тратится(не спрашивайте почему), даже если собственная разработка обойдется дороже.

И думаю я не первый месяц. Но к сожалению опыт работы с Оперативным учетом и SQL практически отсутствует. Немного лучше с 1С++.
Поэтому я и пишу сюда, что думалка моя запуталась
Возможно просто взгляд замылился....
Помогите добрым советом!

1. Два регистра это совершенно нормально - см. в 8.0 типовую торговлю или УПП.

2. Не понял какое отношение задача имеет к 1С++(?) - все решается обычными методами.

3. ДатаОплаты в регистре конечно удобно иметь для обработки итогов, но на практике
лично я сталкивался, что менеджеры меняли задним числом эту дату в документе,
и из за этого "съезжал" регистр, если уже было погашение на эту дату.
В результате оставил только КредитныйДокумент.

kiruha писал(а) 15. Января 2008 :: 00:23:


У автора несколько дат, т.к. задолженность учитывается по товарам
В целом не очень понятно как там организована оплата, ведь оплачиваемого документа тоже недостаточно если оплаты происходят еще и по товарам (или там по ФИФО, ХЕЗ короче...)

kiruha писал(а) 15. Января 2008 :: 00:23:


Каким образом? 

leshik писал(а) 15. Января 2008 :: 11:49:


Да. Именно так! Ввиду того, что выполнить движения типовых регистров на дату отличную от даты документа невозможно, имеем следующее:
BuZZZard писал(а) 14. Января 2008 :: 17:48:


Регистры НЕ ТИПОВЫЕ! Я собираюсь написать собственный механизм регистров.
Правильное ли направления я выбрал?
Может есть готовые решения?
Может ведется их разработка?