база внутри. за прошедшее время она обросла таблицами .
Опишу, это все, постараюсь сделать лаконично
База консолидирует информацию по продажам и остаткам. Содержит.
А. Первичные продажи (PERVICHKA) структура следующая
distributor
product
date_pervichka
quantity
sales_whitout_VAT
Б. Вторичные продажи (SALES) продажи дистрибьюторов
price
distributor
product
brunch
customer
quantity
region
date_sales
В. Планы продаж (PLAN) .План выставляется на определенные регионы и на определенные продукты (в таблицах PRODUCT и REGION есть поле которое указывает на это (это поле plan))
region
product
date_plan
plan rub
plan quan
Г. Остатки на филиалах поставщиков (ACTUAL_BALANCE).
brunch
distributor
product
actual_balance
date_actual_balance
Что нужно получить в первом приближении .
БД в которой будут храниться/обновляться данные по : (добавление на ежемесячной основе новых данных, предполагается загрузка из EXCEl) -продажам -планам -прайсам -остаткам дистрибьюторов
Натсроены отчеты по :
-продажам (отчет, который будет выдавать продажи в рублях, на основании прайса) -отгрузкам (отгрузки по месяцам и по дистрибьюторам ) -выполнению плана ( план факт таблица ) -история цены прайса -остатки дистрибьюторов (остатки помесячно у дистрибьюторов)
И самый главный для меня вопрос как сделать так, что бы это обновлялось и пополнялось новыми данными.
база внутри. за прошедшее время она обросла таблицами .
Опишу, это все, постараюсь сделать лаконично
База консолидирует информацию по продажам и остаткам. Содержит.
А. Первичные продажи (PERVICHKA) структура следующая
distributor
product
date_pervichka
quantity
sales_whitout_VAT
Б. Вторичные продажи (SALES) продажи дистрибьюторов
price
distributor
product
brunch
customer
quantity
region
date_sales
В. Планы продаж (PLAN) .План выставляется на определенные регионы и на определенные продукты (в таблицах PRODUCT и REGION есть поле которое указывает на это (это поле plan))
region
product
date_plan
plan rub
plan quan
Г. Остатки на филиалах поставщиков (ACTUAL_BALANCE).
brunch
distributor
product
actual_balance
date_actual_balance
Что нужно получить в первом приближении .
БД в которой будут храниться/обновляться данные по : (добавление на ежемесячной основе новых данных, предполагается загрузка из EXCEl) -продажам -планам -прайсам -остаткам дистрибьюторов
Натсроены отчеты по :
-продажам (отчет, который будет выдавать продажи в рублях, на основании прайса) -отгрузкам (отгрузки по месяцам и по дистрибьюторам ) -выполнению плана ( план факт таблица ) -история цены прайса -остатки дистрибьюторов (остатки помесячно у дистрибьюторов)
И самый главный для меня вопрос как сделать так, что бы это обновлялось и пополнялось новыми данными.qpp
Вот, например, таблица PLAN. Зачем ей уникальный ключ в виде абстрактного поля "номер плана"(id)? Ну есть номер и дальше что? Он ни с чем не связан и несмотря на свою "ключевость" легко пропускает дублирование любой записи, ну конечно сам при этом не повторяясь (только что толку от этого?).
Взгляд на эту таблицу наводит на мысль, что вот комбинация полей "region - product - date_plan", наверное, по смыслу должна быть уникальна. Вот эти три поля и следует сделать первичным составным ключом этой таблицы (значок "золотого ключика" в схеме будет напротив каждого из них).
Ну-с, начнём потихоньку критиканствовать...
Вот, например, таблица PLAN. Зачем ей уникальный ключ в виде абстрактного поля "номер плана"(id)? Ну есть номер и дальше что? Он ни с чем не связан и несмотря на свою "ключевость" легко пропускает дублирование любой записи, ну конечно сам при этом не повторяясь (только что толку от этого?).
Взгляд на эту таблицу наводит на мысль, что вот комбинация полей "region - product - date_plan", наверное, по смыслу должна быть уникальна. Вот эти три поля и следует сделать первичным составным ключом этой таблицы (значок "золотого ключика" в схеме будет напротив каждого из них).Gustav
qpp, по Вашему первому запросу (пост №17) попробуйте такой вариант [vba]
Code
SELECT [Запрос ПЕРВИЧКА по дистрибам].distributor, Sum([Запрос Sales дистрибьютор регион].[Sum-quantity]) AS [sales-quantity], Sum([Запрос ПЕРВИЧКА по дистрибам].[Sum-quantity]) AS [PERVICHKA-quantity], [Запрос ПЕРВИЧКА по дистрибам].date_pervichka FROM [Запрос Sales дистрибьютор регион] RIGHT JOIN [Запрос ПЕРВИЧКА по дистрибам] ON ([Запрос Sales дистрибьютор регион].distributor = [Запрос ПЕРВИЧКА по дистрибам].distributor) AND ([Запрос Sales дистрибьютор регион].data_sales = [Запрос ПЕРВИЧКА по дистрибам].date_pervichka) GROUP BY [Запрос ПЕРВИЧКА по дистрибам].distributor, [Запрос ПЕРВИЧКА по дистрибам].date_pervichka ORDER BY [Запрос ПЕРВИЧКА по дистрибам].date_pervichka;
[/vba] Это если поле даты будет всегда первым числом месяца.
Quote (qpp)
предполагается загрузка из EXCEl
А в Excel данные откуда будут попадать?
qpp, по Вашему первому запросу (пост №17) попробуйте такой вариант [vba]
Code
SELECT [Запрос ПЕРВИЧКА по дистрибам].distributor, Sum([Запрос Sales дистрибьютор регион].[Sum-quantity]) AS [sales-quantity], Sum([Запрос ПЕРВИЧКА по дистрибам].[Sum-quantity]) AS [PERVICHKA-quantity], [Запрос ПЕРВИЧКА по дистрибам].date_pervichka FROM [Запрос Sales дистрибьютор регион] RIGHT JOIN [Запрос ПЕРВИЧКА по дистрибам] ON ([Запрос Sales дистрибьютор регион].distributor = [Запрос ПЕРВИЧКА по дистрибам].distributor) AND ([Запрос Sales дистрибьютор регион].data_sales = [Запрос ПЕРВИЧКА по дистрибам].date_pervichka) GROUP BY [Запрос ПЕРВИЧКА по дистрибам].distributor, [Запрос ПЕРВИЧКА по дистрибам].date_pervichka ORDER BY [Запрос ПЕРВИЧКА по дистрибам].date_pervichka;
[/vba] Это если поле даты будет всегда первым числом месяца.
По логике абсолютно правильно, регион-продукт-дата это уникальное значение для таблицы ПЛАН.
для PERVICHK'и (id_distr / id_prod / date_pervichka) т.к это тоже уникальное значение. Тогда, по той же логике, я должен сделать составной ключ для SALES ( id_distr / id_prod / ID_brunch / data_sales) получается отгрузка на филиал по дате.
К сожаления, я только могу догадываться о полезности составного ключа, по-этому за любую информацию буду благодарен.
to Pelena в эксель данные попадают из отчетов дистрибьютора, свожу ручками + огромную помощь оказывает уважаемый коллега с форума, потихоньку автоматизируя процесс сбора данных, приведения к одному формату.
я понял вашу логику, спасибо , можно ли использовать в ACCeSS команду FULL OUTER JOIN у меня почему то она не срабатывает
По логике абсолютно правильно, регион-продукт-дата это уникальное значение для таблицы ПЛАН.
для PERVICHK'и (id_distr / id_prod / date_pervichka) т.к это тоже уникальное значение. Тогда, по той же логике, я должен сделать составной ключ для SALES ( id_distr / id_prod / ID_brunch / data_sales) получается отгрузка на филиал по дате.
К сожаления, я только могу догадываться о полезности составного ключа, по-этому за любую информацию буду благодарен.
to Pelena в эксель данные попадают из отчетов дистрибьютора, свожу ручками + огромную помощь оказывает уважаемый коллега с форума, потихоньку автоматизируя процесс сбора данных, приведения к одному формату.
я понял вашу логику, спасибо , можно ли использовать в ACCeSS команду FULL OUTER JOIN у меня почему то она не срабатываетqpp
bigqpp скайп
Сообщение отредактировал qpp - Четверг, 27.09.2012, 18:54
Составной ключ предполагает уникальность сочетания полей. Защита от дублирования.
Quote (qpp)
(id_distr / id_prod / date_pervichka) т.к это тоже уникальное значение
Т.е. первичная отгрузка происходит для каждого дистрибьютора+продукт один раз в месяц?
Quote (qpp)
можно ли использовать в ACCeSS команду FULL OUTER JOIN
Access не поддерживает такую команду, но можно попробовать использовать такую конструкцию SELECT ... FROM ... LEFT JOIN ... ON ... UNION SELECT ... FROM ... RIGHT JOIN ... ON ...
(сама не использовала)
Quote (qpp)
о полезности составного ключа
Составной ключ предполагает уникальность сочетания полей. Защита от дублирования.
Quote (qpp)
(id_distr / id_prod / date_pervichka) т.к это тоже уникальное значение
Т.е. первичная отгрузка происходит для каждого дистрибьютора+продукт один раз в месяц?
Quote (qpp)
можно ли использовать в ACCeSS команду FULL OUTER JOIN
Access не поддерживает такую команду, но можно попробовать использовать такую конструкцию SELECT ... FROM ... LEFT JOIN ... ON ... UNION SELECT ... FROM ... RIGHT JOIN ... ON ...
Т.е. первичная отгрузка происходит для каждого дистрибьютора+продукт один раз в месяц?
Насколько меня терзают смутные сомнения, тут нет хозяйственных операций. Это база сводных данных. Похоже, мы тут сообща проектируем какой-то OLAP-сервер...
Quote (Pelena)
Т.е. первичная отгрузка происходит для каждого дистрибьютора+продукт один раз в месяц?
Насколько меня терзают смутные сомнения, тут нет хозяйственных операций. Это база сводных данных. Похоже, мы тут сообща проектируем какой-то OLAP-сервер... Gustav
Спасибо, т,е, по первичке я дату убираю, тоже и по продажам ? Потому как и в следующем месяце возможна такая комбинация дистр/фил/товар Уважаемый , Gustav, вы считаете что такая детализация излишня?
Спасибо, т,е, по первичке я дату убираю, тоже и по продажам ? Потому как и в следующем месяце возможна такая комбинация дистр/фил/товар Уважаемый , Gustav, вы считаете что такая детализация излишня?qpp
Да, запись одна. Это условие я сделал для того, что бы избежать лишних записей в таблице. внутри одного месяца продукт/дистрибьютор/дата уникальная запись.
Я понимаю что отчет по первичным и вторичным продажам может быть связан через этот составной ключ дистриб/продукт/ дата, но воторой отчет, который я планирую добавить, так же содержир еще и деление по филиалам, т.е. для него ключь будт следующий (id_distr / id_prod / ID_brunch / data_sales). Полностью уникальная запись продажи товара с филиала дистрибьютора за один месяц. Возможно, меня уже заносит не в ту степь .. Но все же.
Который час, а еще с работы не ушел, интересно это.
Да, запись одна. Это условие я сделал для того, что бы избежать лишних записей в таблице. внутри одного месяца продукт/дистрибьютор/дата уникальная запись.
Я понимаю что отчет по первичным и вторичным продажам может быть связан через этот составной ключ дистриб/продукт/ дата, но воторой отчет, который я планирую добавить, так же содержир еще и деление по филиалам, т.е. для него ключь будт следующий (id_distr / id_prod / ID_brunch / data_sales). Полностью уникальная запись продажи товара с филиала дистрибьютора за один месяц. Возможно, меня уже заносит не в ту степь .. Но все же.
Который час, а еще с работы не ушел, интересно это.qpp
qpp, опишу в виде набора тезисов как мне видится ваша база и ее функционирование, а Вы прокомментируйте насколько это соответствует действительности. Итак:
1. Есть некая дистрибьюторская сеть - рисуем круг в центре листа бумаги. Это наша замкнутая система, а круг - ее границы
2. Слева от круга рисуем входящую стрелку - это наш входящий в систему логистический поток (деньги+количество). В схеме данных это таблица PERVICHKA (по смыслу - ПРИХОД системы).
3. Справа от круга рисуем вЫходящую стрелку - это, соответственно, выходящий поток. В схеме данных это таблица SALES (по смыслу - РАСХОД системы).
4. Не забываем основную простую формулу любого учета: ОСТАТОК = ПРИХОД - РАСХОД. В системе понятию ОСТАТОК соответствует таблица ACTUAL_BALANCE. С позиций теоретического проектирования БД наличие такой таблицы уже представляется избыточным, так как по формуле видно, что остаток может быть рассчитан динамически по данным таблиц прихода и расхода. Поэтому теоретически обоснованными в таблице ACTUAL_BALANCE могут быть только единожды помещенные туда данные по остаткам на момент начала учета. Все остальные остатки на любую более позднюю дату могут быть рассчитаны. С применением этой таблицы основная формула может быть чуть-чуть (непринципиально) изменена: ОСТАТОК в любой момент = начальный ОСТАТОК + ПРИХОД до этого момента - РАСХОД до этого момента.
5. ПРИХОД системы (PERVICHKA) представлен в разрезе по: distributor + product.
6. ОСТАТОК системы (ACTUAL_BALANCE) представлен в разрезе по: distributor + brunch + product. Т.е., образно говоря, это наш аккумулятор, в который "втекает" приход и из которого "вытекает" расход.
7. РАСХОД системы (SALES) представлен в разрезе по: distributor + brunch + product (всё те же) + (дополнительно еще) region + customer.
8. Внимание! Первый принципиальный вопрос: а когда в ОСТАТКЕ поток успевает разделиться еще и на brunch? Ведь brunch в ПРИХОДЕ отсутствует...
9. Таблица PLAN с точки зрения логистического потока вообще "не при делах". Всё, что можно с ней делать, так это сравнивать за период её данные и данные таблицы SALES, сгруппированные по полям product + region (чтобы соответствовать "разрезу" таблицы PLAN). По результатам анализа можно выписывать премии/нагоняи - наверное, региональным менеджерам (ну не продуктам же!)
to be continued... (в смысле - по возможности буду еще писать в это сообщение до конца дня)
qpp, опишу в виде набора тезисов как мне видится ваша база и ее функционирование, а Вы прокомментируйте насколько это соответствует действительности. Итак:
1. Есть некая дистрибьюторская сеть - рисуем круг в центре листа бумаги. Это наша замкнутая система, а круг - ее границы
2. Слева от круга рисуем входящую стрелку - это наш входящий в систему логистический поток (деньги+количество). В схеме данных это таблица PERVICHKA (по смыслу - ПРИХОД системы).
3. Справа от круга рисуем вЫходящую стрелку - это, соответственно, выходящий поток. В схеме данных это таблица SALES (по смыслу - РАСХОД системы).
4. Не забываем основную простую формулу любого учета: ОСТАТОК = ПРИХОД - РАСХОД. В системе понятию ОСТАТОК соответствует таблица ACTUAL_BALANCE. С позиций теоретического проектирования БД наличие такой таблицы уже представляется избыточным, так как по формуле видно, что остаток может быть рассчитан динамически по данным таблиц прихода и расхода. Поэтому теоретически обоснованными в таблице ACTUAL_BALANCE могут быть только единожды помещенные туда данные по остаткам на момент начала учета. Все остальные остатки на любую более позднюю дату могут быть рассчитаны. С применением этой таблицы основная формула может быть чуть-чуть (непринципиально) изменена: ОСТАТОК в любой момент = начальный ОСТАТОК + ПРИХОД до этого момента - РАСХОД до этого момента.
5. ПРИХОД системы (PERVICHKA) представлен в разрезе по: distributor + product.
6. ОСТАТОК системы (ACTUAL_BALANCE) представлен в разрезе по: distributor + brunch + product. Т.е., образно говоря, это наш аккумулятор, в который "втекает" приход и из которого "вытекает" расход.
7. РАСХОД системы (SALES) представлен в разрезе по: distributor + brunch + product (всё те же) + (дополнительно еще) region + customer.
8. Внимание! Первый принципиальный вопрос: а когда в ОСТАТКЕ поток успевает разделиться еще и на brunch? Ведь brunch в ПРИХОДЕ отсутствует...
9. Таблица PLAN с точки зрения логистического потока вообще "не при делах". Всё, что можно с ней делать, так это сравнивать за период её данные и данные таблицы SALES, сгруппированные по полям product + region (чтобы соответствовать "разрезу" таблицы PLAN). По результатам анализа можно выписывать премии/нагоняи - наверное, региональным менеджерам (ну не продуктам же!)
to be continued... (в смысле - по возможности буду еще писать в это сообщение до конца дня)Gustav
Gustav, 1-3 соответствует действительности, на практике я бы добавил стрелку в обе стороны на п.3 т.к. дистрибьюторы перепродают товар другим дистрибьюторам, которые так же покупаю товр у нас (скажем если другие не смогли купить товар у нас (дефектура и прочее ) ( но это лирика, описание мук вычисления правдивой информации о продажах из этого нескончаемого потока)) данные которые будут загружаться в базу де-факто от этого уже почищены.
п.4 к сожалению тут не применим, по скольку ACTUAL_BALANCE это срез остатков у дистрибьютора на начало след месяца ( т.к. если мы снимаем продажи за август, таблица ACTUAL_BALANCE предоставляет данные по остаткам на 1 сентября), и как я уже описывал выше возможно что дистр закупил наш товар у кого-то еще ( что нормальная практика), по этой причине данные по остаткам нам так же предоставляет дистрибьютор, и они в 95% случаев не бьются с расчетными приход-расход.
п.5-8 мы отгружаем (первичка) на основной склад дистрибьютора (т.е. в первичке один дистрибьютор имеет один филиал (brunch)), а сам дистрибьютор уже разбрасывает товар по своим филиалам с учетом потребностей (эти данные по остаткам и продажам мы уже получаем от дистрибьютора)
п.6 на самом деле ACTUAL_BALANCE это всего лишь вспомогательные данные, для расчета созданного товарного запаса у дистрибьютора, они должны быть и мы их получам на ежемесячной основе
нашим основным аккумулятором является таблица SALES на основании которой построена вся отчетность, это конечные продажи=вторичные продажи, то что уходит уже в розницу, т.е. нам с вами.
и уже как ,я считаю, к этой таблице нужно привязывать PERVICHKA по дистрибьютору/ товару,
ACTUAL_BALANCE по дистрибьютору/ товары/ филиалу
PLAN по товар/регион/дата
надеюсь я смог ответить на все вопросы.
Gustav, 1-3 соответствует действительности, на практике я бы добавил стрелку в обе стороны на п.3 т.к. дистрибьюторы перепродают товар другим дистрибьюторам, которые так же покупаю товр у нас (скажем если другие не смогли купить товар у нас (дефектура и прочее ) ( но это лирика, описание мук вычисления правдивой информации о продажах из этого нескончаемого потока)) данные которые будут загружаться в базу де-факто от этого уже почищены.
п.4 к сожалению тут не применим, по скольку ACTUAL_BALANCE это срез остатков у дистрибьютора на начало след месяца ( т.к. если мы снимаем продажи за август, таблица ACTUAL_BALANCE предоставляет данные по остаткам на 1 сентября), и как я уже описывал выше возможно что дистр закупил наш товар у кого-то еще ( что нормальная практика), по этой причине данные по остаткам нам так же предоставляет дистрибьютор, и они в 95% случаев не бьются с расчетными приход-расход.
п.5-8 мы отгружаем (первичка) на основной склад дистрибьютора (т.е. в первичке один дистрибьютор имеет один филиал (brunch)), а сам дистрибьютор уже разбрасывает товар по своим филиалам с учетом потребностей (эти данные по остаткам и продажам мы уже получаем от дистрибьютора)
п.6 на самом деле ACTUAL_BALANCE это всего лишь вспомогательные данные, для расчета созданного товарного запаса у дистрибьютора, они должны быть и мы их получам на ежемесячной основе
нашим основным аккумулятором является таблица SALES на основании которой построена вся отчетность, это конечные продажи=вторичные продажи, то что уходит уже в розницу, т.е. нам с вами.
и уже как ,я считаю, к этой таблице нужно привязывать PERVICHKA по дистрибьютору/ товару,
Коллеги ,оживляя тему прошу помочь из данного условия сделать запрос на удаление
[vba]
Код
SELECT First(CUSTOMER.client_name) AS [client_name поле], First(CUSTOMER.physical_address) AS [physical_address поле], First(CUSTOMER.legal_address) AS [legal_address поле], First(CUSTOMER.city) AS [city поле], Count(CUSTOMER.client_name) AS Повторы FROM CUSTOMER GROUP BY CUSTOMER.client_name, CUSTOMER.physical_address, CUSTOMER.legal_address, CUSTOMER.city HAVING (((Count(CUSTOMER.client_name))>1) AND ((Count(CUSTOMER.city))>1));
[/vba] это запрос на поиск задваоений в названии клиентов, как оказывается, они у меня есть.
Коллеги ,оживляя тему прошу помочь из данного условия сделать запрос на удаление
[vba]
Код
SELECT First(CUSTOMER.client_name) AS [client_name поле], First(CUSTOMER.physical_address) AS [physical_address поле], First(CUSTOMER.legal_address) AS [legal_address поле], First(CUSTOMER.city) AS [city поле], Count(CUSTOMER.client_name) AS Повторы FROM CUSTOMER GROUP BY CUSTOMER.client_name, CUSTOMER.physical_address, CUSTOMER.legal_address, CUSTOMER.city HAVING (((Count(CUSTOMER.client_name))>1) AND ((Count(CUSTOMER.city))>1));
[/vba] это запрос на поиск задваоений в названии клиентов, как оказывается, они у меня есть.qpp
bigqpp скайп
Сообщение отредактировал qpp - Среда, 07.11.2012, 12:34
По ходу у меня возник вопрос, хочу услышать комментарии.
В таблице CUSTOMER, у меня присутствует список клиентов с их адресом и прочей информацией ( эти данные идут из отчетов контрагентов, и нормализировать их я , на данном этапе не смогу , в идеале конечно же хотелось отдельно список адресов, городов, привязанных к клиенту - мне это сейчас не доступно )
Вопрос заключается в следующем:
в будущем, понадобиться "схлопнуть" этот список, т.е. связать дубли между собой, как мне поступить. Т.к. сейчас я присваиваю каждому клиенту(читаем записи клиент-адрес) уникальный ID_customer.
Как поступить правильно ? у меня есть пара вариантов решения (возможно, костыли ), но сперва хотелось бы услышать мнение опытных пользователей.
коллеги, приветствую.
Хотелось бы продолжить данную тему
По ходу у меня возник вопрос, хочу услышать комментарии.
В таблице CUSTOMER, у меня присутствует список клиентов с их адресом и прочей информацией ( эти данные идут из отчетов контрагентов, и нормализировать их я , на данном этапе не смогу , в идеале конечно же хотелось отдельно список адресов, городов, привязанных к клиенту - мне это сейчас не доступно )
Вопрос заключается в следующем:
в будущем, понадобиться "схлопнуть" этот список, т.е. связать дубли между собой, как мне поступить. Т.к. сейчас я присваиваю каждому клиенту(читаем записи клиент-адрес) уникальный ID_customer.
Как поступить правильно ? у меня есть пара вариантов решения (возможно, костыли ), но сперва хотелось бы услышать мнение опытных пользователей.qpp
Вход
Регистрация
Напомнить пароль
Автосумма
Часто используемые
ВПР
ЕСЛИ
СУММЕСЛИ
Финансовые
Логические
Текстовые
Даты и времени 
Ссылки и массивы 
Математические
Другие функции
Проверка свойств и значений
Баз данных
Математические
Обработки массивов
Обработки строк
Преобразования типов данных 
Загрузки данных
Работы с файлами
Обработки системных параметров
Обработки цвета
Работы с датами и временем
Преобразования в системы счисления
Финансовые
(скажем если другие не смогли купить товар у нас (дефектура и прочее ) ( но это лирика, описание мук вычисления правдивой информации о продажах из этого нескончаемого потока)) данные которые будут загружаться в базу де-факто от этого уже почищены. 
