Собственно проблема:
Приходят ежемесячные отчеты дистрибьютеров об их продажах как сырые выгрузки из 1С
Спроектировать реляционную структуру БД для меня не порблема, проблема в другом - планируется повысить частоту предоставления отчетов о продажах с ежемесячного до еженедельного предоставления (с целью повышения оперативности принятия решений и прочее бла бла бла)
Т.е. неделя1, неделя2......неделя59 ит.д.
Детализации по дням нет.
Структура отчетов в общих чертах: кто у них брал(полей 10), что у них бралось(2 поля),канал сбыта(поля2), когда бралось(неделя) и сколько (кг & руб)
Как собрать недели в месяцы?
Сейчас родилась мысль - дробить каждую атомарную запись переходящей недели как остаток на следующий месяц запрашивая у дистрибьютера контрольную выгрузку каждый месяц.
Только как это на практике провернуть? Да и решение это видится кривоватым.
У кого  нибудь вообще есть опыт в решении подобных задач?

Да в общем никак...


Обязуйте их формировать локально эти отчёты ежедневно. А пересылать в центр - по установленному графику (еженедельно - так еженедельно, но 7 ежедневных отчётов). И делов... 

Не...
Собирают, работал в компании, где такое делали (к сожалению утрачен контакт с  этими людьми)


Проблема избыточности в 2-х аспектах: 1)Конечным пользователям данные глубже недели не требуются
2) Месячный отчет 1 дистра - это порядка 50 тысяч записей(их клиентские базы в разрезе нашей номенклатуры), дистров около 200, если высылать еженедельно в дневной детализации - это лишние объемы записей( в 30 раз больше) - которые все равно будут агрегироваться минимум в недели - максимум в месяцы.
С моей стороны было предложение сделать рассылку подекадной (идеальный вариант)- отклонили
Так жизнеспособная у меня идея по поводу дробления переходящих недель или нет?

Это сообщение отредактировал(а) FINANSIST - 16.11.2009, 14:09

FINANSIST, а месячная отчетность остается?
Есть ли возможность влиять на т.е. можно ли им написать свой алгоритм?
Если да, то в их алгоритм добавить 3 поля "год", "номер месяца", "номер недели"

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

Хорошо, промежуточный вариант. Недельные отчёты, но при переходе через границу месяца - делим его на два. Т.е. в среднем раз в 4 недели пересылается 2 отчёта, а не один.

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


Кому то да (есть толковые 1С ники в штате) но в большинстве своем в регионах сидят тетки с "бодуна" (Sorry за оффтоп) которые при формировании месяцев с выбором дат ошибаются, тем более дробить переходящую неделю на 2 выгрузки им интеллекта не хватит - это мне так объяснили.



Да ничего страшного, сам постоянно так работаю- банальный OLAP...
Вполне нормальное желание видеть условно на 14 или на 21 число промежуточные результаты для понимания - с чем выйдем по итогу месяца, ну и помесячная история продаж до кучи



Сам предлагал на совещаниях такой вариант
Опять упираемся в теток - тупой аргумент, сам знаю, но задача поставленна такая: Пн-Вскр + Месячная выгрузка
------------------------------------------------------------------------------------------------
Такое предложение: 
Выносить переходящие недели в отдельную сущность
определить уникальный идентификатор атомарной записи переходящей недели как сочетание аналитик =  SKU + ТорговаяТочка
Далее по идентификатору находим контрольную месячную сумму данной атомарной записи и вычитаем целые недели из месяца данной записи
Инсертим остаток от месяца атомарной записи в общую таблицу с заполнением измерений "номер месяца" и "номер недели"
Находим по идентификатору остаток от переходящей недели из отдельной сущности и инсертим в общую таблицу остаток переходящей недели с месяцем N+1.
Чего то как то сложно получается....



Это сообщение отредактировал(а) FINANSIST - 17.11.2009, 10:57

Я только не понимаю, почему ПРОГРАММНО нельзя сделать деление на нужные тебе куски? чтобы не зависеть от тёток? им остаётся нажать кнопку и ждать мессбокса с сообщением об окончании выгрузки и кнопкой "ОК" - такое даже обезьяна сделает.

а нельзя один скрипт выгрузки для всех написать чтобы он автоматом работал?
В конце концов можно на Delphi своять программу для забора данных из "1С", повесить ее на шедулер и вперед.

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



Т.е. некий рукотворный мастер экспорта, который можно централизованно разослать по местам, я правильно понял?

Вам нужно идти по пути создания комплекса сбора информации.
То есть отрабатываете протокол передачи, для наиболее используемых и стандартных средств (скажем 1С версий 7.7, 8.0 и 8.1) создаёте средство экспорта в выбранный формат (видимо, XML будет лучшим вариантом), а у себя соответственно средство импорта. Созданные документацию (полная спецификация формата выгрузки) и экспортёр утверждаете и распространяете по филиалам.
Те, кто пользуется средствами, к которым вы создали экспортёр, используют его. Те, кто работает на ином ПО (а при желании и те, кто работает на стандартном, почему нет?) - решают задачу приведения экспортных данных к заданному формату самостоятельно (либо переходят на ПО, к которому есть средства выгрузки).

А ссылки на глупых тёток - это, извини, детский лепет. Таких надо просто увольнять и набирать грамотных.

именно так.

Добавлено @ 12:52

И я про то же, только объяснить у меня в компании всем это сложно


Буду двигаться по этому пути, 
Akina, спасибо

Это сообщение отредактировал(а) FINANSIST - 17.11.2009, 12:52