Техническое задание

Разработка правил обмена КД 3.0 для объединения баз 1С:БГУ 2.0

Исходные данные

* Конфигурация: 1С:Бухгалтерия государственного учреждения 2.0.
* Релиз: 2.0.110.49.
* Платформа во всех базах одинаковая.
* Все информационные базы файловые.
* Количество исходных баз: 22.
* Каждая база содержит данные одной организации (школы).
* Требуется разработать правила обмена для последующего самостоятельного объединения баз в одну информационную базу.

Задача исполнителя

Разработать и настроить правила обмена в Конвертации данных 3.0 для корректного переноса данных между базами 1С:БГУ 2.0.

В рамках работы требуется:

* настроить правила выгрузки и загрузки объектов;
* обеспечить корректное сопоставление объектов между базами;
* исключить создание дублей справочников;
* сохранить корректные ссылки между объектами;
* обеспечить возможность дальнейшего проведения документов после загрузки.

Объекты для переноса

Необходимо предусмотреть перенос:

Справочники:

* организации;
* физические лица;
* сотрудники;
* контрагенты;
* договоры;
* подразделения;
* лицевые счета;
* банковские счета;
* основные средства;
* материальные запасы;
* номенклатура;
* прочие необходимые справочники.

Регистры и настройки:

* необходимые регистры сведений;
* настройки бухгалтерского учета;
* данные, необходимые для корректного формирования проводок;
* настройки типовых операций (при необходимости).

Документы:

* документы бухгалтерского учета;
* документы, необходимые для восстановления корректных движений.

Требования к результату

После загрузки данных по разработанным правилам:

* документы должны корректно открываться;
* документы должны проводиться без ошибок;
* при перепроведении должны формироваться корректные движения;
* бухгалтерские проводки должны формироваться с заполненными субконто;
* не должно происходить удаления движений регистра бухгалтерии при повторном проведении.

Важно

Ранее выполнялась попытка переноса через обработку «Выгрузка/Загрузка данных XML». После переноса возникли проблемы:

* ошибки проведения документов;
* отсутствие субконто в проводках;
* удаление проводок после перепроведения.

Необходимо разработать правила обмена с учетом особенностей конфигурации 1С:БГУ 2.0.

От исполнителя требуется

Указать:

* опыт разработки правил обмена КД 3.0;
* опыт работы с 1С:БГУ 2.0;
* опыт объединения нескольких информационных баз;
* сроки разработки;
* стоимость работ.

В состав результата передать:

* готовые правила обмена КД 3.0;
* описание порядка использования правил;
* рекомендации по выполнению выгрузки и загрузки.

ИИ не предлагать? )

Вам контора нужна, а не разработчик. Т.к. вы устанавливаете метод интеграции.

Пятнично -)

ИИ-ное ТЗ, да еще и КД 3.0. Но найдут кого-нибудь, что уж. )

(4) Так ошибки без сверки будут 1 в 1 как указаны в (0)

Без анализа источников результата не получится.
Что там в исходниках неизвестно.
1 базу из Камина делали, другую из 7.7, третью из какой-нибудь самоделки еще на foxpro

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

Короче из разрозненного бардака хотят организованный бардак и без ошибок, а бухов на местах уволить.
Да еще и на автомате отчетность должна заполняться )
Сказочники.

а потом у вас появится еще одна задача - как разделить одну базу на несколько чтобы отдать кому-то учет. вести разные компании в разных базах - это удобно.

(0) Позвольте узнать, а почему непременно КД3? EnterpriseData к бюджетным документам ну никаким боком. Это значит, собственную схему ваять придётся. Полгода-год я бы заложил на это.
ИМХО, КД2 тут гораздо более подходящий инструмент.

(5)  +100500

(4) Стопудово ИИ балует
Тот кто способен осилить это ТЗ выкатит такой ценник, что бюджетное учреждение не потянет в жизни. У них ведь как: все должно быть сделано за смешной оклад по штатному расписанию. Выделить деньги (да еще очень немалые) стороннему исполнителю - да скорее удавятся

(7) ИИшечка сказала КД 3, значит КД 3 и ниипет)

