gifts2017

Сложный («нелинейный») учет в БП, ЗУП и т.д. Мой взгляд на проблему

Опубликовал г. Казань Рустем Гумеров (Rustig) в раздел Программирование - Практика программирования

       Есть насущная проблема: а) сначала разбора и понимания ЗУПовских запросов, б) затем внесения изменений в заложенные механизмы. Если используется запрос для получения всех взаимосвязей и взаимовлияний показателей, то получается «большой» запрос. В чем проблема «большого» запроса? Он подобен карточному домику: строится долго, а захочется поменять карту из середины строения – домик разрушится. На своем примере учета задолженностей контрагентов в разрезе полугодий (не типовой учет БП, и не ЗУПовский) я покажу, как я изменил механизм учета и превратил «большой» запрос в «маленький», а дальнейшее сопровождение программы в сказку 1С-ника.
       Есть предположение, что причины использования "больших" запросов кроются в схемах построения учетных механизмов, и, изменив схему, мы сможем избавиться от всех неудобств "больших" запросов.



"Блок — простое механическое устройство, позволяющее регулировать силу.Подвижный блок предназначен для изменения величины прилагаемых усилий:для подъёма груза потребуется сила вдвое меньше, чем вес груза.При этом груз пройдёт расстояние, вдвое меньшее пройденного точкой приложения силы."

 


Часть 1. Вводная

       Есть насущная проблема: а) сначала разбора и понимания ЗУПовских запросов, б) затем внесения изменений в заложенные механизмы. Кто сдавал специалиста по ЗУП - поправьте меня, если я преувеличиваю. Подобные большие запросы есть также в учете амортизации ОС - в механизме, который заложен в БП. У кого найдутся еще примеры больших запросов, прошу писать в комментариях для обмена и накопления опыта.
       Однажды я столкнулся с подобной проблемой, когда разрабатывал отчет для организации, ведущей учет задолженностей своих контрагентов в разрезе полугодий. Начисление и оплата регистрируется в регистре бухгалтерии по субконто1 – контрагенту и по субконто2 - условно назову его, период: за первое полугодие, за второе полугодие. Сложность учета заключалась в одновременном учете нескольких показателей (даты первой сделки, даты последней сделки, разделения оплат по полугодиям) и влиянии оплат предыдущих периодов на задолженность текущего периода. Не вдаваясь в детали учета, условно напишу так: от даты первой сделки и даты последней сделки зависело, за какой период должен оплатить контрагент. Выставление счетов производится каждое полугодие с учетом уже оплаченной суммы за предыдущие периоды (предыдущие года, предыдущее полугодие).
       Если воспользоваться запросом для получения всех взаимосвязей и взаимовлияний показателей, то получится «большой» запрос. В чем проблема «большого» запроса? Он подобен карточному домику: строится долго, а захочется поменять карту из середины строения – домик разрушится. На своем примере я покажу, как я изменил механизм учета и превратил «большой» запрос в «маленький», а дальнейшее сопровождение программы в сказку 1С-ника. Smile

 

Часть 2. Главная

       Использование регистров накопления и регистров сведений как вспомогательных очевидно при разработке подсистем оперативного учета. «Очевидно» - при условии, что к этим регистрам можно обратиться за получением понятной конечному пользователю информации. Сразу проиллюстрирую на картинках схемы использования механизмов 1С – вариант первый на рис. 1.

Рис. 1. Простая схема использования механизмов 1С

       В данном случае в качестве регистра может быть использован любой регистр: регистр сведений, регистр накоплений, регистр бухгалтерии или регистр расчета. Не хочу углубляться в другую суть вопроса, что, мол, любая таблица подойдет для хранения промежуточной информации, или отчет и вовсе можно строить сразу на документах. Подразумеваю главным образом то, что при создании отчетов используются заложенные в регистрах собственные механизмы получения итогов.
       Более сложную, но «понятную» схему использования механизмов демонстрирую на рис. 2.

