Всем добрый день! Меня зовут Анна, я тут впервые. Нам очень нужна помощь специалиста.
Задача: 2 розничных магазина. в конце смены продавец заполняет единственный отчет (нужно сделать форму) данные с отчета должны разносится по другим таблицам в этой же книге.
Отчет должен каждый вечер уходить на почту руководителю. А также часть данных должна уходить в таблицы на GOOGLE диске. Если это вообще возможно!
Постарались сделать табличку с техзаданием. возможно мы перемудрили :)) Если будут конструктивные предложения по оптимизации нашего плана - Будем очень признательны!
Если Вы можете помочь нам в реализации идеальной картины (пусть даже частично!) давайте договоримся по стоимости и будем работать!
Всем спасибо!
п.с. писать предложения можно тут.
Всем добрый день! Меня зовут Анна, я тут впервые. Нам очень нужна помощь специалиста.
Задача: 2 розничных магазина. в конце смены продавец заполняет единственный отчет (нужно сделать форму) данные с отчета должны разносится по другим таблицам в этой же книге.
Отчет должен каждый вечер уходить на почту руководителю. А также часть данных должна уходить в таблицы на GOOGLE диске. Если это вообще возможно!
Постарались сделать табличку с техзаданием. возможно мы перемудрили :)) Если будут конструктивные предложения по оптимизации нашего плана - Будем очень признательны!
Если Вы можете помочь нам в реализации идеальной картины (пусть даже частично!) давайте договоримся по стоимости и будем работать!
Там задача не просто "глобальная", там бы по идее надо заново строить модель хранения данных. Например, отказаться от неких "месячных таблиц" и переходить к стандартизованному движению-учёту: первички - ежедневные отчеты, их и заполняют продавцы, обмен - накопительная база данных первичек и таблицы с устанавливаемыми "сверху" параметрами с "планами на периоды" и т.д., ну и "отчетность" с выборками по необходимым периодам и формированием данных в нужном виде. Учитывая, что желательны ещё всякие внешние обмены (1С, почта, гуглодокументы и прочее) - то и реализацию вообще надо изначально делать на чистых макросах...
Там задача не просто "глобальная", там бы по идее надо заново строить модель хранения данных. Например, отказаться от неких "месячных таблиц" и переходить к стандартизованному движению-учёту: первички - ежедневные отчеты, их и заполняют продавцы, обмен - накопительная база данных первичек и таблицы с устанавливаемыми "сверху" параметрами с "планами на периоды" и т.д., ну и "отчетность" с выборками по необходимым периодам и формированием данных в нужном виде. Учитывая, что желательны ещё всякие внешние обмены (1С, почта, гуглодокументы и прочее) - то и реализацию вообще надо изначально делать на чистых макросах...AndreTM
Skype: andre.tm.007 Donate: Qiwi: 9517375010
Сообщение отредактировал AndreTM - Пятница, 28.04.2017, 08:51
AndreTM, спасибо большое за мнение и за то, что вникли в суть проблемы.!
Ваше предложение, конечно же очень логично. Сейчас "месячная таблица" как раз является и первичным документом и накопителем и отчетной формой. так как отчетный период у нас месяц. + есть консолидированные годовые отчеты. За 4 года эта месячная таблица претерпела разные изменения и теперь вышла на оптимальное содержание по показателям: все нужно и ничего лишнего.
Я думала над изменением всей структуры в том же ключе, как предложили Вы. Вот какая была логика моих рассуждений: первый документ ввода информации - отчет за день создавать по-любому. Если теперь убирать эти месячные таблицы и создавать для каждого блока параметров промежуточные таблицы по накоплению информации с первичных отчетов и потом еще новые отчетные формы (которые в целом не будут сильно отличаться от нашей месячной таблицы), то это в любом случае дополнительная работа, которая будет стоить денег. Вопрос в том насколько сложно создать автосоздание нового листа (когда месяц закончился - создается новый лист) или привязывать данные с первичных отчетов к 12 разным листам. (если сделать 12 листов заранее на год). Этого я не знаю. Насколько текущая задача "глобальнее" создания новой системы сбора данных? То есть, если специалист говорит, например, что проще создать промежуточные таблицы для сбора и потом уже отчеты - я не возражаю. Зачем же усложнять.
Если возникнет единая накопительная база - это очень хорошо.! Я так тоже люблю, когда можно вертеть информацией, как хочешь. Есть НО: 1. Отчетные формы нужны за месяц. И они должны делаться автоматически, без участия оператора. то есть по окончании месяца отчет готов и сохранился в новый лист/книгу. Это возможно? 2. Наша "месячная таблица" нужна продавцам каждый день с заполненными данными на утро (за предыдущие дни месяца). По ней они видят сколько им осталось сделать до Плана, видят сумму премий будущих и уже заработанных, видя все свои результаты работы и это их реально стимулирует "поднажать". То есть если данные с первичных отчетов будут попадать в накопительную базу, то оттуда они должны каждый день обновляться в нашу месячную таблицу. Как реализовать это обновление? продавцу придется утром "кнопку нажимать"? Это вполне выход, если не очень сложная процедура. (Женщинам 45 лет, мы их с трудом к компьютерам приучили.)
Другие таблицы, которые указаны в моем ТЗ являются сразу накопителями. отчет по этой информации не нужен. Там можно обойтись фильтрами. Буду признательна за ответы на мои вопросы про возможности программирования.
Спасибо!
AndreTM, спасибо большое за мнение и за то, что вникли в суть проблемы.!
Ваше предложение, конечно же очень логично. Сейчас "месячная таблица" как раз является и первичным документом и накопителем и отчетной формой. так как отчетный период у нас месяц. + есть консолидированные годовые отчеты. За 4 года эта месячная таблица претерпела разные изменения и теперь вышла на оптимальное содержание по показателям: все нужно и ничего лишнего.
Я думала над изменением всей структуры в том же ключе, как предложили Вы. Вот какая была логика моих рассуждений: первый документ ввода информации - отчет за день создавать по-любому. Если теперь убирать эти месячные таблицы и создавать для каждого блока параметров промежуточные таблицы по накоплению информации с первичных отчетов и потом еще новые отчетные формы (которые в целом не будут сильно отличаться от нашей месячной таблицы), то это в любом случае дополнительная работа, которая будет стоить денег. Вопрос в том насколько сложно создать автосоздание нового листа (когда месяц закончился - создается новый лист) или привязывать данные с первичных отчетов к 12 разным листам. (если сделать 12 листов заранее на год). Этого я не знаю. Насколько текущая задача "глобальнее" создания новой системы сбора данных? То есть, если специалист говорит, например, что проще создать промежуточные таблицы для сбора и потом уже отчеты - я не возражаю. Зачем же усложнять.
Если возникнет единая накопительная база - это очень хорошо.! Я так тоже люблю, когда можно вертеть информацией, как хочешь. Есть НО: 1. Отчетные формы нужны за месяц. И они должны делаться автоматически, без участия оператора. то есть по окончании месяца отчет готов и сохранился в новый лист/книгу. Это возможно? 2. Наша "месячная таблица" нужна продавцам каждый день с заполненными данными на утро (за предыдущие дни месяца). По ней они видят сколько им осталось сделать до Плана, видят сумму премий будущих и уже заработанных, видя все свои результаты работы и это их реально стимулирует "поднажать". То есть если данные с первичных отчетов будут попадать в накопительную базу, то оттуда они должны каждый день обновляться в нашу месячную таблицу. Как реализовать это обновление? продавцу придется утром "кнопку нажимать"? Это вполне выход, если не очень сложная процедура. (Женщинам 45 лет, мы их с трудом к компьютерам приучили.)
Другие таблицы, которые указаны в моем ТЗ являются сразу накопителями. отчет по этой информации не нужен. Там можно обойтись фильтрами. Буду признательна за ответы на мои вопросы про возможности программирования.
Дополню: В том-то и дело, что не должно быть никаких "дополнительных накопителей". То есть ежедневные отчеты (первичные) - это исходная информация, ОДНА накопительная база данных первички (плюс справочники) - это как раз единый накопитель, а вот всякие "месячные таблицы полностью", "месячные таблицы для продавцов с текущими данными", "квартальные/годовые отчеты", "аналитика по магазинам/продавцам" и т.д., любые отчеты по нужным формам за любые периоды - это всё "выходная информация", она всегда строится на основе данных из базы, её можно/нужно получать в любой момент, за любой период, с нужной периодичностью, и выдавать куда нужно, сохранять, если надо, рассылать, если надо... но это будет именно "отчетная" информация. Сделать нужное количество шаблонов-форм и заполнять/рассылать их, хоть "по кнопке", хоть "по автоматике". Суть как раз в том, что выходную/отчетную форму заполнять руками никто не должен, она должна _строиться_ на основании исходных имеющихся данных. А исходные данные (возвращаемся) - это ежедневная первичка плюс справочники. В общем, как минимум надо разделить "исходную информацию (ввод данных)", "накопитель" и "отчетные формы". Иначе так и будет продолжаться то самое топтание на месте, к которому вы пришли из-за неверно изначально спроектированной модели хранения.
Ну и ещё дополню, с учетом поста Сергея: Решение с перестроением "модели" вообще надо начинать с изучения того, как у вас сейчас организован доступ пользователей к заполнению исходных данных и получению отчетов. Ведь наверняка у вас распределенные места работы, и нужно понимать, как "продавцы/ответственные" будут вносить данные (и как эти данные окажутся в "базе"), какие кому нужны отчеты и кто как их будет получать, кто будет отвечать за контроль данных в самой "базе", наконец, какие на будущее планируются дополнительные возможности, чтобы сразу можно было предусмотреть расширение/масштабирование и т.д.
Дополню: В том-то и дело, что не должно быть никаких "дополнительных накопителей". То есть ежедневные отчеты (первичные) - это исходная информация, ОДНА накопительная база данных первички (плюс справочники) - это как раз единый накопитель, а вот всякие "месячные таблицы полностью", "месячные таблицы для продавцов с текущими данными", "квартальные/годовые отчеты", "аналитика по магазинам/продавцам" и т.д., любые отчеты по нужным формам за любые периоды - это всё "выходная информация", она всегда строится на основе данных из базы, её можно/нужно получать в любой момент, за любой период, с нужной периодичностью, и выдавать куда нужно, сохранять, если надо, рассылать, если надо... но это будет именно "отчетная" информация. Сделать нужное количество шаблонов-форм и заполнять/рассылать их, хоть "по кнопке", хоть "по автоматике". Суть как раз в том, что выходную/отчетную форму заполнять руками никто не должен, она должна _строиться_ на основании исходных имеющихся данных. А исходные данные (возвращаемся) - это ежедневная первичка плюс справочники. В общем, как минимум надо разделить "исходную информацию (ввод данных)", "накопитель" и "отчетные формы". Иначе так и будет продолжаться то самое топтание на месте, к которому вы пришли из-за неверно изначально спроектированной модели хранения.
Ну и ещё дополню, с учетом поста Сергея: Решение с перестроением "модели" вообще надо начинать с изучения того, как у вас сейчас организован доступ пользователей к заполнению исходных данных и получению отчетов. Ведь наверняка у вас распределенные места работы, и нужно понимать, как "продавцы/ответственные" будут вносить данные (и как эти данные окажутся в "базе"), какие кому нужны отчеты и кто как их будет получать, кто будет отвечать за контроль данных в самой "базе", наконец, какие на будущее планируются дополнительные возможности, чтобы сразу можно было предусмотреть расширение/масштабирование и т.д.AndreTM
Skype: andre.tm.007 Donate: Qiwi: 9517375010
Сообщение отредактировал AndreTM - Суббота, 29.04.2017, 11:34
логичнее не копить отчеты, а вести базу, на отдельном листе, где все данные за прожитый день будут накапливаться, а лист отчета за нужный период создаваться в новом документе из заготовленного шаблона по запросам из данных внесенных в базу. в отчете не будет формул или фильтров только данные уже рассчитанные и отфильтрованные кодом.
я думаю что нужно делать как то так: создать форму ввода данных за прошедший день для продавца (лист или программная форма, это по желанию) создать форму управления базой для Директора создать форму отчета создать структуру хранения данных на листе база при открытии файла, в зависимости от уровня доступа (по паролю или учетной записи пользователя) открывать нужные формы листы.
по правильно структурированным данным можно составить любой отчет за месяц, год, неделю, по фамилии продавца и т.д.
по возможностям: 1. отчеты возможно формировать автоматически, при открытии файла и достижении определенной даты( например 25е число, открыли файл 25, 26,27, сначала проверка создавался отчет или нет, если нет то создать и в нужную папку сложить)
2. для продавца можно сделать интуитивно понятный интерфейс формы, который при открытии будет подгружать нужные данные из базы и отображать их
Доброго дня.
логичнее не копить отчеты, а вести базу, на отдельном листе, где все данные за прожитый день будут накапливаться, а лист отчета за нужный период создаваться в новом документе из заготовленного шаблона по запросам из данных внесенных в базу. в отчете не будет формул или фильтров только данные уже рассчитанные и отфильтрованные кодом.
я думаю что нужно делать как то так: создать форму ввода данных за прошедший день для продавца (лист или программная форма, это по желанию) создать форму управления базой для Директора создать форму отчета создать структуру хранения данных на листе база при открытии файла, в зависимости от уровня доступа (по паролю или учетной записи пользователя) открывать нужные формы листы.
по правильно структурированным данным можно составить любой отчет за месяц, год, неделю, по фамилии продавца и т.д.
по возможностям: 1. отчеты возможно формировать автоматически, при открытии файла и достижении определенной даты( например 25е число, открыли файл 25, 26,27, сначала проверка создавался отчет или нет, если нет то создать и в нужную папку сложить)
2. для продавца можно сделать интуитивно понятный интерфейс формы, который при открытии будет подгружать нужные данные из базы и отображать ихK-SerJC
Всем добрый день! Спасибо еще раз за участие в решении проблемы.
Я, как человек с техническим складом ума и финансист по призванию, полностью согласна с Вашими мыслями. Считаю, что это самый верный путь. Для меня все очень усложняется незнанием возможностей программирования экселя. Так как писать прямо полноценную программу задачи не было. (а тут речь уже идет именно про нее). Почему нет? ...
Еще 5 назад когда магазины были только открыты и мы выстраивали систему учета, думала про создание "под нас" базы в acsess. Но было решено отказаться от этой идеи, так как моя любовь к учету и аналитике показалась моим партнером нездоровой. (аргументы : Многие не сетевые магазины даже 1С не ставят, на бумаге считают или обходятся возможностями 1С. А учетом можно заниматься до бесконечности, воровство все равно не искоренить, считать показатели ради показателей - глупость. давайте лучше сосредоточимся на более важных вещах). было решено остановиться на базовых показателях, за период взять месяц и год по ключевым показателям.
В целом, получившаяся за время работы итоговая система законченная. Считаю ее не сложной, так как процессы элементарны. Все что требуется - это сравнение между собой различных показателей, и расчет составных частей ЗП (оклад, проценты, доплаты за нормативы, премии за план). Позже появилась потребность мотивации продавцов и создание для них таблички, в которой они будут видеть, сколько им осталось до плана. (Это работает!)
К чему я веду (простите за отвлечение):
Даже при несложной системе показателей, я не возражаю сделать накопитель и скорректировать отчеты. Первичная форма ввода инфо нужна по-любому, за ней и пришла. Есть один момент, который мне не понятен при системе с "накоплением": Это потребность отсекать информацию по месяцам. Например, будет создан накопитель. С множеством столбцов (параметров) и связей между ними. Ну, прямо супер все сделаем, включим туда все, что нужно и не нужно (пусть и это заодно посчитает, вдруг потом захотим и такой отчет :)). Накопитель будет единый за весь период. Строки "даты" собираются после добавления нового отчета за день. Но! Мне же нужно, чтобы с мая мы начали новую жизнь и 31.05.2017 месячный период закрыли и подвели итоги. То есть на май будет установлен новый план (форма управления базой для Директора), и каждый следующий день в мае выручка будет приближаться к плану, зарплата продавцов будет расти и ВСЕ завязки идут только на выручку и план мая. Прошлые периоды не в счет. Если в итоговом отчете не будет никаких формул, значит в накопителе будет столбец "остаток по месячному плану на утро текущего дня". И если в накопителе собираются данные за 365 дней, то придется как-то группировать эти данные по месяцам в самом накопителе? Или можно обойтись формулами и алгоритмами, чтобы он построчно собирал всю инфо в нужный столбец ? Как-то так: Если текущий день = май, то план на май минус сумма всех выручек за предыдущие дни мая, так получается? Я так понимаю что в накопителях столбцы должны содержать одну и ту же формулу, и не должно возникать промежуточных строк с другими формулами? В общем, может ли эксель определить "если май" по дате?
Или вот другой момент, если в отчетах не будет формул, то в каком месте будет написала формула по расчету премии? если в мае общая выручка >= плану, то продавец получает фиксированную премию, например, 1000 рублей. Где-то должен произойти расчет и начисление этой суммы, если не в отчете о ЗП. Значит в накопителе? или этот расчет будет где-то "между" накопителем и отчетом? в коде? (ой, не люблю когда не видно..) А если в накопителе, то я не понимаю как его привязать через столбец к строкам, где только даты и нет промежуточной строки за месяц.
В этом и проблема, от незнания возможностей, такое и ТЗ. (( Я могу подумать и написать "как хочу в идеале", и не пытаться вникнуть в процесс создания. Возможно так будет проще. Только я за простоту. Не хочу, чтобы возникали слишком сложные и неоправданные алгоритмы. И еще я бы хотела все таки видеть расчеты каждого параметра, чтобы "за кадром было минимум расчетов", только связи.
Спасибо!
Всем добрый день! Спасибо еще раз за участие в решении проблемы.
Я, как человек с техническим складом ума и финансист по призванию, полностью согласна с Вашими мыслями. Считаю, что это самый верный путь. Для меня все очень усложняется незнанием возможностей программирования экселя. Так как писать прямо полноценную программу задачи не было. (а тут речь уже идет именно про нее). Почему нет? ...
Еще 5 назад когда магазины были только открыты и мы выстраивали систему учета, думала про создание "под нас" базы в acsess. Но было решено отказаться от этой идеи, так как моя любовь к учету и аналитике показалась моим партнером нездоровой. (аргументы : Многие не сетевые магазины даже 1С не ставят, на бумаге считают или обходятся возможностями 1С. А учетом можно заниматься до бесконечности, воровство все равно не искоренить, считать показатели ради показателей - глупость. давайте лучше сосредоточимся на более важных вещах). было решено остановиться на базовых показателях, за период взять месяц и год по ключевым показателям.
В целом, получившаяся за время работы итоговая система законченная. Считаю ее не сложной, так как процессы элементарны. Все что требуется - это сравнение между собой различных показателей, и расчет составных частей ЗП (оклад, проценты, доплаты за нормативы, премии за план). Позже появилась потребность мотивации продавцов и создание для них таблички, в которой они будут видеть, сколько им осталось до плана. (Это работает!)
К чему я веду (простите за отвлечение):
Даже при несложной системе показателей, я не возражаю сделать накопитель и скорректировать отчеты. Первичная форма ввода инфо нужна по-любому, за ней и пришла. Есть один момент, который мне не понятен при системе с "накоплением": Это потребность отсекать информацию по месяцам. Например, будет создан накопитель. С множеством столбцов (параметров) и связей между ними. Ну, прямо супер все сделаем, включим туда все, что нужно и не нужно (пусть и это заодно посчитает, вдруг потом захотим и такой отчет :)). Накопитель будет единый за весь период. Строки "даты" собираются после добавления нового отчета за день. Но! Мне же нужно, чтобы с мая мы начали новую жизнь и 31.05.2017 месячный период закрыли и подвели итоги. То есть на май будет установлен новый план (форма управления базой для Директора), и каждый следующий день в мае выручка будет приближаться к плану, зарплата продавцов будет расти и ВСЕ завязки идут только на выручку и план мая. Прошлые периоды не в счет. Если в итоговом отчете не будет никаких формул, значит в накопителе будет столбец "остаток по месячному плану на утро текущего дня". И если в накопителе собираются данные за 365 дней, то придется как-то группировать эти данные по месяцам в самом накопителе? Или можно обойтись формулами и алгоритмами, чтобы он построчно собирал всю инфо в нужный столбец ? Как-то так: Если текущий день = май, то план на май минус сумма всех выручек за предыдущие дни мая, так получается? Я так понимаю что в накопителях столбцы должны содержать одну и ту же формулу, и не должно возникать промежуточных строк с другими формулами? В общем, может ли эксель определить "если май" по дате?
Или вот другой момент, если в отчетах не будет формул, то в каком месте будет написала формула по расчету премии? если в мае общая выручка >= плану, то продавец получает фиксированную премию, например, 1000 рублей. Где-то должен произойти расчет и начисление этой суммы, если не в отчете о ЗП. Значит в накопителе? или этот расчет будет где-то "между" накопителем и отчетом? в коде? (ой, не люблю когда не видно..) А если в накопителе, то я не понимаю как его привязать через столбец к строкам, где только даты и нет промежуточной строки за месяц.
В этом и проблема, от незнания возможностей, такое и ТЗ. (( Я могу подумать и написать "как хочу в идеале", и не пытаться вникнуть в процесс создания. Возможно так будет проще. Только я за простоту. Не хочу, чтобы возникали слишком сложные и неоправданные алгоритмы. И еще я бы хотела все таки видеть расчеты каждого параметра, чтобы "за кадром было минимум расчетов", только связи.
На самом деле, вся суть перестроения модели как раз и сводится к тому, чтобы приблизить систему _хранения_ данных к СУБД, но только средствами Excel. То есть как раз не будет "множества столбцов-полей с кучей формул и связями", будет именно набор форм и таблиц (таблицы с данными в таком случае _вообще_ не редактируются "прямым доступом", и в большинстве случаев - нормализуются). Нам ведь просто нужен техпроцесс "с какой-то периодичностью вводим исходные данные->храним в нужном виде->получаем по мере надобности необходимые отчеты-своды-выборки" (дополнительно - некоторые виды выборок можем просто показывать, некоторые - рассылать, некоторые - сохранять уже как источники данных для других процессов/программ; можем параллельно заниматься различными сверками/бэкапами/выгрузками).
Что именно использовать для описания бизнес-логики (формулы в ячейках шаблонов, формулы в коде, просто заранее разработанные реляционные модельки, да хоть динамическое формирование формул кодом...) - выбирается прямо в процессе разработки, исходя из эффективности (сложность реализации, быстродействие, объемы данных, переносимость), хоть всё сразу и везде.
А иметь таблицы-монстры, на 90% состоящие из формул, постоянно пересчитывающиеся (ну, не всегда, конечно, но тем не менее), дублирующие информацию, плохо масштабируемые - это не есть гут. Да и позволю напомнить про "любовь к учету и аналитике": нормальное хранилище в качестве источника данных - позволяет оперировать любыми стандартными средствами программы так же, как и специально отдельно запрограммированными заранее. Хоть сводные и срезы делайте свои, хоть любую аналитику по вашему разумению и возникающей потребности. Это же база данных, по сути...
На самом деле, вся суть перестроения модели как раз и сводится к тому, чтобы приблизить систему _хранения_ данных к СУБД, но только средствами Excel. То есть как раз не будет "множества столбцов-полей с кучей формул и связями", будет именно набор форм и таблиц (таблицы с данными в таком случае _вообще_ не редактируются "прямым доступом", и в большинстве случаев - нормализуются). Нам ведь просто нужен техпроцесс "с какой-то периодичностью вводим исходные данные->храним в нужном виде->получаем по мере надобности необходимые отчеты-своды-выборки" (дополнительно - некоторые виды выборок можем просто показывать, некоторые - рассылать, некоторые - сохранять уже как источники данных для других процессов/программ; можем параллельно заниматься различными сверками/бэкапами/выгрузками).
Что именно использовать для описания бизнес-логики (формулы в ячейках шаблонов, формулы в коде, просто заранее разработанные реляционные модельки, да хоть динамическое формирование формул кодом...) - выбирается прямо в процессе разработки, исходя из эффективности (сложность реализации, быстродействие, объемы данных, переносимость), хоть всё сразу и везде.
А иметь таблицы-монстры, на 90% состоящие из формул, постоянно пересчитывающиеся (ну, не всегда, конечно, но тем не менее), дублирующие информацию, плохо масштабируемые - это не есть гут. Да и позволю напомнить про "любовь к учету и аналитике": нормальное хранилище в качестве источника данных - позволяет оперировать любыми стандартными средствами программы так же, как и специально отдельно запрограммированными заранее. Хоть сводные и срезы делайте свои, хоть любую аналитику по вашему разумению и возникающей потребности. Это же база данных, по сути...AndreTM
Что именно использовать для описания бизнес-логики (формулы в ячейках шаблонов, формулы в коде, просто заранее разработанные реляционные модельки, да хоть динамическое формирование формул кодом...) - выбирается прямо в процессе разработки, исходя из эффективности (сложность реализации, быстродействие, объемы данных, переносимость), хоть всё сразу и везде.
вот это то что нужно обсудить !
Подумаю еще раз над отчетными формами. списки параметров для хранения имеются.
Что именно использовать для описания бизнес-логики (формулы в ячейках шаблонов, формулы в коде, просто заранее разработанные реляционные модельки, да хоть динамическое формирование формул кодом...) - выбирается прямо в процессе разработки, исходя из эффективности (сложность реализации, быстродействие, объемы данных, переносимость), хоть всё сразу и везде.
вот это то что нужно обсудить !
Подумаю еще раз над отчетными формами. списки параметров для хранения имеются.
Договорились с K_SerJC обсудить ТЗ 30.04.17perangirl
Вход
Регистрация
Напомнить пароль
Автосумма
Часто используемые
ВПР
ЕСЛИ
СУММЕСЛИ
Финансовые
Логические
Текстовые
Даты и времени 
Ссылки и массивы 
Математические
Другие функции
Проверка свойств и значений
Баз данных
Математические
Обработки массивов
Обработки строк
Преобразования типов данных 
Загрузки данных
Работы с файлами
Обработки системных параметров
Обработки цвета
Работы с датами и временем
Преобразования в системы счисления
Финансовые
Нам очень нужна помощь специалиста.