ИМХО, я бы тут другую схему попробовал бы.
1. Создал одну новую базу приемник.
2. Свернул все базы на начало года.
3. Выгрузил из всех баз универсальной выгрузкой/загрузкой данные.
4. В каждом файле выгрузки заменить уиды предопределенных уидами новой базы. Также план счетов и субконто заменить сразу.
5. Загрузку производить последовательно универсальной выгрузкой/загрузкой.
6. Выверка данных после загрузки каждой выгрузки.
7. Удаление дублей справочников в приемнике.

Согласен с (7) и с  (5) тут КД3 не нужны. Тут вообще никакая "волшебная" кнопочка не получится.

(0) Много раз объединял разные базы. Лет 10 назад была мода создавать ЦБО, объединяя разные бюджетные учреждения: школы, детсады, средне-специального образования, культуры, спорт, больницы и т.п.

Так вот, никогда КД 3.0 не пользовался. Тем более, кроме 1С:БГУ есть и другие системы вообще не от 1С.

Кто это требование по КД 3 ставил? Если он такой специалист по КД 3 то пускай сам и написал бы?

(10) Ты забыл главное: у индивидуальных справочников, т.е. те которые у каждого свои: физ.лица, контрагенты — надо поменять префиксы и желательно все элементы сложить в одну общую папку, чтобы когда это все придёт в общую базу не образовалась мешанина.

(12) Да, спасибо за дополнение с префиксами. Но я так задачу пока прикинул с точки зрения единых правил обмена.

(5)

И что? В любом случае проводки надо приводить к документу Ввод остатков.

А, например, по ОС, я бы тупо попросил карточки основных средств в экселе и насрать как они там у себя в БГУ ОС вели, карточка есть карточка и там достаточно сведений для заполнения ввода остатков.

(0) Несчастные. Понятно что бюджетное учреждение, и начальник самодур воодушевленный лозунгами и рекламой ИИ, но хоть бы представить попробовал как это делается.

До разработки тут еще идти, и идти.
1. Нормализация НСИ;
2. Анализ и нормализация методик учета в базах (не факт что во всех базах все одинаково учитывали);
3. Разработка правил преобразования данных (не программных, а как бы эту работу делал человек);

только после этого

4. Тестирование баз ТиИ;
5. Разработка правил конвертации.
6. Тестовый перенос;
7. Проверка аналитиками и конечными пользователями;
8. Боевой перенос в случае положительного заключения по 7 пункту. Если результат в 7 был отрицательным то все с начала.
9. Обучение пользователей работе с в единой базе;
10. Тестирование знаний пользователей.
11. После успешного 10 пункта, можно считать завершенным проект.

Из всего этого вы взяли только один 5 пункт. Ну... так себе.

Если готовы потратить 2-2,5 миллиона, готов организовать рассмотрение вопроса.

(13)

А чтобы не было проблем с УИДами то можно просто в КД2 поставить галочку: поиск по коду/наименованию. Но это для индивидуальных справочников.

С другой стороны есть не индивидуальные справочники, всякие классификаторы, предопределнные и т.п. так вот для них как гуиды должны совпадать, чтобы потом не вычищать несколько предопределенных элементов.

(14) Здесь речь не идёт о вводе остатков, насколько я понял. Надо 100500 баз "как есть" слить в одну.

(15) Люто, неистово плюсую!

Так они же перенос с историей хотят, чтобы в единой базе были все старые документы всех организаций, да еще и перепроводились также, как были проведены там ...

(0) Что значит: "выполнялась попытка переноса через обработку «Выгрузка/Загрузка данных XML»" - т.е. попытались перенести данные между абсолютно одинаковыми конфигурациями Файловая - Серверная?  Больше похоже, что без мыслей сделали и решили, что должно работать. Там дублей и перезаписей данных будет выше крыши из-за поиска по ИД.

Мощно, но для разового переноса КД2 выше крыши, только:
- Корректность результата кто будет анализировать?
- Кто сопоставит планы счетов (22 разных в один эталонный)?
- Вот это: "прочие необходимые справочники" - кто определяет какие справочники нужно забрать и что делать если в эталонной БД их нет?

(8) больше похоже на лабораторную работу, раз без мыслей использовали обработку. Возможно, хотят применить в работе, но силов не хватает понять с какого бока подойти и как реализовать

