gifts2017

БП1.6. Просроченная задолженность по 62 счету. Продолжение разговора

Опубликовал Игорь Исхаков (Ish_2) в раздел Отчеты - Бухгалтерские

Свободное скачивание.
Для бухгалтера : подробный отчет о просроченных долгах контрагентов по 62 счету.
Для программиста : как одним  запросом получить выходную таблицу просроченных долгов ? Развитие темы  "Подведем итоги. Нарастающие" http://infostart.ru/public/61295/

Общий вид отчета :

Для бухгалтера.

Для каждой пары контрагент-договор  на дату отчета определяется сумма сальдо по 62 счету в целом (колонка" Общий долг"). На эту сумму сальдо в обратном хронологическом порядке набираются документы отгрузки (дебетовые обороты счета 62.01). Для каждого документа отгрузки  определяется  количество дней от даты отчета. Это количество сравнивается с количеством дней , установленным в договоре и определяется просрочен долг по документу или нет (колонки "Просрочено" или "Не просрочено"). Если в договоре документа не указан реквизит Срок оплаты , то берется значение из формы отчета - "Срок Оплаты". Колонку "Просрочено" можно развернуть по назначенным интервалам(кнопка "Интервалы")  и дням. См рисунок.

Внимание. Значение в колонке "Общий долг" для контрагента может не совпадать с сальдо контрагента по 62 счету в целом.
Потому что общий долг контрагента формируется как сумма всех больших нуля сальдо по договорам. В эту сумму не входят отрицательные сальдо по договорам.
Работа отчета не зависит от установки режима "Расчет по документам" (наличие или отсутствие третьего субконто на 62 счете).

Для программиста.

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

Запрос для получения выходной таблицы получен без кодинга. Только при помощи конструктора запроса. Автору представляется такой подход к построению отчета   наиболее оптимальным для клиент-серверного варианта базы. Мы практически отвязываемся от "слабости" клиента и основную обработку перекладываем на сервер БД. Алгоритм, используемый в отчете и описанный в статье http://infostart.ru/public/61295/,  должен быть эффективен при использовании как на малых , так и на средних (>30 Гб) и  больших базах (>100 Гб). Автор будет особенно признателен авторам отзывов , которые будут тестировать отчет на средних и больших базах.
В представленном внешнем отчете для оформления использованы процедуры и функции типового отчета БП 1.6 "Задолженность покупателей по срокам долга". Функционирование отчета протестировано на релизах БП с 1.6.15 по 1.6.22.
Для выделения строки в табличном документе отчета использована разработка "Активный крест в табличном документе" http://infostart.ru/public/19519/

 

Для любопытных.

Задача просроченных долгов - лишь частный случай задачи списания по методу ФИФО.
Действительно, в задаче просроченного долга :
S- сумма долга контрагента
C1,C2,.....Сk - последовательность сумм документов отгрузки
Нужно определить такую последовательность Сm,Cm+1....Cn , чтобы
S=Сm+Cm+1+....+Cn
Грубо говоря , мы набираем на сумму S суммы документов отгрузки.

Если вместо S определить последовательность приходов S1,S2,.....Sk , то получим задачу списания по методу ФИФО.

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

"Позднее" наступило 02.04.2010 http://infostart.ru/public/68225/

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
ЗадолженностьПокупателейПоСрокамДолга_1_3.erf
.erf 29,89Kb
08.07.10
400
.erf 29,89Kb 400 Бесплатно

См. также

Подписаться Добавить вознаграждение

Комментарии

