GeorgeaКоллеги, доброго времени суток!
Вы бы не занимались корсс-постингом.
Ответил тут http://forum.mazzy.ru/index.php?showtopic=10610

GeorgeaЕще конкретный вопрос по функциональности товаров, связанных с ОС; подскажите, пожалуйста.
Имеем ОС, связанные с номенклатурными номерами. При вводе их в эксплуатацию должен автоматически выполняться расход этой номенклатуры со склада. Вопрос: откуда система берет код склада, с которого нужно делать расход?????? По идее, номенклатура может покупаться на разные склады, а потом еще и перемещаться между ними (причем при перемещении инв. номер ОС, вроде, не указывается), поэтому четкий контроль пользователем склада списания выглядит непременным. Но склада вообще нигде нет в строках Журнала ОС. Есть инв. номера ОС, но непонятно, к номенклатуре какого склада они относятся...
Тут либо какая-то ваша доработка. Либо вы не очень разобрались.
Стандартный функционал позволяет:
1. закупить ОС. Тогда стандартная закупка приходует ОС через склад, указанный в этой же закупке. В этот момент ОС со склада сразу списывается и появляется на 08 счете. Далее ввод в эксплуатацию и амортизация выполняются в модуле ОС и складов не трогает.
2. собрать ОС из ТМЦ. В этом случае склад можно указать при сборке.

Но "расход при вводе в эксплуатацию" - это нестандартное поведение.

GeorgeaКасательно момента списания со склада, родное Руководство пользователя по ОС говорит:
ОСНОВНЫЕ СРЕДСТВА Руководство пользователя 3.3. Ввод в эксплуатацию
...
После разноски операции по вводу в эксплуатацию в системе происходят следующие изменения:
В Главной книге формируются проводки с типом Ввод в эксплуатацию .

Для номенклатурной единицы, соответствующей основному средству (если таковая имеется),
формируются проводки списания со склада.

ОС/НМА приобретает статус Эксплуатация .

То есть стандартно списываться со склада товар должен всё-таки в момент ввода связанного ОС в эксплуатацию. Но раз уж мы решили (вроде) от реализации спецодежды через ОС отказаться, то вопрос о складе списания теряет актуальность... слава богу :)
Опс... Проверил. Виноват, наврал.

В карточке ОС на закладке Покупка/Продажа есть информация о накладной, по которой купили.
В накладной есть строка с данным ОС.
Строка накладной по коду Лота связана со складской проводкой прихода.

Такое ощущение, что оттуда и берет.
Хотя может быть я снова неправ.

Я знаю, что плохо давать ссылки на другой форум.
Однако, попробуйте спросить на форуме http://axforum.info
Там есть гораздо более опытные специалисты по модулю ОС.

andr_andreyВ 4 русской Аксапте нет учета МБП и спецодежды?
почему?

andr_andrey mazzy andr_andreyВ 4 русской Аксапте нет учета МБП и спецодежды?
почему?
А зачем люди морочатся с втискиванием этого учета через ОС "...ради стандартного мат. ответственного лица и статуса (куплено, в экспл., списано)".?
Понятия не имею.

andr_andreyЯ не знаком со стандартной конфигурацией Аксапты для России, но думал, что у нее есть такой стандартный для всех "наших" систем функционал учета МБП и Спецодежды (с выдачей, МОЛ, срок полного износа, списание и т.п.)
Есть. В HRM.
Такой учет стандартен не только для "наших" систем и учета.

andr_andrey mazzy
Есть. В HRM.
Такой учет стандартен не только для "наших" систем и учета.
Спасибо, за разъяснение. Вот, что значит не приобретать HRM :)
Сразу "приобретать".
Я бы сказал по-другому: Вот, что значит не читать документацию

GeorgeaА нельзя ли чуть-чуть поподробнее об этом? Хотя бы ссылки на главы документации? Я скачал с сайта Майкрософт родные руководства по персоналу, пробежался по оглавлениям - ничего похожего не увидел...
Не помню точно. Вроде Заемные ТМЦ...

John 3Volta GeorgeaПоскольку в системе одна и та же номенклатура не может храниться на разных счетах - номенклатуру с/о придется дублироватьА это 100% ? Разве там не возможно хранение одной номенклатуры на разных складах по разным счетам?
А вот это правда - невозможно.
Очень грустная, но правда.
Эта фича лежит в основании Аксапты. Бла-бла-бла на тему почему именно так.
Так просто эта багофича не исправляется. Обсуждений было много как на форуме у Маззи, так и на аксфоруме.
даже в FAQ вошло http://forum.mazzy.ru/index.php?showtopic=1925

andr_andreyЖаль, что локализация Аксапты для СНГ не содержит штатно те вещи, которые приняты на законодательном уровне.
Я все удивляюсь: с чего вы это взяли?
С утверждения "Не буду утверждать применительно к Аксапте"?

TasmanianDevil mazzy John 3Volta[quot Georgea]Поскольку в системе одна и та же номенклатура не может храниться на разных счетах - номенклатуру с/о придется дублироватьА это 100% ? Разве там не возможно хранение одной номенклатуры на разных складах по разным счетам?
А вот это правда - невозможно.
Очень грустная, но правда.
Эта фича лежит в основании Аксапты. Бла-бла-бла на тему почему именно так.
Так просто эта багофича не исправляется. Обсуждений было много как на форуме у Маззи, так и на аксфоруме.
даже в FAQ вошло http://forum.mazzy.ru/index.php?showtopic=1925
Сергей, давайте назовем вещи своими именами, это не фича и не багофича - это банальная архитектурная недоработка, как впрочем и большая часть постинга операций в ГК в Аксапте, сделанное на "отвяжись".[/quote]
Почитай обсуждения :)
Эта фича сделана очень давно и все еще тянется для целей закрытия.

