0
Under vurdering

Оплата по счету банковской картой

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

Со своей стороны мы сформировали задание на то, чтобы дополнительно проверить работу приложения с памятью. Однако, веб-браузер может распоряжаться свободной системной памятью по своему усмотрению: например, очищать неиспользуемые данные только при каких-нибудь эпизодических действиях со стороны пользователя. Пожалуйста, попробуйте использовать другой браузер, например Firefox, и проверить, сохранится ли проблема.

Kundesupport af UserEcho