Настроить 1с для филиала

Использован релиз 3.0.72

В программе «1С:Бухгалтерия 8» (ред. 3.0) учет по обособленным подразделениям поддерживается только в целях формирования отчетности по НДФЛ для организаций с численностью не более 60 человек.

Раздел: Зарплата и кадры — Настройки зарплаты (или раздел: Администрирование – Параметры учета, ссылка «Настройки зарплаты»).
Раскройте блок «Расчет зарплаты» и установите флажок «Расчет зарплаты по обособленным подразделениям» (рис. 1).

В справочнике «Подразделения» станет видимым и доступным для редактирования флажок «Обособленное подразделение».

Раздел: Главное — Организации.
Откройте карточку организации и перейдите по ссылке «Подразделения».
Создайте новое подразделение по кнопке «Создать» или откройте уже существующее подразделение, которое является обособленным.
Установите флажок «Обособленное подразделение», в форму элемента добавится поле «КПП» и блок «Налоговая инспекция». Укажите КПП, раскройте блок «Налоговая инспекция» и проверьте реквизиты (должны заполниться автоматически). Если реквизиты не заполнились автоматически, то укажите код ИФНС и заполните реквизиты ИФНС самостоятельно или по кнопке «Заполнить реквизиты по коду».
Кнопка «Записать и закрыть».

Полноценный учет для обособленных подразделений организован в программе «1С Бухгалтерия КОРП». В частности ведется учет по приему и передаче основных средств, готовой продукции, материалов, денежных средств, а также перевод сотрудников между головной организацией и обособленными подразделениями. Ведется учет доходов, расходов, прибыли по каждому обособленному подразделению. При составлении декларации по налогу на прибыль рассчитываются доли распределения налога по ИФНС. Подробнее см. «Рекомендации по организации учета и представлению отчетности в программе «1С:Бухгалтерия 8 КОРП» редакция 3.0».

Смотрите также

Не пропускайте последние новости — подпишитесь
на бесплатную рассылку сайта:

десятки экспертов ежедневно мониторят изменения законодательства и судебную практику;
рассылка бесплатная, независимо от наличия договора 1С:ИТС;
ваш e-mail не передается третьим лицам;

Источник

Настроить 1с для филиала

Использован релиз 3.0.58

Для ведения учета затрат по каждому подразделению установите в программе две настройки:

в форме «Параметры учета» настройте аналитику плана счетов;
в справочнике «Подразделения» добавьте новые элементы – подразделения.

Настройка Параметров учета.

Раздел: Администрирование – Параметры учета.
Перейдите по ссылке «Настройка плана счетов».
Если в разделе «Учет затрат» ссылка имеет значение «Сводно, по организации в целом», то перейдите по ней и установите переключатель в положение «По каждому подразделению» (рис. 1).
Кнопка «Записать и закрыть».

Добавление новых подразделений.

Раздел: Главное – Организации.
Дважды щелкните по нужной организации.
По ссылке «Подразделения» откройте справочник «Подразделения». По умолчанию в справочнике есть только одно «Основное подразделение» (его можно переименовать).
Кнопка «Создать» (рис. 2).
Введите наименование подразделения.
Флажок «Обособленное подразделение» устанавливается, если в программе планируется вести учет зарплаты работников обособленного подразделения (для организацией с численностью до 60 человек).
Кнопка «Записать и закрыть».
Кнопки с синими стрелками позволяют настроить нужную последовательность подразделений в списке.

Смотрите также

Не пропускайте последние новости — подпишитесь
на бесплатную рассылку сайта:

десятки экспертов ежедневно мониторят изменения законодательства и судебную практику;
рассылка бесплатная, независимо от наличия договора 1С:ИТС;
ваш e-mail не передается третьим лицам;

Источник

Использование одного идентификатора различными обособленными подразделениями

Видеоинструкция

Текстовая инструкция

Отправка электронных документов филиала организации через идентификатор участника ЭДО головной организации.

У головной организации имеется идентификатор участника ЭДО и настройка ЭДО с контрагентом. В справочнике «Организации» есть сведения о филиале, запись которой отличается от головной организации наименованием и КПП. Рассмотрим сценарий, в котором головной организации необходимо отправить контрагенту документы реализации от имени филиала.

Формируем документ «Акт выполненных работ», в котором продавцом выступает филиал:

