Форум OlegON > Программы и оборудование для автоматизации торговли > Кассовые программы > УКМ-4

оптимизация отчета по внешним скриптам : УКМ-4

22.11.2024 12:30


02.07.2010 16:05
Здравствуйте.

Вот столкнулся с проблемой. Нужен был отчет по внешним скриптам, в котором бы выводилась информация по проданным товарам разделенная по типам оплаты(нал/безнал) и ставкам НДС(10/18%). Т.е.:

За смену ... на кассе ...

Наличными
НДС 18%
Возвращено(шт.) ...
на сумму(РУБ.) ...
сумма налога(РУБ.) ...
Продано(шт.) ...
на сумму(РУБ.) ...
сумма налога(РУБ.) ...
НДС 10%
Возвращено(шт.) ...
на сумму(РУБ.) ...
сумма налога(РУБ.) ...
Продано(шт.) ...
на сумму(РУБ.) ...
сумма налога(РУБ.) ...

Безнал
НДС 18%
Возвращено(шт.) ...
на сумму(РУБ.) ...
сумма налога(РУБ.) ...
Продано(шт.) ...
на сумму(РУБ.) ...
сумма налога(РУБ.) ...
НДС 10%
Возвращено(шт.) ...
на сумму(РУБ.) ...
сумма налога(РУБ.) ...
Продано(шт.) ...
на сумму(РУБ.) ...
сумма налога(РУБ.) ...

Делал на основании function report_ext_cashier_taxes(__rep, __print_data)
в report_ext.lua. Вроде все работает, но вопрос как оптимизировать запросы, вычисляющие кол-во/сумму продаж/возвратов их 4 они однотипные. Приведу один из них в моем варианте с подставленными значениями:

select if(sum(i.total+i.discount) is null, 0, sum(i.total+i.discount)) from trm_out_shift_open so
inner join trm_out_receipt_header h on so.id = h.shift_open and so.cash_id = h.cash_id
inner join trm_out_receipt_footer f on h.id = f.id and h.cash_id = f.cash_id
inner join trm_out_login l on h.login = l.id and h.cash_id = l.cash_id
inner join trm_out_receipt_item i on h.id = i.receipt_header and h.cash_id = i.cash_id
left join trm_out_receipt_item i2 on i.receipt_header = i2.receipt_header and i.id = i2.link_item and i.cash_id = i2.cash_id
inner join trm_out_receipt_item_tax it on i.id = it.receipt_item and i.cash_id = it.cash_id
inner join trm_out_receipt_tax t on it.receipt_tax = t.id and it.cash_id = t.cash_id
inner join trm_out_receipt_payment p on h.id = p.receipt_header and p.cash_id = h.cash_id
where so.number = 1
and h.type in (0,5)
and f.result = 0
and l.user_id in (20)
and i.type = 0
and i2.link_item is null
and t.tax_id = 1
and so.cash_id = 1007006
and t.percent = '10.00%'
and p.type = 0
and p.payment_id = 0
and p.id not in (
select id from trm_out_receipt_payment
where type = 0
and cash_id = 1007006
group by receipt_header having count(*)>1
)

В таком варианте работает медленно(минуты 3 пока отчет напечатается)
Можно ли как-то обойтись без подзапроса, сохранив результат?
Может group by ... having ... вытащить на уровень общего запроса, но как?
Тут есть еще косяк...если будут комбинированные оплаты, то считать будет неправильно, но кассиры о такой возможности пока не знают.
03.07.2010 16:24
Проверь это.
С разбивкой по всем видам оплаты и налогам.
Можно и по типу чека (продажа/возврат) группировку сделать, будет 1 запрос вместо 4-х.

Код:
select p.payment_name, t.percent,
       ifnull(sum(t.amount*(p.amount/s.amount)), 0) 'tax_sum',
       ifnull(sum((i.total+i.discount)*(p.amount/s.amount)), 0) 'item_sum', 
       count(*) 'items'
from trm_out_shift_open so
inner join trm_out_receipt_header h on so.id = h.shift_open and so.cash_id = h.cash_id
inner join trm_out_receipt_footer f on h.id = f.id and h.cash_id = f.cash_id
inner join trm_out_receipt_subtotal s on h.id = s.id and h.cash_id = s.cash_id
inner join trm_out_login l on h.login = l.id and h.cash_id = l.cash_id
inner join trm_out_receipt_item i on h.id = i.receipt_header and h.cash_id = i.cash_id
left join trm_out_receipt_item i2 on i.receipt_header = i2.receipt_header and i.id = i2.link_item and i.cash_id = i2.cash_id
inner join trm_out_receipt_item_tax it on i.id = it.receipt_item and i.cash_id = it.cash_id
inner join trm_out_receipt_tax t on it.receipt_tax = t.id and it.cash_id = t.cash_id
inner join trm_out_receipt_payment p on h.id = p.receipt_header and p.cash_id = h.cash_id
where so.number = 1
and h.type in (0,5)
and f.result = 0
and l.user_id in (20)
and i.type = 0
and i2.link_item is null
and so.cash_id = 1007006
and t.tax_id = 1
and p.type = 0 
group by p.payment_id, t.percent
;
Если сумму НДС не брать из таблиц, а вычислять по % ставке из конечных 'item_sum', между ними будет разница в копейках.
06.07.2010 15:21
идею понял, но так все равно без подзапроса не обойтись

проблема в том, что иногда кассиры пробивают 2 оплаты одинаковым типом
(ой что-то мало налички отбили, надо бы еще разок...)
в результате в таблице trm_out_receipt_payment есть две записи с одинаковыми cash_id, receipt_header и payment_id, а из них нужна только одна.

...и отличие "на копейки" конечника никак не устроит. Они мотивируют необходимость этого отчета тем, что:
-бухгалтерия от них требует, что бы это все с z-отчетом сходилось
-им же КМ-7 заполнять
(тут может еще появиться "хотелка" КМ-7 из УКМ'а печатать в нужной форме, а в документации про это не очень подробно расписано. Есть что-то более полное?)
06.07.2010 15:29
Я не совсем понимаю, зачем в КМ7 выделять НДС?
06.07.2010 16:04
Цитата:
Павел Сосновских идею понял, но так все равно без подзапроса не обойтись

проблема в том, что иногда кассиры пробивают 2 оплаты одинаковым типом
(ой что-то мало налички отбили, надо бы еще разок...)
1) Как я понимаю "идею" - там от каждой такой записи берется нужный процент суммы. У себя проверял - конечные суммы сходятся, в том числе, если есть чеки с такими частичными оплатами. Потому и написал - проверь.

2) У вас на Z есть суммы НДС ?
Плюс хотят, чтобы они совпадали с отчетом из УКМ?
Странные у вас бухи :)
06.07.2010 16:35
Цитата:
Mtirt Я не совсем понимаю, зачем в КМ7 выделять НДС?
честно говоря, я тоже
06.07.2010 16:58
Попробовал...сумму продаж считает правильно. Спасибо.
По налогам не сходится, сильно. Так ведь налоги считать налоги не совсем правильно. Ведь в одном чеке есть товары с разными налоговыми ставками.

Правда там может быть косяк в том, что у некоторых товаров не загружается(или не установлена) налоговая ставка(сзади пока софт самописный).
Часовой пояс GMT +3, время: 12:30.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.