GeorgeaДоброго времени суток, господа!

Подскажите, плиз...

Не можем найти в ОЕБСе, как счет за транспортные расходы (отдельный счет, а не строку внутри счета за товары) привязать к осуществленным поставкам. Такое есть вообще в системе?

Это нам хочется для нормального учета ТЗР покупки, привязывания их к конкретным поставкам и соответствующего протягивания себестоимости.
Если такой возможности всё-таки нет - то какие обычно практикуются в ОЕБСе подходы для учета ТРЗ, выставляемых отдельным счетом?

Буду очень благодарен за подсказку.

Есть такая возможность. Можно завести счет-фаткуру в Кредиторах и согласовать не с типом позиция, а с типом фрахт. Причем согласовать со счетом, к которому ТЗР относятся. После чего в Кост менеджменте запускается программа, которая данный ТЗР распределяет на те затраты куда были списаны ТМЦ пришедшие по основной счет-фактуре.

Но сразу скажу на моей памяти от данной функциональности отказывались и писали кастомизацию на распределению ТЗР в конце периода.

Georgea Тогда прошу пояснить, какие в этой функциональности такие подводные камни, что " на моей памяти от данной функциональности отказывались и писали кастомизацию на распределению "?? Если это можно кратко изложить, конечно. То есть стоит ли за эту функциональность браться вообще? Заказчик ориентировочно предпочел бы именно прямую привязку ТЗР к поставкам.

(понимаю, что не очень умный вопрос. Но, может, что-нибудь сможете посоветовать...)

Одну из причин указал коллега va_kochnev. Но есть и другая причина, по которой отказывались использовать данный механизм (или отказывались его дорабатывать).
И внедряя на других системах, где подобные механизмы работали неплохо, все равно отказывались от их использования по организационным причинам.
Дело в том, что если предприятие или организация очень большая, то ввод первичной документации в систему занимаются те отделы (департаменты) которые отвечают за ведение определенных договоров и закупок. И чем крупнее объект автоматизации, тем больше таких точек ввода. В результате увеличивается большая вероятность ошибок по неточному распределению ТЗР на уровне оперативного учета, т.е. на местах. В то же время бухгалтер должен проверить все эти распределения перед отработкой в бухгалтерском учете (трудоемкость увеличивается в разы).
Есть такое правило, что себестоимость управленческого учета не должна превышать сумму сэкономленных затрат от его применения. В результате вставала дилемма, что трудоемкость, а значит, себестоимость не соответствовала тому результату, который был на выходе (т.е. более точная сумма затрат по МВЗ и продукту куда ушли ТМЦ). Тем, более что при применении схемы списания как средняя цена по предприятию (не везде она применяется), такие потуги становились бесполезными.
В результате применялась более простая схема.
1. Регистрируется счет-фактура на ТЗР
2. Обрабатывается на 16 счет проводками Дт 16 Кт60, Дт 19 Кт60.
3. В конце месяца производится распределение Дт 16 в кредит затратных счетов пропорционально списанию с материальных счетов (Например: 10) за исключением внутренних оборотов.
Примечание: Но тут нужно определиться, как будут собираться затраты по 16 счету.

Как сделать это в OEBS? Особенно если субсчетов 10 счета несколько?
Есть тут свое ИМХО….
1. В механизме костинга есть возможность вести учет ТМЦ на разных субсчетах 10 счета привязываясь к категории. Если применяем схему, что ТЗР будет вестись пропорционально 10 субсчетам, то заводим в системе аналогичное количество (с аналогичными названиями) 16 счета по учету ТЗР.
2. Далее заводим перечень позиций по услугам (ТЗР) как минимум равных субсчетам 16 счета, на эти позиции назначаем необходимые категории.
3. Берем специалиста по Workflow (если не 12 версия) который рисует дополнительное правило обработки счета-фактуры (тут нужно быть осторожным и специалист должен знать, что делать). Правило примерно следующее, система видит позицию, видит нужную категорию, ставит нужный 16 счет из счетов категорий.
4. В результате мы заводим поступление на услугу (Дт15 Кт60), потом заводим счет-фактуру и согласовываем с потеплением (Дт 16 Кт15). Получаем сумму на 16 счете по нужному субсчету.
5. Распределять 16 счет необходимо в конце периода пропорционально соответствующему 10 счету за исключением внутренних оборотов. Например: 1601, пропорционально списанию с 1001. Как выявить внутренние обороты? В настройки счетов есть 5 квалификаторов соответствующих разделам баланса GAAP. Нужно проанализировать на какие счета возможны списания в 10 счетов. Представим, что списания возможны только на затратные счета, значит, те счета, которые имеют признак – expense. То есть программа должна просматривать для расчета оборот Кт 10 Дт 20,23,25,26,29,91 и т.д.
6. Можно конечно для распределения 16 счетов было использовать в GL механизм авторазмещений (фактически распределение средств по счетам). НО! Но каким механизмом вычислить именно сумму оборота без внутренних перемещений? Вот тут придется писать программу.

ЗЫ. Вести затраты на 16 в OEBS в разрезе номенклатуры проблематично. Можно извернуться но очень дорого будет стоить.

Georgea Удачи нам :)

Желаю удачи вам во внедрении! Как понимаю у вас новый проект OEBS? Я только знаю сейчас 3 новых проекта ).

GeorgeaТочек ввода у нас немного, и вообще сторонние перевозчики привлекаются редко. Так что прямой учет ТЗР должен нормально пойти.

С теми ТЗР которые идут в одном счет - фактуре с ТМЦ так же могут возникнуть проблемы. Как их собираетесь относить на стоимость ТМЦ?
Еще у вас может возникнуть такая ситуация как неотфактуровка и отклонения по неотфактуровке. Обычно такие отклонения так - же относятся на 16 счет, а потом распределяются по аналогии.

Georgea Со спецами по Workflow у нас, боюсь, всё не очень хорошо. Спасибо за описание схмы сбора ТЗР на 16-м, но ориентироваться на реализацию напрямую. Удачи нам :)

Workflow - дело нужное. Особенно в 11 версии. Чуть, что берите на аутсорс если будут проблемы. Слышал я кое-где было несколько спецов и компетенции в данной области.

Leonid Kudryavtsev
Описанную задачу (настройка счетов при костинге) - вполне можно сделать и без Workflow. В документации костинге описан пакет который за это отвечает. Т.ч. сойдет и обычный программист на PL/SQL даже "средней" компетенции (кода на 10-25 строчек), разумеется при наличии грамотного консультанта.

Там нужно учесть, что генерация счетов по Дт инвойса затрагивает другие процессы WF. Например: процесс генерации бюджетного счета в Закупках при поступлении. Прежде, чем менять механизм нужно, выявить взаимосвязи, которые могут повлиять в других процессах. Хотя Оракл позиционирует генератор счетов как гибкий механизм.