Движения регистра НЕ датой документа это хорошо? #376714

Вот пытаюсь начать думать про 8-ку ;) прочитал что 8-ка умеет делать движения по регистрам любой датой, отличной от даты документа. возникло несколько вопросов 1. хорошо это или плохо? 2. как тогда определяется "позиция" записи в регистре? ногами не бить. в 8-ке я чайник

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

про регистр сведений всё понятно. я про регистр остатков спрашиваю

в этом случае, когда нужна "позиция" - период по регистратору делается

1. Иногда приходится. Обычно можно найти другие решения (но не всегда они устраивают) 2. Не вполне понятно. При формировании движения указываешь нужный период. А там: дата + регистратор (если правильно понял суть вопроса)

новое понятие "регистратор". поясните на пальцах пожалуйста

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

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

то что двигает регистр.

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

Более того, если не привязан тип документа к регистры накопления в качестве регистратора, то он не сможет делать движения по этому регистру. См закладку Регистраторы в свойствах РегистраНаколпения и закладку Движения в свойствах документа

а если купили? то чо тогда?

ну это отдельная песня :) в данном контексте не интересная :)

а тогда - жопа...

вся восьмерка - в ответе типа тогда нас не ипает...

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

если стоит контроль остатков то не даст продать, если кроме резерва не хватает (говорю про УТ)

и где будет ТА при перепроведении этого дока задним числом...

ё-маё... так клиент за товаром пришёл за отложенным

значит ему продашь

тут не требуется менять даты при проведении

цитирую: Масштабируемость разработки Архитектура системы была значительно переработана, чтобы обеспечить эффективную реализацию крупных многофункциональных прикладных решений. Введен механизм подсистем, позволяющий делить конфигурацию на отдельные прикладные задачи. Исключены объекты или свойства объектов, ограничивающие совмещение в одном прикладном решении совершенно различных по времени процессов, например, учета фактических движений денежных средств (прошлое) и планирования бюджетов (будущее). Например, больше нет единой точки актуальности, общих реквизитов документов, единого журнала операций и т.д.

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

1. это хорошо. 2. "позиция" записи определяется полем "период" ;)