Текущее время: Вт, апр 24 2018, 03:02

Часовой пояс: UTC + 4 часа


Правила форума


ВНИМАНИЕ!

Вопросы по исходящим поставкам - сюда



Начать новую тему Ответить на тему  [ Сообщений: 17 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Копирование ручных условий в поставку. Кто-нибудь делал?
СообщениеДобавлено: Пн, янв 16 2006, 16:52 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 14:35
Сообщения: 4375
Откуда: Москва
Привет!
Создаю заказ, вручную ввожу скидку 10%.
Создаю поставку, провожу разделение позиции. И в этот момент мне очень хочется, чтобы в позиции поставки в схему калькуляции подтянулась эта скидка.
Кто-нибудь такую програмку писал? Поделитесь опытом, плиз...

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 09:14 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Пт, авг 20 2004, 08:19
Сообщения: 602
Привет, эта проблема когда-то обсуждалась на sapfans.com, так что если есть желание, то можешь прошерстить их форум. Но вообще, для начала неплохо бы определиться, зачем в документе поставке необходима торговая схема калькуляции.
Обычно в поставке, если это надо, ведут собственный расчет неких расходов, связанных с отгрузкой/транспортировкой продукции, которую потом хотят выставить клиенту. Торговый расчет (цена, скидки/надбавки и налоги) все равно перекочуют из заказа в фактуру. Так что, может, в консерватории что-то подправить?

_________________
С уважением,

Сабир.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 10:26 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 14:35
Сообщения: 4375
Откуда: Москва
Сабир, спасибо за совет - буду искать.
А дело вот в чем. У меня происходит разделение позиций в поставке, причем в фактуре используются групповые условия, чтобы сумма фактуры была равна сумме заказа.
В результате, если печатать накладную до создания фактуры, программа печати берет за основу заказ и производит расчет стоимости позиций по правилам, отличающимся от тех, что зашиты в схеме калькуляции фактуры. Ну а если фактура уже есть, то при печати накладной все нормально - цены берутся из фактуры.
Так что я вижу два варианта:
А) Просто поставить предпосылку, запрещающую печать накладной, пока нет фактуры. Минус - пользователям придется сначала создать поставку, потом фактуру, потом снова вернуться к поставке, чтобы ее напечатать.
Б) Сделать в поставке рассчет цен идентичный тому, что есть в фактуре и печатать цены из поставки. А для этого надо:
- включить схему калькуляции в поставке
- научиться копировать ручные условия цен из заказа в поставку (отсюда мой вопрос)
- изменить программу печати Торг-12.

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 10:40 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Пт, авг 20 2004, 08:19
Сообщения: 602
Знакомая проблема, но мы решили ее несколько иначе.

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

Не совсем понятно требование равнозначности суммы заказа и связанных фактур. Если вы заказ разбиваете на несколько поставок, в фактуре будет несколько позиций, и тогда по математике неизбежны т.н. ошибки округления. Мы долго анализировали эту проблему, пытались от нее уходить по-разному, но все-таки пришли к пониманию, что особенности округления будут всегда! Уйти от них можно только, если объем позиции в заказе будет равен позиции поставки. А это не всегда возможно. Поэтому, вместо того, чтобы изобретать велосипед и затем ставить заплатки на заплатки, мы решили проблему описанным выше способом. Организационно пришлось помучаться (читай, сталкивать лбами коммерсантов, финансистов и бухгалтеров), зато сейчас все предельно ясно, четко и, самое главное, в этой области мы не делали своих z-наработок.
Чего и вам желаю!

_________________
С уважением,