TasmanianDevilБолее-менее упорядочено и стандартизовано все, что постится на основе общего журнала (правда сам журнал загажен до неимоверности), а вот все остальное, сделанное через LedgerVoucher напрямую (движение номенклатур в том числе) - постится таким образом, как бог на душу положит, в зависимости от уровня фантазий разработчика. Это, собственно, и есть личное "бла-бла-бла" по этому поводу.[/quote]
Это точно. Потому что ничего не упорядочено и не стандартизовано.
Типы разносок - это устаревший механизм, пришедший с древних еще доконкордовских времен, когда система была только финансовой и раработчики надеялись сделать универсальный журнал.
Об этом тоже неоднократно говорилось.

Ты не первый, кто ожидает от механизма разносок "большой и чистой любви"

[quot TasmanianDevil]Модификация профилей разноски движения номенклатуры (разные счета по разным складам или другим разрезам складской аналитики) не так так уж и сложна(2 поля в InventPosting - уровень складской аналитики и ее код, модификация метода accountnum() в этой же таблице - доп. параметр с пустым значением кода складской аналитик по умолчанию и анализ этого параметра , в зависимости от которого либо будет исполняться стандартный метод поиска счета разноски, либо наш новый метод поиска), проблем с пересчетом/закрытием не будет, если нормально сделано заполнение протокола разноски номенклатуры (InventTransPosting) согласно этой модификации.[/quote]
Бли-и-и-ин... Началось.
Говорилось же уже раз двадцать.
Параметры ты поставишь, а что будешь делать в момент закрытия?
Я же в ФАКе не зря написал - если кто-то говорит, что сделал - проверьте как работает закрытие.

В общем, читай аксфорум.

[quot TasmanianDevil]
Проблемой будет , если будет нужна разная аналитика ГК в Дб/Кр при разноске движения номенклатуры, ибо :
1) Протокол разноски InventTransPosting хранит только одну общую для Дб/Кр аналитику
2) Семейство InventMovement тоже понятия не имеет о возможности ведения разной аналитики по Дб/Кр
Вот тут функционал Аксапты конкретно проседает. Модификация для такого случая возможна, но весьма обширна и затрагивает слишком много классов и таблиц.
Вот-вот. Сначала предлагают "не так уж и сложную модификацию", а потом думают.
Как и в случае с первоначальным вопросом.

TasmanianDevil
P.S. Не все так гладко в датском королевстве ...
Еще бы.
Это нормальная система, которая живет и развивается, в которой есть ограничения, есть баги, есть и работающий функционал.

Если так хочется убедится, что "не все гладко", то еще одна тема (вчерашняя)
http://axforum.info/forums/showthread.php?t=22651

andr_andrey mazzy andr_andreyЖаль, что локализация Аксапты для СНГ не содержит штатно те вещи, которые приняты на законодательном уровне.
Я все удивляюсь: с чего вы это взяли?
С утверждения "Не буду утверждать применительно к Аксапте"?

Изучаю документацию по Аксапте 4 Рус - интересная система. Сравниваю с тем, что мы имеем у себя сейчас.
Жаль мне становится, когда, вместо решения НАШИХ НЮАНСОВ по сопровождению договоров, производству, ремонтам, автотранспорту, поддержке рецептурных партий, учет брака и другому необходимому нам функционалу, на внедрении программисты тратят время, на стандартные (6 лет как минимум) бухгалтерские вопросы.
Я так понимаю, партнеры по Аксапте делают этот учет, так почему же не вынести это в стандартный функционал поставки локализации с описанием модулей и заказчику будет проще определиться, откуда ему знать, что учет спецодежды будет в модуле HRM.
Я тормоз. Я не понял суть. Понял только, что вы что-то предлагаете.

На всякий случай хочу напомнить, что я работаю всего-лишь в одном из партнеров Майкрософта и вряд ли смогу ответить за то, что делает майкрософт.

TasmanianDevile mazzy
Ты не первый, кто ожидает от механизма разносок "большой и чистой любви"

Дык пора бы уж :) Годов-то уже около 7-8 прошло, как систему выпустили на российские поля.
Пора вырастать из детских штанишек :)
А причем здесь российские поля?
Механизм разносок не развивается уже лет 10.
Я же говорю - это устаревший инструмент, пришедший из очень древних версий.
Насколько я понимаю, развивать его не планируют. Но для совместимости он остается.

TasmanianDevil
mazzy
Бли-и-и-ин... Началось.
Говорилось же уже раз двадцать.
Параметры ты поставишь, а что будешь делать в момент закрытия?
Я же в ФАКе не зря написал - если кто-то говорит, что сделал - проверьте как работает закрытие.

В общем, читай аксфорум.


Читал :)
А оно мне нужно там делать чего-либо в момент закрытия ;-) ?


почитай, например, fed
http://axforum.info/forums/showthread.php?t=17705
http://axforum.info/forums/showthread.php?t=20746
и другие его статьи.