Два invoice, один с нулевым количеством

[vazerdim]

Пытаюсь понять как лучше реализовать один из бизнес процессов компании в AX.

Что имеем:
1. Разносят Sales order на клиента, один invoice с ценой и кол-вом. К примеру:
Кол-во: 5
Цена: 100
Сумма: 500

2. Пока груз идет до клиента, может измениться цена на товар и компания хочет провести новый invoice на увеличение стоимости:
Стало:
Кол-во: 5
Цена: +5
Сумма: 25

Сейчас они делают следующим образом: сторнируют старый invoice и проводят новый с новой ценой, но это не решает вопрос с датами оплаты, invoice на +5 должен иметь свою дату оплаты, отличной от invoice на 100(у которой дата оплаты остается первоначальная).

Как вариант выхода из данной ситуации я вижу следующий:
1. Первый invoice на 100 мы не трогаем.
2. Проводим новый Free text invoice на +5, с новой датой оплаты.

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

Может я не прав? Может есть какой то другой вариант выхода из данной ситуации?

[ashu]

использовать корр фактуры на изменение цены? это первый вариант который приходит в голову.
кроме того что как то пересмотреть процесс

[vazerdim]

Счет-фактур тут нет, европейская AX.

[EVGL]

Цитата:

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

Как вариант выхода из данной ситуации я вижу следующий:
1. Первый invoice на 100 мы не трогаем.
2. Проводим новый Free text invoice на +5, с новой датой оплаты.

На моем текущем проекте делаем именно так.

[mazzy]

Цитата:

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

2. Пока груз идет до клиента, может измениться цена на товар и компания хочет провести новый invoice на увеличение стоимости:

для этого в системе предусмотрен не один invoice, а несколько документов.
есть packing list (или как он сейчас называется)
и есть invoice

packing list - документ, который отвечает за переход прав на физическое количество.
packing list может содержать цены. но это так называемые "физические цены" или другими словами ориентировочные цены

invoice - документ, котрый отвечает за переход прав на финансовую составляющую товара.
invoice фиксирует суммы сделки.
количество в invoice может отличаться от количества в packing list на величину допустимого отклонения (по умолчанию допустимое отклонение отсутствует).

цена и сумма в инвойса также может отличаться от цены и суммы в пакинг листе. в зависимости от параметров аксапта умеет как учитывать разницу, так и сторнировать физическую сумму, а потом разносить финансовую.

аксапта вполне допускает выписывать как один инвойс по нескольким packing list'ам, так и несколько разных инвойсов по одному packing list, а также по разному комбинировать.

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

таким образом,
сперва разносите packing list по Sales Order.
затем фиксируйте окончательные условия сделки инвойсами.

[mazzy]

Цитата:

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

Как вариант выхода из данной ситуации я вижу следующий:
1. Первый invoice на 100 мы не трогаем.
2. Проводим новый Free text invoice на +5, с новой датой оплаты.

Ужос, нах.

так вы теряете информацию о фактической стоимости товара и фактической марже.
в результате отчет "структура стоимости" можно будет сделать только котловым методом.

[potential]

Цитата:

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

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

вариант с оприходованием 10 шт вместо 5 шт вряд ли понравится складу

Цитата:

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

это не решает вопрос с датами оплаты, invoice на +5 должен иметь свою дату оплаты, отличной от invoice на 100(у которой дата оплаты остается первоначальная).

они могут разбить задолженность по графику

[vazerdim]

Цитата:

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

вариант с оприходованием 10 шт вместо 5 шт вряд ли понравится складу

в Free text invoice нет кол-ва, модуль запасов мы не затрагиваем.

[EVGL]

Цитата:

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

Ужос, нах.

так вы теряете информацию о фактической стоимости товара и фактической марже.
в результате отчет "структура стоимости" можно будет сделать только котловым методом.

Конечно теряем. Но это проблема не сколько процесса, сколько системы, в которой это не предусмотрено. Аналогичная ситуация в закупках решена только в русской локализации. Так что отчет "структура стоимости" (хм, "стоимости"?) делаем по аналитике "cost purpose" = номер продукта в модуле Cost Accounting.