Сабир.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 10:57 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 14:35
Сообщения: 4375
Откуда: Москва
Да я понимаю, если по одному заказу есть несколько поставок или физически невозможно отгрузить ровно столько, сколько заказали (отгрузка идет на вес), то борьба с копейками бесмысленна.
Но у нас все меряется в штуках, и зачастую по одному заказу одна поставка, просто в этой поставке товар отгружается из разных партий с разными ГТД => разделение партий в поставке и в фактуре их тоже соединять в одну нельзя. Да еще как правило применяется 100% предоплата.
И вот в такой ситуации очень заманчиво избавляться автоматически от разниц в 1-2 копейкимежду счетом и фактурой, чтобы они потом не висели на счетах наших дебиторов. Но, конечно, городить огромный z-огород тоже не хочется...

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 11:04 
Гость
LKU написал(а):
Сабир, спасибо за совет - буду искать.
А дело вот в чем. У меня происходит разделение позиций в поставке, причем в фактуре используются групповые условия, чтобы сумма фактуры была равна сумме заказа.
В результате, если печатать накладную до создания фактуры, программа печати берет за основу заказ и производит расчет стоимости позиций по правилам, отличающимся от тех, что зашиты в схеме калькуляции фактуры. Ну а если фактура уже есть, то при печати накладной все нормально - цены берутся из фактуры.
Так что я вижу два варианта:
А) Просто поставить предпосылку, запрещающую печать накладной, пока нет фактуры. Минус - пользователям придется сначала создать поставку, потом фактуру, потом снова вернуться к поставке, чтобы ее напечатать.
Б) Сделать в поставке рассчет цен идентичный тому, что есть в фактуре и печатать цены из поставки. А для этого надо:
- включить схему калькуляции в поставке
- научиться копировать ручные условия цен из заказа в поставку (отсюда мой вопрос)
- изменить программу печати Торг-12.


Для решения Ваших проблем есть выход, которым воспользовались мы: Программа печати накладной и ТТН моделирует счет фактуру ( грубо говоря просто создает ее в системе, после чего делается откат => счета в системе небудет),берет из нее все значения сумм, и по ним печатает накладную и ТТН, по моему одно из самых правильных решений, по крайней мере суммы в накладной и фактуре всегда сходятся!!! Попробуйте!!!


Принять этот ответ
Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 11:09 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Пт, авг 20 2004, 08:19
Сообщения: 602
И все-таки я не вижу принципиальной проблемы.

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

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

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

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

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


P.S. С каждым постом все длиннее и длиннее. :)

_________________
С уважением,

Сабир.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 11:18 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Пт, авг 20 2004, 08:19
Сообщения: 602
Здравствуйте, Евгений.

Evgenii написал(а):
Для решения Ваших проблем есть выход, которым воспользовались мы: Программа печати накладной и ТТН моделирует счет фактуру ( грубо говоря просто создает ее в системе, после чего делается откат => счета в системе небудет),берет из нее все значения сумм, и по ним печатает накладную и ТТН, по моему одно из самых правильных решений, по крайней мере суммы в накладной и фактуре всегда сходятся!!! Попробуйте!!!


Не совсем понял, что значит создается СФ и затем откатывается - она виртуально моделируется, или все-таки создается запись в VBRK (и всех связанных таблицах), а затем сторнируется/архивируется?

Отдельно хочу сказать, что этот метод теоретически может "выстрелить" при формированиий коммерческой отчетности по поставкам - получается для каждой позиции в отчете надо будет формировать СФ, а затем откатывать. Не тяжеловато будет?

_________________
С уважением,

Сабир.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 11:28 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 14:35
Сообщения: 4375
Откуда: Москва
Я понимаю, что разница в копейках - не ошибка "тупого сапа", а математическая неизбежность. Вопрос только в том что с этим делать - подгонять цены и НДС в фактуре, чтобы ее сумма сошлась с заказом или потом решать в бугалтерии проблемы с ненулевым сальдо дебитора (например, перенести на другой контракт.)
Но вот если покупатель разовый, то надо потом либо требовать от покупателя дополнительный платеж на 2 копейки (кому это понравится?), либо эти деньги куда-то списывать.
Про единицы измерения я написал потому, что они определяют специфику бизнеса. Например, если вы продаете картофель в мешках, то есть плановая цифра (50кг), но покупатель от вас не ждет, что каждый мешок будет весить ровно столько. Значит, клиенты в таком бизнесе привыкли, что либо предоплата не 100%, либо после отгрузки им придется оплатить разницу, либо это разница останется на их счете до следующей отгрузки. А вот если вы отгружаете йогурты в коробках и выставляете требование авансового платежа на 100% стоимости (по заказу), то клиенты вовсе не готовы к тому что им потом скажут, что цена изменилась на 1-2 копейки.
Что-то я тоже расписался :)

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 11:30 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 14:35
Сообщения: 4375
Откуда: Москва
Evgenii, мысль интересная! А можно огласить технические подробности?
1. Как именно моделируется фактура - с сохранением или без.
2. Если без сохранения, то как считываются значения цен?

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 11:32 
Гость
moonrajah написал(а):
Здравствуйте, Евгений.

Не совсем понял, что значит создается СФ и затем откатывается - она виртуально моделируется, или все-таки создается запись в VBRK (и всех связанных таблицах), а затем сторнируется/архивируется?

Отдельно хочу сказать, что этот метод теоретически может "выстрелить" при формированиий коммерческой отчетности по поставкам - получается для каждой позиции в отчете надо будет формировать СФ, а затем откатывать. Не тяжеловато будет?


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


Принять этот ответ
Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 11:43 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Пт, авг 20 2004, 08:19
Сообщения: 602
Вот мы и докопались до сути проблемы. Дело не в округлении - это всего лишь катализатор, а избыток/недостача средств на счетах отдельных дебиторов. :)

Тут мы ступаем на более зыбкую почву, так что утверждать ничего не буду, сообщу лишь общие наблюдения. С постоянными клиентами вопрос расхождения суммы предоплаты не острый. Во-первых, отчетные документы (фактуры) они получают, и по ним видят суммы. Объяснить им, что таковы особенности системы учеты, как правило, проблемы не представляет (конечно, есть особо упертые, но такие есть везде, и подход к ним в каждом случае отдельный).
Во-вторых, изменение подхода на подсчет не по общему объему заказа, а по факту, не есть игра в одни ворота - в одном случае с клиента требуется на 2 копейки больше, в другом - на 3 копейки меньше. Люди разумные это понимают, и переносить остатки свободных денег по контракту можно (у нас это делают сами коммерсанты) без особых проблем.
В-третьих, проблема одноразовых покупателей не так уж уникальна. А что если клиент, с которым вы работали последний год, обанкротился или вообще исчез вместе со своей бухгалтерии в направлении горячих южных стран? Как тогда будете списывать недостачу? Да, списать можно, но геморрой еще то будет.
В-четвертых, эту проблему частично можно решить на уровне системы так, чтобы система в real-time анализировала что и по какой сумме отгружается. Например, в юзер-экзитах кредитного менеджмента (или головной программы) прописать проверку свободных денег в рамках данного контракта/заказа в момент формирования отгрузки с тем, что уже было отгружено в пределах СД (к нас для этих целей используется собственная структура ИСЛ, куда пишутся агреггированные данные о движении денег в рамках одного контракта) и с тем, что уже реализовано (данные FI). Если сумма превышена, то отгрузку можно блокировать с выводом подробного мессаджа. У нас внедрена похожая вещь (правда на уровне сохранения заказа, а не поставки).

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

_________________
С уважением,

Сабир.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 12:29 
Гость
LKU написал(а):
Evgenii, мысль интересная! А можно огласить технические подробности?
1. Как именно моделируется фактура - с сохранением или без.
2. Если без сохранения, то как считываются значения цен?


Увы, :-( но технические подробности я не знаю, постараюсь выяснить у нашего ABAP консультанта, может быть он подскажет, как моделировать счет-фактуру в SD!!! Выясню, напишу!


Принять этот ответ
Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 13:05 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 14:35
Сообщения: 4375
Откуда: Москва
Спасибо, будем ждать! (ну и сами, конечно, покопаемся :) )

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 17 2006, 14:13 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 14:35
Сообщения: 4375
Откуда: Москва
LKU написал(а):
Так что я вижу два варианта:
А) Просто поставить предпосылку, запрещающую печать накладной, пока нет фактуры. Минус - пользователям придется сначала создать поставку, потом фактуру, потом снова вернуться к поставке, чтобы ее напечатать.
Б) Сделать в поставке рассчет цен идентичный тому, что есть в фактуре и печатать цены из поставки. А для этого надо:
- включить схему калькуляции в поставке
- научиться копировать ручные условия цен из заказа в поставку (отсюда мой вопрос)
- изменить программу печати Торг-12.


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

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 17 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 4 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB