закрытие склада по номенклатуре типа услуга - зачем? (аксапта)

[Елена Сысовская]

собственно, сабж:
1. зачем закрывать склад по номенклатуре типа услуга?
и по попутно
2. для чего сделана номенклатура типа услуга? если это услуги, оказываемые и продаваемые на сторону, то ... почему это не спецификации?
3. почему по этому типу вообще склад?
собираем по нитке кто что знает...

[LR20]

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

[glibs]

Судя по всему, номенклатуру с типом "услуга" делали в первую очередь под MRP. Ее предполагается закупать. В спецификациях есть строка с типом "поставщик". Предполагается субподряд, т.е. приобретение услуги. Для связи с договорным процессом и сделана "услуга".

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

[mazzy]

Цитата:

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

Поясни, плз. А почему ты не рассматриваешь с free text incoice (накладная на услуги)?

[LR20]

По спланированным закупкам услуг можно создать БЮДЖЕТ закупок с помощью периодической операции перенесения "Прогноз закупок в Главную книгу"

[mazzy]

ага. понял. извините, был невнимателен.

[maxsmirnov]

если будете делать так, как предлагает LR20, то обязательно в описании бизнес процессов укажите _конкретного_ человека который будет обязан эти услуги со склада списывать. а то получится как у нас - посмотрел недавно на склад, а там, мама дорогая! коляски ставить некуда, весь склад завален арендой и услугами связи

[mazzy]

Цитата:

Изначально опубликовано maxsmirnov
...посмотрел недавно на склад, а там, мама дорогая! коляски ставить некуда, весь склад завален арендой и услугами связи

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

[maxsmirnov]

Цитата:

Изначально опубликовано mazzy

Просто вам нужен модуль управление складом.
Он может ответить на вопрос "сколько мы еще сможем положить колясок?"

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

[Михаил Андреев]

Цитата:

Изначально опубликовано mazzy
Просто вам нужен модуль управление складом.
Он может ответить на вопрос "сколько мы еще сможем положить колясок?"
Без этого модуля вы получаете ответ только на вопрос "а сколько и куда было положено?".

Сергей! Ну ты и провокатор

[mazzy]

Цитата:

Изначально опубликовано maxsmirnov
ждем отраслевого решения

g делать настраиваемым?
Или можно ограничиться случаем, когда небоскребы строятся только на планете Земля?

[Михаил Андреев]

Цитата:

Изначально опубликовано mazzy

g делать настраиваемым?
Или можно ограничиться случаем, когда небоскребы строятся только на планете Земля?

Конечно, g должно настраиваться, ты что, не в курсе, небоскребы собираются строить уже не только на одной планете Земля, и даже не только на планетах ?

[mazzy]

Цитата:

Изначально опубликовано Михаил Андреев
Сергей! Ну ты и провокатор

почему, собственно?! (потупив очи и шаркая ножкой )

[LR20]

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

[Елена Сысовская]

Итак, возвращаемся к номенклатуре типа услуга.
Мало что поняла из ответов, поэтому расскажу сама что знаю:
1.Номенклатура типа услуга в учете по складу и расчету себестоимости ведет себя совершенно аналогично обычной номенклатуре.
2.Соответственно, она ведет себя аналогично в процедурах расчета спецификаций (как компонент), процедурах сводного планирования.
3.Она предназначена для закупки. Потому что для продажи собственных услуг есть специальная накладная на услугу, в которой есть возможность ввести произвольную текстовую строку. А для расчета затрат на производство собственных услуг, видимо, необходимо будет создать номенклатуру типа спецификация. Поэтому в дальнейшем будем называть ее Покупаемая Услуга (ПокУс)
4.Номенклатура типа ПокУс и накладные расходы по закупке – это разные вещи. Не смотря на то, что при закупке или отгрузке продукции можно учесть возникающие накладные затраты через НакРас, эту функцию лучше использовать при работе по схеме, когда поставщик включает затраты в счет на товар. Потому что при учете накладных расходов (НакРас), учитываемых по закупке (стракам закупок) не возникает задолженность перед поставщиком. В этом кардинальное отличие ПокУс от НакРас. (в нашей жизни это привело к такой схеме: 1. учет НакРас по строке Дт 41 Кт 44, 2. учет закупки от поставщика Дт 44 Кт 60. Такая схема позволяет в наших условиях учесть нормативное начисление затрат по закупке )
5.Соответственно, можно выполнять функции планирования закупок ПокУс, планирования платежей и переноса прогноза платежей в бюджет ДС (не делала, терминологию использую по пониманию)
6.Так как ПокУс приходуется на склад, то их оттуда надо списывать. Это становится, как говорится, отдельной бизнес-функцией. Перед закрытием склада или сразу после закупки желательно делать.
7.Попытки снять с номенклатуры в учете признаки финансовой и складской аналитики возможно, могут привести к непредсказуемым последствиям при закрытии склада, особенно если было разнонаправленное движение. Поэтому лучше завести склад услуг, указать необходимость контроля финансового и физического склада. И разрешить их отрицательное значение.
8.Есть еще вот такое предупреждение: «One caution of using service items. If you in any way sell some of the items you will have to use batch numbering and reservation (or in 3.0 marking) otherwise your costs can go terribly wrong when closing inventory. The only time you can use the service items safely without batch numbering/reservation/marking is if they are truly one-way......only buy-not sell or only sell-not buy. Ole». Ээээ… Сложно понять, что автор имел ввиду. Но после того, как мы сделали у услуги партию, исчезла ошибка с некорректными проводками, возникающими при закрытии склада. Они возникали не в той компании!
9.Списание на счета затрат, или себестоимость продукции – непростой процесс, и это сейчас раскрывать не будем.
10.Собственно, ПокУсл необходимо использовать в первую очередь для MRP, то есть для планирования потребностей в субподряде. Например, для планирования почасовых работ. В другом случае можно делать сразу накладную, с регистрацией проводок на требуемые счета, с нужной аналитикой (в том числе статьей затрат).
11.В этом случае услуга должна быть включена в спецификацию с типом строки спецификацию «поставщик». То есть при сводном планировании система будет всегда планировать закупку этой услуги, а не производство, не отгрузку со склада.
12. Правильнее было бы номенклатуру называть не типа Услуга, а типа Работа.

