Graude-msk.ru

Ремонт бытовой техники
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Настройка переноса данных между 1С УПП и 1С БП

Настройка переноса данных между 1С УПП и 1С БП

Анна Викулина

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

В данной статье мы рассмотрим обмен между 1С УПП 1.3 и 1С:Бухгалтерия – один из самых «востребованных» рынком обменов.

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

Для проверки зарегистрированных для обмена данных можно воспользоваться обработкой «Регистрация изменений для обмена данными». Обработку можно найти в разделе «Функции для технического специалиста».

Функции для технического специалиста

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

Регистрация изменений для обмена данными

Важно! Такую проверку нужно осуществлять при отключенном регламентном задании «Автоматическая синхронизация с iCRM».

Регистрация изменений для обмена данными

Регистр накопления «Прочие расчеты» предназначен для учета взаиморасчетов по зарплате, налогам и подотчетным лицам для целей УСН (рис. 6).
Возникновение дебиторской задолженности в регистре отражается приходными записями, погашение дебиторской задолженности — расходными записями. Возникновение кредиторской задолженности в регистре отражается расходными записями, погашение кредиторской задолженности — приходными записями.

Рисунок 6.

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

Записи в регистрах накопления подсистемы УСН формируются при проведении документов, регистрирующих факты хозяйственной жизни организации.

Регистры при синхронизации 1с

Дорогие читатели, в этом уроке я хочу затронуть крайне важную тему при работе в 1С:Бухгалтерия 8.3 — Регистры.

Детективная история

Сразу покажу на небольшом примере почему это так важно.

Пусть у нас есть начисление заработной платы за январь:

В начале февраля мы создаём ведомость на выплату зарплаты из кассы и нажимаем кнопку «Заполнить»:

И получаем следующее:

Но ведь за январь:

  • Начисление 50 000 рублей
  • НДФЛ 6 500 рублей
  • Итого к выплате 43 500 рублей

Где закралась ошибка? Что пошло не так? Неужели теперь всегда вводить сумму к выплате вручную?

Опытный бухгалтер тут же сделает оборотно-сальдовую ведомость по 70 счёту:

И будет в ещё большем недоумении, потому что по данным отчёта к выплате выходят всё те же 43 500! И откуда же взялись лишние 5 000 рублей?

Причём такая ситуация (с любыми расчётами) может произойти как в «тройке», так и в «двойке».

Читайте так же:
Можно ли регулировать вентилятор на ноутбуке

Сегодня я попытаюсь приоткрыть завесу тайны — почему же иногда программа ведёт себя так странно. Я расскажу как в таких случаях находить и устранять ошибку. Ближе к концу статьи мы разберёмся — откуда же взялись эти самые 5 000 рублей.

Учимся видеть регистры

При проведении документов 1С:Бухгалтерия 8 делает проводки по бухгалтерским счетам (кнопка ДтКт у любого документа):

Именно на основании этих проводок строятся все бухгалтерские отчёты: Анализ счёта, Карточка счёта, Оборотно-сальдовая ведомость.

Но есть огромный пласт данных, которые пишутся программой параллельно с проводками и используются для всего остального: заполнение КУДИР, книги покупок и продаж, регламентированной отчётности. заработной платы к выплате, наконец

Как вы уже, наверное, догадались этот пласт называется регистрами, вот он:

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

Скажу лишь, что нам просто жизненно необходимо постепенно учиться «видеть» движения по этим регистрам, чтобы лучше понимать и, когда надо, корректировать поведение программы.

Давайте присмотримся к регистру «Зарплата к выплате» — именно он имеет смысл для решения нашей проблемы с лишними 5 000:

Мы видим две записи по этому регистру, сделанные в приход, то есть в плюс. Если пролистать экран в право, то мы увидим в первой строчке сумму к выплате «-6 500», а во второй «50 000».

Остаток по этому регистру -6 500 + 50 000 равен 43 500, который и должен попасть в документ «Ведомость на выплату из кассы», когда мы нажимаем на кнопку «Заполнить».

Ещё раз повторюсь — ведомость на выплату определяет нашу задолженность по заработной плате перед сотрудником не по 70 счёту, а по регистру «Зарплата к выплате» .

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

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

Учимся анализировать регистры

И такой инструмент есть, он называется «Универсальный отчёт«.

Переходим в раздел «Отчеты» пункт «Универсальный отчёт»:

Выбираем тип регистра «Регистр накопления», регистр «Зарплата к выплате» и нажимаем кнопку «Сформировать»:

Получилось не очень информативно:

Всё потому, что требуется предварительная настройка отчёта, нажимаем кнопку «Показать настройки» и на закладке «Группировка» добавляем поле «Сотрудник»:

Читайте так же:
Яндекс диск синхронизация webdav

На закладке «Отборы» делаем отбор по нашей организации:

Нажимаем кнопку «Сформировать»:

Вот это уже более интересно. Видим остаток к выплате нашему сотруднику те самые 48 500 рублей!

Снова заходим в настройки отчёта и добавляем на закладку «Показатели» новое поле «Регистратор»:

Снова формируем отчёт:

Вот теперь мы прекрасно видим, что 5 000 появились как результат операции (видимо ввода остатков) 31 декабря 2014 года.

И нам нужно либо изменить эту операцию, либо вручную откорректировать регистр «Зарплата к выплате» и закрыть эти 5 000 рублей, например, 31 декабря 2015 года.

Давайте пойдём вторым путём. Итак, наша задача — сделать так, чтобы на начало 2016 года по регистру «Зарплата к выплате» не было нашей задолженности перед сотрудником.

Это делается ручной операцией.

Учимся корректировать регистры

Заходим в раздел «Операции» пункт «Операции, введенные вручную»:

Создаём новую операцию концом 2015 года:

Из меню «Ещё» выбираем пункт «Выбор регистров. «:

Указываем регистр «Зарплата к выплате» и нажимаем ОК:

Переходим на появившуюся закладку регистра и делаем расход на 5 000 рублей:

Этим самым мы как бы отнимаем от регистра 5 000 рублей по сотруднику, чтобы выйти на ноль к началу 2016 года.

Проводим операцию и заново формируем универсальный отчёт:

Всё получилось! Видим, что наша ручная операция от 31.12.2015 вывела остаток в ноль и зарплата к выплате после начисления равна ожидаемым 43 500.

Замечательно. И сейчас мы проверим это в ведомости на выплату.

Но прежде я хочу обратить ваше внимание на ещё один важный момент:

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

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

Если нам требуются остатки по группировке сотрудник — нужно сначала удалить из настроек добавленный нами показатель «Регистратор»:

И только потом формировать отчёт:

Сейчас остатки показаны корректно.

Результат

Напоследок убедимся, что мы сделали всё правильно. Снова заходим в ведомость на выплату заработной платы за январь и нажимаем кнопку «Заполнить»:

Мы молодцы, на этом пока всё

Кстати, подписывайтесь на новые уроки.

С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).

Владимир Милькин

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

Читайте так же:
Как синхронизировать приложения с sony xperia

Как могли бы выглядеть регистры в 1С при наличии ООП

image

В 1С одним из ключевых элементов системы являются регистры. Этот термин имеет свой аналог в английском языке — ledger. Он первоначально появился в бухгалтерской практике, но со временем его логика начала использоваться и в других сферах.

В отличие от 1С, где регистры являются одним из встроенных типов, в самой платформе lsFusion такого понятия нет. Зато в ней есть наследование, полиморфизм и агрегации, что, в частности, позволяет реализовать аналогичную логику регистров. В этой статье на примерах я покажу как именно.

Регистр — это набор записей, каждая из которых отражает некоторое изменение состояния для некоторого множества субъектов (или измерений).

В 1С различают 4 вида регистров:

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

Любую запись в регистре можно рассматривать как объект некоторого абстрактного класса. Предположим нужно реализовать простой регистр, который рассчитывает остаток по товару на складе.

Для этого объявим абстрактный класс SkuLedger:

CLASS ABSTRACT SkuLedger ‘Регистр изменения остатка товара’ ;

Формально, один экземпляр которого будет отражать единичное изменение остатка по заданному товару и заданному складу на определенное количество (положительное или отрицательное).

Зададим у него измерения как абстрактные свойства типов Sku (товар) и Stock (склад) соответственно. Их нужно будет реализовать при наследовании конкретных классов от класса регистра:

sku ‘SKU’ = ABSTRACT Sku (SkuLedger);
stock ‘Склад’ = ABSTRACT Stock (SkuLedger);
dateTime ‘Дата/время’ = ABSTRACT DATETIME (SkuLedger);
quantity ‘Кол-во’ = ABSTRACT NUMERIC [ 14 , 2 ] (SkuLedger);
balance (Stock st, Sku sk) ‘Остаток’ = GROUP SUM quantity(SkuLedger l) IF stock(l) = st AND sku(l) = sk;

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

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