Проводим документ, нажимаем кнопку «ЭДО» и выбираем пункт «Отправить электронный документ». Программа увидит имеющуюся учетную запись головной организации (или филиала, если идентификатор участника ЭДО получен на филиал) и предложит отправить документ от этой учетной записи. Поиск учетной записи происходит по ИНН организации, без учета КПП.

Далее нажимаем кнопку «Готово». Документ отправится от головной организации, но в графе документа «Продавец» будет указан филиал.

После отправки в настройках ЭДО автоматически создается отдельная настройка для филиала, в которой указывается учетная запись ЭДО головной организации (или филиала, если идентификатор участника ЭДО получен на филиал).

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

Обмен документами между филиалами различных организаций, не имеющими собственные идентификаторы участника ЭДО

У головных организаций имеются идентификаторы участников ЭДО и настройки обмена между собой. В роли продавца и покупателя выступают филиалы организаций. Рассмотрим сценарий, в котором отправку и получение документов необходимо осуществить между филиалами организаций.

Создаем документ реализации, в котором продавцом является филиал организации отправителя, а покупателем — филиал организации получателя. Проводим документ, нажимаем кнопку «ЭДО» и выбираем пункт «Отправить электронный документ». Программа покажет имеющиеся учетные записи головных организаций, между которыми уже настроен обмен и предложит отправить документы, используя эти учетные записи.

При нажатии на кнопку «Готово» документ будет отправлен с идентификатора ЭДО головной организации на идентификатор ЭДО головной организации контрагента.

При присмотре документа в печатном виде видим, что в качестве продавца и покупателя указаны филиалы организаций.

На стороне получателя документ также будет создан с указанием филиалов организаций.

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

Источник

Филиал в 1С ЗУП 3.1

1. Как создать Филиал в 1С 8.3

Данная статья содержит информацию о том, как правильно в программе 1С ЗУП 3.1 создать филиал или так называемое обособленное подразделение (сокращенно ОП) для того, чтобы иметь возможность формировать отчетность в разрезе ИФНС в 1С. Обособленным считают подразделение, расположенное территориально отдельно от главного офиса компании. Если у организации есть ОП, тогда организация должна перечислять НДФЛ как по месту основной регистрации, так и по месту нахождения ОП – в бюджет соответствующего региона. Сумму НДФЛ определяют по начисленному доходу, который получили работники данного ОП.

Рассмотрим, какие настройки необходимо выполнить в программе для регистрации филиала. Отметим, что вариант регистрации обособленного подразделения в 1С ЗУП 3.1 зависит от того, выделено ли ОП на отдельный баланс или нет.

Если структурная единица выделена на отдельный баланс, тогда в программе 1С ЗУП 3.1 – это элемент справочника «Организации».

Если ОП не выделено на отдельный баланс, тогда в программе 1С ЗУП 3.1 оно является элементом справочника «Подразделения».

2. Ведения учета по обособленному подразделению в 1С ЗУП

Для ведения учета по обособленному подразделению в 1С ЗУП для главной организации необходимо установить флажок – «У организации есть филиалы (обособленные подразделения)»:

Если структурная единица выделена на отдельный баланс, тогда в качестве филиала создаем элемент справочника «Организации», устанавливаем флаг – «Это филиал», указывая главную организации. Далее необходимо заполнить данные регистрации ИФНС в 1С, к которой относится этот филиал.

Если структурная единица не имеет выделенного баланса, тогда в качестве филиала создаем элемент справочника «Подразделения», который будет соответствовать ОП.

В реквизитах подразделения следует установить флажок – «Это – обособленное подразделение». Этот признак дает возможность внести данные о регистрации ИФНС и о территориальных условиях, если в этом есть необходимость.

В результате таких настроек все аналитические и регламентированные отчеты по НДФЛ можно будет формировать в разрезе ИФНС в 1С.

Источник

Настройка филиальных баз данных

Все началось с того что у клиента был большой штат сотрудников и документооборот в разных городах. У клиента уже были базы Бухгалтерия ПРОФ, ЗУП и УТ CRM. Причем УТ CRM имел РИБ в другом регионе. Работали обмены ЗУП — БУХ (переносились новые физические лица и связанная с ними информация в бухгалтерию), двухсторонний типовой регламентный обмен УТ CRM-БУХ и типовой обмен РИБ между базами в УТ CRM.

Поначалу они решили, что в центральном филиале будут вести учет и выплачивать зарплату по всем филиалам сами. Но видимо у бухгалтеров кончилось терпение и силы и нам поставили задачу.

