розничная торговля в Navision

[lena_imported]

хотелось бы получить совет о настройках розничной торговли в Navision,
наша схема: товар приходит на оптовый склад по ценам поставщика, далее делаем наценку и перемещаем по магазинам уже по розничным ценам.
Вопрос: как лучше это переложить на Navision
Главный вопрос, как правильно сделать наценку:использовать журнал переоценки или использовать товарные издержки или внутренние или транзитные перемещения(кстати при использованиии последних цена не меняется, а только фин счета, если я правильно разобралась) или писать свой фоб. Сложность еще и в том, что приход от поставщика идет по 15000 позиций
Надеюсь, что народ уже настраивал розницу и поделиться опытом

[Alterant]

Цитата:

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

хотелось бы получить совет о настройках розничной торговли в Navision, 
наша схема: товар приходит на оптовый склад по ценам поставщика, далее  делаем наценку и перемещаем по магазинам уже по розничным ценам.
Вопрос: как лучше это переложить на Navision
Главный вопрос, как правильно сделать наценку:использовать журнал переоценки или использовать товарные издержки или  внутренние или транзитные перемещения(кстати при использованиии последних цена не меняется, а только фин счета, если я правильно разобралась) или писать свой фоб. Сложность еще и в том, что приход от поставщика идет по 15000 позиций
Надеюсь, что народ уже настраивал розницу и поделиться опытом

<{POST_SNAPBACK}>

Что значит в магазины товар приходит по розничным ценам???
Т.е. прибыль получается при перемещении товара со склада в магазин, а при продаже она равна 0?

[lena_imported]

да, при перемещении с оптового склада в розницу производится наценка товара и в магазинах товар храниться уже по розничным(продажным)ценам

[Галина]

Цитата:

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

хотелось бы получить совет о настройках розничной торговли в Navision, 
наша схема: товар приходит на оптовый склад по ценам поставщика, далее  делаем наценку и перемещаем по магазинам уже по розничным ценам.
Вопрос: как лучше это переложить на Navision
Главный вопрос, как правильно сделать наценку:использовать журнал переоценки или использовать товарные издержки или  внутренние или транзитные перемещения(кстати при использованиии последних цена не меняется, а только фин счета, если я правильно разобралась) или писать свой фоб. Сложность еще и в том, что приход от поставщика идет по 15000 позиций
Надеюсь, что народ уже настраивал розницу и поделиться опытом

<{POST_SNAPBACK}>

А вы как после перемещения в розницу ведете учет товаров ? Ведете ли количественный учет или ваша задача только списать товар с основного склада и плюс сформировалась бы наценка на розничный товар ?

[rmv]

Завестм магазинаы как клиентов, связать со складом и не париться
Вариант 1:
После учета заказа продажи на такого клиента формировать приходные операции в товарном журнале на розничный склад, себестоимость сделать равной цене продажи в строках заказа. Минус - слетают применения.
Вариант 2:
Отломать 81 кодеюнит, при продаже розничным магазинам формировать строку товарного журнала с типом операции Перемещение вместо Продажа.

[s71]

Цитата:

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

да, при перемещении с оптового склада в розницу производится наценка товара и в магазинах товар храниться уже по розничным(продажным)ценам

<{POST_SNAPBACK}>

Без привязки к Навижену
Являются ли магазины и оптовый склад одним "субъектом" учета?
Если да - то тогда вообще непонятна методика использования разных методов себестоимости в зависимости от места хранения.
Если нет - то тут куча вариантов, начиная от ведения учета по каждой бизнес-единицы в отдельной фирме, до извратов вроде продажи-покупки самому себе.

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

[Alterant]

Мне кажется, что если и реализовывать такой механизм, то издержками, а не куплей-продажей. Но механиз по-прежнему кажется очень странным.

[Галина]

Цитата:

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

Мне кажется, что если и реализовывать такой механизм, то издержками, а не куплей-продажей. Но механиз по-прежнему кажется очень странным.

<{POST_SNAPBACK}>

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

[GalaM]

Галина права, согласно бухгалтерскому учету в розничной торговле может быть два варианта учета товаров в торговых залах (независимо от ПО ).

И при внедрении ПО, хорошо бы перейти на количественно-суммовой учет в закупочных ценах.
А то, в NAvision намучаетесь Вы с этими розничными ценами.
Знаем, летали
Так что пока не поздно, уговаривайте клиента переписывать учетную политику

[lena_imported]

Спасибо за совет, я это и предполагала, будем уговаривать клиента переписать учетную политику

[Галина]

Цитата:

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

Спасибо за совет, я это и предполагала, будем уговаривать клиента переписать учетную политику

<{POST_SNAPBACK}>

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

[Dzemon]

Цитата:

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

Спасибо за совет, я это и предполагала, будем уговаривать клиента переписать учетную политику

<{POST_SNAPBACK}>

Извините, lena, а как это вас угораздило розницей заняться в Навижине?
Вы что-то свое пишите или на РБО?

[s71]

Цитата:

Сообщение от Галина

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

<{POST_SNAPBACK}>

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

[GalaM]

Цитата:

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

скидку в кассовом отчете почти никто отдельно не отражает.

<{POST_SNAPBACK}>

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

А вы попробуйте отразить изменение цены при перемещении!!!.
Да еще осуществить требование один товар (штрих-код, арикул у кого-как) одна цена.
Вот где головная боль начинается.

[s71]

Цитата:

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

[Скидку в кассовом отчете отражает, хотя бы в суммовом выражении отражает большинство отчетов. Если ее можно пробить в чеке отдельной строкой, то и в z-отчете найти можно.

<{POST_SNAPBACK}>

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

Цитата:

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

А вы попробуйте отразить изменение цены при перемещении!!!.
Да еще осуществить требование один товар (штрих-код, арикул у кого-как) одна цена.
Вот где головная боль начинается. 

<{POST_SNAPBACK}>

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

[Arshak]

Цитата:

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

Завестм магазинаы как клиентов, связать со складом и не париться
Вариант 1:
После учета заказа продажи на такого клиента формировать приходные операции в товарном журнале на розничный склад, себестоимость сделать равной цене продажи в строках заказа. Минус - слетают применения.
Вариант 2:
Отломать 81 кодеюнит, при продаже розничным магазинам формировать строку товарного журнала с типом операции Перемещение вместо Продажа.

идея интересная,
а можно подсказать какие проводки при этом должны фрмироватся?

[zm]

Я реализовывал примерно таку же схему через "Консигнацию". Магазин = Клиент. Осуществляется обыкновенная продажа(по любой ценовой политике) с соответствующими проводками по налогам (по крайней мере в Латвии по законодательству нужно именно так). А далее...Был разработан функциональный блок "Консигнация"- 4 табл, 10 форм, 10 отчетов, 1 CodeUnit + небольшие изменения в некоторых стандартных объектах. Имя клиента = название когсигнационного склада, он сделан аналогично Item Ledger Entry + Sales Line: там присутствуют количества, цены, скидки, валюты. номера партий, серий и т.д. - все что необходимо контролировать. С какой-то периодичностью из этих магазинов приходит отчеты о продажах, возвратах, списаниях, это заводится как документ продажи(списания, уценки, возврата,..) с консигнационного склада и, на основе этого документа, формируется счет на оплату, контролируется поступление денег + пишутся соотв. проводки в журнал оплаты с соответствующими привязками к исходным документам.
Несколько трудоемко, но зато без всяких извращений и в соответствии с законодательством.

[RobiBaggio]

Цитата:

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

Я реализовывал примерно таку же схему через "Консигнацию". Магазин = Клиент. Осуществляется обыкновенная продажа(по любой ценовой политике) с соответствующими проводками по налогам (по крайней мере в Латвии по законодательству нужно именно так). А далее...Был разработан функциональный блок "Консигнация"- 4 табл, 10 форм, 10 отчетов, 1 CodeUnit + небольшие изменения в некоторых стандартных объектах. Имя клиента = название когсигнационного склада, он сделан аналогично Item Ledger Entry + Sales Line: там присутствуют количества, цены, скидки, валюты. номера партий, серий и т.д. - все что необходимо контролировать. С какой-то периодичностью из этих магазинов приходит отчеты о продажах, возвратах, списаниях, это заводится как документ продажи(списания, уценки, возврата,..) с консигнационного склада и, на основе этого документа, формируется счет на оплату, контролируется поступление денег + пишутся соотв. проводки в журнал оплаты с соответствующими привязками к исходным документам.
Несколько трудоемко, но зато без всяких извращений и в соответствии с законодательством.

Расскажи, плиз, поподробней. У меня стоит такая же задача, по консигнации. Если можешь дай описание, возможно цену данного решения.

[zm]

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