Рис. 2. Более сложная схема использования механизмов 1С

       Заметьте, что для получения отчета используются несколько регистров, напрямую связанных с документом, и регистры, напрямую не связанные с документом. Опять-таки в качестве регистра может быть использован любой регистр: регистр сведений, регистр накоплений, регистр бухгалтерии или регистр расчета.
       Вернусь к вопросу «очевидности» использования вспомогательных регистров… Не так очевидно (!) их использование как таблицы хранения промежуточной, напрямую никому не нужной (без дополнительной обработки) информации. Для примера обратите внимание на механизм РАУЗ – на регистр сведений «Аналитика учета затрат». На мой взгляд, это первый случай использования промежуточных регистров такого рода – то есть для хранения промежуточной, напрямую никому не нужной (без дополнительной обработки) информации. Кто знает еще примеры, пишите, пожалуйста, в комментариях.
       И совсем неочевидно использовать вспомогательные регистры совместно с регистрами бухгалтерии или регистрами расчета в таком варианте – рис. 3.

Рис. 3. Неочевидная схема использования механизмов 1С

       *Скажу наперед, что структура вспомогательного регистра полностью повторила те разрезы и показатели, которые надо было отразить в отчете. То есть, я «плясал» от отчета: если надо было отразить такой показатель, как наличие «акта сверки», значит, в регистре возникало измерение Контрагент и возникал ресурс булева типа НаличиеАктаСверки. Если нужно было отразить такой показатель, как «частичная/полная оплата или совсем не оплатил», то в регистре возникал ресурс типа перечисление СтатусОплаты. То же самое коснулось и ресурса ДолгЗаПериод, который рассчитывался, как и все остальные показатели, в отдельно вынесенных алгоритмах.

       **В дальнейшем я покажу и отчет, и структуру регистра – сейчас не суть.

       ***Я использовал непериодический регистр сведений. Так как не нужно было формировать отчет за предыдущие периоды, а нужно только на текущий момент. Но наличие дополнительного измерения Период не меняет принципа схемы, только лишь усложняет алгоритм расчета показателей, что не критично для решения нашей задачи – задачи избавиться от «большого» запроса.
       Продолжу. В варианте 3 (рис. 3) мне надо было решить вопрос: в какой момент времени, и по какому событию промежуточная информация попадает во вспомогательный регистр? В вариантах 1 и 2 этот вопрос неочевиден, потому что информация попадает при проведении документа. (В случае регистров расчетов дополнительно используются служебные регистры Перерасчетов.)  
     Так вот, для решения этого вопроса я завел дополнительный регистр сведений  ТребуетсяПереопределитьСтатусыКонтрагента и придумал такую схему – рис. 4.


Рис. 4. Расширение механизма учета

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

 

Часть 3. Демонстрация

       Ниже будут представлены иллюстрации и алгоритмы с минимум комментариев.  Надеюсь все будет понятно.

       Ниже представлен макет одного из отчета и структура вспомогательных регистров (рис. 5).

Рис. 5. Макет отчета и структура вспомогательных регистров

        Ниже представлен список записей регистра сведений Статусы контрагентов: каждый контрагент выделен своим цветом. Список напоминает Олап-Куб – когда для одного и того же контрагента имеется ровно столько записей, сколько необходимо задействовать дополнительных измерений (в данном случае дополнительными измерениями выступают год и полугодие).

Рис. 6. Олап-куб записей вспомогательного регистра

       Ниже представлен код вызова процедуры общего модуля ТребуетсяПереопределитьСтатусы.

 

Если Не Отказ И РольДоступна("ПравоНастройкиПрограммы") Тогда

  Попытка
  
Запрос = Новый Запрос;
  
Запрос.Текст = "ВЫБРАТЬ
   | ТребуетсяПереопределитьСтатусы.Контрагент
   |ИЗ
   | РегистрСведений.ТребуетсяПереопределитьСтатусы КАК ТребуетсяПереопределитьСтатусы"
;

  
Результат = Запрос.Выполнить();
  Если НЕ
Результат.Пустой() Тогда

  
#Если Клиент Тогда
   
Сообщить("Не закрывайте окно и не выключайте компьютер: будет произведена регламентная процедура",     СтатусСообщения.Информация);
  
#КонецЕсли

 
СписокКонтрагентов = Результат.Выгрузить().ВыгрузитьКолонку("Контрагент");
 
ДополнительныеФункции.ПереопределитьСтатусы(СписокКонтрагентов);

  КонецЕсли;
  Исключение
  КонецПопытки;