1. ValeriTim (ValeriTim) 14.01.10 10:21
Вот действительно классный отчет с отличной реализацией. Можно было бы поставить +10 - поставил бы :!:
2. Александр Медведев (anig99) 16.01.10 20:18
гыгы... плюсы за идею уже ставил... отчет может и хороший, но я такие не юзаю, поэтому ничего пока не поставлю....(:
3. Игорь Исхаков (Ish_2) 16.01.10 23:16
4. Света М (мсе) 18.01.10 11:43
Очень приятно, что можно увидеть дату возникновения задолженности.
5. Eugeneer (Eugeneer) 18.01.10 17:38
Опять за бесплатно. Вот делать вам нечего. Когда будет продаваться поставлю плюс. Иначе смысла нет. Доверять правильности отчета можно только платной версии, т.к. только в таком случае разработчик может доводить все до идеального рабочего варианта.
6. Игорь Исхаков (Ish_2) 18.01.10 17:43
(5) Да , ладно ,Женя. Чего там..
7. Eugeneer (Eugeneer) 18.01.10 17:48
(6) ну а что я неправ?:) отдаете свои знания задаром. Лучше бы уже мегасуперотчет сделали и все были довольны и ты даром силы не тратил. лучше бы пустил силы на поддержку пользователей и развитие.
тема уже скучная просто. итак понятно что все супер и т.п. вот версию для БП сделали.
8. Eugeneer (Eugeneer) 18.01.10 17:50
насчет плюса на платную версию пошутил конечно.
ставлю плюс однозначно. отчет хороший.
9. Борис Балясников (bb1962) 20.01.10 09:53
(0) > такая задача может быть решена без кодинга при помощи одного пакета запросов
Всегда ли это хорошо? По этому пути идут разработчики 1С, но каково потом вносить изменения в эти "многоэтажные запросы".
10. Игорь Исхаков (Ish_2) 20.01.10 11:31
(9) Вопрос закономерный : Всегда ли это хорошо ?

Для данной конкретной задачи - считаю , что ДА.

1. Переносим всю обработку на Сервер БД(отвязываемся от слабости клиента).

2. Для больших БД такой подход более эффективен (обладает высоким быстродействием), чем кодинг.

3. "Многоэтажный" запрос - это совокупность небольших простых запросов , последовательное получение временных таблиц. Такой запрос легко может быть разбит при отладке и есть возможность просмотра промежуточных результатов.

11. Anatolii Karasev (KapasMordorov) 20.01.10 12:33
(9)
(10)
Я тут sql.ru пошарил.
Вроде бы ФИФО запросами они там сделали.
Но пришли к выводу, что цикл в хранимой процедуре быстрее.
12. Игорь Исхаков (Ish_2) 20.01.10 12:53
(11) Речь идет методе списания ФИФО ?
Эффективность реализации метода списания ФИФО - как "все в одном запросе", разумеется, будет определяться по результатам тестирования и сравнения. На SQL.ru я задавал этот вопрос . Кроме общих скептических соображений ничего не услышал и ссылок никто не привел.
Пока речь идет лишь о решениии некоей абстрактной задачи
http://infostart.ru/public/63048/?PAGEN_1=3#comm340515
13. Anatolii Karasev (KapasMordorov) 20.01.10 13:37
Сегодня НДС и не помню какой текст в яндексе вчера набирал для поиска. Попадаю в другую ветку sql.ru
Будет время, поищу
14. Игорь <...> (I_G_O_R) 23.01.10 20:47
Зачем запрос отдельно от СКД?
15. Игорь Исхаков (Ish_2) 23.01.10 22:40
(14) Заметил -таки.
Вначале я планировал так :
Наборы данных :
Первый - это сам запрос.
Второй - это таблица интервалов дней ( вводится пользователем), каждая строка которой содержит два значения "с" и "по" .
Делаем левое соединение и ОК.
Но левое соединение в СКД предполагает только соединения по равенству.
Моё же левое соединение должно быть по условию вхождения в интервал
> "с" и <="до" (двойное неравенство).
Поэтому пришлось всё делать вне СКД.

А ты еще помнишь тему "Языком запросов раздать N яблок M складам"
http://infostart.ru/public/21564/
Ноги третьего абзаца "для любопытных" растут из неё .
16. Игорь <...> (I_G_O_R) 23.01.10 23:01
да я давно заметил, просто сказать было нечего, да и посмотрел только

а в чем проблема соединение делать в запросе и использовать один набор данны?
СтрЗаменить - тоже не нравится, я бы все-таки сделал полностью в СКД, в настройках бы добавил отборы, но включал их только если значения заполнены


