{{branchTel}}

{{section.attributes.section}}

Все результаты

  • По вашему запросу {{search.q}} ничего не найдено.

Перейти на страницу поиска
{{countBasket}}

{{userFullName}}

Личный кабинет

Выйти
Доставка и оплата
Контакты

Обмен с Общепитом 8

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

Поиск  Правила 
Страницы: Пред. 1 2
RSS
Обмен с Общепитом 8
 
#26
18.10.2011 09:31:09
Цитата
Игорь Сухоруков пишет:
При XML-обмене производится обмен карточками.

Для обмена суммами накоплений по карте используется реквизит "Сумма накопленная" карточки.

Значение данного реквизита обновляется при совершении операций

с дисконтно-депозитным сервером.

Какие должны быть настройки карт и видов оплат, чтобы реквизит "Сумма накопленная" карточки падала из Рестарта в Общепит. Используем Общепит + ДДС + Рестарт.
 
 
 
#27
22.11.2011 17:11:07
Цитата
Игорь Сухоруков пишет:
.... и их использование (реквизит "Карточка" в документе "Чек" (Закрытие смены))

почему реквизит "Карточка" в документе "Данные продаж" не заполняются? Возможно ли это заполнени?
 
 
 
#28
24.11.2011 11:41:33
Цитата
КОФ пишет:
почему реквизит "Карточка" в документе "Данные продаж" не заполняются? Возможно ли это заполнени?

Какие релизы вы используете? Обновитесь до последних официальных
 
 
 
#29
30.11.2011 14:55:08
Цитата
....Обновитесь до последних официальных

Обновили до 2.0.28.3 — док. Данные продаж фронта:
закладка Оплаты:
- Вид оплаты = Карта (фискальное условие исп-я, Детализация — Персонификация платежа)
- фискальный = Истина
- Сумма оплаты = сумма по чеку
- Карточка = ..... пусто
 
 
 
#30
30.11.2011 15:12:17
хотя появилось поле Дисконтная карта и оно заполняется

P/S
Поправьте в журнале Документы Общепита гр. "Сумма" - там и в новом релизе стоит "Организация"
 
 
 
#31
31.01.2012 21:55:27
Добрый вечер!
1) При обмене между Рарус Общепит 2.0.28.3 и Рестарт (последний релиз на сегодняшний момент) получается вот что: в общепит перегружаются данные продаж из рестарта, но номер смены в документе общепита все время один и тот же, хотя смены закрываются в рестарте, бывает даже значение -1. так же значение с "минусом" бывает и у чека. не очень понимаю что это означает. встречалось ли такое у кого?
2) Интересует механизм обмена: насколько мне известно рестарт сканирует с заданной периодичностью каталог обмена на наличие новых сообщений. При выгрузке данных из Общепита начинается загрузка данных в рестарт, и тут же выгружается новое сообщение обмена из рестарта. Таким образом, выполнив повторно обмен в общепите (загрузив изменения), можно следить за продажами во фронте,  еще до закрытия кассовой смены?? Возможно, я немного неверно понимаю сам процесс, пожалуйста, поясните :)
Изменено: Andrew Luchkin - 31.01.2012 21:56:52
 
 
 
#32
15.02.2012 10:29:48
Здравствуйте!

версия ПП Рестарт 1.9.16

При загрузки данных продаж в конфигурацию Общепит (2.0.32.4) возникает расхождение сумм реализации.
Обмен произвожу по настройкам: снята галочка в настройках кассового узла "Выполнять
загрузку из данных продаж фронта", далее загрузку данных продаж произвожу через обработку
"Загрузка из данных продаж фронта", со снятой галочка "Переходящая смена". Т.к. смена закрывается ночью следующего дня.

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

Т.е. февраль месяц загружен верно (суммы продаж сошлись).

А, например,  в период с 14 по 15 января в ПП Рестарт сумма продаж 100 руб., а при обмене данных в Общепите формируется сумма продаж значительно больше. Не фискальных чеков именно в этом периоде нет. И так до февраля месяца.

При чем если обратить внимание на время документов Данные продаж, то оно в заданный период соответствует времени открытия и закрытия смены (отбор данных производила и в ручную).
 
 
 
#33
15.02.2012 13:36:04
Цитата
Andrew Luchkin пишет:
Добрый вечер!
1)...
бывает даже значение -1. так же значение с "минусом" бывает и у чека. не очень понимаю что это означает. встречалось ли такое у кого?
Такое случается при ошибках связи между драйвером ФР и устройством. Когда такое происходит сразу после пробития чека то иногда получается что результат фискализации чека в ФР нам известен (положительный), а фискальные реквизиты чека нет (номер смены, номер чека номер документа). В таком случае они записываются со значением -1 (0 это корректное значение). Т.к. в последнее время участились обращения к нам по таким случаям, то в последнем выпущенном релизе продукта у нас реализован автоматический дополнительный запрос в ФР при детектировании данной ситуации. Если же ФР так и не ответит (драйвер производителя так и не смог восстановить связь с устройством), то выводится отдельный запрос оператору с предложением ввести эти реквизиты вручную. Надеемся теперь таких случаев станет меньше

P.S. Также рекомендуется проверить/заменить интерфейсный кабель между ФР и ПК(POS'ом), использовать правильное заземление, также были случаи когда помогало переподключение всех устройств на одну и ту же фазу электропитания (в одну розетку)
 
 
 
#34
15.02.2012 17:11:14
Цитата
Andrew Luchkin пишет:
2) Интересует механизм обмена: насколько мне известно рестарт сканирует с заданной периодичностью каталог обмена на наличие новых сообщений. При выгрузке данных из Общепита начинается загрузка данных в рестарт, и тут же выгружается новое сообщение обмена из рестарта. Таким образом, выполнив повторно обмен в общепите (загрузив изменения), можно следить за продажами во фронте,  еще до закрытия кассовой смены?? Возможно, я немного неверно понимаю сам процесс, пожалуйста, поясните  
Принцип работы обмена описан верно. В режиме использования нового формата обмена когда данные продаж передаются не сменными отчетами, а отдельными чеками (которые загружаются в БЭК в виде документов "ДанныеПродажФронта") действительно есть возможность следить за продажами практически "вживую" (с периодичностью обменов). Однако на стороне БЭКа насколько я знаю еще не реализовано никаких отчетов, которые бы использовали напрямую ДанныеПродажФронта. А каждый раз запускать обработку для переформирования реализационных документов для такой задачи будет неправильно.
 
 
 
Страницы: Пред. 1 2
Читают тему
Поддержка отраслевых решений «1С-Рарус»
Узнать подробнее
Услуги 1С