Я проводил тренинг для конечных пользователей в России для формирования корректировочных фактур в условиях отгрузки по палетам, партиям и/или серийным номерам, спасибо: вероятность сделать ошибку и породить еще одну пару сторнировочных проводок - это где-то 50:50 даже для образованного пользователя типа меня.

Что касается длинного поста перед этим, то packing slip невозможно оплатить, как вы знаете, и в стандарте он не содержит цен. Почему счета выставляются до момента перехода права собственности - это вопрос к автору темы. Солидаризуясь с автором, я замечу, что так делают сплошь и рядом, поскольку процесс отслеживания товара в условиях доставки типа DAP в системе [Dynamics 365 fFO EE] технически почти не поддерживается (опять-таки кроме России и "отложенного перехода права собственности" или TMS с уведомлениями о местонахождении груза - опять все вручную) и почти всегда реализуется как-то вовне системы.

[mazzy]

Цитата:

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

invoice на +5 должен иметь свою дату оплаты, отличной от invoice на 100(у которой дата оплаты остается первоначальная).

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

для каждой проводки custTrans можно создать несколько открытых проводок custTransOpen.

это было так во всех версиях аксапты.
руками можно рассплитить открытую проводку в форме сопоставления (см. скриншот)

автоматически аксапта создает несколько открытых проводок, если указан график оплат.

таким образом, чтобы по одному инвойсу получить несколько разных дат оплат, нужно всего лишь указать график оплат ДО разноски. или же вручную рассплитить открытые проводки по инвойсу ПОСЛЕ разноски.

[EVGL]

Цитата:

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

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

для каждой проводки custTrans можно создать несколько открытых проводок custTransOpen.

это было так во всех версиях аксапты.
руками можно рассплитить открытую проводку в форме сопоставления (см. скриншот)

автоматически аксапта создает несколько открытых проводок, если указан график оплат.

таким образом, чтобы по одному инвойсу получить несколько разных дат оплат, нужно всего лишь указать график оплат ДО разноски. или же вручную рассплитить открытые проводки по инвойсу ПОСЛЕ разноски.

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

[mazzy]

Цитата:

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

Но это проблема не сколько процесса, сколько системы, в которой это не предусмотрено.

да, ну?

Цитата:

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

Аналогичная ситуация в закупках решена только в русской локализации.

му-ха-ха-ха!!!

Цитата:

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

Что касается длинного поста перед этим, то packing slip невозможно оплатить, как вы знаете, и в стандарте он не содержит цен.

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

но документ packing slip цены таки содержит.

Цитата:

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

Почему счета выставляются до момента перехода права собственности - это вопрос к автору темы.

потому что до перехода прав собственности этот документ называется invoice proforma. в россии аналогом является счет на оплату.

в аксапте этот документ можно распечатать, если начать разносить инвойс, но в форме параметров выключить галку Обрабатывать (Posintg) см. скриншот.

особенность аксапты - этот документ не имеет номера.

Цитата:

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

Солидаризуясь с автором, я замечу, что так делают сплошь и рядом, поскольку процесс отслеживания товара в условиях доставки типа DAP в системе [Dynamics 365 fFO EE] технически почти не поддерживается

Му-ха-ха-ха...
Бедные разработчики целого модуля доставки... Они отчитались еще для акс2012...

[mazzy]

Цитата:

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

Господа вы, упорно делаете вид, что не понимаете вопроса, пытаясь подобрать лишенное экономического смысла техническое решение. Проблема в том, что в момент отгрузки продавец не знает цены товара, когда он придет в Сингапур 3 недели спустя.

Госопдин, Евгений, вы упорно демонстрируете свое абсолютное не знание системы.

если в момент отгрузки продавец не знает цены, то он выписывает документ packing list. в документе packing list могут присутствовать физические цены.

после того, как начальники таки договорятся о финансовых условиях сделки, то выписывается инвойс.

Цитата:

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

Как в систему занести информацию, которая принципиально не существует?

Очень просто - заносить только ту информацию, которая существует.
И Аксапта предоставляет необходимые инструменты для этого.

Цитата:

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

При этом если не выставлять счет, то этот товар никогда не пройдет таможню, например.

Прекрасно! Брависсимо. Логические противоречия в соседних предложениях!

