Вопрос по Проектам

[PSA]

Всем добрый день!

Вопрос знатокам модуля Проект. Вопрос скорее идеологический, чем технический.

В Аксапте, как я понимаю, реализована следующая схема создания проекта:

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

При этом в документации написано, что все проекты обязаны ссылаться на счета по проектам и «счета по проектам содержат информацию о создании накладной; например, информация относительно расчетов с клиентами, адреса и условий оплаты».

Соответственно возникает вопрос: зачем введена такая хитрая система создания проектов и что за особый зверь такой «Счет по проекту» что его выделяют в отдельную сущность. И почему нельзя эту самую информацию «относительно расчетов с клиентами, адреса и условий оплаты» регистрировать на самом проекте?

Я вижу только один логичный ответ, что в модуле Проект введены два объекта:

1) Техническая сторона договора (тот самый Счет по проекту) содержащая информацию о клиенте по договору, условиях оплаты по договору, валюте договора.
2) Собственно реализация договора (проект) в части регистрации планируемых и фактических расходов и доходов по проекту.

С этой точки зрения становится понятно, почему подпроект может быть привязан к счету отличному от счета родительского проекта. Это нужно например когда по договору возникло доп.соглашение. Тогда доп.соглашение может быть зарегистрировано в Аксапте как новый счет по проектам. А исполнение доп.соглашения заведено в Аксапте как подпроект проекта по основному договору.

Вопрос: я правильно понял смысл необходимости Счета по проекту, или есть какой-то более глубокий смысл?

[Gad]

Ну в принципе никакого противоречия в логике не видно. Кроме выше сказанного, могу добавить,что здесь реализована функциональность "двух клиентов" почти как в заказах\закупках. То есть, если Вы в Счете по проекту выбрать Клиента, затем выбрать этот Счет по проекту в Проекте, то Клиент из Счета по проекту подтянется в Проект. При этом в проекте Вы можете его изменить. При создании заказа из-под проекта в поле Клиент заказа подставится Клиент из проекта, а в поле Счет на заказа Клиент из Счета по проекту того проекта, на основе которого делается заказ. Таким образом, связка Проект-Счет по проекту может служить, помимо прочего, неким шаблоном для ввода заказов у которых Клиент != Счет на.

[glibs]

Цитата:

Сообщение от PSA

...
я правильно понял смысл необходимости Счета по проекту, или есть какой-то более глубокий смысл?
...

Насколько я припоминаю, основная идея invoice project заключается в том, чтобы группировать счета для одного клиента.

Поясню на примере. Предположим, мы работаем с клиентом. Для него делаем несколько проектов или несколько подпроктов. Предположим, мы хотим выставлять клиенту консолидированные счета по нескольким подпроектам (один счет по всем работам по всем подпроектам). Вроде, сделать не сложно.

Теперь усложняем постановку задачи. Предположим, есть подпроекты А, Б, В, Г, Д, Е, Ж. Предположим, что все работы по подпроектам А, Б, В мы хотим инвойсить (вписывать все работы по этим подпроектам за месяц) в одном счете, по подпроектам Г, Д — в другом, а по Е, Ж — в третьем. Можно ли такого эффекта достичь без invoice project? Очевидно, что можно. Но вручную, и можно ошибиться. Invoice project обеспечивает включение работ по проекту по одному и тому же клиенту в различные счета (причем эффект "различные счета" достигается автоматически).

Резюме. С т.з. "нашего" менталитета получается, что invoice project — это не что иное как... договор.

PS. Как-то я об этом раньше даже не задумывался. Спасибо, что натолкнули на интересную идею.

[PSA]

Ответ на вопрос получил. Спасибо

[PSA]

Но возник еще вопрос:

Ветка: Вопросы по модулю Проекты в Ах30

Обсуждались ряд вопросов по модулю Проекты, но вопрос №4:

4. Для чего нужны промежуточные накладные в проектах Время и затраты. Т.к. в проектах с фиксированной ценой сумма промежуточных накладных за период является суммой проекта, то смысл их в проектах время и затраты не совсем понятен.

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

[glibs]

А чего тут непонятного? Это авансовые платежи. На сумму on-account уменьшается сумма последующего счета по проекту.

[PSA]

Цитата:

Сообщение от glibs

А чего тут непонятного? Это авансовые платежи. На сумму on-account уменьшается сумма последующего счета по проекту.

И действительно если промежуточные накладные рассматривать как авансовые платежи, то все сходится

И становятся понятны такие навороты как:

1) в проектах типа "Фиксированная цена" просто вводятся проводки по промежуточной накладной и все
2) в проектах типа "Время и расходы" кроме основных проводок надо ввести еще и корреспондирующие проводки на ту же сумму но с минусом

А на самом деле просто в проектах типа "Фиксированная цена" нет проводок по реализации и соответственно не выставляется накладная по реализации, а выставляются промежуточные счета. А в проектах типа "Время и расходы" сумму выставляемой накладной нужно уменьшать на сумму предыдущих авансовых платежей дабы не было дублирования. Это уменьшение и достигается за счет корреспондирующих проводок с минусом, если конечно при формировании предложения по накладной включить галку "Промежуточная накладная"

