1с движения по регистру бухгалтерии не записываются
Чуда не случилось, и как всегда старт новой платформы чреват наличием довольно грубых ошибок. Попробовал перевести базу на 8.3. В результате даже не очень глубоких тестов прямо сходу наткнулся на некорректную работу по перепроведению документов (без отмены проведения). Данный трабл наблюдается стабильно при просо перепроведении документа, без его модификации и при условии того, что по документу делается всего одна единственная проводка по регитсру бухгалтерии. Если модифицируется документ, либо по документу больше 1-й проводки такого поведения не словил (может просто не повезло). Исходные данные по документу:
Оперативное проведение: разрешить
Удаление движений: Удалять автоматически при отмене проведения
Запись движений при проведении: Записывать выбранные
Режим блокировок: Управляемый
Модуль обработки проведения:
Процедура ОбработкаПроведения(Отказ, Режим)
Ген=Новый ГенераторСлучайныхЧисел(0);
Сум=Ген.СлучайноеЧисло(10,10000);
Проводка=Движения.Хозрасчетный.Добавить();
Проводка.Период=Дата;
Проводка.Организация=Организация;
Проводка.Содержание="Приход готовой продукции";
При перепроведении корреспонденция остается одной и той-же, меняется только сумма проводки (для тестирования специально выхолостил весь алгоритм и сумму формирую случайным образом). На выходе из процедуры в отладчике и сумма проводки верная, и признак записи регистра бухгалтерии установлена. Но после выхода в проводках сумма остается неизменной.
Если в результате перепроведения изменится что либо кроме суммы - то эта ситуация отлавливается и все перезаписывается, но вот сумму игнорирует.
Более того, пробовал перепроводить с интерактивным изменением данных в документе - если что-то влияеет на набор записей кроме суммы - все срабатывает, если просто изменение не повлекшие изменения в данных (например сумму повтороно пробио то же самое значение в форме) - то фиг - проводки не переписываются, если же изменить какой-либо реквизит - то и тут засада, почти по всем документам проводки тогда перезаписываются (во всяком на выборочном десятке), но вот на последнем документе по времени в журнале - НЕТ. Я фигею, дальше только чисто по-русски. :)
(2) - не беда!? Если бы сумма только зависела от значения в документе - то и хрен с ней. Но если сумма расчитывается по неким алгоритмам (например по себестоимости списанных материалов и т.п.). В базе в данных сначала что-то не верно отразили, в результате найденной ошибки изменены данные, теперь нужно перепровести докменты, в которых это сказывается - запускаем обработку (а хоть даже руками) и потом поучаем что а собственно кривизна как была так и осталась, хоть пользователь себе и не помыслит что это не так!!Да и в принципе: как можно пользоваться системой, которая даже записи в базу делает не те, которые от нее требуют. Я не уверен что и по регистрам какой-нибудь аналогичной бодяги нет. Тупо смотреть на картинки на экране?! Нах такая система.
Видать хитрый случай с единственной проводкой проскользнул через юнит-тесты :)
(4) не сложилось как-то с диалогом 1С. Не знаю , может сейчас что изменилось, но раньше без предоставления данных о регистрации и прочей мути 1С даже не хотела слушать об ошибках. Я работаю на разных клиентов, и мало того что я за бесплатно тестирую ихние траблы, то мне теперь надо клиента поднять, а предоставьте ваши данные, на что мне в 90% случаев посылаю нафиг, ибо кому-то надо напрячься, перевернуть все свои мусорки во всех кабинетах в поисках регисртационных данных, то это у Мани, то это у Клавы. У меня уже выработался стойкое убеждение: А мне оно надо?.
(8) - Может и барахлит, только в журнале у меня ничего из алгоритмов ВООБЩЕ нет, просто вывод данных из регистра. И даже если это он, то мало утешений.(7) - одна проводка - далеко не хитрый случай. Изначально наткнулся на это из реальной ситуации: акт приходования выпущенной продукции. Не замораяиваю почему, но так уж случилось, что клиенту удобно приходовать единственную позицию, а не список продукции. Потому в документе и формируется 1 единственная проводка. Но даже при таблице, запросто может оказаться аналогичная ситуация
(9) Ну, 1С тоже можно понять. Им нужно как-то фильтровать вал обращений к разработчикам, который без оной фильтрации на 99% будет тупо спамом.
(13) Знаешь, сколько таких багонаходителей вчера открывших ломаную 1С будет всякой фигни слать? Кто будет эти авгиевы конюшни разгребать? Причем девочку с ресепшена не посадишь, надо спеца садить.
Другое дело, что подготовить хороший баг-репорт (особенно если проблема не простая) по которому разработчик сможет воспроизвести проблему - это тоже время/деньги. А мотивации практически нет. Ящитаю, за подтвержденные баг-репорты надо в самом деле как-то премировать.
(14) - ладно суть данной темы не в том общаться или не общаться с 1С и каким образом.
(8) проверил - барахлит не журнал, отчет показывает аналогичные цифры, и перезагрузка 1С не помогает, так что все 100% трабл в записи данных
(+14) если кто-то посчитает нужных сообщить об этом баге - 1С валяйте, претензий не имею :)
(16) - не перешел, а посмотрел на предмет перейти. А крепкая задница должна быть на любом релизе: покажите мне хоть один в котором нет каких-то траблов :)
(17) Думаю, кто-нить из партнеров сообщит. Подозреваю, что они с этого хоть какой-то профит имеют, пусть и нематериальный.
(21) Ну я озвучил трабл - сначала 2 дня кувыркался вокруг, думал я что-то накосячил. Потому и накроптал тестовое проведение, чтобы ну на все 100 быть кверенным что некие иные подводные камни не влияют. Единственное - не было времени с нуля создать пустую урезанную конфигурацию, и в ней попробовать (это что бы отмести возможный вариант конвертации базы 8.2). Хотя пробовал и в режиме 8.2. без каких-либо преобразований (теоретически) и в файловом и в серверном варианте - поведение стабильно одинаковое на моих данных (тобишь реальных данных версии 8.2). Если кто-то на пустой базе такое сварганит - и получит тот же результат, ну тогда на все 500 будет фиксированный баг
(21) Если бы кто-нить проверил - уже отписался бы.
(22) А если не подтвердится, то может оказаться еще хуже - значит требуется какая-то совокупность условий, которые еще надо устанавливать. Ну, или как легкий вариант, ты - лох :)
Какую-то мизерную вероятность оставляю, может изначальный трабл где-нибудь еще с 8.2 тянется из каких-нибудь служебных полей, хз. Пока нет времени до чистого эксперимента на пустой базе (текущую работу все-таки никто не отменял). Если у кого-то есть время и желание, может раньше проверит, если нет - чуть позже попробую сам (для очистки совести) :)
(0) проверил, на пустой базе, с один документов, план счетов, РБ все работает как надо, при каждом проведении меняется сумма
(28) - это уже интересно. Попробую уточнить: Удаление движений: Удалять автоматически при отмене проведения
и Запись движений при проведении: Записывать выбранные? Ибо естественно если поставить Удалять автоматически - то все будет ок (перед проведением ясный перец движения очищаются автоматически)
(30) +100. Я тоже попробовал бы, а то если блин еще железо влияете или роза ветров. - то блин. :)
(29) первый пункт - да
второй ( Запись движений при проведении: Записывать выбранные) не вижу где он.
(32) - там же в свойствах рядом (если открыт свойства документа)
(34) угу, нашел, палец разработчикам в глаз, по F2 не все свойства.
Bober, в твоей базе еще круче, с каждым перепроведением добавляется еще одна строка :)
5 раз перепровел не закрываюя форму - 5 проводок! :) И вроде с первого взгляда все нормально настроено. Единственное переключив в режим совместимости 8.2 и запуск обычного приложения - н о это не должно влиять на поведение
И вопрос в неоперативном проведении. Если перепровести оперативно - то одна проводка, если неоперативно - то проводка добавляется. Но по-моему это еще один косяк в платформе! или я уже как белка в колесе закрутился.
(35) - можно и вообще фламастером раскрасить :) не в обиду, речь не в том какие способы существуют для оформления проведения. Каждому случаю свои фишки. Но по методике той же 1С - для оптимизации, что бы не делать лишних движения и бла-бла-бла рекомендуется работать с набором движений документа, и т.д и т.п. В рамках этой идеологии и написан алгоритм проведения, и в рамках этой идеологии он и не работает!!
Блин - тут еще поведение проведения зависит от формы, в которой открыт документ: не меняя ничего в модуле проведения если открыть в обычном режиме и проводить - то при неоперативном проведении документа проводки плодятся. Если проводить документ в управляемом интерфейсе - то проводки делаются по одной и да таки с изменением данных. Правда формы генерируются автоматически. Кстати вот тут и есть кажется момент в разном поведении. И поэтому тестовая база от Bober ведет себя по-иному. Попробую выудить истину
В базе готовая ситуация для демонстрации трабла. Попробуйте кто-нибудь еще - может это только на моем железе.
Окончательные результаты теста: Для более детального рассмотрения немного изменил процедуру в проведении:
Перед началом записей очистка набора движения Хозрасчетный сознательно не делается (в 8.2 такой алгоритм работал без вопросов да и должен по логике).
1. Перепроведение из обычного интерфейса: проводки плодятся с количеством проведений (добавляются всякий раз независимо от оперативно или неоперативно проводится документ).
Перепроведение из управляемого интерфейса - в неоперативном режиме проводки поменются если их количество по сранению с предыдущим состоянием изменится, дальше перестают изменяться (триггерный эффект). Оперативно проводимый документ - делает правильные проводки.
2. Если в начале модуля поставить очистку набора (Движения.Хозрасчетный.Очистить();) то в обычном интерфейсе приходим к одинаковому поведению с управляемым - то бишь тогда проводки не плодятся.
Резюме: грубая ошибка платформы 8.3 (в таком режиме в ней работать нельзя).
Если я не прав - поправьте меня.
(база с эмуляцие ошибки в посте 43, можно переписать модуль на вариант приведенный здесь).
(45) не гони, все известно что снеговик сырой и глюченый.
(47) тебе человек привел все выклпдки, код и базы. Глюкалово. Вот так вот, и не надо нам тут про СП и прочие подставки для кофия, все что там написано не правда
(40) Это просто еще один для тестов. Что неправильно работает набор или набор в составе объекта вводе движений.
(45) - да в 8.2 аналогичное поведение (по поводу размножения проводок) - но. лично я отнесу это к ошибке, которая и в 8.2. сидит (ну хотите к недоработке). От того управляемый это интерфейс или обычный поведение не должно меняться. А так лажа. Пусть разработчик и будет меня уверять что это крутая фича. Это лично мое мнение.
Ну а претензия не к размножению проводок, а к тому что они не прерписываются. Кстати провел тест на 8.2 на этой же базе (благо в режиме совместимости можно без конвертации открывать в одной или другой платформе) - в 8.2 все нормально проводится и при еоперативном проведении.
(51) Не баг это. Попробуй создать конструктором движений движения в любом документе, при выбранном свойстве в корне конфигурации "Основной режим запуска" - "Обычное приложение". Конструктор сам напишет "Очистить()" перед формированием движений.
Надо просто понимать отличие поведения обычных форм и управляемых.
(52) И что управляемые блокировки только в модуле работают?
Там нужно просто объявить транзакцию
(53) - да хоть как назовите, но тогда где ж логика: для очистки нужно дать Движения.Хозрасчетный.Очистить(). Перед эти открываем в отладчике Движения.Хозрасчетный - он пустой (ведь это набор записей). И команда очистки применяется к этому набору - другой вопрос что в базе есть записи прошлого периода. Ладно - чего по этому поводу спорить - я ж говорю это мое личное мнение: это плохо. Так же как отсутствие контекстного поиска в управляемых формах (именно поиск а не отбор). Сколько бы не утверждали что отбор это лучше - извините мое личное мнение это разные вещи. Так же как и выделение строки одним фоном независимо от режима выделения (ячейки или строки). Разработчик это считает нормальным - но извините мое мнение иное. Так и по различного поведения в обычной форме и управляемой - тоже это мое мнение, в данном случае я не претендую на истину единственно допустиму.
(54). По этому поводу не стоит спорить - хотите пишите так. Долго докапываться до сути - но рекомендации 1С: при записи наборов движения документа следует использовать Движения.Записать(), а не Движения.Хозрасчетный.Записать(),Движения.Остатки.Записать() и т.п. , а тем более записывать наборы. Все упирается в конкуренцию блокировки данных (в общих словах). Тем более ничего не мешает передавать в процедуры конструкцию (Движения.Хозрасчетный и даже просто Движения)
в режиме обычного приложения не работает.
Создал привилегированный модуль. Но при попытке передать туда Объект, или КоллекциюДвижений - ошибка передачи мутабельного значения. Получается, что для того, что бы изменить движения документа в привилегированном режиме его нужно передать на сервер, а на сервер его передать нельзя, потому что он - мутабельное значение.
Решил сделать запись в регистр через Набор записей.
В модуле подписки очищаю движения документа:
Готовлю Структуру для передачи на сервер (в привилегированном модуль):
Потом очищаю набор записей ВзаиморасчетыСКонтрагентами
передаю структуру с параметрами в привилегированный модуль, там готовлю таблицу для записи в регистр и пытаюсь записать:
В результате движения как были штатными так и остались. Момогает только если до передачи на сервер очишаю коллекцию движенний по этому регистру, а после коллекцию перезаписываю
Тогда все работает. Но при "Источник.Движения.ВзаиморасчетыСКонтрагентами.Записать(Ложь)" пользователем не имеющим доступа к реквизиту (упр организации) - У пользователя недостаточно прав. Т.е с чего начал тем и закончил.
Короче выход только записывать данные в регистр на сервере в привилегированном модуле, а там движения не записываются. 6 утра уже.
Подскажите что я не так делаю?
Промучившись со штатным регистром, решил попробовать с нештатным:
копирую регистр Взаиморасчетов с контрагентами. Прав нет ни у кого. Никаких. Даже у "Пользователя" и даже на чтение.
В привилегированном модуле:
Вуайля. Из под роли бухгалтер все РАБОТАЕТ.
Очевидно, что дело скорее все дело в RLS: т.е. если у пользователя по одной из ролей наложен RLS на некое поле регистра, и в это поле от имени пользователя происходит попытка записи значения на которое право отсутствует, то даже при наличии привилегированного модуля права на запись не будет. А вот если RLS нет (даже при отсутствии доступа даже на чтение), тогда запись из привилегированного модуля работает.
Тогда попробовал добавить новую роль, и НЕ дать ей право на штатный регистр. Т.е ни прав, ни RLS. Пробую: не работает. Добавил право на чтение: вуайля.
Т.е выводы:
1 для проведения манипуляций связанных с записью в БД значений, на которые у пользователя наложен RLS-запрет, в кл-серверных базах необходимо, как правило, передать объект как параметр в привилегированный модуль. Даже при работе режиме обычного приложения, привилегированный модуль всегда серверный, и передача мутабельного значения не поддерживается. Те. каждый раз какие то грабли. При этом с файловым вариантом таких грабель судя по всему нет.
2 если при манипуляций объектами БД, связанных с записью этих объектов, у пользователя по одной из ролей наложен RLS-запрет на доступ к объекту, право на запись будет не доступна даже в из привилегированного модуля. При этом лечится это наличием роли у пользователя с правом Чтения без RLS.
3 если при манипуляций объектами БД, связанных с записью этих объектов, у пользователя НИ по одной из ролей не наложен RLS-запрет на доступ к объекту, право на запись будет доступна из привилегированного модуля даже в случае отсутствия права на чтение этого объекта.
[1C]
Движения.СтоимостьОСУпр.Записывать = Истина;
Движения.Управленческий.Записывать = Истина;
Пока Выборка.Следующий() Цикл
Д = Движения.СтоимостьОСУпр.Добавить();
ЗаполнитьЗначенияСвойств(Д, Выборка);
Д.Срок = 1;
Д.Стоимость = Выборка.Стоимость/Выборка.Срок;
Д.ВидДвижения = ВидДвиженияНакопления.Расход;
Д.Период = КонецМесяца(ПериодРегистрации);
УД.Период = КонецМесяца(ПериодРегистрации);
УД.ДатаЗаписи = УД.Период;
УД.Организация = Организация;
УД.СчетДт = Выборка.СчетЗатрат;
//УД.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконтоУправленческие.Подразделения] = Выборка.Подразделение;
////УД.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконтоУправленческие.ОсновныеСредства] = Выборка.ОС;
УД.СчетКт = Выборка.СчетАмортизации;
//УД.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконтоУправленческие.Подразделения] = Выборка.Подразделение;
//УД.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконтоУправленческие.ОсновныеСредства] = Выборка.ОС;
УД.Сумма = Д.Стоимость;
КонецЦикла;
А в регистр накопления движения попадают. В чем может быть проблема?
Похоже на правду. А как узнать, кто их может затирать?так ты в транзакции, наверно, выполнял это. Например, при записи или при проведении.
после записать() снимается истина у Записывать и движения в итоге затираются
Давайте разбираться.
Движения - это свойство объекта документа. Имеет тип: КоллекцияДвижений. Предоставляет доступ к коллекции наборов записей движений документа.
Состав наборов записей, входящих в эту коллекцию, определяется системой исходя из информации, хранящейся в конфигурации (список регистров на закладке "Движения" у документа как объекта конфигурации). Использование данного свойства облегчает работу разработчика, которому нужно создать или изменить наборы записей регистров, подчиненных данному документу. Формирование новых наборов записей можно выполнять как посредством свойства объекта документа "Движения", так и без использования этого свойства, работая непосредственно с набором записей.
В обработке проведения документа создаются движения по документу, то есть формируются наборы записей регистров, для которых данный документ является регистратором. У документа есть свойство "Запись движений при проведении", которое устанавливает поведение системы при создании движений во время проведения документа.
Может принимать два значения - Записывать выбранные (по умолчанию) и Записывать модифицированные.
Записывать выбранные: Перед началом проведения документ устанавливает всем наборам записей, участвующим в регистрации движений, свойство Записывать в Ложь. В этом случае после выхода из обработки проведения те наборы записей, у которых свойство Записывать имеет значение Истина, будут автоматически записаны платформой. После этого свойство Записывать у этих наборов движений будет установлено в значение Ложь.
Записывать модифицированные: Все наборы записей, участвующие в регистрации движений документа, имеют значение свойства Записывать установленным системой по умолчанию в Истина, то есть в случае значения Записывать модифицированные после выхода из обработки проведения все модифицированные наборы записей будут автоматически записаны платформой.
У коллекции Движения есть метод Записать(), который "Выполняет запись движений при проведении в единой последовательности, т.е. делает то же самое, что делает документ после окончания обработчика ОбработкаПроведения, включая снятие признака Записывать у наборов записей." Причем записывать система будет те наборы записей, у которых свойство Записывать имеет значение Истина. Этот метод можно использовать при работе с регистрами расчета, когда при проведении расчетных документов сначала записываются рабочие наборы записей, а затем эти наборы записей рассчитываются.
У набора записей тоже есть метод Записать(), который "Записывает в базу данных набор записей регистра накопления". Английский язык проще русского в грамматическом смысле, поэтому эквивалент у свойства Записывать и метода Записать() одинаковый - Write.
Свойство Записывать имеет смысл именно для коллекции движений документа, так как разработчик благодаря этому свойству имеет возможность управлять записью элементов коллекции движений, определять те наборы записей, которые следует записывать при проведении документа.
По своей структуре регистр бухгалтерии напоминает регистр накопления, поэтому в данной статье будут рассмотрены только те свойства, которые характерны только для регистра бухгалтерии.
Как правило регистр бухгалтерии всегда связан с планом счетов. План счетов указывается на закладке Основные. Один регистр бухгалтерии может быть связан только с одним планом счетов, в свою очередь план счетов может быть связан с несколькими регистрами бухгалтерии:
В одном регистре бухгалтерии хранятся данные по всем счетам бухгалтерского учета. Если сейчас добавить один ресурс Сумма, указать хотя бы один регистратор и сохранить конфигурацию базы данных, то в базе данных будет создана следующая таблица:
| Период | Регистратор | Номер строки | Активность | Счет | Вид движения | Сумма |
|---|
Колонка Счет добавляется автоматически, если была указана связь с планом счетов. В колонке Вид движения могут храниться два значения: Дебет или Кредит.
Можно сказать, что регистр бухгалтерии это регистр накопления, у которого есть предопределенное измерение Счет, а в поле Вид движения вместо Приход и Расход хранится Дебет и Кредит.
Если установить на закладке Основные флаг Корреспонденция:
То вместо колонок Счет и Вид движения будут созданы колонки СчетДт и СчетКт:
| Период | Регистратор | Номер строки | Активность | СчетДт | СчетКт | Сумма |
|---|
Так как в России применяется схема бухгалтерского учета с двумя корреспондирующими счетами, то как правило регистр бухгалтерии создается именно с флагом Корреспонденция. Также это позволяет анализировать обороты между счетами.
Также как и с регистрами накопления, каждое новое измерение, ресурс или реквизит регистра бухгалтерии добавляет в таблицу новую колонку.
Таблица итогов
Для каждого регистра бухгалтерии создается таблица итогов, в которой хранятся и остатки и обороты. Состав колонок таблицы следующий:
| Период | Счет | Сумма Остаток | Сумма Оборот | Сумма ОборотДт | Сумма ОборотКт |
|---|
Для примера добавим документ Приходная накладная со следующими реквизитами:
А также в обработке проведения добавим код для формирования движений по регистру бухгалтерии:
//устанавливаем признак записи в регистр бухгалтерии Движения . РегистрБухгалтерии 1 . Записывать = Истина; Движение = Движения . РегистрБухгалтерии 1 . Добавить ( ) ; Движение . СчетКт = ПланыСчетов . Хозрасчетный . РасчетыСПоставщиками ;Проведем один документ:
В результате в таблицу движений будет добавлена строка:
| Период | Регистратор | Номер строки | Активность | СчетДт | СчетКт | Сумма |
|---|---|---|---|---|---|---|
| 17.07.2021 | Приход №1 | 1 | Истина | 41.01 | 60 | 200 |
В таблице итогов появятся две строки для текущих итогов:
| Период | Счет | Сумма Остаток | Сумма Оборот | Сумма ОборотДт | Сумма ОборотКт |
|---|---|---|---|---|---|
| 01.11.3999 | 41.01 | 200 | 0 | 0 | 0 |
| 01.11.3999 | 60 | -200 | 0 | 0 | 0 |
Для текущих итогов хранятся только остатки. Остаток считается как оборот по дебету минус оборот по кредиту по всем записям регистра, независимо от вида счета (активный, пассивный или активный-пассивный).
Чтобы появились промежуточные итоги нужно установить период рассчитанных итогов в обработке Управление итогами. Установим 31.08.2021, чтобы были рассчитаны итоги для остатков на конец июля:
После этого в таблицу итогов будут добавлены еще четыре строки:
| Период | Счет | Сумма Остаток | Сумма Оборот | Сумма ОборотДт | Сумма ОборотКт |
|---|---|---|---|---|---|
| 01.07.2021 | 41.01 | 0 | 200 | 200 | 0 |
| 01.07.2021 | 60 | 0 | -200 | 0 | 200 |
| 01.08.2021 | 41.01 | 200 | 0 | 0 | 0 |
| 01.08.2021 | 60 | -200 | 0 | 0 | 0 |
| 01.11.3999 | 41.01 | 200 | 0 | 0 | 0 |
| 01.11.3999 | 60 | -200 | 0 | 0 | 0 |
Колонка Оборот считается как ОборотДт минус ОборотКт за один месяц.
В одной строке хранится оборот за месяц, а также начальный остаток на конец предыдущего месяца. Если сейчас провести еще одну приходную накладную в августе:
То в строку с периодом 01.08.2021, где раньше хранились только остатки будут добавлены обороты за август:
| Период | Счет | Остаток | Оборот | ОборотДт | ОборотКт |
|---|---|---|---|---|---|
| 01.07.2021 | 41.01 | 0 | 200 | 200 | 0 |
| 01.07.2021 | 60 | 0 | -200 | 0 | 200 |
| 01.08.2021 | 41.01 | 200 | 100 | 100 | 0 |
| 01.08.2021 | 60 | -200 | -100 | 0 | 100 |
| 01.11.3999 | 41.01 | 300 | 0 | 0 | 0 |
| 01.11.3999 | 60 | -300 | 0 | 0 | 0 |
Добавление нового измерения в регистр бухгалтерии автоматически добавляет новую колонку в таблицу итогов. Если добавить новый ресурс, то будет добавлено сразу четыре колонки:
- Ресурс остаток
- Ресурс оборот
- Ресурс оборот дебет
- Ресурс оборот кредит
Обороты между счетами
| Период | СчетДт | СчетКт | Сумма |
|---|
| Период | СчетДт | СчетКт | Сумма |
|---|---|---|---|
| 01.07.2021 | 41.01 | 60 | 200 |
| 01.08.2021 | 41.01 | 60 | 100 |
У регистров бухгалтерии без флага Корреспондеция такой таблицы нет.
Добавление нового измерения или ресурса в регистр бухгалтерии автоматически добавляет новую колонку в таблицу оборотов между счетами.
Признак Балансовый
В свойствах ресурса есть признак Балансовый:
По умолчанию данный флаг установлен и для ресурса добавляется одна колонка в таблицу, которая одновременно изменяет сумму и по дебету и по кредиту.
Если снять флаг Балансовый, то контроль двойной записи не будет выполняться:
Для регистра с поддержкой корреспонденции при снятом флаге Балансовый для одного ресурса в таблице движений будет создано два поля: для дебета и для кредита. Например, добавим в регистр ресурс Количество и снимем флаг Балансовый:
В таблицу движений будет добавлено сразу два поля: КоличествоДт и КоличествоКт.
| Период | Регистратор | Номер строки | Активность | СчетДт | СчетКт | Сумма | КоличествоДт | КоличествоКт |
|---|
Теперь можно записывать разное значение количества для счета дебета и счета кредита:
Читайте также: