хочу для типового документа "Перемещение" с признаком "Бух. учет" поставить "оперативный учет"
документов в базе туева туча
Кто делал что-то подобное? Поделитесь опытом:
это вообще реально? и какие возможные негативные последствия

в конфигураторе поставить птису Оперативный учет
а для чего сие действие?

А почему именно оперативный? Зачем в бухгалтерии оперативный? Подумайте о возможности учета на забалансовом счете.
Хотя конечно же стоит для начала знать какая именно задача стоит.

птицу поставила, но какая-то херня получается
при проведении выскакивает окно с сообщением "Существуют более ранние проведенные документы"

изобретаю "велосипед с треугольными колесами":
система складского учета с адресным хранением (ячейки)
пытаюсь сделать ее на регистрах параллельно бух.учету

Скоко измерений в регистре?

Если вкладываемся в количество субконто - действительно проще вести учет на забалансовом счете.
Зачем задействовать точку актуальности ?

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

ВСЕ!!!


нужно просто установить точку актуальности на док. правая мышь

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

теперь стою перед выбором:
на одной чаше весов - Оперативный учет (регистр по ячейкам)
на другой - Бух.учет (забалансовый счет)

дивлячись, що потрібно отримати в кінцевому результаті - відповідна чаша переважить

уже есть почти все необходимые отчеты

пока перевешивает чаша с регистром, потому как схема разработана, основные алгоритмы написаны, и самое основное - время поджимает
все доработанные документы имели признаки обоих учетов оперативного и бух, кроме "Перемещения"
но в перспективе нужно будет изменить еще ряд чисто бухгалтерских документов
(пока что вводим адресное хранение для склада готовой продукции)

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

В УТ и УТП 8 адресное хранение это просто возможные места хранения в справочнике ТМЦ. Легко и просто. И приблизительно знаем где оно может лежать.

приблизительно не подходит
надо точно
еще один "нюанс": в бух учете продукция числится на двух МестахХранения, менять эту схему нельзя на ней многое завязано
территориально, т.е. физически складов с готовой продукцией сейчас 2+на территории предприятия, что тоже можно считать складом
так, что если вводить забалансовый счет, нужно вводить новый вид субконто, подобие местуХранения (закодированная ячейка, связанная с МестомХранения)

справочник Ячейки нужно делать подчиненным Складам

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

это головная боль не моя, а руководства
задача мне поставлена: четкое определение места расположения ТМЦ+Партия
я так понимаю - возможные места хранения?
это, на мой взгляд подходит для предприятий, занимающихся оптовой торговлей
мы - производственное предприятие и работаем по заказам, а не на склад
основной поток продукции минует склад как таковой

смотреть вперед не вредно. и просчитывать ситуации. находя оптимальные способы решения проблем.
как только по-ячеечные остатки станут (накопительно!) неактуальными, или кто-то что-то не так введет, так, что "задним числом" откорректировать будет невозможно (период закрыт) - тут же встанет вопрос именно к Вам как к к разработчику - "и что теперь делать то? и как?"
проверено.

+++
а возможна такая ситуация, что 1 партия находится: 1 - не в 1 ячейке, 2 - не на 1 складе. Если да, то партии нужно распределять по ячейкам, а не ТМЦ, поэтому вариант спр.Ячейки - подчиненный ТМЦ неподходит...
А не вариант построить структуру спр.Места хранения, тоесть сделать склады - группами, а ячейки элементами. Тогда вы получите по каждому ТМЦ/партии - МестоХранения(Элемент) - ячейка, МестоХранения.Родитель - Склад.
Соответственно, вы узнаете в каких ячейках и на каком складе находится и партия и ТМЦ.


Это вы имеете ввиду 2 склада - склад и ячейка?
Странно..и чтоже, оба склада на балансе?


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

Учет складской - на кой там партии?
Два и больше места хранения - териториально разнесенные склады (при чем тут баланс?)
Справочник Ячейки подчинять МестамХранения по причине разных складов - один и тот-же товар на разных складах может лежать в разных ячейках (полки,палеты и т.д.)

на первый вопрос ответ:

По поводу баланса:

в бухучете это подразумевается на материальных счетах, тоесть 20,26,27,28 и тд. где есть аналитика по складам. И если 1 единица ТМЦ числится на 2 складах(места хранения), то это в бухгалтерии фактически дублирование остатков, что в итоге влияет на баланс самой Бухгалтерии...И вообще нафига это нужно было, и как это реализовано, во всех материальных документах добавлен еще 1 склад?...Вообще ничего непонял....
Ну и ячейки делать подчиненным МХ...Можно конечно. Хотя мне кажется просто структуру МХ правильно изначально несделали, теперь возможно переделать неполучится. Хотя это если нехотеть переделывать.