[glibs]

Цитата:

Изначально опубликовано Михаил Андреев
...Сергей! Ну ты и провокатор...

Ну почему же?

Это пример грамотного подхода к процеесу продаж Аксапты.

Я, напрмер, предложил бы вам модуль CRM, чтобы провести рекламную акцию и толкнуть кому-нибудь, наконец, все ваши залежалые аренды и услуги связи в тридорога, чтобы склад для колясок освободить. Даже рентабельность проекта "посчитал" бы.

Какой-то у вас, программистов, некоммерческий подход к жизни.

Шутка.

[glibs]

А если серьезно...

Цитата:

Изначально опубликовано maxsmirnov
...если будете делать так, как предлагает LR20, то обязательно в описании бизнес процессов укажите _конкретного_ человека который будет обязан эти услуги со склада списывать. а то получится как у нас - посмотрел недавно на склад, а там, мама дорогая! коляски ставить некуда, весь склад завален арендой и услугами связи...

Ой, можно подумать это великое дело раз в год, например, сделать инвентаризацию и неглядя списать все услуги в никуда. Может еще трех менеджеров в штат принять?

[glibs]

Цитата:

Изначально опубликовано glibs
...Согласен... насчет... использования услуг для планирования хозяйственных и пр. расходов на... услуги... Но мне... такой вариант не очень нравится...

А я попробовал... вроде ничего получается. Мне даже начинает нравиться. Выходит, просто я раньше с ними плохо разобрался.

Пожалуй, я передумал.

Опять же согласен с LR20 насчет отдельного склада. Так и назвать его — "Бухгалтерия". Они сами быстро разберутся, что с этими услугами делать.

PS. Но идеологически правильно было бы планировать закупку всяких услуг в модуле Проекты. Это лучший путь. Тем более, что их все-равно по хорошему потреблять нужно именно там. Да и план с фактом сравнивать тоже... А то представьте себе, что у меня на 26-м счете аналитика по 25 статьям. Это мне придется 25 номенклатурных групп для разноски услуг (в ГК) сделать (кроме всего прочего). А еще есть 20-й, 25-й, 44-й и куча других счетов, на которые тоже могут закупаться услуги. Тут еще и несколько подвидов услуг появится (аренда производственная, аренда административных помещений...). А потом эти группы начнут мешаться в управленческой статистике...

Только планирование в Проектах совсем сырое. И в бюджет ГК ничего переносить не умеет.

[Елена Сысовская]

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

[Тимур]

Цитата:

Изначально опубликовано Елена Сысовская

Потому что при учете накладных расходов (НакРас), учитываемых по закупке (стракам закупок) не возникает задолженность перед поставщиком. В этом кардинальное отличие ПокУс от НакРас. (в нашей жизни это привело к такой схеме: 1. учет НакРас по строке Дт 41 Кт 44, 2. учет закупки от поставщика Дт 44 Кт 60. Такая схема позволяет в наших условиях учесть нормативное начисление затрат по закупке )

Не могу согласиться. Накладные расходы по строке/заказу изменяют как стоимость приобретаемого МПЗ, так и увеличивают кредиторскую задолженность. Надо только правильно настроить разноску.


10.Собственно, ПокУсл необходимо использовать в первую очередь для MRP, то есть для планирования потребностей в субподряде. Например, для планирования почасовых работ.


Согласен. Могу порекомендовать на эту тему ознакомиться с книгой "Управление и организация в сфере услуг" К.Хаксевер, Б. Рандер, Р.С. Рассел, Р.Г. Мердик (переведено и издано в 2002 издательством "Питер") Глава 19. Системы управления запасами. Там раскрываются особенности применения MRP в сфере услуг - Service Requirements Planning (SRP).