Реализовать возможность работы бухгалтеров (наняли в каждом городе) таким образом, чтобы они сами могли подготавливать все отчеты и делать необходимые расчеты, но все налоги, как и прежде, должны были сдаваться в центре. Вся справочная информация, необходимая для работы филиалов, должна быть им доступна. Нужно закрыть доступ ко всем документам и отчетам о деятельности между офисами — филиалами и разрешить видеть и использовать центру все, что происходит во всех филиалах.

У нас имеется 2 конфигурации в которой уже работает Центр это ЗУП и БУХ Проф. В этих конфигурациях уже занесены данные о сотрудниках офиса — зарплаты, отпуска, отчисления и тп. Нужно теперь разделить эту информацию пофилиально предварительно создав возможность бухгалтеров работать в базах.

Первым делом начали продумывать, как реализовать задачу для Бухгалтерии. Самые первые мысли были из серии создать каждому филиалу по одной базе и перенести туда все необходимые справочные материалы и сведения, которые ранее велись в центральной базе (документы реализаций, заказов, поступлений и т.п.). Так как эта идея пришла первая в голову, она оказалась не шибко умной, учитывая, что количество филиалов постоянно будет расти и усложнится поддержка огромного числа баз, которые еще будут периодически сбрасывать созданные там документы и элементы справочников в центр (отчетность сдается там) и получать новые справочные данные из центра. Еще нужно учесть возможность возникновения дублей, коллизий при обмене и тому подобную ерунду.

Следующим пришел на ум вариант сделать Распределенную Информационную Базу (РИБ) — всего одну. В этот РИБ поместить все филиалы, ограничив при первоначальном создании базы «дочки» перенос информации, которая не должна попасть в филиалы согласно ТЗ. Это решается буквально в пару строчек в модуле объекта плана обмена «Полный» — дописать какие элементы мы игнорируем при загрузке\выгрузке. Но разделение по работе разных организаций в одной конфигурации Бухгалтерии есть только в версии КОРП. Значит перед созданием РИБ нужно еще обновить Бухгалтерию до версии КОРП.

Красота РИБ в нашем случае очевидна — занеся один раз в Центр справочную информацию, она передастся в Дочернюю базу и наоборот и сразу отпадает вопрос дублей. Разграничение между филиалами будет работать согласно типовому разграничению версии КОРП. Организации не будут видеть друг друга, а Центр будет получать все документы, созданные в филиалах за счет стандартного обмена РИБ. Но тут есть жирный минус — нам нужно как то обзывать филиалы и заводить их как организации в Бухгалтерии КОРП и тогда средствами РИБ эти все организации и соответственно все документы со ссылкой на эти организации перенесутся в Центр, а нам нужно сдавать консолидировано всю отчетность от Юр лица в Центре. Выход есть: поправить сам обмен РИБ и добавить правила, которые бы подменивали название организаций при переносе из РИБ Дочерней базы в Центр. Тогда резонный вопрос — а зачем нам РИБ и так ли он нам необходим? Ведь помимо всех плюсов у этого механизма есть и существенные минусы, например, такие как идентичность ИБ (дочерняя база изначально зависима от Центра и все изменения в конфигурации, которые произошли в Центре, просто необходимо подтвердить в Дочерней базе, чтобы начать работать — а это значит, что невозможно разделить явно работу Центра и филиалов и может попасться информация, которая просочится в филиал).

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

Обновить версию до КОРП — это совсем просто — скачать специальный дистрибутив с сайта 1С и простым обновлением (релиз ПРОФ должен соответствовать релизу обновления до КОРП) с помощью этого дистрибутива наша Бухгалтерия становится КОРП.

Перенести справочную информацию без ссылок на, например справочник Организации и документы, тоже не сильно сложно — расставить пару галочек в конфигурации «Менеджер обмена данными» и с помощью универсальной обработки обмена форматом XML, подгрузив файлик правил, перенести всю выбранную информацию.

