! 1С ВСД в ГИС Меркурий » 1Cv7 ВСД в ГИС Меркурий

Мне кажется это какая то
узко специализированная потребность. Из всего описанного я понял чо Вы хотите к ТОВАРУ привязать конкретные партии из ВЕТИСА и только их списывать при продаже. Так?

Pentyukhov Sergey писал(а):

Вы хотите к ТОВАРУ привязать конкретные партии из ВЕТИСА и только их списывать при продаже. Так?

Совершенно верно. У меня пришел товар с тремя разными датами изг.:01.06.19, 06.06.19 и 12.06.19. Сейчас по умолчанию списывается партия 01.06.19 (принцип ФИФО -что раньше пришло то первым списывается). Но мне нужно чтобы списывалась дата 06.06.19. А дату от 01.06.19 списывать не нужно. Как это сделать? Сейчас мы ручками правим.

Написать свой модуль распределения, для этого есть Интеграция2.ert, в нее можно переопределить функцию распределения{получения} партий. Вопрос где хранить список партиий для конкретно взятой номенклатуоы. Если у Вас стандартная Торговля, можно использовать ДопСвойства. Создаете ДопСвойство с сылкой на ПартииВСД, И С НИМИ РАБОТАЕТЕ. КАК вариант.

Pentyukhov Sergey писал(а):

Написать свой модуль распределения, для этого есть Интеграция2.ert, в нее можно переопределить функцию распределения{получения} партий. Вопрос где хранить список партиий для конкретно взятой номенклатуоы. Если у Вас стандартная Торговля, можно использовать ДопСвойства. Создаете ДопСвойство с сылкой на ПартииВСД, И С НИМИ РАБОТАЕТЕ. КАК вариант.

Написать свой модуль распределения это не проблема. Здесь вопрос больше к разработчику: если я приобрел обработку у KB99, то мне нужно понять планируют ли разработчик это внедрять в пакете стандартных обновлений /доработок. Одновременно у меня вопрос к форумчанам (пользователям Меркурия): это я один "белая ворона"? Другим пользователям Меркурия это неактуально что ли? Или народ ещё "не врубился" в глубокие слои? Если я белая ворона то я знаю как мне это сделать в лучшем для меня варианте. Но зачем мне это делать если через неделю разработчик сделает это обновление и моя доработка начнет конфликтовать с его обновлением. Вот в чем вопрос. У разработчика сейчас в работе "ВСД2_Транзакция - выбор партии по сроку годности Реализации" https://redmine.kb99.pro/issues/2841, по логике этот функционал можно адаптировать под выбор даты изготовления, потому что это два конца одной палки. Поэтому я жду что ответит Филипп

Отвечу за себя, нам персонально привязывать ОПРЕДЕЛЕННЫЕ партии к товару нет необходимости. Будем идти от реализации(документа) в табличной части будем указывать или реальную дату партии или ЖЕЛАЕМУЮ и подбирать из ближних.

Pentyukhov Sergey писал(а):

Отвечу за себя, нам персонально привязывать ОПРЕДЕЛЕННЫЕ партии к товару нет необходимости. Будем идти от реализации(документа) в табличной части будем указывать или реальную дату партии или ЖЕЛАЕМУЮ и подбирать из ближних.

в документе реализации (накладная) нет выбора партии, или вы это сами допилили? Это кстати неплохая идея вывести в табличную часть накладной выбор партии. Только вот списание партий делает "ГО Реализация", и именно эта обработка работает по принципу ФИФО. Опять же если вы сами прописали чтобы партия "подтягивалась" из накладной, то это понятно. Или это все входит в стандартный функционал? Может у меня старая версия? Вы вообще тестировали, это работает?

Айрат, привязать к ВСД_Продукция_Элемент справочник ВСД_Партии в принципе можно (делали такую привязку)
насколько это правильно - не берусь судить, но у меня много вопросов к такому алгоритму...

1. выбирать конкретную партии в документе Реализация
2. указать дату изготовления в Реализации (так делают многие)

Самара Айрат писал(а):

Pentyukhov Sergey писал(а):

Написать свой модуль распределения, для этого есть Интеграция2.ert, в нее можно переопределить функцию распределения{получения} партий. Вопрос где хранить список партиий для конкретно взятой номенклатуоы. Если у Вас стандартная Торговля, можно использовать ДопСвойства. Создаете ДопСвойство с сылкой на ПартииВСД, И С НИМИ РАБОТАЕТЕ. КАК вариант.

Написать свой модуль распределения это не проблема. Здесь вопрос больше к разработчику: если я приобрел обработку у KB99, то мне нужно понять планируют ли разработчик это внедрять в пакете стандартных обновлений /доработок. Одновременно у меня вопрос к форумчанам (пользователям Меркурия): это я один "белая ворона"? Другим пользователям Меркурия это неактуально что ли? Или народ ещё "не врубился" в глубокие слои? Если я белая ворона то я знаю как мне это сделать в лучшем для меня варианте. Но зачем мне это делать если через неделю разработчик сделает это обновление и моя доработка начнет конфликтовать с его обновлением. Вот в чем вопрос. У разработчика сейчас в работе "ВСД2_Транзакция - выбор партии по сроку годности Реализации" https://redmine.kb99.pro/issues/2841, по логике этот функционал можно адаптировать под выбор даты изготовления, потому что это два конца одной палки. Поэтому я жду что ответит Филипп