Спасибо

[PSA]

glibs, можно задать еще пару вопросов:

1) Опять же возвращаясь к ветке Вопросы по модулю Проекты в Ах30

там был вопрос:

2. Периодические операции Разноска издержек и Разноска выручки.
Для чего применяются, что происходит в системе?
Не совсем понятно.

И действительно не совсем понятно

2) В форме "Свойство проводки" есть две галки:

- Накладная
- Может быть начислено

Если не стоит галка "Накладная", то сумма реализации по проводке с таким свойством проводки не будет включено в предложение по накладной. С этим все понятно.
Если не стоит галка "Может быть начислено", то сумма реализации по проводке с таким свойством проводки не будет включено в общую сумму реализации и например не отразится в Статистике в потенциальных доходах. Технически понятно, но в каком случае это может быть полезно и зачем это нужно?

[karina]

"там был вопрос:

2. Периодические операции Разноска издержек и Разноска выручки.
Для чего применяются, что происходит в системе?
Не совсем понятно.

И действительно не совсем понятно "

Попробую ответить с примером. Например, Функция "Разноска издержек" используется для внутренних проектов.
В течении проекта все затраты по внутреннему проекту аккумулируются на счёте "Затраты".(Указаном в настройке, например 08.100, вложения во Внеоборотные активы). После окончания проекта все затраты, должны быть перенесены на счёт "Амортизация" 08.200. Для этого в настройках разноски для типа "НЗП-стоимость" указан счёт "Амортизация".
С помощью кнопки функции "Разноска издержек" система позволяет накопленные издержек с одного счёта "Затраты" перенести на другой счёт ГК, указанный в настройках разноски.

[Starling]

Цитата:

Сообщение от PSA

2) В форме "Свойство проводки" есть две галки:

- Накладная
- Может быть начислено

Если не стоит галка "Накладная", то сумма реализации по проводке с таким свойством проводки не будет включено в предложение по накладной. С этим все понятно.
Если не стоит галка "Может быть начислено", то сумма реализации по проводке с таким свойством проводки не будет включено в общую сумму реализации и например не отразится в Статистике в потенциальных доходах. Технически понятно, но в каком случае это может быть полезно и зачем это нужно?

В Аксапте реализовано два способа сопоставления расходов и доходов по проекту:
1. Использование НЗП
2. Использование принципа начислений.
С НЗП я думаю все понятно, и на нем останавливаться не стоит.
А вот принцип начислений состоит в том, что бы в момент отражения расходов на счетах Прибылей/Убытков отражать и плановый доход, который может быть сопоставлен с этими расходами. В момент обработки накладной плановый доход реверсируется, а вместо него отражается фактический доход.
Для того, что бы в проектах типа Время и расходы активировать принцип начислений необходимо что бы:
1. В группе проектов учет расходов был настроен на счета Прибыль/Убытки
2. В группе проектов для соответствующих расходов был активен параметр «Провести выручку при разноске …»
3. В свойствах проводки был активен чек/бокс «Может быть начислено»

Цитата:

Сообщение от PSA

2. Периодические операции Разноска издержек и Разноска выручки.
Для чего применяются, что происходит в системе?
Не совсем понятно.

И действительно не совсем понятно

Функция разноска издержек – позволяет перенести расходы со счетов прибылей и убытков на счета НЗП и наоборот. Это может быть использовано в различных ситуациях. Например: есть внутренний проект, в рамках которого все расходы отражаются на счете НЗП. По окончанию этого проекта расходы необходимо перенести со счета НЗП на счет Прибылей/Убыков. Так вод в этом случае необходимо будет использовать функцию Разноска издержек
Разноска выручки – это функция накопленный оборот?

[Starling]

А вот такой вопрос.
Есть проект типа Время и расходы, по которому может быть несколько плательщиков. Т.е. накладная будет формироваться на разных клиентов по одному и тому же проекту. Как это реализовать с наименьшими трудозатратами. В момент создания проекта, неизвестно кто будет платить и какие суммы.
Чаще всего плательщик меняется раз в период, т.е. в январе один плательщик, в феврале другой и т.д. Это как мне кажется проще всего реализовать периодически меняя «Cчет по проектам» на карточке проекта.
А как быть в случае, когда в одном периоде необходимо распределить накладную на 9 клиентов? Я так думаю выписывать накладную на одного клиента, а потом общим журналом раскидывать ее по другим клиентам. Какие еще могут быть варианты?

[Посторонний V]

Цитата:

Сообщение от Starling

А как быть в случае, когда в одном периоде необходимо распределить накладную на 9 клиентов?

Есть вариант создавать разные строки проектов на разных контрагентов.
Т.к. проект по сути есть договор, то просто по строке проекта перевыставлять счет-накладную на каждого контрагента.....

По крайней мере мы так делали.......

[Starling]

Цитата:

Сообщение от Посторонний V

