Ваши комментарии

С этим полностью согласен. Есть в программе многие неудобные моменты. Что мешало разработчикам при наборе номенклатуры сделать так, как в интерфейсе продавца? Там можно и код, и штрихкод, и название, и артикул ввести. Вполне удобно.

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

А нельзя сделать как поступление на счет, только сумма попадала бы туда, куда падет оплата по терминалу чеком. А в документе указывать не сам счет, а терминал. Тогда и будет всего один документ, и поступление на счет от эквайринга будут нормально проходить.
Не подскажите когда планируете реализовать загрузку цен для существующих товаров? А то в связи с колебанием курсов (занимаемся розничной торговлей импортом, напрямую зависимым от текущего курса) вообще перестали пользоваться розничными ценами в Большой Птице, все цены продавцы берут из прайса. В Птице нереально каждую неделю вручную менять ценники. Хотелось бы хотя бы иметь возможность обновления цен по ID товара с помощью CSV.
Про импорт из банк клиента, согласен полностью. Тут нужна ручная работа. Массовое изменение удобно было бы использовать в рознице для назначения ДДС. Я просто изменяю документы Чек, которые создают продавцы. Проверяю их, назначаю ДДС, и перепровожу их, чтобы следить за правильными остатками. Если программа ругается на недостаточноть товаров, значит где то есть проблема. У меня работают 6 продавцов и все создают перемещения, реализации и т.п. Вот и получается, что кто то бывает забывает сделать, либо неправильно сделает перемещение, либо реализацию. По отрицательным остаткам как правило злодей быстро находится). По поводу тормозов. Можно провести эксперимент. Я в хроме открываю диспетчер задач и открываю большую птицу. В начале она занимает всего 70 808 К. Если открыть журнал.розница и поочередно открыть и закрыть (либо сохранить изменения и закрыть) примерно 40 чеков, то программа уже будет занимать 310 800 К. Еще 60 шт - 370 164 К. Если открыть поступление товаров и там открыть и закрыть еще документов 20, то вес уже будет 540 000 К. Тут и начинаются тормоза. Конечно если подождать минут 20, то объем уменьшиться опять до 360 000 К. Кончено не критично, но часто приходится выходить и заново заходить, тогда все норм. Причем когда закрываешь вкладку, программа почти минуту думает. 
Просто я не знаю другого способа как оформить предоплату за заказ, в случае если она производится банковской картой. В любом случае любая оплата по терминалу должна попадать в общую кучу. А потом одним документом заноситься в банк. Тогда импорт данных из клиент банка происходит проще простого. Еще бы возможность массового изменения документов, цены бы не было. А то когда меняешь по одному, то через минут 40 - 50 программа начинает жутко тормозить, приходится выходить и снова заходить.
В журнале "Оплата по терминалу" все как положено. А в Розница журнал тип операции значится "возврат". Просто бросается в глаза. Лучше бы документы "оплата по терминалу" там вообще не обозначались.
Нет. Импорт данных из клиент банка дает суммы. В комментариях пишется что это эквйринг. Я сам ставлю тип операции эквайринг, а комиссию беру из комментариев. Тогда в отчете "движение по терминалу" в терминале становится 0. Т.е. вся сумма с терминала попадает в банк. Так легче искать ошибки в документах. Если не ноль, значит где то допустили ошибку. По возврату. У меня когда создаешь документ в РОЗНИЦА > ОПЛАТА ПО ТЕРМИНАЛУ тип операции по умолчанию ставится "возврат оплаты покупателю", его я меняю на "получение оплаты от покупателя". Но в Розница.Журнал тип операции у него показывается все равно как "возврат", хотя по отчету деньги как и положено идут на терминал.


Сервис поддержки клиентов работает на платформе UserEcho