одно лечим другое калечим ...
вместо того чтобы полностью устранить баг - вы советуете закрыть его и добавить новый ...
рекомендации советчикам : задумываться о качестве своих советов;
рекомендации просящим : глубоко анализировать полученный совет
|
одно лечим другое калечим ...
вместо того чтобы полностью устранить баг - вы советуете закрыть его и добавить новый ...
рекомендации советчикам : задумываться о качестве своих советов;
рекомендации просящим : глубоко анализировать полученный совет
Кратк. - сестр. тал. !
Не совсем с вами согласен
Баг не добавляется, просто модуль БВ приводиться в соотвествии с константой.
Возможно по учетной политеке предприятия принято что оплата ВСЕГДА первое или второе событие (что часто используется с абонплатой - что первично оплата абонплаты или услуга которая еще не оказана, т.к. абонплата платится вперед?)
именно добавляется ... причем в том месте где его раньше не было ...
т.е. разрабочики как бы его зафиксировали (потому что таки да в ранних релизах он подчинялся константе), но фиксить его (т.е. делать нормальной работу БВ) не стали, вместо этого влепили заплатку , которая опять же таки да решила проблему...
нормальных способов решения проблем была масса... как минимум должно было бы быть предложение автоматической свертки по одинаковым заказам...
но если разработчики не удосужились по-человечески решить проблему (но кое как решили)- вы же предлагаете создать именно баг....
з.ы. не знаю ни одного предприятия где в учетной политике ВСЕГДА первое событие оплата(или услуга, т.е. четко определено и подругому быть не может)
абон плата не всегда платится вперед ....
=) спорим дальше ?
Кратк. - сестр. тал. !
Можно спорить и дальше, но мне кажется что все равно каждый останется при своем мнении
Знаю минимум 2 компании которые именно в части абонплаты оплату воспринимают всегда как первое событие
какой то определенный вид оплаты возможно и будет всегда первым событием(тут уже действительно вступает в силу учетная политика предприятия) .. но не ВСЕ виды оплаты будут таковыми ... согласны ?
да и спорт то собссно о том , стоит ли изменять механизм проведения БВ ... возвращая спор в предыдущее русло хочу отметить , что на мой взгляд вы советуете сделать баг =) ...
давайте лучше сюда вытащим модуль проведения БВ и вместе постараемся подумать .. как сделать его правильным..
Последний раз редактировалось Mulder_1; 19.10.2009 в 09:57.
Кратк. - сестр. тал. !
С лету вижу несколько вариантов
1 вариант
1. Модуль проведения
1.1 Выгрузить табличную часть в ТЗ
1.2 Свернуть ТЗ
1.3 Проходить не построкам табличной части, а построкам ТЗ
2. Модуль формы
2.1 Изменить процедуру ИзмЗаказ(), так чтобы суммы СуммаО и НДСО не вычислялась если в документе уже есть такой же заказ по такому же движению
Минус данного варианта - если пользователь изменит заказ в той строке, где первый раз был проставлен заказ, то в другой строке СуммаО и НДСО не пересчитаются (или в проц. ИзмЗаказ() все время пересчитывать все строки документа)
2 вариант.
Определить строки документа в которых повторяется заказ и в этих строках перераспределить СуммаО и НДСО.
Если перераспределенные значения записать в строки документа, то при перепроведении документа могут возникнуть проблемы с повторным переспределением
Т.е. оптимально создать еще 2 реквизита табличной части куда и распределять новые значения СуммаО и НДСО, соотвественно и в модуле проведения прописать новые реквизиты
Может еще придумать множество вариантов обхода данной проблемы, но самый оптимальный будет вариант, когда известно в каких случаях может повторяться заказ в БВ. Т.е. под конретное предприятие
Да и заказчик данного вопроса молчит
Последний раз редактировалось DanilKr; 19.10.2009 в 12:37.
Скажите плиз что надо для набора накладных в 1с?
1С предприятие 8. Конфигурация "Управление торговлей" 2.3.3.4.
В документе "Поступление товаров и услуг", в табличной части "Товары" есть кнопочка "Серийные номера". При нажатии на нее открывается обработка по заполнению серийных номеров.
Вопрос. При проведении документа никаких движений по регистрам с использованием введенных серийных номеров не формируется. Как же тогда можно узнать какие серийники есть на складе, а какие уже отгружены?
Я в курсе. Она и в некоторых других документах есть.
Но суть вопроса не в том.
Вопрос в том как реализовать учет серийников? Использовать для этого серии не подойдет, т.к. при поступлении большой партии товара получим документ с сотней, а может и больше строк и количеством в каждой строке 1. Такая же картина получится и при отгрузке. В результате ставим документ на проведение и идем курить бамбук? Есть предложение порациональнее?
Опыт имеется.
Перед тем, как создавать регистр, нужно понимать ЗАЧЕМ он нужен.
Т.е. зачем Вам складской учет серийников? Какие отчеты нужны по его данным?
Ответить на эти вопросы могут помочь другие вопросы: о роде деятельности предприятия, например.
И еще ... складской учет серийников - непростая задача с управленческой точки зрения... регистр сделать несложно... а вот заполнить его корректно - это задача.
В большинстве известных мне случаев (торговля техникой) достаточно знать дату приобретения и дату продажи, а также длительность полученной и длительность предоставленной гарантии. Для решения этой задачи ДОСТАТОЧНО наличия серийников в документах покупки и продажи.
Исключение - сервисный центр, но сервисному центру вообще нужно ГОРАЗДО больше аналитики.
Спасибо.
Каким образом поставить запрет на проводку расходной накладной при превышении кредита клиентом. В конфигураторе-константы, есть такое - и есть два значения-да и нет. А вот где их проставить?
Социальные закладки