11.01.2006, 16:14 | #1 |
Участник
|
предоплата наличными через кассу магазина
Здравствуйте Коллеги!
Наши коммерсанты хотят брать с покупателя предоплату наличными и выдавать ему кассовый чек. Схема такая. Продается сервиз. Покупателю нравятся кофейные блюдца, и не нравятся суповые тарелки. Он говорит: "Хочу 23 блюдца!" - "Пожалуйста, сделайте предоплату, получите кассовый чек с надписью ПРЕДОПЛАТА и договор". Потом у поставщика специально закупаются 23 таких же блюдца и передаются покупателю. Речь о продаже сервиза по частям не идет. Карточка товара на это блюдце появляется только ПОСЛЕ предоплаты, т.е. это не привязанные к товару деньги. ВОПРОС - как такую схему реализовать? Наша система - сильно переписанный 2.6. с RBO. |
|
11.01.2006, 16:32 | #2 |
Участник
|
А сейчас используется как то карточка товара на блюдце (или сервиз) в кассовом чеке?
У вас пишется название товара и количество в чеке? Если так то наверно лучше завести карточку товара "Предоплата" и на нее бить предоплаты. |
|
11.01.2006, 16:47 | #3 |
Участник
|
Галина, спасибо за быстрое реагирование .
Карточка товара конечно используется, из нее берется название (или какое-то там название для чека, не суть). Если мы создадим карточку товара ПРЕДОПЛАТА, то во первых она должна постоянно продаваться по кассе с разной ценой, но это пустяки. А движение по складу? Мне оприходовать 1000 единиц товара ПРЕДОПЛАТА и расходовать их? Или продавать товар ПРЕДОПЛАТА в минус? Или можно как-то использовать не ТОВАР, а НЕСКЛАДИРУЕМЫЙ ТОВАР(non-stock item кажется). И как мне потом превратить товар ПРЕДОПЛАТА в товар БЛЮДЦЕ? как-то не годится |
|
11.01.2006, 17:16 | #4 |
Участник
|
А у вас RBO? и поэтому все списывается по количеству? Так?
|
|
11.01.2006, 17:20 | #5 |
Участник
|
у нас RBO. все списывается по количеству, а поэтому или не поэтому к стыду своему не знаю
а как иначе может быть? (теоретически интересно) практически нам надо сделать в нашей системе |
|
12.01.2006, 10:27 | #6 |
Участник
|
Ясно. А без количества у вас нет возможности сделать чек? и не проводить его по количеству?
Если нет возможности-то наверно действительно лучше списывать в минус. Или если у вас переписанный функционал-возможно есть опция - товар или услуга? Если услуга, то не создавать товарный операции. Не поняла, зачем вам превращать товар ПРЕДОПЛАТА в товар БЛЮДЦЕ? |
|
12.01.2006, 11:24 | #7 |
Участник
|
Услуга у нас не реализована. И по логике вещей это не услуга, тем более не товар, а именно предоплата. Предоплата вещь нередкая, и хочется знать как она реализуется штатно. Увжаемые люди посоветовали посмотреть квоты, хотелось бы узнать про них подробнее.
Завести товар ПРЕДОПЛАТА получается довольно дико. Под "превращать товар ПРЕДОПЛАТА в товар БЛЮДЦЕ" я имею ввиду необходимость списать со склада товар БЛЮДЦЕ, когда он передается клиенту, и оприходовать товар ПРЕДОПЛАТА, ведь если я его продам с ненулевым количеством, то у меня по нему образуется отрицательный остаток. Нулевое количество - тоже здорово - у меня будет нулевое количество при ненулевой сумме - чего не хочется. ВОПРОС - как штатно реализуется предоплата. |
|
12.01.2006, 13:20 | #8 |
Участник
|
Предоплата действительно вещь нередкая-но она проводится элементарно в Навижине через кассу (или банк) и на клиента или поставщика и ТОВАР никакого отношения к предоплате не имеет. А у вас RBO. И я так понимаю у вас все проводится через кассовый аппарат - через магазин - а это совсем другой случай-вам нужна другая пердоплата. Разберитесь с определением сначала. Завести как раз товар ПРЕДОПЛАТА не дико - потому что еще раз повторю, как вариант (причем я видела это в реальной базе) если завести поле и после делать на это поле проверку при создании товарных операций, то вы просто не создаете товарных операций и все. Но тем не менее свойства товара используете как вам нужно в чеке. И в этом случае вам не нужно "превращать товар ПРЕДОПЛАТА в товар блюдце".
А квоты не думаю что вам помогут-потому что вы используете RBO. Хотя конечно еще вопрос в какой мере вы используете RBO может быть в каком то усеченном. Вообщем так просто на ваш вопрос не ответишь-вариантов много-нужно смотреть как сделано у вас. Ну и если вам Уважаемые люди посоветовали посмотреть квоты, то спросите у них про квоты и пусть они объяснят как их использовать в Вашем случае. ЗЫ. И при варианте который я вам описала у вас не будет ненулевой суммы при нулевом количестве (если я конечно правильно поняла вас) Последний раз редактировалось Галина; 12.01.2006 в 13:23. |
|
12.01.2006, 14:17 | #9 |
Участник
|
Да Галина, Вы меня поняли правильно.
Вот мнение уважаемого человека:"я так понимаю процесс следующий: делаем предоплату, то есть побивам чек на некую сумму и в системе проводим это как авансовую операцию по клиенту. Далее делаем заказ продажи или квоту заказа а потом из нее заказ продажи, учитываем его и применяем к предоплате. Разницу можно тоже как-нить привчязать к кассе и наликом выозвращать." Я повторюсь, у нас функционал на базе 2.6 и соответствующий RBO. Переработка используемого кода - 60-80%, и искать там следы исходных решений сильно непросто. Почему однако RBO должен привести к отрицанию базового навижн непонятно, и предоплата есть предоплата в обоих случаях . Сложилось у меня такое впечатление (по Москве по крайней мере), что реально работающих решений розницы на навижн очень немного. Конечно очень интересно реализована ли у кого-нибудь предоплата от розничного покупателя, и как. Расскажите пожалуйста подробнее о том решении, которое Вы видели. ЗЫ А то что идти можно многими путями понятно, хочется то и лучше и проще. |
|
12.01.2006, 16:36 | #10 |
Участник
|
RBO не приводит к отрицанию базового навижина. Насколько я знаю-у вас должна быть репликация с касс. Соответственно должны быть продажи (говорю про стандартный RBO) обезличенные без клиента - только сумма чека и товар.
товар списывается после в навижине как расход. Если у вас проходит расход с касс через клиентов - то тогда не могу сказать. А уважаемый человек все правильно ответил про предоплату-так же как и я сказала-проводим оплату на клиента и дальше работаем как с клиентом. Но у вас то другая ситуация (еще раз повторю я говорю про стандартный RBO) вы хотите прогнать оплату через кассу. Мне кажется вы сильно себе усложняете жизнь-во первых в виде превращения ПРЕДОПЛАТЫ на фактический товар, во-вторых я не понимаю откуда возьмется разница?тоже достаточно сложно. |
|
12.01.2006, 17:31 | #11 |
Участник
|
Сказать про Навижн, что он вообще есть какой-то "стандартный" можно только с большой натяжкой, т.к. он под каждую фирму дорабатывается. К RBO это относится еще сильнее.
У нас списание со склада при продаже розничному покупателю идет операцией типа ПРОДАЖА. Клиентом при этом указывается клиент с определенным кодом, который где-то в RBO настроен как розничный покупатель, и я всегда считал что это и есть "стандартный RBO" , (этот RBO у меня уже второй, но от одного и того же известного внедренца). На мой взгляд уважаемый человек ответил все логично и наверное правильно, т.е. часть "стандартного навижна" в общих чертах описана, но кроме нее еще должна быть прикрутка к RBO. На мой взгляд, Галина, вместе, а не вместо. Следующую цитату я не понимаю: Цитата:
Сообщение от Галина
Мне кажется вы сильно себе усложняете жизнь-во первых в виде превращения ПРЕДОПЛАТЫ на фактический товар, во-вторых я не понимаю откуда возьмется разница?тоже достаточно сложно.
Во-вторых не понимаю о какой разнице речь. Галина, а опишите, пожалуйста, то решение, которое Вы видели, я буду очень признателен. |
|
12.01.2006, 17:52 | #12 |
Участник
|
Ок-значит я недостаточно хорошо знаю стандартный RBO.
По поводу уважаемого человека -я тоже сказала, что он ответил правильно в рамках стандартного функционала. Что такое вместе, а не вместо - я что то тоже не понимаю - к чему было сказано? Разницу написал уважаемый человек-вот ее то я и не понимаю-откуда она возьмется. Мой вариант решения я написала (услуга), как объяснить подробнее я не знаю-так как это решение известного внедренца, и скорее всего от этого то внедренца у вас rbo-спросите лучше у него. Они показать смогут. Хотя сразу оговорюсь-может и не подойдет то что я предложила, нужно смотреть. Если вы не хотите превращать ПРЕДОПЛАТУ в ТОВАР - так и не превращайте - я не понимаю зачем ее превращать. |
|
12.01.2006, 19:32 | #13 |
Участник
|
А... Уважаемый человек имел ввиду разницу, которая может возникнуть, если внесенный аванс не равен сумме продажи (в частности больше, т.е. мы берем с клиента нал, а потом решаем часть этого нала вернуть).
Цитата:
Из сообщений от Галина
Если вы не хотите превращать ПРЕДОПЛАТУ в ТОВАР - так и не превращайте - я не понимаю зачем ее превращать. ... Завести как раз товар ПРЕДОПЛАТА не дико ВОПРОС - видел ли кто-то что-то подобное, уже реализованным? |
|
12.01.2006, 20:04 | #14 |
Участник
|
Возможно и так-только я не понимаю причем здесь квоты и заказы? Зачем? когда у вас и так продажи по чеку пройдут, когда появятся блюдца и автоматически попадут в ПРОДАЖУ?
А для того чтобы разницу вернуть - вам нужно ее посчитать и соответственно вам придется аванс и продажу по этому авансу(по чеку) делать отдельно от остальных продаж , я так понимаю заводить клиентов и на них уже проводить продажу. Я правильно понимаю, вы так и хотели делать? Или как вы будете отделять аванс и продажу по каждому клиенту? Мое предложение вы правильно поняли. Конечно Услуга про которую я говорила, сделана была в Навижине без rbo. |
|
12.01.2006, 20:28 | #15 |
Участник
|
Я честно пока не знаю как это сделать, да и не хочу особенно это делать. Тем более потому что трудозатрат на обеспечение этого процесса уйдет минимум человекомесяц, а реальных продаж таких будет с гулькин нос. Моей целью является выяснить возможный оптимальный путь, ходил ли кто по нему и размер бедствия, чтобы (если честно) обосновать необоснованность этой разработки.
Квоты можно использовать и для оформления продажи клиенту, и для заказа этого товара у поставщика. Клиента такого, внесшего аванс, на мой взгляд и проименовать хорошо бы, вдруг их толпа соберется, и все будут Розничный Покупатель - бардак-с . Еще интересны всякие детали - клиент внес деньги, мы ему выдали чек, потом пришел за товаром, мы ему товар выдали, а еще один чек дать должны? Наверное да, потому что сроки обмена там всякие... А сумма в нем - нулевая? Это, конечно, на другие форумы, но может и здесь кто знает . Дамы и Господа, если у кого есть соображения, делитесь! |
|
12.01.2006, 21:25 | #16 |
Участник
|
блин... объясните мне как вы квоты прицепите к продажам, которые должны поступать из касс из таблиц которые вы указали 99001472-99001474? как? В обыкновенном навижине - да понятно как использовать квоты-сперва квоты-после непосредственно процесс продаж счета или заказы(и то в Навижине)=после учет.
У вас же RBO- у вас обратная схема - сперва непосредственно процесс продаж на кассах-после поступает через репликацию в счета - а после учет. Вы же сами пишите-продажи идут через клиента с кодом, указанным где то в RBO. Как вы собираетесь использовать другие коды клиентов? |
|
13.01.2006, 10:40 | #17 |
Участник
|
Согласен, проблемы есть. Мне как раз и интересно как, и даже что.
За квоты я в принципе не держусь. Просто два уважаемых человека сказали - предоплаты - через квоты. А вот другой код клиента нужен, от этого никуда не деться. Да и механизмы стандартного навижна использовать надо - мне же необходимо связать предоплату в книге операций клиента с продажей в книге операций товара. |
|
13.01.2006, 12:44 | #18 |
Участник
|
Цитата:
Сообщение от rst
А вот другой код клиента нужен, от этого никуда не деться. Да и механизмы стандартного навижна использовать надо - мне же необходимо связать предоплату в книге операций клиента с продажей в книге операций товара.
Я просто не пойму почему вы это хотите делать? Раз у вас RBO-значит вы розничное предприятие-значит у вас обезличенные продажи(без клиента-то что RBO использует клиента - это чисто для продажи товара в Навижине-другие системы не используют клиента). Вы уверенны что по предоплате вы хотите от этого отказаться и делать все по клиентам? |
|
13.01.2006, 13:20 | #19 |
Участник
|
Я так понимаю что при предоплате я должен ее где-то зафиксировать. Самое логичное - в книге операций клиента и естественно в финкниге операций. Продажа по этому клиенту НЕОБХОДИМО возникнет только в случае, если аванс был частичный, а не полный, хотя даже если аванс был полный, продажу тоже можно фиксировать, но с нулевой суммой (денег), вопрос нужно ли. В общем случае, Вы правы, конечно нужно.
Продажа по товарной книге операций все равно должна пройти обязательно, это понятно, а значит и связать ее с клиентом нужно, а значит код клиента надо использовать в ней настоящий, а не обезличенный. Предприятие у нас действительно розничное, но в нем (как и в любом другом наверное реальном российском розничном предприятии) оптовые продажи тоже не редкость, как некое побочное явление. RBO же обезличивает клиента, потому что при ОБЫЧНОЙ розничной продаже фиксировать клиента нет ни возможности ни необходимости. А такая продажа по предоплате обязательно требует фиксировать клиента, и она со всех сторон похожа на обычную оптовую продажу по предоплате, кроме одного - необходимости пробить чек через ККМ. |
|
13.01.2006, 13:37 | #20 |
Участник
|
Ок-понятно. Т.е. есть ваши бухи считают что по предоплате нужно делать розничную продажу, как оптовую. Согласна. Тогда не понимаю-зачем чек пробивать на предоплату? и проводить через выручку магазина?Можно через обыкновенную кассу и дальше стандартно. Это вопросы уже касающиеся бизнес процессов. Вам конечно виднее как лучше сделать.
Когда продажа пройдет по товарной операции она еще пройдет и по клиент книге операции и по фин.книге. Потому мне как то непонятно было-когда вы говорили связать предоплату =Клиент книга операций с продажей=Товар книга операций. Вообще такого понятия нет и не связывают. А связывают предоплату=Клиент книга операций с продажей=Клиент книга операций. И если у вас сумма нулевая-то не обязательно проводить продажу, так как продажа=Клиент книга операций и она нулевая. А что у вас на кассах стоит? Plus Pos? |
|
|
Похожие темы | ||||
Тема | Ответов | |||
Экспорт данных в файл через dataport | 0 | |||
Предоплата в счетах-фактурах. | 44 | |||
Учёт через Журнал товаров | 2 | |||
Navision Attain через Citrix | 2 | |||
расчеты с поставщиками через подотчетников | 0 |
|