Есть вариант создавать разные строки проектов на разных контрагентов.
Т.к. проект по сути есть договор, то просто по строке проекта перевыставлять счет-накладную на каждого контрагента.....

По крайней мере мы так делали.......

Разные строки проектов - это подпроекты?

[Посторонний V]

Цитата:

Сообщение от Starling

Разные строки проектов - это подпроекты?

Да.
На пример есть глобальная задача - построить дом - данный проект будет с типом Сводка. Затем создаем для него подпроекты с типом Время и расходы или Фиксированная цена, количество этих строк = количеству работ по постройке дома, или количеству контрагентов которые выполняют эти работы (в зависимости от того как вам будет удобнее).

[Starling]

В моем случае, это похоже работать не будет. Причины в следующем:
1. На подпроекты уже деление есть – оно соответствует работам. Такой разрез отражает реальную картину и его менять, я думаю, не стоит.
2. Можно было бы конечно и подпроекты (работы) разбить на более мелкие проекты, каждый из которых соответствовал бы плательщику. Но в этом случае получается такая картина – до тех пор пока работа выполняется, кто конкретно за нее будет платит не известно. В результате все расходы могут быть зафиксированы только на проект, который соответствует работе (а не плательщику). Как я уже говорил, проекты имеют тип Время и расходы, т.е. расходы перевыставляются клиенту с наценкой. Таким образом, накладная будет выписываться по проекту, соответствующему работе, а в ней может быть только один плательщик.

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

[Посторонний V]

Цитата:

Сообщение от Starling

На подпроекты уже деление есть – оно соответствует работам. Такой разрез отражает реальную картину и его менять, я думаю, не стоит.

Есть вариант сделать деление по аналитическим статьям (по сути работы), каждую работу может оплачивать один контрагент, а возможно что и несколько контрагентов одну и туже (т.е. работа одна, но подпроектов несколько, соответственно и контрагентов).

Цитата:

Сообщение от Starling

Но в этом случае получается такая картина – до тех пор пока работа выполняется, кто конкретно за нее будет платит не известно.

Странно, а как вы планируете??
Один из наших вариантов - заключили договор, составили план, после этого отслеживаем выполнение плана и оплату.

[Starling]

Я понимю, вы предлагаете следующую иерархию проектов:
1. Проект
1.1 Работа1
1.1.1 Плательщик1
1.1.2 Плательщик2
1.2. Работа 2
1.2.1 Плательщик5
…
Но для следующиего БП она неподходит:
1.Заключается договор с клиентом, в котором оговаривается план работ и их стоимость.
2.По факту выполнения работ клиенту выставляется счет на оплату
3.Поступают платежи, но… платит за выполнения этого проекта не сам клиент, а например его дилеры. При этом кто из них, за какие работы, и какие суммы будет платить неизвестно. Это уже клиент ясное дело решает сам. Главное что в сумме платежи дилеров, соответствовали бы выставленному счету.

В итоге работы сделаны, деньги получены, все довольны.

Итого: кто будет платить за работы (1.1 и 1.2) неизвестно, значит делить работы на подпроекты можно только после того как деньги пришли от N-ого числа плательщиков. Но к этому времени уже все операции отражены в системе на проектах 1.1 и 1.2 , остается только сформировать накладную на нужного клиента.

Таким образом, после получения денег я должен был бы перенести уже зарегистрированные расходы на подпроекты 1.1.1, 1.1.2, 1.2.1, которые соответствуют плательщики, а уже потом только сформировать накладные.

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

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

З.Ы.: Поменять этот БП нереально, так как он исходит от клиента, а ему на внедрения Аксапты наплевать.
З.Ы.Ы.: Фух… че-то я много написал - надеюсь не запутал.

[Посторонний V]

Цитата:

Сообщение от Starling

1.Заключается договор с клиентом, в котором оговаривается план работ и их стоимость.
2.По факту выполнения работ клиенту выставляется счет на оплату
3.Поступают платежи, но… платит за выполнения этого проекта не сам клиент, а например его дилеры. При этом кто из них, за какие работы, и какие суммы будет платить неизвестно. Это уже клиент ясное дело решает сам. Главное что в сумме платежи дилеров, соответствовали бы выставленному счету.

Как "замутили"

Только один момент интересует:
Договоры с дилерами вы заключаете? Кому вы счет то выставляете??

[Starling]

Договор с клиентом, счет выставляют тоже ему. а вот платят по счету уже диллеры.

[PSA]

По свойству проводки "Может быть начислено" и Разноске издержек стало понятно. Спасибо

Остался вопрос по Разноске выручки, т.е. Накопленному обороту.

Технически я так понял Накопленный оборот работает аналогично Разноске издержек, т.е. накопленная сумму на НЗП - в ценах реализации / Начисленная выручка - в ценах реализации реверсирует на Начисленная выручка - в ценах реализации / НЗП - в ценах реализации.

Вопрос в том что сумма накопленного оборота реверсируется точно так же при разноске накладной по проекту. Соответственно зачем реверсирование делать через Накопленный оборот? Типа не дождались разноски накладной?