вводя ячеечный учет на регистре, я бух.итоги не затрагиваю
приход/расход в регистр и бух.операция выполняются одновременно одним документом,
т.е для всех документов, которые приходуют на склад, введен реквизит ячейка обязательный к заполнению,
а для документов, списывающих со склада, этот реквизит заполняется автоматически, по остаткам регистра и перезаполняется при проведении
+ документ для перемещений внутри склада между ячейками(только по регистру), с функцией расположения остатков склада по ячейкам(временно пока есть нераспределенные ТМЦ)
остатки склада по бух.учету всегда актуальны, инвентаризация на складе проводится ежеквартально, а для корректировки остатков регистра у меня есть механизм, с этим проблем не будет
остатки регистра по результатам инвентаризации можно привести в соответствие с бух.итогами

не вариант, пару лет назад мой коллега реализовывал подобную схему - не взлетело, и месяца не проработало, всех корявостей не помню, знаю что было категорически отвергнуто бухами, по той причине, что разлезлось списание партий (у нас FIFO), и сплошные неудобства у кладовщиков
важность этого мое начальство очччень хорошо понимает, объяснять не нужно
похоже я невнятно описала ситуацию с двумя складами
попробую еще раз:
сейчас ячеечный учет мы налаживаем для Склада готовой продукции (ГП)
изначально это было одно помещение, но 2 МестаХранения на материальных счетах, никакого дублирования остатков, одно ТМЦ+Партия только на одном МестеХранения
сейчас склад ГП - это территориально 3 помещения
в идеале (и мы к этому придем) должно ПомещениеСклада=МестоХранения
пока я решила эту проблему, с расчетом на переход в будущем к однозначному соответствию помещения склада и места хранения
с остальными складами(материалов, запчастей и пр.) такой проблемы не будет

Для падения базы с диагнозом "незакрытый регистр" - слабое утешение.

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

Уфф... я лучше пойду отсюда, а то сам себе уже стал напоминать склочного критикана...

вы прям такую жуть описываете
"незакрытый регистр" - это отрицательные остатки?, если да, то не вижу причины для падения базы, есть механизмы это исправить
в решаемой мною задаче ТМЦ+Партия может хранится только в одной ячейке, а в ячейке может быть несколько ТМЦ
в регисте учет только количественный, сумм нет
По расходу: кладовщик пользуется данными из непроведенного документа. Если по документу остатки ТМЦ в ячейке N, а он их там не находит - это его же косяки при распределении по ячейкам прихода на склад
перезаполнение при проведении - перестраховка на тот случай, если произошли изменения остатков регистра в прошлом(по-большому счету дутье на воду)
в большинстве случаев отгрузка идет с площадок(их 5 штук, соответственно 5 ячеек)
но есть продукция, которая лежит по-дольше и хранится на стеллажах в ячейках, вот тут и нужно в "задании кладовщику"(печатная форма документа на отгрузку) указать ячейку,с которой нужно взять товар
если автоматически создавать такой документ при проведении родительского, то на мой взгляд геморойней, чем делать все эти действия в одном доке,
а создание вручную кладовщиком - им двойная работа и возможные "забыли, пропустили"
- ? Я и решаю эту задачу доп.регистром
идея о дополнительном документе у меня была - о подчиненном
не подчиненный, отдельный от основного учета документ распределения по ячейкам - НЕТ категорическое (двойная работа кладовщика, разница на оси времени у движений в основном учете и ячеечном)

Cthulhu, соглашусь с вами в том, что методология решения корявенькая, в свое оправдание: времени в обрез, нет ТЗ, или нормальной устной постановки задачи
надеюсь довести все до ума в процессе внедрения

P.S. Модераторам: тема уже далеко ушла от своего названия, может стоит выделить последние посты в отдельную тему типа "Как автоматизировать складской учет с адресным хранением"

Судя повыше сказанному Вами выше, Хранение на 2 местах - это: 1 - Остаток на складе ГП, 2 - остаток на сладе 1(из 3, входящих в склад ГП), а ячейка, это часть в любом из этих 3 складов. Тоесть ячейка - это минимальная на данный момент у вас точка хранения, что в конфигурации легко задается элементом справочника. Склад 1, состоящий из ячеек - легко в 7 улаживается в Группу элементов (ячеек), в свою очередь Склад ГП, тоже группа, состоит из 3 групп - 3 территориально разные единицы. Тоесть логика, ту что я показал Группа - элемент вполне улаживается в вашу задачу. И все будет ОК.
А вот чтоб сделать так, чтобы это удовлетворило ваших кладовщиков, и как это все перестроить это уже другой вопрос. Понятно что хочется списывать например 1 ТМЦ с 1 склада(группа) и автоматически получать остатки по ячейкам этого склада по ФИФО. Но это же другая задача, которые вы нехотите решать, а лезете еще в большее болото..

имхо, мое мнение..