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

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

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

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

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

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

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

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

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

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.