Добрый день. Имеется ТиС, естественно допиленная вдоль и поперек. Партии имеются.

Подскажите, пожалуйста, способы реализации учета остатков товара по срокам реализации.
Ну то есть последний срок, когда товар еще можно продать!

Спасибо.

В приходную добавить колонку Срок реализации.
При проведении приходной в справочник Партии вписывать срок.
Готово.

Ну как-то так.
В бух учете это бы сработало. В тис не знаю.

Нет справочника Партии. Есть регистр ПартииТоваров.

Насколько я помню, то значение измерения Партия - это как раз одниоменный справочник.

есть они, на руках когда-то были, конфигурации по фармацефтике. Вот они по этой теме. в том числе ТиС доработанные.

Измерения: Фирма,Склад,Товар,Статус,Контрагент,Поставщик,Поставка,ПрихДокумент

Это в Бухии есть Субконо и одноименный справочник Партия, Партии или как то так.

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

Создать отдельный справочник (аналог регистра сведений)
В него писать данные:
Документ поступления/Номенклатура/Срок годности
При проведении ПН писать в справочник.

хорошо. а отчеты? связать реализацию со сроками годности.

Наверное, лучше завести еще один регистр, и потом, там где в коде встречаются партии вставить еще соответствующие движения. Плюс еще как-то нужно реализовать контроль остатков. Плюс оприходование, списание так как это увеличит пересортицу.

Как то так.

по сути - срок годности привязан больше всего к партии. это дополнительное качество партии. или в вашем случае в партии разные сроки годности попадаются?

да кто его знает. это еще нужно выяснять.
Все равно даже если все поставки с одинаковым конечным сроком реализации, его (срок реализации) нужно куда-то впихнуть !

шото заговариваюся

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

Можно купить товар, изготовленный вчера, а можно - полгода назад. Срок реализации будет разный. Никогда не будет совпадать с датой годности товра. Так как покупателю нужно тоже какое-то время на реализацию. То есть срок реализации индивидуален для каждого товара и вводится вручную.

реквизит... новый реквизит в существующем регистре. как его появление влияет на прописывание стандартных методов, функций..

Как писал классик : "покиньте ту хххню і подивіться фільм Хабібуліна"
Вы вообще представляете, как это реально будет работать ?
На наших отечественных складах с трудом могут учитывать количество в пределах артикула, а учитывать сроки годности внутри артикула так, чтобы это соответствовало реальности... ой.
Мне приходилось делать сроки годности 2 (два) раза. По методу, который указал Ardi. Один раз на бакалейной базе. А второй раз в могазинчике бытовой химии. Завсклад физически не может навести у себя такой порядок. Даже умозрительно. Мало того, это известно заранее.

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

П.С.
Не. ну мне один чувак рассказывал, что на "Орифлейме" учитывают сроки по-честному. Но судя по тем рассказам, там не отечественные склады. Там какое-то зазеркалье.

Смотря вообще сколько партий в месяц. Например в месяц один приход. И потом продают этот приход и прошлый.

И получим автоматическое проставление сроков в документе согласно учету.
Ну и потом пусть руками правят как хотят.

А совсем чёткий учет сроков тоже думаю не нужен.

Та ладно
Если клиент не готов купить и содержать пару-тройку принтеров этикеток и потребное количество мобильных ТСД(на каждый склад) - посылать лесом/полем/огородом. Если готов - нормальная задача.
Хотя, если под "отечественностью" понимать убеждения, что все можно сделать на голом энтузиазме(причем "от руки и на глаз"), то я с Вами полностью согласен.)

Тут возникают вопросы реализации. С ТСД идут какие либо дрова, обработки 1С, протоколы обмена и т.д.
т.е. какова сложность подключения ТСД к 7.7?

Спасибо.


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

С 1с7.7 я ничего подобного не делал. НО пару раз обходился "вообще без ничего". На ТСД было что-то Вин-подобное, он подключался к серверу по РДП и работал в общей базе. Нужно просто отследить факт подключения такого пользователя и "подсунуть" ему адаптированные под такую работу формы.

Самый простой алгоритм - дата реализации в реквизит регистра партии + отчет.

Я більше виступаю за окремий регістр обліку. Плюси:
1) Не чипаємо існуючі алгоритми партійного обліку;
2) Так як ефективність для реальної роботи дуже сумнівна (як зазначалось вище), легше буде цей механізм виключити надалі;
3) Не по всім товарам, можливо, необхідно мати терміни реалізації.