КонецЕсли;

       За кадром остается алгоритм расчета показателей, по сути влияния показателей друг на друга - в общем, алгоритм как алгоритм, в котором показатели определяются по различным условиям. Стоит только отметить три момента. Первый, для пояснения, о каких условиях идет речь. Например, контрагент оплатил за первое полугодие 2011 года сумму большую, чем полагалось. Тогда излишек должен распределиться (обратите внимание) на второе полугодие 2011 года, при условии, что за этот период оплаты не было. И т.д. анализ по всем периодам и условию, что контрагент в этом периоде еще осуществляет сделки (помните про дату первой сделки и дату последней сделки?)

       И второй момент, что рассчитать показатели с помощью отдельно вынесенного алгоритма легче, чем рассчитывать показатели внутри "большого" запроса. "Легче" в плане разработки, прозрачности кода, отладки и дальнейшего расширения в рамках сопровождения. Выносить на обозрение "большой" запрос и конечный "малый" не буду, поскольку найдутся желающие оптимизировать "большой" запрос. Напишу только, что для получения отчета по всем показателям "малым" запросом использовано 66 строк запроса, оформленного конструктором запроса. А для получения отчета "большим" запросом я сначала произвел декомпозицию запроса, и для каждого отдельного показателя отчета использовал запрос в 100 строк. В таких запросах  использовал пакетные запросы "ОтносящиесяКПервомуПолугодию", "ПолностьюОплатившиеЗаПолугодие", и т.д. и т.п. согласно условиям задачи.

       Третий момент - ретроспектива или исторический - "большой" запрос себя оправдал на начальном этапе использования такого рода учета задолженностей контрагентов в разрезе полугодий. Но когда пришлось (через полгода) отразить в учете влияния переплат и долгов 2011 года на задолженности 2012 года, то схема "большого" запроса вдруг стала неповоротливой, настолько громоздской, что дала сбой. "Наращивание" и анализ показателей по полугодиям (с течением времени) с помощью "больших" запросов стали нетривиальными задачами. И наоборот, для добавления алгоритма по анализу показателей за 2013 год в процедуру общего модуля потребовалось 30 минут. Разве не сказка? Smile    


Центр автоматизации, ИП Гумеров Р.И. http://готовые-решения-1с.рф/

См. также

Вознаграждение за ответ
Сумма: 0 $m
Добавили:
Владимир (hogik) (32.00 $m), г. Казань Рустем Гумеров (Rustig) (20.00 $m)
Подписаться Добавить вознаграждение

Комментарии

1. Александр Рытов (Арчибальд) 26.07.13 10:24
2. Александр Лапшин (zfilin) 27.07.13 00:22
О! Декомпозиция, модульность, изоляция кода!
Спасибо, это отлично. Концепцию третьей схемы беру на вооружение.
Где-то пару раз "бессознательно" я так и поступал, но не выделил так четко в "архитектурный шаблон". Теперь все стало на место.
3. Трактор Трактор (Трактор) 27.07.13 00:58
Раздел 3 ПереопределитьСтатусывыполнять не при завершении работы, а регламентным заданием.
u_n_k_n_o_w_n; JohnyDeath; +2 Ответить 2
4. Евгений Мартыненков (JohnyDeath) 27.07.13 14:19
Всё хорошо за исключением момента, когда нужно переопределить статусы. Согласен с (3), на эту роль хорошо подойдут регламентные и фоновые задания.

Сам сейчас решаю похожие проблемы в нашей конфигурации. Пришлось даже написать обработку, в которой строится дерево зависимостей временных таблиц запроса.
5. Александр Лапшин (zfilin) 28.07.13 01:22
(3) Да, как сказать. Тут без пользователей и окружения наверняка сказать нельзя, когда именно следует обновлять эти данные. Если отчет не нужен чаще, например, чем раз в месяц и пользователь готов ждать, то нет особого смысла тратить ресурс на его периодический пересчет. Перед формированием - то, что нужно. Зачем нужно пересчитывать при завершении работы? Думаю, это надо спросить у уважаемого Рустема.
Мое предположение такое:
1. Все-таки пересчитывать регистры не только перед формированием, а еще когда-нибудь, чтобы пересчет перед формированием не был запредельно долгим, в случае, когда отчетом долго не пользовались.
2. Вот это "когда-нибудь" вешать на событие завершения работы для того, чтобы решение проще работало в файловом варианте, где для выполнения регламентных нужен пользователь "робот". А так можно обойтись без него.