Ноги третьего абзаца
- не понял что это

17. Игорь Исхаков (Ish_2) 23.01.10 23:34
(16)
В одном наборе данных , т.е. в одном запросе в СКД нельзя использовать данные из внешнего источника.
Т.е. тот запрос из текста как есть в СКД не засунешь, т.к. он содержит
&ВнешнийИсточник.

Третий абзац текущей темы "Для любопытных" содержит описание задачи
списания по ФИФО.
В первый раз я описал эту задачу в коммментарии № 8 твоей темы про яблоки.
18. Andrey Fedotov (nikola_piter) 24.01.10 00:15
19. Игорь <...> (I_G_O_R) 24.01.10 13:31
а задача с периодами решается вообще в режиме предприятие с помощью пользовательских полей или таким запросом
ВЫБРАТЬ
	1 КАК НомерИнтервала,
	1 КАК НачалоИнтервала,
	7 КАК КонецИнтервала,
	"от 1 до 7 дней" КАК ИмяИнтервала
ПОМЕСТИТЬ ТабИнтервалы

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
	2,
	8,
	15,
	"от 8 до 15 дней"

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
	3,
	16,
	30,
	"от 16 до 30 дней"
;
...Показать Скрыть
Прикрепленные файлы:
20. Игорь Исхаков (Ish_2) 24.01.10 15:03
(19) Такой подход к пострению в запроса оправдан, если интервалы вечны и неизменны.Но так как пользователь должен произвольно назначать интервалы , то такой путь построения запроса сомнителен.