И в самом деле как же так! ведь, по вашим словам информации не существует. Как же он пройдет таможню?! с несуществующей принципиально информацией... Беда-беда - огорчение!...

================
приведенная вами цитата из моего сообщения вообще никак не относится к ценам. а относится к совершенно перпендикулярной области - даты оплаты.

[EVGL]

Цитата:

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

Му-ха-ха-ха...
Бедные разработчики целого модуля доставки... Они отчитались еще для акс2012...

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

• в TMS есть таблица для отслеживания, но никаких штатных средств, чтобы ее заполнять. Стало быть, процесс информирования продаж о достижении точки "Сингапур" не автоматизирован.
• проформа-инвойс - один из способов решения проблемы. Отсутствие номера - это "особенность", которую приходится учитывать и исправлять.
• другой способ решения проблемы - это печатать цены в особой печатной форме на базе таблицы Packing slip, этот подход используем на текущем проекте. Неприятность в том, что цен там нет даже физически в таблице, они заполняются только в польской и русской локализации, если не ошибаюсь.

[EVGL]

Цитата:

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

Госопдин, Евгений, вы упорно демонстрируете свое абсолютное не знание системы.

если в момент отгрузки продавец не знает цены, то он выписывает документ packing list. в документе packing list могут присутствовать физические цены.

См. предыдущий пост. Могут, но не присутствуют. Мне уже очень не нравится ваш тон.

[ashu]

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

[ashu]

если говорить с точки зрения возможной реализации- из серии пофантазировать. а если разницу в ценах отражать через ГК и привязывать затем через накладные расходы к накладной по реализации?

[mazzy]

Цитата:

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

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

Может просто документацию наконец прочитать?
Это базовые механизмы Аксапты.

Цитата:

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

может кто то примет за офтоп, но только меня смущает:
прошла отгрузка товара, по какой то цене.

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

так вот, на такие случаи в Аксапте как раз и существуют несколько разных документов в Аксапте.

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

финансовая стоимость перекрывает и физическую.
финансовое количество и финансовая стоимость может отличаться от физического количества и физической стоимости.

на этом была, есть и будет аксапта.
эти механизмы исопльзуются не только в продажах, но и в производстве (план/факт), и в модуле проекты.

собственно вся аксапта, это обвязка вокруг физического, финансового и их расхождений.

Цитата:

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

мы потом в одностороннем порядке меняем цену отгрузки (или по соглашению с клиентом)?

это не так малешко.

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

а вот если с покупателем более хитрые условия. например, дополнительные скидки в зависимости от выбранного за период объема. или за отчетный период клиента перевели в другую колонку прайс-листа. или рибейт. или какие-нибудь другие условия, которые становятся известны ПОСЛЕ физической поставки. например, широко известное условие "бери или плати" для поставок газа.

ну или банально, клиент выбил спец.условия, бухая с нашими директорами в сауне.

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

Цитата:

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

как по мне- если прошла отгрузка- значит есть какой то договор- или договор "шапочный" без цен и сумм?

Какой-то - это правильное слово.
Договор может не содержать конкретных сумм.
Договор может не содержать конкретных количеств.

=========================
Возвращаясь к исходному вопросу vazerdim
Начальные условия, высказанные в исходном сообщении, в принципе не могут возникнуть в условиях, когда о количествах и суммах договорились заранее.

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

А для работы с физической и финансовой составляющей при продажах, в Аксапте предусмотрены документы packing slip и invoice соответственно.

[EVGL]

Цитата:

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

Прекрасно! Брависсимо. Логические противоречия в соседних предложениях!

И в самом деле как же так! ведь, по вашим словам информации не существует. Как же он пройдет таможню?! с несуществующей принципиально информацией... Беда-беда - огорчение!...

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

[Napalm]

Вообще один Sales Order может иметь несколько Invoice-ов. И если цена меняется, то в Sales Order можно добавить еще одну линию (или несколько) для разницы в цене (используя как вариант специальный Item, Category, Service) и сделать для нее свой Invoice.

Для этого надо будет разработать соответствующую модификацию.

Если без модфикаций - линию надо добавлять заранее, так сказать на всякий случай.