Рустем, пролейте свет на вопрос. Зачем именно перед завершением, а не регламентом раз в сутки, например?
6. Александр Лапшин (zfilin) 28.07.13 01:24
А вообще это мелочи. Идея хорошоа. Вот это главное.
7. г. Казань Рустем Гумеров (Rustig) 28.07.13 01:37
(5) :)
удивительно! вы все верно написали.
8. Сергей (Che) Коцюра (CheBurator) 28.07.13 01:50
Нифига не понял... Смысл в чем..? в том, что структура (вспомогательных) регистров проектировалась "от нужд отчета"..? Не уловил связь изложенного подхода с декомпозицией большого запроса...
???
9. г. Казань Рустем Гумеров (Rustig) 28.07.13 04:14
(8) :) Вспомогательные регистры служат для хранения промежуточно-рассчитанной информации. Структура хранения информации не должна совпадать с конечными макетами различных отчетов. Но многие отчеты могут использовать одну и ту же информацию о показателях, статусах - которые как раз и нужно хранить в вспомогательных регистрах.
...чтобы не плодить громоздских запросов, которые с избытком напичканы конструкциями (пример из ЗУП)
|ВЫБРАТЬ
	|	ОблагаемаяБаза.ФизЛицо КАК ФизЛицо,
	|	ОблагаемаяБаза.Период КАК Период,
	|	ВЫБОР
	|		КОГДА ОблагаемаяБаза.ЗаГод - Предел.Размер >= 0
	|			ТОГДА ОблагаемаяБаза.ЗаГод - Предел.Размер
	|		ИНАЧЕ 0
	|	КОНЕЦ - ВЫБОР
	|		КОГДА ЕСТЬNULL(ОблагаемаяБазаПрошлогоМесяца.ЗаГод, 0) - Предел.Размер >= 0
	|			ТОГДА ЕСТЬNULL(ОблагаемаяБазаПрошлогоМесяца.ЗаГод, 0) - Предел.Размер
	|		ИНАЧЕ 0
	|	КОНЕЦ КАК СуммаПревысившаяПредел
	|ПОМЕСТИТЬ ВТБазаПревышенияДохода
...Показать Скрыть
10. Алексей 1 (AlX0id) 28.07.13 10:30
Хорошая схема, за исключением идеи расчета при завершении работы пользователя. С регламентниками оно как-то поинтереснее выглядит )
11. Владимир (hogik) 28.07.13 21:36
(0)
Рустем (Rustig).
Плюс под публикацию поставил. Однако, категорически не согласен с предлагаемым способом борьбы с "большими" запросами путем переноса проблем запроса в сложность схемы базы данных. Проектирование схемы базы данных "плясками от отчета" - это пляски на поминках информационной системы.
И первый ;-) вопрос к Вам:
Каким алгоритмом формируется "регистр сведений ТребуетсяПереопределитьСтатусы" на начальном этапе внедрения, если база данных уже находится в эксплуатации?
12. Алекс Ю (AlexO) 28.07.13 22:32
(2) zfilin,
О! Декомпозиция, модульность, изоляция кода!

Вы что, до этого не программировали?
(9) Rustig,
Вспомогательные регистры служат для хранения промежуточно-рассчитанной информации.

Было бы все намного проще, если бы никто не развивал "концепции 1С", а просто сделали те же самые промежуточные расчеты, разбив простыни запросов на мелкие и упорядочив это все в дополнительные функции.
u_n_k_n_o_w_n; +1 Ответить 2
13. Алекс Ю (AlexO) 28.07.13 22:35
(11) hogik,
Однако, категорически не согласен с предлагаемым способом борьбы с "большими" запросами путем переноса проблем запроса в сложность схемы базы данных

Я больше склоняюсь к мнению, что подобное больше является умствованием ради процесса, а не результата, хотя в 1С это и поощряется во всех проявлениях.
14. Агапова Екатерина (katya0702) 28.07.13 22:49
15. evgen1977 (musatov1c.ru) 29.07.13 07:19
Интересно. У меня похоже есть заказ на похожую задачу. Обязательно опробую ваш метод :) Спасибо.
16. Алексей Роза (DoctorRoza) 29.07.13 08:45
ЗУП, в плане, крутых запросов - эталон в ТК! Хотя предложенный подход неявно, но реализован в УПП. Посмотрите, например, сколько движений делает документ Принятие ОС! :) Одних РС там 25 штук (1.2.21.1)! Каково, а!? :) Отмечу, что в предложенном подходе есть и небольшая мина, что, при смене программиста, его сменщик может не уловить идею и наиндусить!
u_n_k_n_o_w_n; Rustig; +2 Ответить
17. г. Казань Рустем Гумеров (Rustig) 29.07.13 10:35
(12)
сделали те же самые промежуточные расчеты, разбив простыни запросов на мелкие и упорядочив это все в дополнительные функции