Далее нужен план обмена, который выгружал бы всю новую справочную информацию из Центра в филиалы, а обратно загружал бы документы и справочную информацию, созданную в филиалах, с подменой и переносом ссылок организаций — филиалов на единственную организацию в конфигурации Центра. Было принято решение сделать 2 плана обмена, первый отправлял бы справочную информацию из центра в филиал, второй отправлял бы документы и связанные с этими документами новые справочные объекты обратно в Центр. Центральная база бухгалтерии довольно нагружена, в ней работает порядка 30 человек, а так же происходит регламентный типовой обмен с конфигурацией УТ CRM (каждые 10 минут). Сама УТ CRM насчитывает 100 параллельных подключений менеджеров и имеет РИБ, который является базой для колл-центра в другом регионе России. В УТ CRM генерируется огромное количество справочной информации, которая средствами типового обмена отправляется в Бухгалтерию Центральную, а далее добирается до филиальной бухгалтерии с помощью нашего нетипового обмена. Так как УТ CRM обменивается с Центральной бухгалтерией каждые 10 минут, то для поддержания актуальности информации в филиалах мы должны реализовать обмен с филиальной базой хотя бы раз в 20 минут, что и было сделано.

Второй обмен должен был переносить документы и связанную с ними справочную информацию из филиалов в Центр — этот обмен был проще, включал в себя 5 документов и обменивался с Центром раз в 4 часа — так как в конце концов эти документы были нужны, только в период консолидированной сдачи отчетности.

После создания и тестирования правил и баз бухгалтерии запустили их в рабочем режиме и . Обрушилась вся контактная информация (удалился весь Регистр сведений «Контактная информация») на стороне УТ CRM. В итоге мы быстренько подгрузили контактную информацию в базу из бэкапа, остановили обмен и начали разбираться.

Ошибка оказалась очень интересной : Когда в базе бухгалтерии создается Контактное лицо со свойством «личный контакт» (такого нет в УТ CRM) и осуществляется обмен через подключение к ИБ (не через папку обмена) на новое контактное лицо со свойством «личный» не накладывается никаких отборов при записи в конфигурацию выгрузки — УТ CRM и за счет пустого отбора и записи регистра успешно затирается весь регистр сведений. При обмене через промежуточный файл такого не происходит.

Вопрос возник другой — почему раньше такого не происходило, а произошло только сейчас, как утверждает клиент, они вообще не пользуются контактным лицом со свойством «Личный». Действительно в справочнике Контактных лиц со свойством «личный» было всего несколько штук и заведены они были очень давно, еще до реализации типового обмена между Центральной бухгалтерией и УТ CRM. Как оказалась — тут моя огромная ошибка — я создал план обмена до переноса первоначальной информации, и совсем забыл удалить все, что план обмена зарегистрировал как модифицированные объекты для обмена, в число которых и попали эти несчастные контактные лица. Когда запустили обмен из филиалов в Центр, он перенес измененные объекты, включая и контактные лица обратно в центр, где они уже и так есть, а план обмена с УТ CRM уже перенес эти зарегистрированные для своего обмена элементы в УТ CRM и благополучно все затер.

Ошибку исправили — закрыли обмен справочником Контактные лица и запустили обмен.

Написали об ошибке в фирму 1С , она воспроизвелась на типовых версиях Бухгалтерии ПРОФ, КОРП и УТ 10.3 — хочется сказать что служба по регистрации ошибок в 1С оставляет желать лучшего. Они 2 недели только вникали как воспроизвести ошибку и потом так и не воспроизведя ее у себя заявили что проблема у нас, хотя еще раз повторю обмен мы воспроизводили на типовых версиях УТ и БУХ и описали как эта ошибка появляется у нас (стандартная форма регистрации ошибок в 1С). В итоге мы нашли в интернете, что проблема возникала и у других людей, но так до сих пор и не решена фирмой 1С.

Далее нужно было реализовать те же требования в конфигурации «Зарплата и Управление Персоналом» (ЗУП) — тут оказалось, что в ЗУП уже заложены механизмы ограничения данных по физическим лицам — что нас вполне устраивало. В каждом филиале работали свои физ. лица и они не пересекались в разных филиалах. Ограничение реализовано так, что каждому пользователю видны те документы, которые относятся к группе доступа физических лиц, присвоенной ему.

Нужно было всего лишь сделать группы доступа физ лиц — занести туда пофилиально порции физ лиц и назначить на каждую группу доступа группы пользователей, которые имеют право видеть документы по своим физ лицам. Если же нужно видеть все документы (Центр) то им создали группу пользователей в которую не входит не одна группа доступа физ лиц — т.е. они видят всех. Очень красиво реализовано и все это в одной конфигурации, где работают и Центр и Филиалы.

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

Источник