Хотелки Опции

[ea]

Версия, в принципе, не важна - смотрел в последней на предмет изменений, дык нет там этого.

1. Возможность печати документов и отчетов не только в базовых единицах измерения. В УПП/УТ в карточке товара есть единица измерения для формирования отчетов. Может есть смысл сделать также? В документах, в принципе, альтернативная единица измерения уже итак присутствует - хотелось бы иметь возможность печатать документы в ней.
2. Работа с ПККМ АТОЛ. В данный момент выгрузка характеристик товаров сводится к тому, что в файле формируется одна схема разрезов "характеристики", в ней валом идут все значения, и для каждого товара подразуемевается режим работы "с заданным списком".
В Далионе есть возможность на каждый товар задать свой тип дополнительных характеристик, и хотелось бы, чтобы в "кассу" это выгружалось разными схемами и с указанием режима работы (полный список, заданный список, заданный список с остатком).
Проблема в следущем - есть товары, учет которых строится в разрезе партий с учетов остатков. В этом случае вариант "заданного списка с остатком" вполне подходит. Но есть еще и услуги, реализация которых ведется в разрезе по врачам. Список врачей "забит" в характеристиках услуги, и его нужно выгружать и использовать на кассе в варианте "полный список", так как здесь привязка к остаткам смысла не имеет.

[Михин Константин]

1. Предложение о формировании отчетов в других единицах будет рассмотрено, у нас справшивали про эту возможность для формирования отчетов по производству. Для каких целей требуется печать документов в различных единицах?
2. Почему для услуг не подходит вариант - "Заданный список"?

[Bладислав]

2. Почему для услуг не подходит вариант - "Заданный список"?

Для услуг подходит именно заданный список. А вот "Заданный список с остатком" не подходит.

[ea]

1. Поясню на примере. Есть несколько аптек. Витамины для кошек закупаются банкам по 100 штук, а в розницу "уходят" поштучно. Соответственно, этот и весь подобный товар "приводится" к той ЕИ, которая у нас будет использоваться на кассе. Но центральный склад оперирует только крупными упаковками, соответственно в документах и в отчетах для них более удобно и логично оперировать более крупными ЕИ.
Вариант, когда те же витамины могут прийдти банками по 50шт или по 200шт, и кладовщиком будут посчитаны реальные места, а программа в отчете по остаткам пересчитает по коэффициенту 100, нами обговаривался. Теоретически, сказали, он возможен Но вряд ли, так как номенклатура не очень обширная, поставщики и вид упаковок практически стабилен и неизменен. Поэтому, если ситуация возникнет, то будут разруливать "руками".

2. С характеристиками все сложно. Чем больше смотрю как это сделано, тем больше мне не нравиться.
Тоже постараемся разобрать на примере.
В аптечке есть ряд услуг, которые могут оказывать несколько врачей. Услуги введены в справочник номенклатуры, врачи заведены как "характеристики". Если врач иванов может оказывать пять наименований услуг, то соответственно для каждой услуги он добавлен в характеристики товара, и при выгрузке на кассу в файл он попадет ПЯТЬ раз с разными кодами в секцию $$$ADDASPECTVALUES. Т.е., как я понимаю, выгружаются именно элементы справочника "ХарактеристикиНоменклатуры".
Чем плохо. С точки зрения Фронтола это абсолютно разные элементы. И если мы будем печатать отчет по разрезам (а клиент требует его печатать при закрытии смены), то в этом отчете фамилия иванов будет отражена пять раз, что не логично.
Второй минус - растет секция $$$ADDASPECTVALUES в формируемом файле, и раздуваются разрезы во фронтоле. Это будет сказываться на скорости обмена и работы кассы.
В нашем случае примерный подсчет показывает, что список услуг содержит порядка 100 позиций, и 15 врачей по аптекам. Итого 1500 записей в секции $$$ADDASPECTVALUES и 1500 записей в секции $$$REPLACEASPECTREMAINSWITHOUTSALE. А все можно сократить до 15 записей, сформировав отдельную схему разрезов.
Соображения. Повторюсь про то, чтобы каждый тип доп.характеристик выгружался на кассу отдельной схемой разрезов, и не раздувался параллельно списку номенклатуры. В качестве значения разреза выгружать не элемент справочника "ХарактеристикиНоменклатуры", а оперировать "ЗначениямиСвойствОбъектов".
Ну и чтобы можно было указывать для каждого типа доп.характеристик "вариант использования разрезов" для фронтола. Сейчас ставится для всех вариант 1 "заданный список". Но для товаров было бы неплохо указать "заданный список с остатком", чтобы проданые партии не показывались кассирам при ручном варианте регистрации. Для услуг в "нашей" аптеке, можно было бы вообще указать "весь список", при условии что список врачей выгружен отдельной схемой, как я и описывал выше. Тогда можно эти товары и услуги не выгружать в секцию $$$REPLACEASPECTREMAINSWITHOUTSALE, и тем самым еще ужать файл обмена. Но это мои варианты использования, у кого-то будут другие, поэтому желательно чтобы это можно было регулировать самому из далиона.
Надеюсь я ничего не напутал со справочниками На освоение 8ки не так много времени, как этого бы хотелось.