(15)

Не НСИ надо нормализировать, а формат передачи.

Я бы создал формат таблиц в экселе/csv.

Для типовых БГУ предоставил обработки выгрузки, а у тех у кого не работают пускай сами этот вопрос решают, хотят ручками забивают, хотят своих франей подряжают.

И выгружать только самые крупные: ТМЦ, ОС, контрагенты.

Если у одного БГУ есть торговля ценными бумагами, а у другого кредиты, у третьего аренда, у четвертого отдыхающие в санатории, у пятого столовая — всё это потому в индивидуальном порядке пущай забивают.

(0) Вариант "дёшево и сердито". Забываем про КД3. Про КД2 тоже. Собираем базу по технологии фреш. Каждая из 22 школ в отдельную область данных. Получаем физически одну базу в которой 22 никак не связанных организации, каждая со своими данными. Отчётность собираем через "Бюджетную отчётность". Получится раза в 4-5 дешевле, чем озвучено в (15).

(17)

Так надо бы задачу уточнить. Одно дело остатки и с нового периода по новому, другое дело подгружать новые документы, а третье это всю старую историю в одну базу.

А может они вообще хотят что-то вроде УХ, чтобы в одной базе все остатки видеть. Типа как Свод, но не только отчетность, а и проводки.

(14) Инвентарные номера ОС 100% совпадут
И префиксы организаций имеет смысл поменять
(18) Тут, можно по разному понимать "обеспечить проведение документов" - либо ввод остатков + новые проводятся корректно, либо история и надо разные алгоритмы для каждой организации (что есть глупость)

(23)

В (16) это описал.

(23) По идее они переносят данные из нескольких баз в одну, конфигурации одинаковые, поэтому и перенесенные данные должны перепроводиться также ...

Но, уже все сказали в (5) и в (15).

Чела найдут, он напишет грамотные правила конвертации, документы перенесутся с проводками, а потом бац, в одной из баз было расширение, влияющее на проводки ...

+
Разработчик требуется, а ценник - не озвучен

(20) Как раз НСИ надо привести к норме, Болт М16 должен называться одинаково во всех БД.
Статьи затрат, Статьи доходов и прочее аналогично
Ввести стандарт именования контрагентов: кратко Рога и копыта, полное ЗАО "Рога и копыта"

я бы начал с создания мастер базы, поэтапного переноса справочников с нормализацией, потом перенёс данные во ВводОстатков. Заодно, пользователи учатся работать в единой БД

(24) Ты не понял № 000001 у одной организации - Шкаф, у другой - здание, у третьей стол директора - что делать станем?

(25) Тут либо запрет изменения, либо тащить все алгоритмы в единую БД
Стоит это как 2 боинга + маленькая яхта

(25)

Я бы шире вопрос ставил: а есть на проекте грамотный методист, аналитик, консультант который ставит задачу.

Без этого никакие "грамотные правила конвертации" — работать не будут.

А учитывая требования:


Такого методиста — нет. Потому что никакой грамотный аналитик не будет доверять настройкам созданным "бабой Маней", он(она) должен ручками все учетные политики перелопатить.

Кроме того могут быть такие настройки которые в целом по базе действуют, и в разных базах могут быть по разному настроены.

А учитывая гибкость БГУ в плане алгоритмов проводок, так они еще могут быть дописаны.

Поэтому выше указанных требований просто не мог оставить грамотный методист.

Бюджетники не страдают такой фигней как размещать такое на форумах. Это просто бесплатный сбор для предварительной оценки. Может какой-то тупой подрядчик хочет, чтобы ТЗ оценили.

(27)

В инвентарный номер добавим свой собственный префикс.

А так в БГУ и у номенклатуры есть отдельный номер, и к нему так же нужен префикс.

Вывод = тупой бот.

Эка вы накинулись обсуждать решение задачи. В бюджете надо не задачу решить, а выделенный бюджет распилить. Один раз уже распилили, теперь второй заход. Вообще при таком подходе вредно даже задачу решать - новый бюджет же не выделят :)

Помню больше полгода в БГУ какую-то фигню пилили, в итоге оказалось, что никто эту фигню внедрять не будет. Деньги закончились. Все разошлись. Кто с бюджетом работает мне кажется это вообще какие-то особенные люди :)

(31) Это должен сказать ТС, а не разработчик правил.
Потом будет вопрос: А с новыми ОС как быть (префикс или как)? Собственно чьё оно? МОЛ? так-то достаточно ли функционала сводной конфигурации для ответа на эти вопросы?

(32) как варианты: припод или шибко вумный начальник, но бот вероятнее

(34) просто логика немного сдвинута: Деньги выделяются и осваиваются, а откуда их взяли тайна великая есть

(35)

В (29) написал, что судя по постановке задачи — нет толкового методиста.

(31) Нужен не префикс, а единый справочник, иначе будет куча дублей

(36) Там нет основного понимания "А зачем собственно? и Что получим в результате?"

(0) я такое делал. В личке контакты.

(37) Куча дублей и так будет. Одни и те же контрагенты, одни и те же лампочки, гвозди, краска. Может и люди будут, типа уборщицы которая в нескольких организациях. И всё это надо будет потом чистить.

(39) Нууу, так не годится! А пофлудить? Пятница жы.

кажется, идентичные конфигурации через КД2 проще

(38) В таких случаях вопроса "зачем ?" не бывает.
В ГорОНО сказали "сделать !" и все, никаких обсуждений

Собственный опыт слияния. Отказался от такого объединения. Для ОС, МЗ, расчетов по родительской плате делал обработки переноса формирующие в итоговой базе документы поступления с проводками Дт 304.06 Кт 101, 105 и т.п. И наоборот, если остатки в пассиве. Слишком разнородные были варианты учета в присоединяемых базах. Где то был учет по ИФО, по подразделениям и прочие прелести. Не забываем про расчеты дебиторку/кредиторку в 169/769 формах. В случае переноса через счет 304.06 имел нулевой остаток на этом счете, значит баланс перенесен корректно. И самое главное - получаем учет полностью идентичный базовому учреждению, т.е. тому к которому присоединили. И всегда есть возможность маневра, исправить ту или иную цифру в доках переноса, не углубляясь в дебри учета чужого учреждения. Да, тоже ГОРОНО, тоже давили сливай.

(44) ТС хочет правила реализующие принцип "Сделать всё правильно" без умственных усилий со стороны использующего

(42) любые конфигурации 1С для разового переноса КД2, для постоянного обмена - кому как удобнее

(45) Наоборот.

Для одноразового переноса — как угодно, хоть через xls, хоть через OLE подключение.

А вот если нужен обмен на постоянной основе, тут как раз КД2, КД3.

Да, можно и наоборот. Но правила конвертации, как мне видеться, нужны именно для многоразового переноса.

А если многоразовый серийный обмен, то должна быть абстрактная структура, независящая от конкретных исполнителей, типа ЭДО, в xml или csv форматах — такие, чтобы можно было без труда открыть и поправить цифры. А еще лучше, прям xls, чтобы сначала этот файл выгрузили, а потом загрузили, дабы не было херни типа: "а я не знаю что там ваша 1Ска выгрузила/загрузила", чтобы можно было каждого ответственного мордой потыкать и с спросить: "а вы что не видели что передавали?". И соответствующими проверками: "в ххх.xls в строке N, столбце M — ошибка такая-то" — чтобы любой бух мог открыть и  поправить.

(0) Для такой работы КД3 это ошибка. Это я вам конкретно говорю, как человек как раз такие работы выполнивший не один раз. Тут КД 2 нужно

Сбоку от спора КД2/КД3: посчитайте заранее объём итоговой базы. 22 школы в одну файловую - и упрётесь не в правила, а в лимит 4 ГБ на таблицу в .1CD, а регистр бухгалтерии в БГУ жирный. Дубли из (40) объём ещё поддуют.
БГУ не наш профиль, но по большим базам грабля одна и та же: если сумма исходных уже около пары гигов, клиент-сервер лучше закладывать до переноса, а не после.

(0) "Требуется разработать правила обмена для последующего самостоятельного объединения баз в одну информационную базу."


это кстати не взлетит. кто пишет правила тот их и применяет единожды. а потом уже по перенесенным данным напильником проходит