:) спасибо за комментарий, надеюсь вашу рекомендацию услышат 1С-ники - разработчики типовых конфигураций.

что касается меня, то по возможности я так и делаю в своих задачах - разбиваю потенциально большой запрос на мелкие. Причина проста - я не силен в больших запросах, и быстрее набросать мелкие запросы.
Заметил две особенности:
1) скорость обработки информации увеличивается. Поэтому в тех задачах, где не критична скорость обработки данных, метод остается
2) в мелких запросах начинают повторяться пакетные запросы (временные таблицы), и для внесения совсем незначительного функционала уже требуется значительное время - проще говоря, одно и тоже приходится изменять в разных местах. Что можно было изменить за 5 минут - приходится изменять 40 минут, а то и больше, вспоминая через полгода, что там напрограммировано
18. г. Казань Рустем Гумеров (Rustig) 29.07.13 11:17
(11) :) спасибо за обсуждение
способом борьбы с "большими" запросами путем переноса проблем запроса в сложность схемы базы данных.


можно искать золотую середину, я ее нашел в своей задаче. мы едины в одном, что проблема "больших" запросов не надумана. правда? я правильно вас понимаю?

Проектирование схемы базы данных "плясками от отчета".

Спасибо, уже успел понять, что я не на том сделал акцент. :(
а вообще всю жизнь так руководствуюсь, что структура регистров накоплений должна прежде всего отвечать на вопрос "что в итоге мы должны получить?" Чтобы понять, надо ли нам применять оборотный регистр или регистр остатков. Зачастую один и тот же документ может делать записи в два разных похожих регистра накопления, отличия механизмов в том, что оба регистра - заполненные одними и теми же данными - будут использоваться в разных отчетах. Регистры могут отличаться даже не признаком, а одним измерением. Для целей учета и вывода в разные отчеты такой подход имеет право на существование. Эту идею почерпнул из книги Радченко и использую уже столько сколько программирую (5 лет).

вопрос к Вам:
Каким алгоритмом формируется "регистр сведений ТребуетсяПереопределитьСтатусы" на начальном этапе внедрения, если база данных уже находится в эксплуатации?


Если честно, не понял вопроса. База в эксплуатации, используется вовсю регистр бухгалтерии Хозрасчетный
Надо получить из него информацию о задолженности. На самом деле регистр не предусмотрен для решения таких задач, когда одни субконто сильно завязаны на других, и поэтому в бухгалтерских остатках надо учесть это влияние. Приходится писать запросы такого порядка, как в примере (9)

Такого рода запросы я разгрузил - вывел расчет в алгоритмы общих модулей, сохранил результаты расчетов в регистре сведений. Дальше использую показатели из регистра сведений. В моем случае получилось, что структура регистра выстраивалась согласно тем показателям, которые надо было получить в отчете. Также в результате получилось, что по каждому контрагенту приходится хранить информацию по всем разрезам - сам заранее не ожидал такого - описал в статье что будет некое подобие олап-куба. Хотя олап-куб и так используется вовсю в конфигурациях, когда мы отвечаем на вопрос "в разрезе каких измерений мы хотим получать отчетную информацию?"
19. г. Казань Рустем Гумеров (Rustig) 29.07.13 11:55
(11) может быть я вас услышал? попробую пояснить ситуацию другими словами. вы спрашиваете:
Каким алгоритмом формируется "регистр сведений ТребуетсяПереопределитьСтатусы" на начальном этапе внедрения, если база данных уже находится в эксплуатации

по схеме на рис. 3 видно, что регистр бухгалтерии - "базовый". Это значит, что внедрять схему использования регистров сведений мы можем в любой момент эксплуатации системы. То есть, если у вас акцент в вопросе ставится на разделении во времении, то я говорю, что это неважно для нас.
20. г. Казань Рустем Гумеров (Rustig) 29.07.13 13:06
(11) по вашему комментарию мысли приходят разные и не сразу :)
Проектирование схемы базы данных "плясками от отчета"

Сейчас я хотел бы добавить, что добавление вспомогательных регистров не обязательно должно идти от необходимости создавать дополнительные отчеты. Просто в моем случае, это совпало.
В целом же необходимость создавать и использовать вспомогательные регистры для хранения промежуточной информации должно идти "от задачи", "от баланса, что использовать": запросы для динамического получения показателей или регистры для статического получения информации.
может быть вы об этом спрашивали? я правильно вас понимаю?
21. Владимир (hogik) 29.07.13 16:12
(18)
"не понял вопроса."(с)
Рустем (Rustig).
А может я не понял Вашего алгоритма? ;-)
Вот тексты:
1) "При записи документов, ... контрагент попадает в регистр сведений ..."(с)
2) "... пришлось (через полгода) отразить в учете влияния переплат и долгов 2011 года на задолженности 2012 года"(с)
Кто и как обеспечил в 2012 году информацию 2011 года в регистре ТребуетсяПереопределитьСтатусы для контрагентов, которые НЕ попадали в регистр в 2011 году, т.к. регистра еще не было?
22. г. Казань Рустем Гумеров (Rustig) 29.07.13 16:25
(21) ясно, спасибо вам, что так глубоко вникаете в вопрос. вы правы в том, что что-то я не дорассказываю. :)
заведомо старался обойти вопрос своего алгоритма, потому что это не принципиально. я даже описание задачи упростил донельзя. теперь постараюсь ответить на ваш вопрос.
"При записи документов, потенциально влияющих на изменение статусов и показателей контрагента, ...."
у меня задействован еще один регистр сведений, называемый условно говоря "Список контрагентов, участвующих в системе бонусов", в которых фиксируются все изменения ключевых параметров: дата первой сделки, дата последней сделки, и т.д.
Поэтому, кроме регистра бухгалтерии Хозрасчетный "обеспечителем" информации 2011-го года в 2012-ом году стал вышеупомянутый регистр сведений. Он же до определенного момента использовался в "большом" запросе.
23. г. Казань Рустем Гумеров (Rustig) 29.07.13 16:29
(22) в новом алгоритме получилось так, что теперь при записи документа перезаписывается регистр сведений "Список контрагентов,....", а при перезаписи этого регистра контрагент попадает в регистр "Требуется переопределить статусы"...
то есть я добавил малость к старому механизму - при Записи регистра сведений "Список контрагентов,..." теперь происходит запись в дополнительный регистр "Требуется переопределить..."
24. Владимир (hogik) 29.07.13 16:58
(23)
"при перезаписи этого регистра контрагент попадает в регистр"(с)
Рустем (Rustig).
А использовать временное множество (массив, список, рабочая таблица) строк содержания "дополнительного регистра" формируемого первым запросом/алгоритмом по регистру "Список контрагентов,...." в ОТЧЕТЕ для дальнейшей обработки другим запросом/алгоритмом - не получается?
25. г. Казань Рустем Гумеров (Rustig) 29.07.13 17:16
(24) ну что вы, :), конечно получается :) я же не об этом

вы обратили внимание на конструкцию в запросе из примера (9) ?

если кратко говорить, то суть моих изменений не в том, что перестал использовать временное хранилище из (24), а в том, что я разгрузил свой большой запрос от конструкций, подобных в примере (9).
26. Владимир (hogik) 29.07.13 17:46
(25)
"разгрузил свой большой запрос от конструкций, подобных"(с)
Рустем (Rustig).
Про это написано в (12) сообщении. Последнее предложение.
А про выбранный Вами способ решения проблемы "больших" запросов написал Вам в первом сообщении (см. в личке). Еще до начала обсуждения в открытой печати. :-)
27. Игорь Исхаков (Ish_2) 30.07.13 16:14
Рустем , правильно назвать тему "Я придумал костыль к типовой..".
Дескать , извернулся в данной конкретной ситуации, потому что другого пути не нашел.
"Затычка" она и есть "затычка". Не судите строго.
При таких разьяснениях не было бы недоуменных реплик про "пляски от отчета".

Если же ты предлагаешь свой подход в качестве "типового" приема в разработке , проектировании БД - мне очень жаль.
28. Александр Лапшин (zfilin) 30.07.13 17:06
(27) Ish_2, Скажите, а чем на ваш взгляд плох такой подход в качестве "типового" приема в разработке, проектировании БД?
29. Игорь Исхаков (Ish_2) 30.07.13 17:32
(28) Суть приема Рустема - создание вспомогательных , дополнительных процедур и стуктур хранения информации для вывода отчета , непредусмотренного в типовой конфигурации.
Вполне возможно , что такой прием оправдан : деваться некуда , структура БД уже задана разработчиками 1с.