Здравствуйте, я давно перестал воспринимать разработку КБ99 как готовое решение. Максимум - пример реализации на базе ТИС и модель для переработки под себя.
В итоге определил инструменты, которые смогли мне давать результат и стал подстраивать их у себя. Использую далеко не весь функционал. Например для решения Вашего вопроса, написал обработку подбора партий. В моем случае нельзя заранее привязать партии меркурия к нашим, поэтому у меня пользователь задает приоритет распределения перед каждым списанием. Эти данные используются для создания документов ВСД_Транзакция.

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

Мне кажется что доработки, которые востребованы и актуальны для >51% пользователей, разработчик должен делать по умолчанию в момент выявления данной потребности и эти обновления должны входить в стандартный пакет обновлений для базовых версий 1С. Это конкурентное преимущество разработчика - поддерживать свой продукт на максимально функциональном уровне, как это делают напр. victuan и прочие разработчики на Инфостарте. Но если версии 1С имеют нестандартную конфигурацию, то тогда пользователи заказывают адаптацию новых обновлений под свою версию за дополнительную плату. Это золотой стандарт по которому работают все рейтинговые разработчики ПО для 1С. По данной конкретной теме я так понял что пользователям не заинтересовались моей доработкой по привязке партий к номенклатуре, поэтому Филипп не будет включать её в базовый пакт обновлений. Значит я буду заказывать для себя эту дорабтку на платной индивидуальной основе. Филипп примите от меня заявку на доработку моей 1С, буду кайфовать один и пусть мне все завидуют)) Только я конечно все равно думаю что данная доработка сверхактуальна для всех, просто пока не все врубились мне кажется. Либо на данном форуме присутствует только 1% пользователей продукта kb99, и из них только половина работает по полному функционалу.

Самара Айрат писал(а):

Мне кажется что доработки, которые востребованы и актуальны для >51% пользователей, разработчик должен делать по умолчанию

...
Только я конечно все равно думаю что данная доработка сверхактуальна для всех, просто пока не все врубились мне кажется. Либо на данном форуме присутствует только 1% пользователей продукта kb99, и из них только половина работает по полному функционалу.

а Давайте Вы за других Думать и решать не будите.... Зачем так огульно всех ХАИТЬ.
У нас тоже специфичная конфигурация и "Тараканов" по распределению партий НЕ МЕНЬШЕ.

Сделали для себя из ОСНОВНОЙ поставки нужные интеграции.

Конечно стало немного дольше накатывать новые обновления, но это мелочи.

Да все верно, конфигурация не типовая.
И задачи, которые приходится решать тоже не типовые.
Гарантий я не искал, единственное всегда хотел видеть что-то вроде демопримера или описания к обработкам, что для чего используется.
Описания к коду есть, они хорошие, а вот назначения обработок сначала было для меня не очевидным.
Может даже вы все это уже сделали.

1. Мы постоянно работаем над улучшением решения, список задач и изменения вносятся практически ежедневно - смотри Хранилище
2. Мы добавляем новые функции необходимые всем пользователям смотри задачи
3. Максимально подробно документируем изменения, показываем необходимость этих изменений
4. Занимаемся поддержкой и обучением = 10 минутные видео
5. Интеграция с ГИС Меркурий - это сложный продукт, в котором нужно учитывать тысячи взаимосвязей, которые еще изменяются. Ни один самый гениальный программист не напишет такую систему сразу, поэтому единственно возможное решение - это открытое решение с открытым исходным кодом, чтобы все могли посмотреть и проверить решение, изменить и адаптировать для себя, именно поэтому тратится так много усилий на коммиты в git. ( фактически это стандарт в программировании, тем более в больших проектах. В Инфостарте, к сожалению не поддерживается данный функционал. )

Ваша конфигурация совершенно нестандартна, если бы Вы использовали рекомендации 1С по разработке, было бы намного проще.
В данный момент, к сожалению, загрузка очень большая, поэтому могу порекомендовать наших партнеров, кто занимается развитием проекта и на высоком уровне выполняет работы, например Pentyukhov Sergey

Так я вроде никого не ругаю. Наоборот, даю обратную связь и делаю свои предложения по развитию продукта. Больше их сюда на Форум выкладывать не буду. С удовольствием приму помощь от Pentyukhov Sergey на взаимовыгодных условиях. У меня нет штатного программиста, работаем по аутсорсу. Есть свои идеи по автоматизации некоторых функций. Если мои идею будут полезны и интересны другим я только рад. Конечная цель - это полная автоматизация процесса с максимальными функциональными возможностями/настройками. Мы - конечные потребители вашего программного продукта, и ежедневно работаем, тестируем и формируем свои предложения по улучшению и развитию продукта. Прошу Pentyukhov Sergey написать мне в личку. У меня есть техзаданий где-то на 10-15 часов работы.