Vos commentaires

Если статью бюджета как-то ещё можно согласовать, то ответственного - точно нельзя, т.к. продавать может один специалист, а вести проект - совсем другой...


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


Пока придерживаемся мнения, что бы по расходам отдать приоритет данным Проекта, а не Продажи и по поступлениям - наоборот приоритет у Продаж оставить.

В настоящее время создание Проекта из Продажи уже реализовано, но при этом не происходит ни копирования ни переноса финансовых планов.


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


Но(!) здесь действительно необходимо продумать каким образом обходить нюансы:

  • приоритет связей при построении отчетов (сейчас в отчетах выводится ссылка на статью бюджета, ответственного менеджера и другие характеристики, которые в Проекте и Продаже могут не совпадать) 
  • к какому из ссылающихся объектов привязывать фактические поступления, что бы неоплаченный план корректно пересчитывался.


Если удастся придумать логику решения этой задачи, то в купе с возможностью создавать Проект по Продаже можно будет считать сформулированную задачу реализованной.

Текущая (уже реализованная) логика следующая:

  1. Есть текстовый файл в формате 1С (экспорт из банк-клиента)
  2. Этот файл распарсивается нашей хранимой процедурой и структурированно данные выдаются во временную таблицу. 
  3. Собственно в этой временной таблице в итоге хранятся все столбцы с данными, которые были определены для парсинга.
  4. ХП может вызываться, с параметрами "путь файла" и "имя врем.таблицы". Путь файл - это то, из чего брать данные, а имя временно таблицы - что бы потом с ней работать.
  5. После выполнения процедура ничего не делает с созданной временной таблицей - это уже задача скрипта, который её вызвал.

Таким образом сейчас стоит задача разработки интерфейса для этого "движка", который должен позволять:

  1. Выбирать файл с диска
  2. Запускать парсинг и сохранять данные в некотором классе, что бы потом с ними можно было работать
  3. Отображать предварительные результаты импорта пользователю в некотором режиме, где он будет уже производить акцепт и разноску импортируемых записей
  4. Кнопка сохранить, которая из предварительного импорта переносит данные уже в систему с заданной разноской. Соответственно всё, что было в предварительном импорте удаляется и готово для следующих загрузок.

Это всё общее... но есть ряд нюансов:

  • На что может быть похож такой интерфейс?
  • Как должна себя система вести, если в одну и ту же дату от одного и того же плательщика на одну и ту же сумму есть два платежа? И вообще по какому принципу отлавливать дубли?
  • Нужно ли хранить дату последнего импорта, что бы повторно данные не загружать?
  • Предлагать ли создавать обязательства оп неразнесённым расходам?
  • ...ну и что-то ещё наверняка ещё не учтено

Здравствуйте

Судя по всему, у вас стоит Microsoft SQL Server 2005, а вы хотите в него распаковать конфигурацию  сделанную для Microsoft SQL Server 2008. Если это так, то для того чтобы обновить  Microsoft SQL Server вам необходимо сначала удалить его через Панель управления (и удалить папку Microsoft SQL Server который находиться на диске С (c:\Program files\)),  а потом поставить новую версию Microsoft SQL Server 2008.

После выхода Клиент-Коммуникатор 7.0, который работает только на MS SQL  Server 2008, все актуальные базы наших конфигураций адаптированы под MS SQL Server 2008.

Речь идёт о том, что бы не только по плановым поступлениям можно было факт регистрировать, но и просто "Встал на счет, нажал кнопку и ввел сумму"... и не только на счёт, а на все объекты учета... 
Здравствуйте!

Логика интерфейса построена таким образом, что постоянного взаимодействия с базой данных на сервере не производится (иначе сетевой трафик был бы просто огромным и не давал работать пользователям в других приложениях). Это означает, что отображенный список в рамках одного режима самопроизвольно не изменяется если с ним не производится каких-либо действий (группировок, фильтрации, редактирования карточки и пр.). По этой причине после внесения изменения в карточку Производства на режиме "Управление производством" - в списке Заказов режима "Управление заказами" автоматически ничего не меняется - менеджер должен обновить режим (нажатием F5). Для критических случаев, как с тем же производством автоматически создаются Задачи с напоминаниями и тогда даже при закрытом режиме "Управление заказами" уведомление сотруднику будет доставлено в виде напоминания о задаче.

В дизайнере интерфейсов "КлиК" есть возможность настроить для режима автообновление через указанный интервал (например каждый 5 или 10 минут). Для этого необходимо войти в Дизайнер интерфейсов под логином sa. Открыть необходимый режим. На верхней панели нажать "Свойства режима" и в поле Интервал автообновления данных режима ввести необходимое значение. После чего сохранить режим. С одной стороны это может быть удобно, а с другой - автоматическое обновление может запускаться "не вовремя" и зачастую мешать работе пользователя. Поэтому к данному вопросу стоит относиться осторожно.

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