CONSTRAINT balance(Stock st, Sku sk) < 0
MESSAGE ‘Остаток по товару на складе должен быть положительным’ ;
Читайте так же:
Программа для samsung galaxy s4 для синхронизации с компьютером

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

При необходимости быстро считать оборот по товару, например, за год можно построить следующее свойство:

balance (Stock st, Sku sk, INTEGER year) =
GROUP SUM quantity(SkuLedger l) IF stock(l) = st AND sku(l) = sk AND extractYear(dateTime(l)) = year MATERIALIZED ;

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

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

balance ‘Остаток на время’ (Stock st, Sku sk, DATETIME dt) =
GROUP SUM quantity(SkuLedger l) IF stock(l) = st AND sku(l) = sk AND dateTime(l) <= dt;
balance ‘Остаток на время’ (Stock st, Sku sk, DATETIME dt) =
currentBalance(sk, st) (-) ( GROUP SUM quantity(SkuLedger l) IF stock(l) = st AND sku(l) = sk AND dateTime(l) > dt);
INDEX dateTime(SkuLedger l);

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

Теперь покажем, как проводить по регистру документы. Предположим у нас объявлен документ поступления товаров на склад:

CLASS ReceiptDetail ‘Строка поступления на склад’ ;
receipt ‘Поступление’ = DATA Receipt (ReceiptDetail) NONULL DELETE ;

sku ‘SKU’ = DATA SKU (ReceiptDetail);

EXTEND CLASS ReceiptDetail : SkuLedger;

stock(ReceiptDetail d) += stock(receipt(d));

Количество и товар мы подставляем непосредственно из строки, а время и склад из документа.

Рассмотрим более сложный случай, когда объявлен документ перемещения со склада на склад:

fromStock ‘Склад (откуда)’ = DATA Stock (Transfer);
toStock ‘Склад (куда)’ = DATA Stock (Transfer);

CLASS TransferDetail ‘Строка отгрузки со склада’ ;
transfer ‘Поступление’ = DATA Transfer (TransferDetail) NONULL DELETE ;

sku ‘SKU’ = DATA SKU (TransferDetail);

dateTime(TransferDetail d) += dateTime(transfer(d));

stock(TransferDetail d) += fromStock(transfer(d));

Так как это расходная операция, то количество берем с минусом, а в качестве склада подставляем склад отправителя.

Так как мы не можем один класс наследовать от другого дважды, то для того, чтобы провести по регистру повторно, создадим агрегированный объект нового класса TransferSkuLedger, который затем наследуем от SkuLedger:

Читайте так же:
Проблемы синхронизации почты на windows 10
CLASS TransferSkuLedger ‘Перемещение на склад (регистр)’ : SkuLedger;
transferSkuLedger = AGGR TransferSkuLedger WHERE stockTo(transfer(TransferDetail transferDetail));

stock(TransferSkuLedger d) += toStock(transfer(transferDetail(d)));

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

К слову, в 1С с этим есть определенные проблемы, так как строка документа может порождать только одну запись в регистре:

Также важным отличием является то, что вся логика задается декларативно, а не императивно на проведении документа. Это позволяет более эффективно обновлять регистр при изменениях в документе, не требует полного распроведения и проведения документов. Если изменилась только одна запись в документе, то обновления в регистре затронут только одну запись.

Регистр сведений

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

Объявление такого регистра абсолютно идентично логике регистра накоплений. Построим для примера регистр изменения цены поступления:

dateTime ‘Дата/время’ = ABSTRACT DATETIME (PriceLedger);

sku ‘SKU’ = ABSTRACT SKU (PriceLedger);
stock ‘Склад’ = ABSTRACT Stock (PriceLedger);

price ‘Цена’ (Stock st, Sku sk, DATETIME dt) =
GROUP LAST price(PriceLedger l)
ORDER dateTime(l), l
WHERE dateTime(l) <= dt
BY stock(l), sku(l);
INDEX stock(PriceLedger l), sku(l), dateTime(l), l;

В индекс и в порядок добавляется сам регистр, так как, в отличие от 1С, в lsFusion могут быть записи с одинаковым временем. В этом случае, в качестве дополнительного выражения будет использоваться внутренний код записи регистра.

Проведение по регистру сведений идет также, как и в регистре накоплений:

dateTime(ReceiptDetail d) += dateTime(receipt(d));

stock(ReceiptDetail d) += stock(receipt(d));

Заключение

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

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

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector