Работа с заказами

[Бродяга_Джон]

...ну да, ведётся, но многое не учитывает, а в сезон просто не сможет учесть, не приспособлена она для этого нормально

ДЭНСИ вообще не приспособлена для какой-либо аналитики, не ее это дело. Задача Дэнси - зафиксировать продажи, а вот обработку этой информации делайте в другом месте. Зачем-то вы выгружаете продажи. И выгружаете в 1С.

я вообще-то про аналитику УТ говорил, а не ДК

[Alexander]

Пример.
Хозяин нескольких торговых точек. У него (и только у него) на ноуте - 1С.
На торговых точках - только ПК с ДЭНСИ: КАССой (+3G-модемы для сеансовой связи с Интернет)
Номенклатура <= 100 позиций (например, сыры/колбасы).
По мере продажи товара каждая точка должна сформировать заказ на пополнение. На основе собранных со всех точек заказов хозяин формирует сводный заказ поставщику.

Ну а если у Вас супермаркет, так по-умолчанию функционал заказов отключен.

P.S. Если необдуманно заказанный товар залежится и испортится, хозяин всегда сможет депремировать нерадивого продавца.
P.P.S. К этому же примеру относятся запросы на включение в ДЭНСИ: КАССу функционала прогрузки весов с печатью этикеток. Я тоже всегда считал, что это функционал товароучетки, но что делать, если на точках только ДЭНСИ: КАССА? На текущий момент приходится объезжать все точки для прогрузки весов с ноутбука.

[kedr19]

Все прочитал, идея расширения функционала регистраций очень хорошая.
Если смотреть на данное предложение в общем, то видим следующую картину:
1. Как бы мы не назвали операцию (продажа, возврат, заказ и т.д.), это тип транзакции (55, 56, 57 и т.д.) и способ работы с ККМ (пробивать или не пробивать).
2. Так как типов транзакций уже 2 (продажа, возврат) и они расширяются, и видимо будут расширяться. То нужно пересмотреть механизм их определения.
3. Так же замечается тенденция деления типов транзакций на группы (продажа и возврат, заказ поставщику и заказ покупателю). Нужно определить оптимальный способ переключения между ними.
4. Если речь идет о заказах, то нужно предусмотреть ситуацию ввода не существующих позиций в БД, например как реализован механизм свободной цены.
5. И главное четко понимать что ДЕНСИ это во многих организациях единственный оплот автоматизации точки продажи, потому нужно не забывать о тех о ком привел пример Александр.

Мои идеи:
1. В настройках программы выбирать в какую по умолчанию регистрацию будут входить при открытия окна регистрации. (это удобно когда заказы делают в самом конце рабочей смены. Избавит от нажатия лишних кнопок и случайных ошибок связанных с пробитием через ККМ).
2. Находясь в одной из групп типов транзакций окна регистрации делать переключение между ними (как открывается чек возврата из окна регистрации, так же можно перейти от продаж к заказам. Как сделать переключение на поставщика или покупателя оптимально пока нелезит ничего в голову), надо обсуждать).

[Бродяга_Джон]

2. Находясь в одной из групп типов транзакций окна регистрации делать переключение между ними (как открывается чек возврата из окна регистрации, так же можно перейти от продаж к заказам. Как сделать переключение на поставщика или покупателя оптимально пока нелезит ничего в голову), надо обсуждать).

для поставщика не выгодно, учётка (ут в частности) сама может формировать заказ поставщику, как по зявке покупателя так и по заявке пополнения торговой точки

лучше пусть будут заявка на пополнение и покупателя,
ибо это разные документы и именно их надо в учётке разделить явно,
а если нужно - учётка сама сформирует для поставщика заявку в учётке

[Alexander]

лучше пусть будут заявка на пополнение и покупателя,

Будем считать, что это уже устаканили.
Хотя в принципе здесь все зависит от обработки обмена а не от ДЭНСИ: КАССы.
А вообще в ДЭНСИ: КАССе можно назвать как-то нейтрально, например, "Заказ покупателя" и "Заказ администратора" (варианты: "Заказ со склада", "Заказ товаров" и т.п.)
Заказ отсутствующих в БД кассы товаров через "свободную цену" с вводом текстового комментария сделать можно, вопрос в том, как это на стороне товароучетки автоматически обрабатывать.

По технической реализации вообще была идея не плодить типы чеков, а ввести новые типы транзакций (условно - 70/71 = заказ покупателя/со склада).
Такая реализация (вместо использования типа транзакции 11 с новыми типами чека) безопаснее с точки зрения использования типовых или устаревших обработок обмена. Там, как правило, 11 транзакция попадает в таблицу проданных товаров и не всегда может быть корректно обработан неизвестный тип чека.

[Rafta]

А вообще в ДЭНСИ: КАССе можно назвать как-то нейтрально, например, "Заказ покупателя" и "Заказ администратора" (варианты: "Заказ со склада", "Заказ товаров" и т.п.)

Можно сделать их переменными, тогда в настройках каждый сможет назвать по-своему, как это представляется более удобным. А по-умолчанию пусть будут "Заказ покупателя" и "Заказ администратора"

По технической реализации вообще была идея не плодить типы чеков, а ввести новые типы транзакций (условно - 70/71 = заказ покупателя/со склада).

Совершенно верно - только новые типы транзакций.

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

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

[Rafta]

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

[kippolit]

погашение заказа, т.е. если привезли, заказ выкупили и как-то зафиксировать этот факт.

А смысл - заказ выкупили, предъявили карту клиента, продажа стала персонифицированной, и уже в обработке 1С проверить, есть ли выкупленный артикул в заказе у этого клиента. А то продавец забудет сделать погашение, лучше без человеческого фактора. А вот анулировать сделанный заказ, ну когда клиент передумал, это надо предусмотреть.

[Rafta]

Как летит время, полгода прошло, есть ли какое продвижение в этом направлении?

[Alexander]

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