[nysysimara]

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

[sava1]

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

[MATEVI]

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

[nysysimara]

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

а для чего сие действие?

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

[sava1]

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

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

[alex040269]

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

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

ВСЕ!!!

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

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

[nysysimara]

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

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

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

Сообщение отредактировал nysysimara - 20.09.12, 11:14

[mister-x]

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

[alex040269]

на другой - Бух.учет (забалансовый счет)

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

[nysysimara]

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

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

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

[Ardi]

(пока что вводим адресное хранение для склада готовой продукции)

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

Сообщение отредактировал Ardi - 20.09.12, 12:48

[nysysimara]

И приблизительно знаем где оно может лежать.

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

[sava1]

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

[Cthulhu]

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

[nysysimara]

строгую дисциплину ввода информации

это головная боль не моя, а руководства
задача мне поставлена: четкое определение места расположения ТМЦ+Партия

fuzzy-logic (нечеткая логика) - на справочниках с маркер-признаками наличия

я так понимаю - возможные места хранения?
это, на мой взгляд подходит для предприятий, занимающихся оптовой торговлей
мы - производственное предприятие и работаем по заказам, а не на склад
основной поток продукции минует склад как таковой

Сообщение отредактировал nysysimara - 24.09.12, 6:56

[Cthulhu]

это головная боль не моя, а руководства

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

Сообщение отредактировал Vofka - 25.09.12, 14:42

Причина редактирования: Не забываем про 1 пункт правил

[igmig65]

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

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

в бух учете продукция числится на двух МестахХранения, менять эту схему нельзя

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

это головная боль не моя, а руководства

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


Сообщение отредактировал igmig65 - 25.09.12, 14:53

[sava1]

а возможна такая ситуация, что 1 партия находится: 1 - не в 1 ячейке, 2 - не на 1 складе. Если да, то партии нужно распределять по ячейкам, а не ТМЦ, поэтому вариант спр.Ячейки - подчиненный ТМЦ неподходит...

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

[igmig65]

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

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

задача мне поставлена: четкое определение места расположения ТМЦ+Партия

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

еще один "нюанс": в бух учете продукция числится на двух МестахХранения

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

[nysysimara]

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

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

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

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

строгий ввод информации в БД на оси времени

важность этого мое начальство очччень хорошо понимает, объяснять не нужно

И если 1 единица ТМЦ числится на 2 складах(места хранения), то это в бухгалтерии фактически дублирование остатков, что в итоге влияет на баланс самой Бухгалтерии......Вообще ничего непонял....

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

Сообщение отредактировал nysysimara - 26.09.12, 9:08