3. Обработка "Управление кассами"
"Заполнить всеми товарами" - заполняет всеми товарами и услугами
"Заполнить по остаткам" - заполняет только товарами
"Заполнить из документа" - смотря какой укажешь документ
"Добавить по остаткам" - добавляет только товары
"Добавить из документа" - смотря какой укажешь документ

Если нужно выгрузить на кассу товары, числящиеся на остатках и услуги, то приходится это делать в два приема - "Заполнить по остаткам", а затем "Добавить из документа", и искать указывать акт переоценки, созданный ради такого отдельно с услугами. Неудобно это. Желательно чтобы услуги также добавлялись в выгружаемый перечень без лишних манипуляций.

[Михин Константин]

1. Про приход товаров мне полностью понятно. Не ясно зачем нужна печать документов либо в штуках, либо в упаковках? Если принимают товар в упаковках, то и печатная форма прежде всего нужна в упаковках.
2. Разрезы в Далионе не предусматривают их использование как сотрудников (менеджеров, врачей). Ситуация для программы не типичная, поэтому и никакой оптимизации под нее нет.

У нас нет информации насколько скорость Фронтола снижается от увеличения количества полей в таблице значений разрезов, поэтому тяжело сказать, насколько это критично. Никто из клиентов с большим количеством разрезов на скорость работы и загрузки не жаловался.

Почему выгружаются именно характеристики, а не свойства и их значения.
Несколько причин:
а) Во Фронтоле ограниченно количество свойств
б) Можно заводить характеристики не указывая значений свойств
в) Могут быть две характеристики с одинаковыми свойствами, но разными названиями. Для конкретных товаров персонал посчитал нецелесообразным заводить дополнительное свойство (а значит и категорию)
г) Замедляется поиск характеристик, при большом количестве чеков.

Сам не как следует не изучал, в Фронтол добавились Сотрудники, может имеет смысл в эту сторону смотреть.

3. Сделаем работу с услугами более удобной.

[ea]

1. В том то и смысл, что базовая единица является самой мелкой - штукой. По ней работают кассы. А центральный склад работает упаковками. И отчеты им логичнее видеть в упаковках. А отчеты формируются без вариантов в базовых.
С документами, с одной стороны проще - там можно поставить "крупную" ЕИ и оформить/распечатать документы в них. Но по умолчанию подставляются все равно штуки (базовая), и каждый раз при оформлении документов нужно менять по каждой позиции ЕИ со штук на упаковки. Не комильфо опять же.
Если посмотреть опять же в сторону УТ, то там можно указать ЕИ для документов и для отчетов. Это лучше.

2. Константин, давайте не будем привязываться к сотрудникам. Я просто привел пример реальной задачи, и какую не совсем логичную штуку мы мы получаем в файле выгрузки. У нас там же еще будет и учет продаж товаров в разрезе по партиям, которые формируются как характеристики, и которые сейчас будут также "кривовасто" выгружаться - одна накладная на 50 товаров будет выгружена 50 раз в разрезы.
Давайте лучше подумаем как сделать выгрузку характеристик наиболее близко к той идеологии разрезов, что задумывалась во фронтоле.

Добавлю - помимо "нормального" фронтола, есть еще фронтол.се, для которого есть ограничения в размере базы и в производительности используемых на кассах ПК.

3. Спасибо

[Михин Константин]

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

[AngelK]

Давайте лучше подумаем как сделать выгрузку характеристик наиболее близко к той идеологии разрезов, что задумывалась во фронтоле.

Или "Фронт" другой написать, а то что то с идеологией не срастается см ветку про минимальную цену и округления

[ea]

Или "Фронт" другой написать, а то что то с идеологией не срастается см ветку про минимальную цену и округления

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