А на скриншоте у тебя показано то же,что и в моём отчете по кнопке "интервалы". Т.е. пользователь интерактивно заполняет таблицу интервалов, которая потом через параметр &ВнешнийИсточник используется в запросе.
21. Ярослав Радкевич (WKBAPKA) 24.01.10 16:39
22. Игорь Исхаков (Ish_2) 24.01.10 20:35
(21) Георгий, ты конструктивен. И лаконичен.
(19) Не сразу понял , что ты вел речь о настройке в типовых отчетах для СКД.
23. Ярослав Радкевич (WKBAPKA) 24.01.10 21:10
Вот запрос который решает проблему для меня в УТ, правда при обходе нужно расчитать коэффициент. Кстати, может укажите мне на мои ошибки:
ВЫБРАТЬ
	ВзаиморасчетыСКонтрагентами.Регистратор КАК Регистратор,
	ВзаиморасчетыСКонтрагентами.Сделка КАК Сделка,
	ВзаиморасчетыСКонтрагентами.Контрагент.ГоловнойКонтрагент КАК ГоловнойКонтрагент,
	ВзаиморасчетыСКонтрагентами.ДоговорКонтрагента КАК ДоговорКонтрагента,
	ВзаиморасчетыСКонтрагентами.ДокументРасчетовСКонтрагентом КАК ДокументРасчетовСКонтрагентом,
	ВзаиморасчетыСКонтрагентами.Контрагент.ГоловнойКонтрагент.ОсновнойМенеджерПокупателя КАК Менеджер,
	ЕСТЬNULL(ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовНачальныйОстаток, 0) КАК СуммаВзаиморасчетовНачальныйОстаток,
	ЕСТЬNULL(ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовКонечныйОстаток, 0) КАК СуммаВзаиморасчетовКонечныйОстаток,
	ЕСТЬNULL(ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовОборот, 0) КАК СуммаВзаиморасчетовОборот,
	ВЫБОР
		КОГДА ВзаиморасчетыСКонтрагентами.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг
				И ВзаиморасчетыСКонтрагентами.Регистратор.Дата >= &Дата1
			ТОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовОборот
	КОНЕЦ КАК СуммаРеализацияТовара,
	ВЫБОР
		КОГДА (ВзаиморасчетыСКонтрагентами.Регистратор ССЫЛКА Документ.ПлатежноеПоручениеВходящее
				ИЛИ ВзаиморасчетыСКонтрагентами.Регистратор ССЫЛКА Документ.ПриходныйКассовыйОрдер)
				И ВзаиморасчетыСКонтрагентами.Регистратор.Дата >= &Дата1
			ТОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовОборот
	КОНЕЦ КАК СуммаОплатыТовара,
	ВЫБОР
		КОГДА ВзаиморасчетыСКонтрагентами.Регистратор ССЫЛКА Документ.ВозвратТоваровОтПокупателя
				И ВзаиморасчетыСКонтрагентами.Регистратор.Дата >= &Дата1
			ТОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовОборот
	КОНЕЦ КАК СуммаВозвратаТовара,
	ВЫБОР
		КОГДА ВзаиморасчетыСКонтрагентами.Регистратор ССЫЛКА Документ.ПоступлениеТоваровУслуг
				И ВзаиморасчетыСКонтрагентами.Регистратор.Дата >= &Дата1
			ТОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовОборот
	КОНЕЦ КАК СуммаПоступленияТовараПоставщик,
	ВЫБОР
		КОГДА (ВзаиморасчетыСКонтрагентами.Регистратор ССЫЛКА Документ.ПлатежноеПоручениеИсходящее
				ИЛИ ВзаиморасчетыСКонтрагентами.Регистратор ССЫЛКА Документ.РасходныйКассовыйОрдер)
				И ВзаиморасчетыСКонтрагентами.Регистратор.Дата >= &Дата1
			ТОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовОборот
	КОНЕЦ КАК СуммаОплатыТовараПоставщик,
	ВЫБОР
		КОГДА ВзаиморасчетыСКонтрагентами.Регистратор ССЫЛКА Документ.ВозвратТоваровПоставщику
				И ВзаиморасчетыСКонтрагентами.Регистратор.Дата >= &Дата1
			ТОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовОборот
	КОНЕЦ КАК СуммаВозвратаТовараПоставщик,
	ВЫБОР
		КОГДА ВзаиморасчетыСКонтрагентами.Регистратор ССЫЛКА Документ.КорректировкаДолга
				И ВзаиморасчетыСКонтрагентами.Регистратор.Дата >= &Дата1
			ТОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовОборот
	КОНЕЦ КАК СуммаКорректировкиДолга,
	ВЫБОР
		КОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовКонечныйОстаток < 0
			ТОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовКонечныйОстаток
		ИНАЧЕ 0
	КОНЕЦ КАК Предоплата,
	ВЫБОР
		КОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовКонечныйОстаток > 0
			ТОГДА ВЫБОР
					КОГДА РАЗНОСТЬДАТ(ВзаиморасчетыСКонтрагентами.ДокументРасчетовСКонтрагентом.Дата, &Дата2, ДЕНЬ) <= ВзаиморасчетыСКонтрагентами.Контрагент.ДопустимоеЧислоДнейЗадолженности
						ТОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовКонечныйОстаток
					ИНАЧЕ 0
				КОНЕЦ
		ИНАЧЕ 0
	КОНЕЦ КАК Текущая,
	ВЫБОР
		КОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовКонечныйОстаток > 0
			ТОГДА ВЫБОР
					КОГДА РАЗНОСТЬДАТ(ВзаиморасчетыСКонтрагентами.ДокументРасчетовСКонтрагентом.Дата, &Дата2, ДЕНЬ) > ВзаиморасчетыСКонтрагентами.Контрагент.ДопустимоеЧислоДнейЗадолженности
							И РАЗНОСТЬДАТ(ВзаиморасчетыСКонтрагентами.ДокументРасчетовСКонтрагентом.Дата, &Дата2, ДЕНЬ) <= ВзаиморасчетыСКонтрагентами.Контрагент.ДопустимоеЧислоДнейЗадолженности + &ЧислоДней
						ТОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовКонечныйОстаток
					ИНАЧЕ 0
				КОНЕЦ
		ИНАЧЕ 0
	КОНЕЦ КАК Лояльная,
	ВЫБОР
		КОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовКонечныйОстаток > 0
			ТОГДА ВЫБОР
					КОГДА РАЗНОСТЬДАТ(ВзаиморасчетыСКонтрагентами.ДокументРасчетовСКонтрагентом.Дата, &Дата2, ДЕНЬ) > ВзаиморасчетыСКонтрагентами.Контрагент.ДопустимоеЧислоДнейЗадолженности + &ЧислоДней
						ТОГДА ВзаиморасчетыСКонтрагентами.СуммаВзаиморасчетовКонечныйОстаток
				КОНЕЦ
	КОНЕЦ КАК Просроченная
ИЗ
	РегистрНакопления.ВзаиморасчетыСКонтрагентамиПоДокументамРасчетов.ОстаткиИОбороты(&Дата1, &Дата2, Регистратор, Движения, Контрагент В ИЕРАРХИИ (&Параметр1)) КАК ВзаиморасчетыСКонтрагентами
ГДЕ
	ВзаиморасчетыСКонтрагентами.ДоговорКонтрагента.БонусДилера = ЛОЖЬ

УПОРЯДОЧИТЬ ПО
	ВзаиморасчетыСКонтрагентами.Сделка.Дата,
	ВзаиморасчетыСКонтрагентами.ДокументРасчетовСКонтрагентом.Дата
ИТОГИ
	СУММА(СуммаВзаиморасчетовНачальныйОстаток),
	СУММА(СуммаВзаиморасчетовКонечныйОстаток),
	СУММА(СуммаВзаиморасчетовОборот),
	СУММА(СуммаРеализацияТовара),
	СУММА(СуммаОплатыТовара),
	СУММА(СуммаВозвратаТовара),
	СУММА(СуммаПоступленияТовараПоставщик),
	СУММА(СуммаОплатыТовараПоставщик),
	СУММА(СуммаВозвратаТовараПоставщик),
	СУММА(СуммаКорректировкиДолга),
	СУММА(Текущая),
	СУММА(Лояльная),
	СУММА(Просроченная)
ПО
	ОБЩИЕ,
	ГоловнойКонтрагент ИЕРАРХИЯ КАК ГоловнойКонтрагент,
	ДоговорКонтрагента КАК ДоговорКонтрагента,
	Сделка КАК Сделка,
	ДокументРасчетовСКонтрагентом КАК ДокументРасчетовСКонтрагентом,
	Регистратор КАК Регистратор


...Показать Скрыть
24. Игорь <...> (I_G_O_R) 25.01.10 00:27
(23)
ГДЕ 
   ВзаиморасчетыСКонтрагентами.ДоговорКонтрагента.БонусДилера = ЛОЖЬ
- это нужно запихать в параметры виртуальной таблицы, но как я понимаю, таких договоров большинство, так что скорости скорее всего не сильно прибавит.
ОстаткиИОбороты - сама по себе очень тормозная таблица, смотрел в MS SQL Profiler, 1С генерирует кучу запросов;
еще нужно заменить
ВзаиморасчетыСКонтрагентами.Регистратор.Дата
на
ВЫРАЗИТЬ(ВзаиморасчетыСКонтрагентами.Регистратор КАК Документ.РеализацияТоваровУслуг).Дата

