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

[mazzy]

Цитата:

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

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

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

Цитата:

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

Вообще один Sales Order может иметь несколько Invoice-ов.

может.
мало того, один Sales Order "может иметь" несколько других Sales Order'ов )))

Цитата:

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

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

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

в общем, печать таким способом "вылечить" конечно можно.
но при этом будет безнадежно убита система планирования и контроля. а мощная аксапта превратится в 1С тыкву.
https://youtu.be/ju5gQaBEsH8?t=5m31s

Цитата:

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

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

ну... модификации то можно и похитрее придумать.

Цитата:

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

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

му-ха-ха-ха!!!
Ребяты, жжоте!

[EVGL]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

Цитата:

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

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

блин, вот все же у всех перед глазами.
Как лихо исчезло условие "в момент отгрузки" ))))

В момент отгрузки продавец и не должен знать цену товара.
фактические 5% от стоимости в счете исчисляется в таможне, а не "в момент отгрузки" ))))

оценочную величину 5% в момент аксапта вполне может прикинуть по физической стоимости. )))

=======================
К сожалению, Евгений, вы ввели в свое рассужение новый термин "стоимость по контракту". Так вот, "стоимость по контракту" действительно может "фиксироваться после прохождения границы". И противорчения в реальной жизни нет. Поскольку "стоимость по контракту" может включать в себя не только стоимость доставляемых товаров и прямых расходов на доставку. Но и рибейты. Но и финансовые скидки (в аксапте Общие скидки). И так далее. И это только вполне легальные способы изменения фактической "стоимости по контракту" после прохождения границы. Не говоря уже о всяких нехороших перекласификациях на таможне.

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

=======================
повторюсь, в аксапте есть физическая и финансовая стоимости.
Если стоимость меняется со временем, то так или иначе задачу надо сводить к этим понятиям.
Для процесса продажи в аксапте предусмотрены документы Packing slip и invoice для работы с физической и финансовой стоимостью.

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

Не надо насиловать девушку. Она сама даст что вам надо.
Просто хотя бы прочитайте документацию наконец то!

[EVGL]

Цитата:

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

блин, вот все же у всех перед глазами.
Как лихо исчезло условие "в момент отгрузки" ))))
В момент отгрузки продавец и не должен знать цену товара.
фактические 5% от стоимости в счете исчисляется в таможне, а не "в момент отгрузки"
оценочную величину 5% в момент аксапта вполне может прикинуть по физической стоимости.
...
Повторюсь, в реальной жизни противоречия нет. Противоречие только в вашей формулировке.

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

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

Цитата:

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

повторюсь, в аксапте есть физическая и финансовая стоимости.
Если стоимость меняется со временем, то так или иначе задачу надо сводить к этим понятиям.
Для процесса продажи в аксапте предусмотрены документы Packing slip и invoice для работы с физической и финансовой стоимостью.

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

Не надо насиловать девушку. Она сама даст что вам надо.
Просто хотя бы прочитайте документацию наконец то!

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

У меня вызывает недоумение максимализм и пафосные отсылки к знаниям, которые набирает стажер в первый год работы, когда затронута одна из сложнейших тем на внедрении: как положить все многообразие договорных отношений с клиентом и различных условий поставки в прокрустово ложе двух документов, дат и сумм. Обсуждение этой темы с клиентами занимало у меня дни, недели, месяцы, и порой не находило удовлетворительного решения не только в D365, но и OeBS.

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

Будьте скромнее.

[Napalm]

Цитата:

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

может.
мало того, один Sales Order "может иметь" несколько других Sales Order'ов )))

См. первый пост о бизнесс процессе - один Sales Order, два Invoice-а.

Цитата:

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

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

в общем, печать таким способом "вылечить" конечно можно.
но при этом будет безнадежно убита система планирования и контроля. а мощная аксапта превратится в 1С тыкву.
https://youtu.be/ju5gQaBEsH8?t=5m31s

Подумайте о том, что я имел ввиду под "специальный Item, Category, Service" и как это может быть связано с лотом, складом и сводным планированием.

Цитата:

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

ну... модификации то можно и похитрее придумать

Придумайте похитрее и поделитесь.

Цитата:

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

му-ха-ха-ха!!!
Ребяты, жжоте!

С клиентами также общаетесь?

[mazzy]

Цитата:

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

См. первый пост о бизнесс процессе - один Sales Order, два Invoice-а.

да-да... вы правы, конечно. это я extra-информацию выдал. )
в исходном запроса на эту информацию не было

Цитата:

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

Подумайте о том, что я имел ввиду под "специальный Item, Category, Service" и как это может быть связано с лотом, складом и сводным планированием.

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

подумайте - это очень правильный совет.

Цитата:

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

Придумайте похитрее и поделитесь.

Уже придумано. Уже реализовано. Ни в коем разе не буду делиться. Контроль изменения стоимости и себестоимости. Тем более на границе... Это очень чувствительные и интимные области.
И да! Ни у одного из моих клиентов таких вещей никогда не было, конечно.

Цитата:

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

С клиентами также общаетесь?

С какой целью интересуетесь?

[Lemming]

Цитата:

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

С какой целью интересуетесь?

Простите, не удержался: Свидетели Иеговы, позвонившие в квартиру пьяного преподавателя философии, приняли ислам прямо возле домофона.

[EVGL]

Цитата:

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

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

подумайте - это очень правильный совет.

Я вот подумал: как раз сейчас тестирую массивный ISV, в котором есть контроль и одобрение продаж. Там бы фокус с отдельной строкой не прошел. Однако, в стандартной D365 нет контроля и одобрения продаж. Более того, в исходной постановке задачи подразумеваются некие внешние условия или темные силы, которые приводят к изменению цены. Если они внешние или неотвратимые, зачем и как их контролировать? Их надо тогда не контролировать, а автоматизировать. К примеру, если речь идет об объемных скидках, то Rebates в D365 формируют отдельный месячный счет и суммарный журнал ГК. Выгода в управляемости и прозрачности есть, но связь с оригинальным заказом тоже весьма опосредованная.

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