Update close - выполнить операцию
Модератор: Дед Пахом
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
-
- ✯ Ветеран ✯
- Сообщения: 1702
- Зарегистрирован: 25 Март 2009, 21:55
- Благодарил (а): 9 раз
- Поблагодарили: 4 раза
Update close - выполнить операцию
После создания накладной в форме (Form), только после записи - (добавления, изменения и проведения/закрытия накладной), чтобы вызывалась процедура оплаты.
Например, порядок таков:
1 Создается накладная (черновик) в Form и не проведена/не закрыта = никаких сообщений об оплате.
2 Создается накладная в Form и проведена/закрыта = сообщение об оплате, при закрытии формы (Form).
3 Редактируется накладная в Form и проведена/закрыта = сообщение об оплате, при закрытии формы (Form).
Хочется избежать лишних операций:
таблица с накладными:
1 создать(редактировать) накладную, после закрытия формы (form),
2 выбрать нужную запись накладной и
3 выполнить оплату по ней.
и нужно
1. создать(редактировать) накладную, после(при) закрытия(и) формы (form), если создана без ошибок, выполнить оплату по ней.
Вроде все просто, но как реализовать в стандартной Form в MySQL, чтобы она добавила,изменила запись, если без ошибок и есть накладная, сразу вывести процедуру оплаты.
Чтобы не было оплаты без накладной.
Спасибо за внимание.
С10 АВС
Например, порядок таков:
1 Создается накладная (черновик) в Form и не проведена/не закрыта = никаких сообщений об оплате.
2 Создается накладная в Form и проведена/закрыта = сообщение об оплате, при закрытии формы (Form).
3 Редактируется накладная в Form и проведена/закрыта = сообщение об оплате, при закрытии формы (Form).
Хочется избежать лишних операций:
таблица с накладными:
1 создать(редактировать) накладную, после закрытия формы (form),
2 выбрать нужную запись накладной и
3 выполнить оплату по ней.
и нужно
1. создать(редактировать) накладную, после(при) закрытия(и) формы (form), если создана без ошибок, выполнить оплату по ней.
Вроде все просто, но как реализовать в стандартной Form в MySQL, чтобы она добавила,изменила запись, если без ошибок и есть накладная, сразу вывести процедуру оплаты.
Чтобы не было оплаты без накладной.
Спасибо за внимание.
С10 АВС
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
-
- ✯ Ветеран ✯
- Сообщения: 4983
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 20 раз
Update close - выполнить операцию
Пока не вижу никаких проблем. Наверно не понял. Форма вызывается из броуза? Броуз стандартный ABC? Если ответы на первые два вопроса "Да.", то третий - в метод Run не заглядывали?
We are hard at work… for you.
Update close - выполнить операцию
Проще сделать Update-процедуру типа Source, а не Form, а в Source-процедуру запихнуть необходимую логику.
Примерно так... Другой вариант - изготовить совсем пустую процедуру Dummy, примерно следующую
и вместо формы в UpdateProcedure поставить вызов Dummy. Посмотреть, куда она в коде встроилась и до (или после) неё написать реальный обработчик.
Код: Выделить всё
Update_Doc Procedure
Code
IF GlobalRequest = InsertRecord
! Правим форму
Form_Record()
IF GlobalResponse = RequestCompleed
! Правим оплату
UpdateFormPay()
END
END
RETURN
Код: Выделить всё
Dummy Procedure
GlobalResponse = RequestCompleted
Return
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4615
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 6 раз
- Поблагодарили: 37 раз
Update close - выполнить операцию
В pos системах несколько иначе обычно реализуют. Вначале сканируют товары в памяти. Затем жмут один из вариантов оплаты (нал или безнал, к примеру). Затем в открывшемся окне приема платежа сканируют, если нужно, дисконтную карту (скидка) и жмут Оплатить. После этого начинается транзакция, в ходе которой информация сохраняется в базе данных, считается сдача (нал) или запрашивается платежная карта, печатаются чеки и т.п.
В оптовке же, когда отгрузка и оплата чаще разнесены во времени, накладная просто сохраняется, а для оплаты используется механизм "Ввод на основании" (то есть создать другой вид документа на основании информации из заданного документа). Не только в журнале документов, но и в отчете по работе с покупателем, к примеру.
В оптовке же, когда отгрузка и оплата чаще разнесены во времени, накладная просто сохраняется, а для оплаты используется механизм "Ввод на основании" (то есть создать другой вид документа на основании информации из заданного документа). Не только в журнале документов, но и в отчете по работе с покупателем, к примеру.
C6/C11, ШВС, tps/btrieve.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7373
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 13 раз
- Поблагодарили: 48 раз
Update close - выполнить операцию
Как реализовать то, что придумали - подсказали специалисты ниже.
Я риску предложить на рассмотрение идею, что вопрос возникает из-за разделения операций ввода накладной и оплаты.
Сделайте интерфейс карточки накладной сразу с полями оплаты и у Вас в принципе не будет ситуации, когда
может образоваться оплата без накладной ...
А разносить и хранить данные накладной и оплаты при нажатии кнопки "Сохранить" в карточке - можете
по любым спискам и т.д. ...
Я риску предложить на рассмотрение идею, что вопрос возникает из-за разделения операций ввода накладной и оплаты.
Сделайте интерфейс карточки накладной сразу с полями оплаты и у Вас в принципе не будет ситуации, когда
может образоваться оплата без накладной ...
А разносить и хранить данные накладной и оплаты при нажатии кнопки "Сохранить" в карточке - можете
по любым спискам и т.д. ...
За теми кто отстал - не возвращаться. (С) Кодекс
-
- ✯ Ветеран ✯
- Сообщения: 4983
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 20 раз
Update close - выполнить операцию
В рамках обсуждения. Раньше в больших системах было разделение на АРМы. И я в своё время заказчика убедил, что не надо лепить всё вместе. Кассир вносит ПКО в своём экране, бухгалтер банковские приходы в своём. А потом кто-то (у нас это был всё-таки бухгалтер) связывает накладные и оплату. В опте были приняты частичные оплаты, авансовые, мог быть платёж сразу на несколько накладных. У меня в системе накладная без оплаты нормальная тема. И платёж без привязки к накладной тоже. Какое-то время это всё живёт так. Но на экранах видно, что платёж не привязан к накладной, накладная без оплаты. Бухгалтер типа отслеживает это дело.Игорь Столяров писал(а): ↑06 Август 2018, 16:53 Я риску предложить на рассмотрение идею, что вопрос возникает из-за разделения операций ввода накладной и оплаты.
Сделайте интерфейс карточки накладной сразу с полями оплаты и у Вас в принципе не будет ситуации, когда
может образоваться оплата без накладной ...
Допускаю, что надо жёстко - одна накладная/одна оплата. Но всё равно - кассир должен заниматься своим делом, менеджер своим, бухгалтер своим.
We are hard at work… for you.
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4615
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 6 раз
- Поблагодарили: 37 раз
Update close - выполнить операцию
Все зависит от бизнес-процессов. В оптовке у меня вообще не делается жесткая привязка отгрузок к оплатам. Программа умеет это все считать автоматически при построении отчетов, перекрывая документы в хронологическом порядке, в том числе пересчитывая с учетом возвратов. Точнее сказать, можно, если разрешено в настройке программы, явно привязывать накладные к оплатам по схеме многие-ко-многим. Тогда такие привязки учитываются, а что не привязано, считается автоматически. Но чаще обходятся без этого, так как требует немалого дополнительного труда по контролю (формируется специальный отчет по возможным перекосам, связанным с изменениями в документах).
C6/C11, ШВС, tps/btrieve.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7373
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 13 раз
- Поблагодарили: 48 раз
Update close - выполнить операцию
Всё абсолютно верно и обосновано.
Но если говорить про первичный ввод данных о продаже продавцом (накладная + возможная оплата)
- то как вариант, можно всё это ввести в одной форме и при нажатии кнопки раскидать по спискам.
И не надо плодить последовательность окон и переживать как там они без нас должны открываться.
А вот далее уже, для рабочего места бухгалтера, менеджера можно показывать авансовые платежи, списки оплаты и т.д. и т.п. -
в полном соответствии с Вашим описанием.
За теми кто отстал - не возвращаться. (С) Кодекс
-
- ✯ Ветеран ✯
- Сообщения: 1702
- Зарегистрирован: 25 Март 2009, 21:55
- Благодарил (а): 9 раз
- Поблагодарили: 4 раза
Update close - выполнить операцию
Заглядывал , извиняюсь, забыл указать маленькую поправку, чтобы оплата должна выводиться поверх формы накладной, чтобы блондины видели за что оплата
Сначала появляется сообщение, если есть доступ(необходимость):
Код: Выделить всё
CASE MESSAGE('Провести оплату?','Оплата по документу',ICON:Question,'Указать сумму|Вся сумма|&Нет'.....
В Form накладной в методе Kill - Leave procedure scope, пытаюсь реализовать не знаю на практике какие будут последствия.
Было уже, много проблем для разных видов оплаты(доступ, пользователи и прочее) работает но кому то лишнее, а кому чего то не хватает, у сейчас меня универсально, накладную может оплатить кассир, бухгалтер или еще кто-то, и для каждого может быть форма оплаты своя.Игорь Столяров писал(а): ↑06 Август 2018, 16:53 Сделайте интерфейс карточки накладной сразу с полями оплаты и у Вас в принципе не будет ситуации, когда
может образоваться оплата без накладной ...
Не согласен, у меня может много оплат привязаны к одной накладной (оплата частями), или оплата без накладнойДопускаю, что надо жёстко - одна накладная/одна оплата
Тоже было, нарастающим, проблемы при большом объеме разобраться, что за чтоВ оптовке у меня вообще не делается жесткая привязка отгрузок к оплатам.
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
-
- ✯ Ветеран ✯
- Сообщения: 1702
- Зарегистрирован: 25 Март 2009, 21:55
- Благодарил (а): 9 раз
- Поблагодарили: 4 раза
Update close - выполнить операцию
Обведено все связанные накладные
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
-
- ✯ Ветеран ✯
- Сообщения: 4983
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 20 раз
Update close - выполнить операцию
Что-то я не догоняю. В какой момент нужно провести оплату? После ввода накладной в форме? В методе Kill окно скорее всего закроется, "поверх" не получится.gopstop2007 писал(а): ↑06 Август 2018, 23:16 Заглядывал , извиняюсь, забыл указать маленькую поправку, чтобы оплата должна выводиться поверх формы накладной, чтобы блондины видели за что оплата
We are hard at work… for you.
-
- ✯ Ветеран ✯
- Сообщения: 4983
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 20 раз
Update close - выполнить операцию
Может и хорошо с такой настройкой. У меня даже в мыслях не было. Старшие товарищи рассказали как сложен мир, лучше сделать через связку
many-many. На самом деле кажется, что так проще жить. С автоматической привязкой в отчётах нет гарантии, что не будет изменений. Да и других подводных камней хватает. А у Вас эту настройку можно в процессе работы поменять? Или она прибивается намертво в начале деятельности?
We are hard at work… for you.
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4615
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 6 раз
- Поблагодарили: 37 раз
Update close - выполнить операцию
Можно в процессе работы менять. С автоматической привязкой есть гарантия, что в отчетах всегда корректный результат. С жесткой возникает ситуация с искажениями при внесении изменений в документы отгрузки/оплаты, или в результате возвратов товаров. На самом деле, это все оценочные методы. В оперативной деятельности обычно никто не заморачивается с подокументным учетом взаиморасчетов и контролируют по общему долгу. Подокументный учет нужен для контроля сроков оплаты. Ну и в КУДир.kreator писал(а): ↑07 Август 2018, 10:07Может и хорошо с такой настройкой. У меня даже в мыслях не было. Старшие товарищи рассказали как сложен мир, лучше сделать через связку
many-many. На самом деле кажется, что так проще жить. С автоматической привязкой в отчётах нет гарантии, что не будет изменений. Да и других подводных камней хватает. А у Вас эту настройку можно в процессе работы поменять? Или она прибивается намертво в начале деятельности?
C6/C11, ШВС, tps/btrieve.
-
- ✯ Ветеран ✯
- Сообщения: 4983
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 20 раз
Update close - выполнить операцию
Ни фига не корректный. Если только флажки расставить. И то сомневаюсь.
Зато ответственное лицо видит, что что-то пошло не так. Для Вас нормальная ситуация - менеджер набрал накладную на 50000р., клиент оплатил эту сумму, потом менеджер в накладной поменял что-то, стало 60000р., и откуда-то образовался долг?
We are hard at work… for you.
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4615
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 6 раз
- Поблагодарили: 37 раз
Update close - выполнить операцию
В оптовке (а мы про не ведем речь) клиенты обычно платят с отсрочкой и не по конкретным накладным. Сами накладные часто изменяются, так как товары могут не довезти, привезти не то и т.п. В общем, у нас вся эта технология годами отшлифована и работает как часики... Опять таки, если обсуждать подобные вопросы, надо вначале четко обозначить сферу применения. У меня продукты питания и хозяйственные товары. В других ситуациях могут быть свои нюансы.
C6/C11, ШВС, tps/btrieve.