Бухгалтерия 7.7 (не типовая).
Имеется рабочая база "Чёрная", куда все всё вбивают. Теперь хочется иметь "Белую", с которой работали бы только "серьёзные" люди. Этаже база является открытой для всяких органов.
Вопрос: как бы всё это грамотно реализовать. Наверняка многие что-то делали в этом плане, поэтому не хочется наступать на те же грабли.

П.С. задавал вопрос на инфостарте, но там ка-то мёртво

Не реально.
Один-два человека будут отвечать за пушистую базу, т.е. править то, что им надо.

Нет, я всё равно такое себе не могу представить. Это по-любому нужны 2 человека, которые больше ничем заниматься не будут, ибо им придётся вносить те документы, которые вносят другие бухи и операторы, а таковых не мало.

П.С. с ТиСом вообще никак не связано. Просто бухгалтерия и всё

JohnyDeath писал(а) 11. Декабря 2008 :: 08:59:


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

kiruha писал(а) 11. Декабря 2008 :: 09:06:

А какой в ТиСе план счетов??

JohnyDeath писал(а) 11. Декабря 2008 :: 09:06:



Не просто белые документы выгружаешь в белую бухгалтерию.

kiruha писал(а) 11. Декабря 2008 :: 09:13:

А как же отчётики ОСВ, Анализ счета и т.п.? Чувствую, мы на разных языках разговариваем. Там нет торговли вообще.

МОД легко настроить

GEORG писал(а) 11. Декабря 2008 :: 09:22:

нее, точно не надо

JohnyDeath писал(а) 11. Декабря 2008 :: 09:17:


Года 4 назад писал в команде по разработкам финотдела, не знаю насколько точно было совпадение со стандартами.
Более продвинутых решений МСФО в 1С достаточно много, даже книги есть
Учет и отчетность по МСФО в 1С:Предприятии 8.0 в вопросах и ответах

Покупаться точно ничего не будет, поэтому МОДы, МСФО и 8 не катят

Ну под прогой я конечно же понимал "обработку".
Тут что хреново: вторую базу прдётся по ОЛЕ подключать, не знаю почему, но чё-т не охота.

Nick писал(а) 11. Декабря 2008 :: 09:40:

Да просто помечтал о полном интерактиве - слва текущая база, справа в которую загружаем; вопросы типа "А такой док уже есть! Че делать?" ну и т.д.   Ладно, это всё мелочи.
А стандартная 1С выгрузка это что? Конвертация?

В ощем выводы такие:
1. Своя обработка по подбору элементов в выгрузку
2. Выгрузка конвертацией
3. Загрузка конвертацией с возможной постобработкой

Так?

JohnyDeath писал(а) 11. Декабря 2008 :: 09:37:


Если ДБФ (?) и в одной сети - можно прямыми запросами и сразу к двум базам.
Быстрее способов не знаю.

JohnyDeath писал(а) 11. Декабря 2008 :: 10:51:


Нет. Я делаю сравнение(например спр Номенклатуры) и получение данных(документы) через прямые.
Запись штатно в базе приемнике (кстати родные методы 1С-ки пишут достаточно быстро)
Запросы из базы приемника

JohnyDeath писал(а) 11. Декабря 2008 :: 11:28:


Из второй базы прямые запросы к родительской и к двум одновременно по технологии
http://www.1cpp.ru/forum/YaBB.pl?num=1182497837/19#19
запись здесь же по результатам запроса.
Никаких других баз не открываю.

JohnyDeath писал(а) 11. Декабря 2008 :: 12:22:


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

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

JohnyDeath писал(а) 11. Декабря 2008 :: 14:55:


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

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

JohnyDeath писал(а) 11. Декабря 2008 :: 15:21:

пространство guid должно быть непересекающимся по различным учетам  (только белое и только черное) для двух баз. Или это свойство guid ?

