Текущее время: Вс, янв 21 2018, 10:27

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


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


ВНИМАНИЕ!

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



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

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

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


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

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

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

Сабир.


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

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

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


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

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

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

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

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

Сабир.


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

Зарегистрирован:
Вт, май 17 2005, 14:35
Сообщения: 4351
Откуда: Москва
Да я понимаю, если по одному заказу есть несколько поставок или физически невозможно отгрузить ровно столько, сколько заказали (отгрузка идет на вес), то борьба с копейками бесмысленна.
Но у нас все меряется в штуках, и зачастую по одному заказу одна поставка, просто в этой поставке товар отгружается из разных партий с разными ГТД => разделение партий в поставке и в фактуре их тоже соединять в одну нельзя. Да еще как правило применяется 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
Здравствуйте, Евгений.

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


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

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

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

Сабир.


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

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

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


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

Зарегистрирован:
Вт, май 17 2005, 14:35
Сообщения: 4351
Откуда: Москва
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
Сообщения: 4351
Откуда: Москва
Спасибо, будем ждать! (ну и сами, конечно, покопаемся :) )

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


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

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


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

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


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

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


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

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


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

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