Галактика в вопросах и ответах

Добрый день.
Собрались начать наоговый учет ОС, да вот не задача по 1 группе ОС (разговор идет об украинских условиях) сумма ремонтов за квартал (учет поквартальный) разбрасываается пропорционально между всеми объектами этой группы. Сейчас учет ведется в экселе. В 5.84 вижу, что сие можно реализовть только изменяя стоимость в каждой карточке отдельно, предварительно сделав расчет в экселе. Когда таких карточек несколько сотен - переходить на него совсем не хочется. Поделитесь опытом: как на всю группу разбросать всю стоимость сумы ремонтов пропорционально. Спасибо.

Что значит "сумма ремонтов за квартал (учет поквартальный) разбрасываается пропорционально между всеми объектами этой группы"?
Можно поточнее описать:
а) смысл этой операции
б) действия оператора (ручные - будем считать, что ничего автоматом не делается).
Что изменяется (какая величина) в результате этой операции? и в какую сторону?

Добрый день.
Деинис: в соответсвие с украинским законодательством сумма выполненных ремонтов за квартал разбрасывается пообъектно и пропорционально между всеми объектами 1 групы. По остальным группам - групповой учет. Учет поквартальный. Например: за квартал было выполено ремонтов на 1600000, объектов около 800 штук в 1 группе (карточек ОС). Вот эту сумму и надо распределить пропорционально стоимости между всеми объектами и соответственно на нее возрастает стоимость ОС и потом износ.Сейчас в экселе считается.

Я понимаю так:
У нас есть 2 объекта 1-ой группы:
ОС №1 ст-ть 100 руб. износ 84 руб.
ОС №2 ст-ть 200 руб. износ 111 руб.
и еще 10 объектов других групп.
В конце квартала бухгалтер, собрав сумму по ремонтам (20 руб.) в модуле ОС делает операции изменения стоимости от последней даты квартала.
В итоге мы имеем на 1-е число следующего квартала
ОС №1 ст-ть 105 руб. износ 89 руб.
ОС №2 ст-ть 215 руб. износ 126 руб.
и еще 10 объектов других групп, по которым ни стоимость ни износ не менялся.
Так? Или не та?

Добрый день.
Деинис: да, ты прав. теоретически так.

Тогда схема может быть такой:
1. В конце каждого месяца бухгалтер делает операцию увеличения стоимости (одну на все ОС), куда включает все ОС из 1-ой группы. Затем запускает ТХО, 1-ый шаблон которой есть, например, &VIP[Obj:"TXO_DeltaOS"]:
1. Запрашивает у бухгалтера сумму ремонтов (или вытаскивает ее сами из БД, если известно что откуда тянуть).
2. Распределяет сумму по позициям спецификации ОС.
3. Модифицирует спецификацию операции "Изменение стоимости", проставляя по каждому ОС распределенную на это ОС сумму.
Последующие шаблоны ТХО отрабатывают стандартным образом.

Я думаю, что проблему локализации Системы под украинское законодательство нужно ставить перед укаинским же предстваительством корпорации. Скорее всего-это уже сделано.
Нигде не нашел алгоримтма &VIP[Obj:"TXO_DeltaOS"] в стандартной поставке со всеми патчами, может быть - это оно и есть. Если нет, то написать фэйс, который берет сумму ремонотов и распределяет ее пропорционально стоимости прямо в спецификациях операции "Изменение стоимости" большого труда не составит(просто пробежаться в цикле по двум таблицам, есть сумма по операции, стоимость, сумма ремонтов, дальше-математика).
Откуда брать сумму ремонтов:
- вводить руками в интерфейсе выбора операций "Изменение стоимости", который и будет все делать
- ввести в спецификацию операции для какой-то специально помеченной карточки(например первой в операции или у которой завод изготовитель определенный)
- если бухучет поставлен полностью, то в интерфейсе можно и ПАТ-формулу рассчитать
В принципе, это дело можно зашить и в ТХО API, однако тут придется реализовать дополнительные функции и анализировать несколько дополнительных факторов, а это уже отдельная песня и песня про войну

&VIP[Obj:"TXO_DeltaOS"] - название я взял из головы. Это собственно и есть предложение "зашить в ТХО API". Самая большая сложность для бухгалтера, как я понимаю - это ваять изменение стоимости по 100 шт. ИК ОС. Можно организовать в ТХО API ввод общей суммы с клавиатуры, а затем распределение этой суммы по спецификации операции.

Можно сделать и API, но тут нужно учитывать проведение изменений в спецификации картотеки, понимать принцип циклической обработки(в ТХО в этом случае будет минимум 2 шаблона для стоимости и износа с циклическими алгоритмами), в любом случае-взять на себя часть функций Системы,что нежелательно. А интерфейс, в котором выбирается созданная уже операция "Изменения стоимости", рассчитывается ПАТ сумма ремонтов и изменяется только операция берет на себя только функции пользователя, так как формирование проводок и модификация картотеки проводяться в этом случае стандартными средствами.

Включаешь журнализацию и изучаешь последовательность изменений. Там модифицируется 2 поля в таблице SpMoveOS и такие же одноименные поля в таблице SpMove (NewStoim и NewSumIzn). Еще должен меняться SoprHoz (сумма).

>> в любом случае-взять на себя часть функций Системы,что нежелательно
Andrey в самом первом сообщение написал: "Когда таких карточек несколько сотен ..."
Именно от монотонных ручных действий хочется освободить пользователя. Собственно тема именно ОБ ЭТОМ. Пожалуй, эту часть функций системы взять на себя можно. А рассчитывается ли сумма ремонтов PAT-формулами или вводится с клавиатуры - это может быть и не принципиально.
Кстати, если ты не предлагаешь освободить пользователя от монотонного изменения по каждой карточке (от чего и уходит Andrey), то что именно означает фраза:
>> изменяется только операция

Мы об одном и том же говорим, интерфейс, который предлагается и освобождает пользователя от этих действий, он и изменяет все перчисленные поля, кстати там еще завязка на методы учета идет в SpMoveOS, и берет на себя действия пользователя по расстановке сумм. Я предлагаю не делать тут Api по причине того, что в процессе привязки ТХО по ОС выполняется еще и корректировка картотеки, также в ТХО будут однозначно и другие шаблоны проводок с циклическими обработками. Поэтому шаги такие(с самого начала я это имел ввиду)
1. Формирование операции "Изменение стоимости"
2. Запуск интерфейса, который все и распределит, изменив спецификацию операции(перечисленные тобой поля).
3. Привязка ТХО со стандартными алгоритмами.

Да, действительно мы говорим об одном и том же.
Но как же тогда будет пользователь запускать интерфейс? В принципе, можно положить ему локально ресурс с фиксированным именем и он будет запускать его через меню "Запуск внешнего интерфейса". Это не вполне удобно.
Можно также предложить сделать 2 ТХО API:
1. Для модификации спецификации операций. Чтобы изменения не вносились в карточки - нужно исправить дату операции на более позднюю. Скажем на 2100 год.
2. Запускается после отработки 1-ой ТХО. Обычная ТХО по разноске сумм.
Однако такой вариант опасен тем, что пользователь может забыть изменить дату операции перед запуском 1-ой ТХО, или забыть какой ТХО в какой очередности пользоваться...
Вероятно остается все же 1-ый вариант (с созданием отдельного фейса).

Ну, можно запуск фейса включить в какой-либо отчет ;D