А вот если мы с нуля проектируем БД и априорно определена необходимость вывода вышеуказанного отчета ,то тогда применение приема Рустема с регламентными заданиями , пересчетами статусов для всего лишь вывода отчета смотрится избыточно и даже диковато.
30. г. Казань Рустем Гумеров (Rustig) 30.07.13 17:43
(29) Свершилось чудо! я наконец-то вас услышал! :)
А вот если мы с нуля проектируем БД и априорно определена необходимость вывода вышеуказанного отчета ,то тогда применение приема Рустема с регламентными заданиями , пересчетами статусов для всего лишь вывода отчета смотрится избыточно и даже диковато.

согласен с вами! я даже уже подумываю а не переписать ли конфу? только уже использовать регистры накопления и регистры сведений для хранения первичной информации вместо регистра бухгалтерии... полагаю, что ничего не стоит пересмотреть структуру БД и алгоритмы даже для базы, находящейся в эксплуатации.
31. Владимир (hogik) 30.07.13 17:50
(30)
"для хранения первичной информации"(с)
Рустем (Rustig).
Как это согласуется с Вашей технологией - "хранить и создавать вторичную ;-) информацию"?
32. г. Казань Рустем Гумеров (Rustig) 30.07.13 17:57
(29) все же если вернуться к теме больших запросов... получается так, что на этапе проектирования сразу не видно какие регистры сведений и накоплений использовать при наличии регистров бухгалтерии и регистров расчетов. ведь кажется что последние регистры решат многие учетные проблемы. Далее система запускается в эксплуатацию, пишутся большие запросы, но уже ни у кого нет ресурсов переиначить структуру БД для упрощения (оптимизации) запросов. проблема не решается, а только усугубляется с изменением законодательства. пока мне так кажется ситуация. и еще мне кажется, почему бы не использовать встроенные механизмы получения итоговых остатков по регистру бухгалтерии и регистру расчетов (по сути уже разработанные, бери и пользуйся, как говорится)? Ведь если подумать только, что для получения аналогичных итоговых остатков, надо будет прописывать механизмы с использованием регистров накоплений - то объем решения задачи увеличивается десятикратно. как вы думаете? я пока простого решения не вижу
33. г. Казань Рустем Гумеров (Rustig) 30.07.13 18:05
(31) не знаю как согласуется :)
в описанном в статье подходе для наполнения регистра сведений я использую итоговые остатки бухгалтерского регистра.
если проектировать БД с нуля, то такой подход кажется не очевидным, и потому "диковатым". я наверное первым описал такой дикий подход. очевидным был бы подход создать регистры накопления как в УТ, которые будут накапливать информацию о взаиморасчетах с контрагентами, по своей сути повторяя те же бухгалтерские итоги в БП. При условии, что базы обмениваются документами.
34. Игорь Исхаков (Ish_2) 30.07.13 18:10
(32) Эге.. Да ты всерьез.
Я ведь прочитал тему наискосок и привел суждения (27),(29) навскидку.
От более подробного обсуждения воздержусь. Здесь важны детали (скорее всего дьявольские).
35. Владимир (hogik) 30.07.13 18:18
(33)
"создать регистры накопления ... которые будут накапливать информацию о взаиморасчетах с контрагентами"(с)
Рустем (Rustig).
У регистров есть еще одно (более значимое) назначение кроме как накапливать. ;-)
Вот мое мнение простым языком:
"... регистр можно "обозвать" общим составным индексом (в терминах СУБД) для множества иерархических структур (документов)."(с) http://infostart.ru/public/94437/
36. г. Казань Рустем Гумеров (Rustig) 30.07.13 20:32
(29) продолжая тему "диких" штучек, зацените http://infostart.ru/public/196028/
:) мне очень понравилось :)
37. Игорь Исхаков (Ish_2) 30.07.13 23:28
(36) "Прогресс-бар" - слово смешное, согласен.
А еше - где там смеяться ?
38. Марат Настоящий (rayastar) 09.01.14 14:31
Вывод статьи я сделал в пользу того, что
первое - надо идти от отчета
второе - проявить творчество и подготовить исходные данные(создать вспомогательные регистры)
На самом деле, решение вспомогательных регистров лежит на поверхности, но пока не увидишь на примере - не поверишь :)
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа