Красная смена на сервере - с чего начать?

Открываем смену, смотрим есть ли расхождения. Расхождений по счетчикам нет, пишет "Неверная нумерация документов":

В документах используется сквозная нумерация. Если пробили чек, сняли X отчет, пробили еще 1 чек. То номера будут 1,2 и 3 соответственно.

Так как расхождений нет, значит в смене не хватает документа не влияющего на счетчики в ФП: X-отчет, Внесение, Изъятие.

Если найти и переотправить с кассы не удается(был сбой ФР и счетчик перепрыгнул), можно скопировать какой-нибудь из подобных документов на кассе :

Проставить:

id_shift - id смены

id - уникальное значение, лучше проставить id копируемого документа со знаком "-"

numberfield - номер документа которого не хватает на сервере. Можно узнать скриптом:

/*
Недостающие номера документов в проблемных сменах
*/
SELECT t1.operday, t1.shopindex, t1.cashnum, t1.numshift, t1.fiscalsum - p.checksum AS FP_CecksSum, 
'BETWEEN ' ||
(SELECT max(nom)+1 FROM 
(SELECT s.operday, s.shopindex, s.cashnum, s.numshift, docs.numberfield as nom FROM od_shift s
LEFT JOIN (SELECT id_shift, numberfield FROM od_purchase UNION ALL
SELECT id_shift, numberfield FROM od_introduction UNION ALL
SELECT id_shift, numberfield FROM od_withdrawal UNION ALL
SELECT id_shift, numberfield FROM od_reportshift) docs ON docs.id_shift = s.id
WHERE s.shiftclose is not null) mmin
WHERE mmin.operday = t1.operday AND mmin.shopindex = t1.shopindex AND mmin.cashnum = t1.cashnum AND mmin.numshift = t1.numshift
AND mmin.nom < (t1.nom-1)
)::varchar(10) || ' AND ' || (t1.nom-1)::varchar(10) || ' OR ' empty_range
FROM (
SELECT s.operday, s.shopindex, s.cashnum, s.numshift, docs.numberfield as nom, s.id, s.fiscalsum, s.state FROM od_shift s
LEFT JOIN (SELECT id_shift, numberfield FROM od_purchase UNION ALL
SELECT id_shift, numberfield FROM od_introduction UNION ALL
SELECT id_shift, numberfield FROM od_withdrawal UNION ALL
SELECT id_shift, numberfield FROM od_reportshift) docs ON docs.id_shift = s.id
WHERE s.shiftclose is not null
) t1
LEFT JOIN (select id_shift, sum(case when operationtype = true then checksumend else -checksumend end) checksum from od_purchase where checkstatus = 0 group by id_shift) p on p.id_shift = t1.id
LEFT JOIN (SELECT s.operday, s.shopindex, s.cashnum, s.numshift, docs.numberfield as nom FROM od_shift s
LEFT JOIN (SELECT id_shift, numberfield FROM od_purchase UNION ALL
SELECT id_shift, numberfield FROM od_introduction UNION ALL
SELECT id_shift, numberfield FROM od_withdrawal UNION ALL
SELECT id_shift, numberfield FROM od_reportshift) docs ON docs.id_shift = s.id
WHERE s.shiftclose is not null) t2 on t1.nom = t2.nom+1
AND t1.operday = t2.operday AND t1.shopindex = t2.shopindex AND t1.cashnum = t2.cashnum AND t1.numshift = t2.numshift
WHERE t2.nom is null AND t1.nom<>1 AND t1.state = 3
ORDER BY 1,2,3,4,5

Если есть расхождения по счетчикам, необходимо найти чек(и) который не дошел до сервера или был задублирован на кассе. Основные советы:

a. Попробовать переотправить документы:

update ch_purchase set senttoserverstatus = 0 where id_shift in (select id from ch_shift where numshift = 378);
update ch_reportshift set senttoserverstatus = 0 where id_shift in (select id from ch_shift where numshift = 378);
update ch_withdrawal set senttoserverstatus = 0 where id_shift in (select id from ch_shift where numshift = 378);
update ch_introduction set senttoserverstatus = 0 where id_shift in (select id from ch_shift where numshift = 378);

б. Если была ошибка записи в ФП, данное событие можно отследить в FiscalPrinter.log на кассе.

в. Поискать чек на сумму расхождений и разбираться что с ним(Например проблема 86 и 133)

Select * from ch_purchase where checksumend = <Сумма расхождений>

Желтая смена на сервере, но смена была закрыта - с чего начать?

Это означает что как минимум отсутствует Z отчет. Для начала переотправить с кассы если не приходит искать где застрял.

Отсутствует смена на сервере - с чего начать?

Для начала попробовать выгрузить только 1 документ, так как когда переотправляешь все скопом, если в одном документе ошибка не придет вся пачка.

Основные моменты:

Смена может не приходить из-за различных версий сервера и кассы. Так как есть недостающие/лишние поля пакет не может обработаться.
Дублирование смен, в некоторых версиях происходило дублирование смен, в этом случае с сервера лучше все удалить и выгрузить все заново с кассы. Если дублирование произошло на кассе, то откорректировать ее там, удалить на сервере и перевыгрузить.
Сетевые проблемы, что то мешает транспорту товаров антивирус, фаервол, не работают службы (nginx, Postgres, JBOSSSVC )

Зеленая смена на сервере, но данные не верные - с чего начать?

Для начала узнать что с чем не сходится. Возможно кто-то подправил или создал Z отчет вручную по имеющимся чекам в БД и он расходится с бумажным.

Не ходят чеки с кассы на сервер. На кассе чеки висят в senttoserverstatus=0

Брандмауэр. Если некорректно выключать, то касса не видит сервер. Проверенный рабочий вариант: Брандмауэр включен и отключена фильтрация сетей.
Антивирус
Службы nginx, JBOSSSVC
Проблемы с сетью
Касса вылетает в TinyCore при "Проверки Связи". Удалить storage\crystal-cash\modules\registry\ServerRegisterModules-config.xml и перезакгрузить кассу
Не проходит "большой" пакет:

Инцидент: На кассе есть связь с сервером (все транспорты работают), но чеки не отправляютя на сервер (senttoserverstatus=0).

Проблема: Проблема с сетевой инфраструктурой клиента. С кассы на сервер не уходят пакеты размером больше 1000 байт.

Как решить: Проверить связь консольно с кассы командой ping -s :

tc@box:~$ ping -s 1000 10.254.94.201 
PING 10.254.94.201 (10.254.94.201): 1000 data bytes 
1008 bytes from 10.254.94.201: seq=0 ttl=58 time=36.914 ms 
1008 bytes from 10.254.94.201: seq=1 ttl=58 time=36.541 ms 
^C 
--- 10.254.94.201 ping statistics --- 
2 packets transmitted, 2 packets received, 0% packet loss 
round-trip min/avg/max = 36.541/36.727/36.914 ms 

tc@box:~$ ping -s 1500 10.254.94.201 
PING 10.254.94.201 (10.254.94.201): 1500 data bytes 
^C 
--- 10.254.94.201 ping statistics --- 
11 packets transmitted, 0 packets received, 100% packet loss

Нужно передавать проблему ИТ службе клиента

С кассы чеки ушли senttoserverstatus=2 , на сервере их нет

В этом случае они скорее всего не валидируются сервером и отклоняются в od_inbound_files.

Возможные причины:

Разные версии кассы и сервера.
не заполнены какие то поля на кассе(ch_purchase / ch_shift)
ошибки в работе PostgreSQL

На сервере все чеки есть, но не (все) выгрузились в ERP