Пожелания по доработкам Альфа-Авто
Внимание! Данный форум является модерируемым.
Для получения к нему доступа необходимо зарегистрироваться или авторизоваться на сайте.
Доступ к форуму партнерам «1C-Рарус» по дистрибуции предоставляется на сайте
rarus-soft.ru
Тогда почему
Когда просто создаешь реализацию и выбираешь эту номенклатуру яч проставляется.
И это правильно...
возник вопрос, у нас есть как и обычные склады, так и ордерно -ячеистые, причем ячейки заданы в карточках номенклатуры как ячейки по умолчанию. соотвественно движений по регистру остатков именно в разрезе ячеек -нет, и нас это очень устравивает, в последних релизах это поменяется?? т.е. придется хранить остатки прямо в разрезе ячеек??
Место того чтобы облегчить работу с программой, ее зачем то усложняют.
по практике 90 % клиентов имеет 1-2 склада и каждый товар имеет свою ячейку, раньше не обязательно было заводить ордерн яч склад, прописывать все параметры и т.п, а было можно указать ячейку по умолчанию для любого склада и она отбражалась в документах, и всех это устраивало.
Ну опять же, это мое мнение, может конечно я и не прав....
Добрый день, Светлана, на обычном складе нельзя задавать ячейки. Раньше это было возможно, что не совсем корректно, на будущем релизе будет введена проверка вида склада при создании ячеек.
я согласна с предыдущим мнением: мне кажется планируемый функционал в бущем только усложнит работу... может есть какой то смысл такого усложнения..
Светлана, чтобы номенклатура хранилась в ячейке, нужно создавать Приходный складской ордер, а данный документ можно создать только на ордерно-ячеистом складе. Обычный склад хранит остаток товара, но по ячейкам товар раскладывается только с помощью приходного складского ордера. То что раньше Вы создавали ячейки для обычного склада и устанавливали ячейки по умолчанию носило только информационный характер, по факту движения по ячейкам не было. Теперь возможность добавления ячейки по умолчанию будет только с указанием ордерно-ячеистого склада, что наиболее корректно.
Мое мнение.
Место того чтобы облегчить работу с программой, ее зачем то усложняют.
по практике 90 % клиентов имеет 1-2 склада и каждый товар имеет свою ячейку, раньше не обязательно было заводить ордерн яч склад, прописывать все параметры и т.п, а было можно указать ячейку по умолчанию для любого склада и она отбражалась в документах, и всех это устраивало.
Ну опять же, это мое мнение, может конечно я и не прав....
Суть проблемы тут
Здравствуйте!
ААА 5.0.13.05. При вводе реализации товаров на основании счета на оплату, не проставляются ячейки хранения.
Мое мнение.
Место того чтобы облегчить работу с программой, ее зачем то усложняют.
по практике 90 % клиентов имеет 1-2 склада и каждый товар имеет свою ячейку, раньше не обязательно было заводить ордерн яч склад, прописывать все параметры и т.п, а было можно указать ячейку по умолчанию для любого склада и она отбражалась в документах, и всех это устраивало.
Ну опять же, это мое мнение, может конечно я и не прав....
СПАСИБО команде поддержки и разработки!! приятно, когда к пожеланиям пользователей прислушиваются! на опыте использования разных программных продуктов - это немаловажная деталь.
а так же было бы не плохо в документ "Изменение цен" добавить заполнение цен
по рекомендованным ценам из прайс листа контрагента..
?..
Для каких целей?
в "Прайс-лист контрагента" много что надо добавлять для хорошей его загрузки и работы.
вот почитай
по рекомендованным ценам из прайс листа контрагента..
А это уже есть прайс-листы контрагентов-обработка-загрузка цен.
Для каких целей?
А это уже есть прайс-листы контрагентов-обработка-загрузка цен.
Доработка прайс-листа есть в планах, просьба опубликовывать вопросы в этой ветки :
Нашел след ошибку при закрытии нераспределенных заказов покупателей.
Воспроизводиться она только в случае если нумерация заказов покупателей идет не друг за другом а в произвольном порядке.
Вот пример:
Заказ №2 от 01.01.2015 10.00.00 Товар 1
Заказ №1 от 01.01.2015 12.00.00 Товар 1
при поступлении товара 1 он зарезервируется сначала под заказ №1, хотя должен по ФИФО под заказ №2
Если же у нас нумерация правильная то все нормально...
Надо в запросе поставить упорядочивание по дате заказа
Запрос.Текст = "ВЫБРАТЬ
| ТаблицаЗаказов.Заказ,
| ТаблицаЗаказов.Номенклатура,
| ТаблицаЗаказов.ХарактеристикаНоменклатуры,
| ЕСТЬNULL(ТаблицаЗаказов.ЗаказаноОстаток, 0)-ЕСТЬNULL(ТаблицаЗаказов.РезервОстаток, 0)-ЕСТЬNULL(ТаблицаРаспределений.КоличествоОстаток, 0) КАК Количество
|ИЗ
| РегистрНакопления.ЗаказыПокупателей.Остатки(
| &НаМомент,
//| Заказ.ПодразделениеКомпании = &ПодразделениеКомпании И
| " + ТекстОтбора + "Номенклатура В (&Номенклатура)) КАК ТаблицаЗаказов
|ЛЕВОЕ СОЕДИНЕНИЕ
| РегистрНакопления.ЗаказыРаспределение.Остатки(
| &НаМомент,
//| ЗаказПокупателя.ПодразделениеКомпании = &ПодразделениеКомпании И
| " + ТекстОтбораРаспределение + "Номенклатура В (&Номенклатура)) КАК ТаблицаРаспределений
|ПО
| ТаблицаЗаказов.Заказ = ТаблицаРаспределений.ЗаказПокупателя И
| ТаблицаЗаказов.Номенклатура = ТаблицаРаспределений.Номенклатура И
| ТаблицаЗаказов.ХарактеристикаНоменклатуры = ТаблицаРаспределений.ХарактеристикаНоменклатуры
|ГДЕ
| (ЕСТЬNULL(ТаблицаЗаказов.ЗаказаноОстаток, 0)-ЕСТЬNULL(ТаблицаЗаказов.РезервОстаток, 0)-ЕСТЬNULL(ТаблицаРаспределений.КоличествоОстаток, 0)) > 0
|ДЛЯ ИЗМЕНЕНИЯ
| РегистрНакопления.ЗаказыПокупателей.Остатки,
| РегистрНакопления.ЗаказыРаспределение.Остатки
|УПОРЯДОЧИТЬ ПО
| ТаблицаЗаказов.Заказ.Дата
|";
Прикрепленные файлы
Планируется ли добавления в Альфу механизма внутреннего чата между пользователями?..
+1
Данное пожелание будет зафиксировано, но в планы оно еще не добавлено.
Ситуация:
Были поступления товаров:
№1 от 28.12.14 с набором товаров №1 из 7шт;
№2 от 14.01.15 с набором товаров №2 из 5шт;
В наборы товаров №1 и №2 могут входить одинаковые товары.
10.02.15 на основании поступления №2 делается реализация товаров, причем часть товаров списывается из партии №1, а часть - из №2 автоматически (партии в документе не указаны).
Сегодня на основании поступления №1 вводим реализацию товаров, но в табличную часть попадают только те товары из партии №1, которые не были проданы в предыдущей реализации.
Использование документа "Заказ покупателя" не подходит, так как поступление товаров (для тюнинга) приходит под конкретный автомобиль, покупатель которого еще не известен.
Пожелание:
При вводе "Реализации товаров" на основании "Поступления товаров" количество товаров не обнулять и по умолчанию списывать с партии документа-основания, если для товара не будет указана другая партия. Если документ-основание не указан, то логика списания такая как сейчас.
В программе есть право "выборочное списание партии", при выставлении значения в истина, Вы сможете выбрать нужную партию при реализации.
Добрый день,
В программе есть право "выборочное списание партии", при выставлении значения в истина, Вы сможете выбрать нужную партию при реализации.
Реализацию таких товаров делают менеджеры отдела продаж автомобилей, им нужно быстро обслужить клиента, а поиск "правильной" партии для каждого товара лишь увеличит время обслуживания (в документе может быть до 8-12 позиций). А без указания партии для списания при вводе на основании Поступления товаров в большинстве случаев (почти всегда) в табличную часть товаров попадают не все позиции документа-основания.
Поэтому прошу в таких случаях партией списания считать документ-основание. Иначе теряется смысл ввода на основании, если из 10 позиций заполнятся только 3-5.
Поэтому прошу в таких случаях партией списания считать документ-основание. Иначе теряется смысл ввода на основании, если из 10 позиций заполнятся только 3-5.
При создании реализации товаров на основании поступления товаров программа переносит все запчасти из прихода, которые есть на остатках по данной партии. При этом в колонке "Партия" устанавливается сам документ поступления товаров. В момент добавления новых запчастей в эту реализацию программа не заполняет партию и после проведения документа списывает товар с партии в соответствии с установленной стратегией списания.
Поэтому прошу в таких случаях партией списания считать документ-основание. Иначе теряется смысл ввода на основании, если из 10 позиций заполнятся только 3-5.
Привожу пример:
1. 21.12.2014 приходят 9 товаров на склад тюнинга (поступление.png)
2. 31.12.2014 на основании этого поступления делается реализация (реализация1.png)
3. При проведении только товар "Боковая графика "Sltuning"" списался с партии документа-основания, остальные - с более ранних партий (партии1.png)
4. От клиента приняли деньги, но позже он отказался от покупки автомобиля, ему вернули деньги и сделали возврат товаров от покупателя
5. 29.01.2015 на основании того же поступления сделали реализацию (реализация2.png)
6. При проведении товары "Накладки зеркал окраш." и "Противотуманные фары" списались с более поздних партий
Релиз 5.0.12.02. Товары списывались по партям не в правильном порядке, как будто документ-основание не влияет на выбор партии для списания
Прикрепленные файлы
Нижеперечисленные пожелания из сообщения #159 приняты?
Добрый день!
Появились новые пожелания:
1. В форме заказ-наряда сделать доступным поле "Вид оплаты" в состоянии выполнен для того, чтобы кассиру было проще и быстрее выбрать "Безналичный расчет", если клиент оплачивает картой. На сервисе могут не знать как клиент будет оплачивать (на карте денег может не хватить например)
2. Сделать единую нумерацию печатной формы "Расходный кассовый ордер". При печати из документа "Расходный кассовый ордер" выходит одна нумерация, а из "Перемещение денежных средств" - другая. Когда кассир в конце дня делает отчет "кассовая книга", нумерация совсем неверная (могут даже два одинаковых номера встретиться от разных типов документов). Этот отчет сдается в бухгалтерию и сшивается в кассовую книгу, то есть из 1с-Бухгалтерии его печатать не хотим.
Аналогично для печатной формы "Приходный кассовый ордер".
3. Добавить в документ "Расходный кассовый ордер" хоз. операцию, где ИП может забрать деньги из кассы и никаких долгов по взаиморасчетам не возникает.
4. Разделить право доступа к складам на два - право на поступление и право на отгрузку. Потому что в документе "Перемещение товаров" нужно указывать два склада (отправитель и получатель), а у пользователя есть доступ только к складу-отправителю (чтобы мог списывать товары только со своего подразделения), и документ не проводится из-за этого. Операции с филиалами не подходят, так как на складе-получателе могут забыть сделать этот документ, поскольку товаров привезли от другого подразделения.
5. Создать документы истории по документам "Реализация автомобилей" (в табличной части: автомобиль, контрагент, сумма, номер документа, дата документа), "Реализация товаров" (в табличной части: контрагент, сумма, номер документа, дата документа) и "Заказ-наряд"(в табличной части: автомобиль, контрагент, сумма, вид ремонта, номер документа, дата документа), в которых указывать данные по продажам в предыдущих базах (например, при свертке все документы "Реализация автомобиля" сворачивать в один документ "Ввод остатков реализаций автомобилей"). Данная информация может использоваться в CRM сервиса. Например при записи на ремонт, чтобы определить покупал ли клиент этот автомобиль у нас, какую сумму он заплатил за товары за все время (и при этом не искать его в предыдущих базах) и т. д.
6. В печатную форму заказ-наряда добавить вывод согласия клиента на обработку персональных данных из карточки контрагента.
Прикрепленные файлы