Я вроде все прочитал, только не совсем понял чем вариант второго плана счетов не устраивает?
Есть конечно один большой минус, очень много документов надо переписывать и второй - быстродействие. Поскольку все проводки в одной таблице то с ростом количества проводок растет и 1SENTRY и это неприятно сказывается на отчетах которые собираются по "промежуточным" периодам. Т.е. не с нач.кон месяца, а с какой-нить даты по какую-нибудь. Но зато потом и все ОСВ и прочие радости с удовольствием работают без проблем.

Жаль что я сначала в тему не влился... но мне инет отрубили и все тут . Хотя мое мнение наверное и не стали бы особо слушать 

JohnyDeath писал(а) 11. Декабря 2008 :: 18:44:


Если будет 2 и более ПС то:
1. Они всегда будут видимы в окне выбора счета (стандартные отчеты+справочники+документы) если там не указан конкретный ПС
- т.е. это первая доработка. Берем каждый отчет и меняем просто Счет -> Счет.Основной (чтобы другой выбрать не могли)
- далее отчетик пишешь чтобы не все подряд смотреть и по нему по метаданным пробегаешься и везде чтобы пользователи мозг не "тру-ля-ля". Нам же скрыть надо по макс верно?
2. Оба ПС будут видимы в окне которое открывается при нажатии стандартной кнопки ТТ на панели 1С.
- лечится написанием своей обработки и подстановкой
3. Документы которые должны быть во втором плане счетов могут быть как в основном так и во втором плане счетов надо переписывать. Как вариант вот порядок действий:
- добавляешь закладки на которых располагаешь нужные тебе реквизиты. Т.е. одновременно документ для некоторых как и был, а для других он еще и дополнительно проводит то что надо. Правда рулежка правами должна быть хорошая. В проведении кое-где просто задвоение, где то переписать. Советую сразу добавить две переменные глОсновнойПланСчетов, глДополнительныйПланСчетов, чтобы не парится. Счета создаются как обычно через "СчетПоКоду", соответственно проблем нет. Берешь копипастишь или в цикл
Для НомерПС = 1 По КолПлановСчетов Цикл

- Что касается прав на закладки, инсентером по конфе пробежаться везде одну процедурку для контроля поставить... но это на вскидку. Отдельные проблемы чуточку сложнее наверное будут в плане реализации управления правами.
- поскольку документы по двум ПС оба будут в движениях и операциях то: 1. Меняешь форму проводок 2. Форму журнала операций прийдется закрыть. Или писать аналогичную но свою собственную. Что собственно не очень сложно. Даже прямым запросом две таблицы понадобиться всего (и работать будет вполне норм). 3. все формы которые так или иначе дают доступ к информации. Их не много.
(как изменить форму просмотра проводок тебе решать или RWidjets ловишь выбор команды и свою подсовываешь, или стандартную форму многострочную часть прячешь, располагаешь ТЗ, колонки аналогично расставляешь (Fromex рулит), заполняешь только по одному плану счетов + привязка. Т.к. ТЗ почему то сама не изменяет размер, благо подправили этот косяк)
- написать пару обработок для просмотра движений по двум ПС.

Есть проблемы с производительностью, т.к. тут в формат хранения вопрос упирается. 1С хранит проводки в одной таблице по всем ПС, соответственно объем проводок увеличится, а значит и увеличится объем таблицы и итоги будут собираться постепенно все тяжелее и тяжелее за промежуточные периоды внутри месяцев (и по проводкам, в общем тогда когда 1SENTRY читается). Кстати в 8-ке реализовано рациональнее насколько я понял.

Это то что я написал на вскидку. Вообще если интересна такая реализация стучись в аську, там я есть, а сюда только по вечерам счас получается . (205 971 125 - вот)

JohnyDeath писал(а) 11. Декабря 2008 :: 08:31:

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

JohnyDeath писал(а) 12. Декабря 2008 :: 09:40:


Я просто забыл об этом сказать