- это из базы знаний 1С http://kb.1c.ru/articleView.jsp?id=44#dot_after_component_type
25. Игорь Исхаков (Ish_2) 25.01.10 07:35
(23) Скажи , Георгий , зависит ли правильность результата отчета от последовательности проведения документов ?
26. Ярослав Радкевич (WKBAPKA) 25.01.10 09:52
2(25): меня зовут не Георгий, а Ярослав...
я так понимаю, что речь идет о дате возникновения долга... прежде всего, я пользуюсь регистром "Взаиморасчеты с контрагентами по документам расчета". Этот регистр, насколько я понял, используется только тогда, когда для договора контрагента установлен признак "Вести учет по документам расчетов". Т.к. я для себя установил такой признак для всех, то соответственно я использую измерения "Документ расчетов с контрагентом" в качестве отправной точки для расчета задолженности. В этом случае для меня последовательность не важна, т.к. фактически я получаю сальдо по этому измерению, а не по регистратору. А т.к. на предприятии в 99% случаев всегда идет цепочка Заказ - Расход то в моем случае задача упрощается...
помучаться пришлось с одним, и то, потому как туповат стал... результат запрос по виртуальным показателям по каждой группировке суммируется, чем больше регисраторов тем в большее количество раз, соответственно, при обходе пришлось брать полученный результат делить на конечный долг, получать коэффициент и уже после этого делить полученный результат на этот коэффициент...
27. Ярослав Радкевич (WKBAPKA) 25.01.10 09:52
28. Игорь Исхаков (Ish_2) 25.01.10 09:56
29. Ярослав Радкевич (WKBAPKA) 25.01.10 10:00
как бы задача решилась, но не приятный остаток остался ...
2(28): скажите, а манипулирование виртуальными таблицами, кроме хранения промежуточных результатов, что дает?
например, могу ли я выполнить запрос с подсчетом итогов с помощью предложения "ИТОГИ ПО", поместить результат в виртуальную таблицу, и в другом запросе обратиться к этому результату, выбрать необходимые данные и опять подсчитать итоги... или виртуальные таблицы просто позволяют делить большие запросы на подзапросы с последовательным (каскадным) исполнением, и предназначены сугубо для оптимизации?
30. Игорь Исхаков (Ish_2) 25.01.10 10:02
(26) Можно сказать , что решение тобой предлагаемое - частное.
Т.е. в случае если не установлен флаг "Вести учет по документам расчетов", то предложенный тобой алгоритм неприменим при нарушении псоледовательности.


31. Игорь Исхаков (Ish_2) 25.01.10 10:04
(29) Кажется не совру , если скажу :
Предложение "ИТОГИ" нельзя использовать при помещении результата во временную таблицу (опция ПОМЕСТИТЬ)
32. Игорь Исхаков (Ish_2) 25.01.10 10:05
(29)
виртуальные таблицы просто позволяют делить большие запросы на подзапросы с последовательным (каскадным) исполнением, и предназначены сугубо для оптимизации?


Согласен.
33. Ярослав Радкевич (WKBAPKA) 25.01.10 10:08
2(30): совершенно верно... это сильно упростило задачу... дело в том, что в типовой сделали закрытие реализации по фифо в платежных документах, но только для этого регистра, грех было не воспользоваться...
34. Игорь Исхаков (Ish_2) 25.01.10 10:11
(33) Ты договаривай до конца : объем данных регистра после установки расчета по документам резко вырос.
35. Михаил Ражиков (tango) 25.01.10 10:13
(29),(31)
Прикрепленные файлы:
36. Ярослав Радкевич (WKBAPKA) 25.01.10 10:13
2(34): ыщо пока не проверял... но если учитывать туеву кучу регистров, что натулили в типовой, добавление еще одного регистра особо как то не повлияет на скорострельность...
но по скорости роста базы, прирост не значителен...
37. Ярослав Радкевич (WKBAPKA) 25.01.10 10:17
2(35): логично, если использовать таблицу значений... есть один нюанс, по крайней мере у меня не получалось, если поле составного типа, то запрос к такой таблице значений не будет работать... требует исключительно типизированные поля...
и еще, и желательно индексировать поля ТЗ, иначе медленно работает
38. Игорь Исхаков (Ish_2) 25.01.10 10:25
(35) Ты привёл пример как обойти ограничение : невозможность совместного использования опций ИТОГИ и ПОМЕСТИТЬ.
Но разумнее , мне кажется, подход , где используется две врем. таблицы :
1. Запрос без итогов
2. Запрос с опцией СГРУППИРОВАТЬ
39. Dimel 30.04.10 05:33
Спасибо - хороший отчет только мелкий косячок в запрос передается дата конца дня а при работе с таблицей остатков надо бы границу ;)
40. ivan ivanov (ivan07) 27.01.12 13:59
Спасибо, воспользовался вашим отчетом, все отлично
41. Андрей - (Motor24) 06.12.12 11:31
Скачал, спасибо, надеюсь на БП 2.0 (8.2) переконвертируется нормально.
43. Игорь Исхаков (Ish_2) 16.04.14 19:22
(42) Здесь скорее интерес для программиста.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа