Почтальонов 20 лет по ошибке сажали в тюрьму из–за «кривого» ПО

 [ Версия для печати ]
Добавить в Telegram Добавить в Twitter Добавить в Вконтакте Добавить в Одноклассники
Страницы: (5) 1 [2] 3 4 ... Последняя »  К последнему непрочитанному [ ОТВЕТИТЬ ] [ НОВАЯ ТЕМА ]
samhuawey
27.04.2021 - 14:30
2
Статус: Offline


Ярила

Регистрация: 22.09.19
Сообщений: 13665
Вот почему профессия QA так важна в современном мире. А туда берут тупых блондинок и платят мало.
 
[^]
maslokrad
27.04.2021 - 14:32
2
Статус: Offline


Ярила

Регистрация: 13.07.11
Сообщений: 4024
https://www.bbc.com/news/business-56859357

пруф на BBC если что

Это сообщение отредактировал maslokrad - 27.04.2021 - 14:35
 
[^]
samhuawey
27.04.2021 - 14:33
2
Статус: Offline


Ярила

Регистрация: 22.09.19
Сообщений: 13665
Цитата
Хм... как человек с бухгалтерским образованием и опытом, не совсем понимаю, почему такой баг, так поздно отловили.

Во первых должны были возникнуть "небьющиеся суммы" не только между выручкой и приходом ДС, но и между другими счетами БУ, что как бы должно было сигнализировать о проблеме.


А вот соглашусь. Любая проводка записывается на два счёта дебитом и кредитом. Если даже на одном счету всё будет в порядке, обязательно вылезет в отчёте по второму счёту и баланс попросту не сведётся.
 
[^]
vlad107
27.04.2021 - 14:35
3
Статус: Offline


Ярила

Регистрация: 24.12.14
Сообщений: 1745
Цитата (Bush6791 @ 27.04.2021 - 12:46)
Хм... как человек с бухгалтерским образованием и опытом, не совсем понимаю, почему такой баг, так поздно отловили.

Во первых должны были возникнуть "небьющиеся суммы"  не только между выручкой и приходом ДС, но и между другими счетами БУ, что как бы должно было сигнализировать о проблеме.

Во вторых - все подобные косяки с некоторым трудом, но вполне себе выявимы в том же Экселе.

Тоже доводилось работать с косячной программой управленческого учета - и в некоторых случаях, только выгрузка и последующие танцы с бубном в Экселе давали возможность получить правильные цифры.

Ктото издил бабло! А ктото прикрывал!

Почти 10 лет!

Вангую эффективные менеджеры...с пейсами.

Это сообщение отредактировал vlad107 - 27.04.2021 - 14:35

Почтальонов 20 лет по ошибке сажали в тюрьму из–за «кривого» ПО
 
[^]
Торк
27.04.2021 - 14:35
1
Статус: Offline


Весельчак

Регистрация: 26.04.21
Сообщений: 177
А в России ломают судьбы даже безо всякого программного обеспечения. Просто, чтобы лишнюю палку для статистики присовокупить.

Размещено через приложение ЯПлакалъ
 
[^]
romanpl
27.04.2021 - 14:37
2
Статус: Offline


Балагур

Регистрация: 22.02.11
Сообщений: 920
Мне почему-то кажется что деньги просто пиз ил встроенный троян, а когда все раскрылось списали га баг.

Размещено через приложение ЯПлакалъ
 
[^]
zhivaz
27.04.2021 - 14:39
2
Статус: Offline


Архимандардрид Секты Нессущих в Херню

Регистрация: 15.04.13
Сообщений: 1221
это не баг - это фича!©
 
[^]
Bush6791
27.04.2021 - 14:40
2
Статус: Offline


Ярила

Регистрация: 12.11.09
Сообщений: 2679
Цитата (ACKEP @ 27.04.2021 - 14:18)
Цитата (Bush6791 @ 27.04.2021 - 13:50)
Цитата (ACKEP @ 27.04.2021 - 13:25)

Я Вас умоляю! Ничего нигде не выплывет. Программа показывает что оператор получил за день 100 евро наличкой - вот будь добр их отдай! Оператор считает кассу - а там 95 евро. Смотрит в экран - там 100 евро. Пожимает плечами и докладывает свои 5 евро. Бухгалтерия даже не увидит всего этого. А если оператор не положит свои 5 евро - к нему будут претензии.

Я обслуживаю сеть аптек с кучей филиалов. Поставили несколько лет назад фискальные регистраторы АТОЛ 55Ф. И у них есть глюк - во время оформления чека он может выдать сначала "Чек аннулирован", а затем сразу нормальный чек. Вот только если чек был безнальный, то аннулируется безнальный чек, а следом выходит чек на эту же сумму, только за нал. И естественно вечером у кассира недостача в кассе на эту сумму. А бухгалтерия этого и не увидит, так как её на счет упадёт правильная сумма и 1С покажет также правильную сумму. Случается редко, но регулярно.

Интересный глюк!

Если можно - чуть глубже копнуть? -я немного не допонял - при оформлении чека продажи по безналу и его последующим глючным аннулированием и пробитием по налу - сама оплата с карты покупателя снимается?

Если снимается - то тогда по идее в одноэске должны не биться выручка по безналу с суммой ДС поступивших на РС в этот день от этой точки - т.е. выручка по программе 100, а на РС пришло 105.

При оформлении безналичной оплаты процедура такая:
1. Кассовое ПО даёт банковскому ПО команду произвести оплату на такую-то сумму.
2. Банковское ПО включает терминал, клиент прикладывает карту.
3. Результат оплаты передается от банковского ПО кассовому ПО чтобы программа знала прошла оплата или нет.
4. Кассовое ПО печатает слип - чек безналичной оплаты.
5. Кассовое ПО дает команду фискальному регистратору оформить безнальный чек.
6. После ответа от фискального регистратора о том что чек оформлен кассовое ПО регистрирует его у себя в базе.

Получается что в описанном выше примере с карты клиента деньги будут списаны и попадут на расчетный счет организации. Ошибка на уровне фискального регистратора, кассовая программа и не знает что в момент оформления чека произошла ошибка. Поэтому кассовое ПО оформит чек как безнальный и в 1С эта продажа отразится именно как безнальная. Поэтому у бухгалтерии всё сойдется. А вот кассир вечером обнаружит недостачу, так как сумма наличных в кассе не будет соответствовать той сумме, который покажет Z-Отчет при закрытии смены.

Этот пример я привел для того чтобы показать какие бывают трудноуловимые глюки. И они не зависят от времени выпуска ПО или страны. К примеру, у того же банковского ПО от Сбербанка есть глюк, в результате которого после успешной оплаты результат операции не передается кассовому ПО. Программа выдает соответствующее предупреждение и по инструкции кассир в этот момент должен совершить определенные действия чтобы проверить - прошла оплата или нет. Но если кассир этого не знал/забыл, то он просит клиента ещё раз провести оплату. В итоге с карты сумма списывается дважды. Приходится потом оформлять отмену операции. Бывает также редко, но регулярно.

БОЛЬШОЕ спасибо за ПОДРОБНЕЙШУЮ консультацию! pray.gif

Все разложено как у настоящего профессионала по полочкам. bravo.gif
 
[^]
Polugut
27.04.2021 - 14:43
0
Статус: Offline


Ярила

Регистрация: 27.11.18
Сообщений: 4876
Японцы тонко отмстили бриттам за поражение в ВМВ?
 
[^]
Fedor17898
27.04.2021 - 14:46
3
Статус: Offline


Ярила

Регистрация: 14.11.13
Сообщений: 2787
Бред какой-то, работал в оптовом магазе корни любой недостача можно найти, этим мы часто и занимались

Размещено через приложение ЯПлакалъ
 
[^]
cosmonova
27.04.2021 - 14:47
0
Статус: Offline


Хохмач

Регистрация: 28.08.19
Сообщений: 792
Цитата (Диногаврик @ 27.04.2021 - 12:40)
А я уверен что пост офис знал об этом баге в своём ПО. Ведь время от времени они инспектировали ПО. И им указывали об ошибке.
Но англичанин есть англичанин. Никогда не признает свою ошибку.

Зато и есть независимый суд, который заставит компанию выплатить миллионные компенсации, вплоть до ликвидации компании

Размещено через приложение ЯПлакалъ
 
[^]
samhuawey
27.04.2021 - 14:47
2
Статус: Offline


Ярила

Регистрация: 22.09.19
Сообщений: 13665
Цитата
Получается что в описанном выше примере с карты клиента деньги будут списаны и попадут на расчетный счет организации. Ошибка на уровне фискального регистратора, кассовая программа и не знает что в момент оформления чека произошла ошибка.


Чувак ты гонишь. Проводка пойдёт кредит на товары, дебит на кеш. Если в кеше на 10 фунтов больше, к концу дня баланс не сойдётся ровно на те же 10 фунтов и продавца пошлют пересчитывать склады. И если складской учёт ведётся ровно (материальные балансы сходятся), то сразу заподозрят неправильно списанную сумму.

То что ты описываешь - это бардак и отсутствие учёта.
 
[^]
Aberrant
27.04.2021 - 14:49
3
Статус: Offline


На фоксе! Всегда!

Регистрация: 3.10.20
Сообщений: 2723
ошибка может быть "накопительная"
например из-за неправильного приведения типов в переменных или в БД.

на этапе отчёта сотрудника и сдачи выручки у него всё сходилось.
на этапе занесения в базу случался глюк,
всё это накапливалось до первой сверки,
которая показывала крупную недостачу по какому-то отделению - деньги найти не могли и просто списывали всё на хитрые махинации.


вы себе даже не представляете сколько раз в день исправляется банальщина вроде : в БД задали тип TINYTEXT, а на деле иногда в строку попадает больше 255 символов
или сначала считают кол-во символов, а перед записью в БД переводят сущности типа кавычек в ссылки на сущности (в тексте у тебя символ ",
а в БД, это уже ") - было 1 символ, а вместо него получилось 6

и дело может быть даже не в том, что программист дурак,
а в том, что разные куски кода пишутся разными людьми.
одни писал основу бекэнда, а второй занимался БД и записью в БД,
не поставив первого в известность, что он решил подстраховаться и "экранировать" все кавычки
 
[^]
ACKEP
27.04.2021 - 14:50
2
Статус: Offline


Ярила

Регистрация: 17.09.13
Сообщений: 4094
Цитата (samhuawey @ 27.04.2021 - 14:47)
Цитата
Получается что в описанном выше примере с карты клиента деньги будут списаны и попадут на расчетный счет организации. Ошибка на уровне фискального регистратора, кассовая программа и не знает что в момент оформления чека произошла ошибка.


Чувак ты гонишь. Проводка пойдёт кредит на товары, дебит на кеш. Если в кеше на 10 фунтов больше, к концу дня баланс не сойдётся ровно на те же 10 фунтов и продавца пошлют пересчитывать склады. И если складской учёт ведётся ровно (материальные балансы сходятся), то сразу заподозрят неправильно списанную сумму.

То что ты описываешь - это бардак и отсутствие учёта.

Читай внимательней и поймешь о чем речь. До проводок там даже не доходит, всё на уровне кассового ПО и железа ФР.
 
[^]
edelweisss
27.04.2021 - 14:51
0
Статус: Offline


Шутник

Регистрация: 3.12.20
Сообщений: 91
Ага... Ошиблись они... Только чей-то в свой карман... И когда обнаружили продолжили ошибаться с этой програмулькой дальше в место того что бы её сразу остановить.
 
[^]
ТолстоКото
27.04.2021 - 14:51
3
Статус: Offline


Балагур

Регистрация: 15.10.15
Сообщений: 833
Цитата (dennsp @ 27.04.2021 - 12:33)
ИТ-технологии развиваются постоянно, в сфере разработки ПО новые технологии появляются чуть ли не каждый день. Контора пользуется ПО, написанным в 1995 году, когда еще интернет был в зачаточном состоянии. Как это возможно? А почту они не на конных повозках возят случайно?

Стоимость и трудозатраты перевнедрения ПО в таких компаниях будут стремится куда то в космос. Пока оо работает, какой смысл менять? Чтобы интерфейсы были вебовские и тормозил и побольше?
Кроме того, в случае вбиварич данных в ПО вручную современные интерфейсы не выдерживают никакой критики.
Время на внесение документа увеличилось в разы...

Размещено через приложение ЯПлакалъ
 
[^]
gelo71
27.04.2021 - 14:52
0
Статус: Offline


Ярила

Регистрация: 30.11.12
Сообщений: 1289
А вот у Печкина не было никаких ИТ-технологий и соответственно проблем таких не было. Кто бы что не говорил, а для работника почты главное велосипед

Почтальонов 20 лет по ошибке сажали в тюрьму из–за «кривого» ПО
 
[^]
StockTrader
27.04.2021 - 14:52
0
Статус: Offline


Ярила

Регистрация: 2.01.21
Сообщений: 1308
Скорее всего суть проблемы в истользовании вещественных типов, вместо денежных типов.
 
[^]
StockTrader
27.04.2021 - 14:53
0
Статус: Offline


Ярила

Регистрация: 2.01.21
Сообщений: 1308
Цитата (masterx777 @ 27.04.2021 - 12:33)
"Fujitsu"

Там должна быть надпись: "ну я же извинилась"
 
[^]
samhuawey
27.04.2021 - 14:54
0
Статус: Offline


Ярила

Регистрация: 22.09.19
Сообщений: 13665
Цитата (ACKEP @ 27.04.2021 - 14:50)
Цитата (samhuawey @ 27.04.2021 - 14:47)
Цитата
Получается что в описанном выше примере с карты клиента деньги будут списаны и попадут на расчетный счет организации. Ошибка на уровне фискального регистратора, кассовая программа и не знает что в момент оформления чека произошла ошибка.


Чувак ты гонишь. Проводка пойдёт кредит на товары, дебит на кеш. Если в кеше на 10 фунтов больше, к концу дня баланс не сойдётся ровно на те же 10 фунтов и продавца пошлют пересчитывать склады. И если складской учёт ведётся ровно (материальные балансы сходятся), то сразу заподозрят неправильно списанную сумму.

То что ты описываешь - это бардак и отсутствие учёта.

Читай внимательней и поймешь о чем речь. До проводок там даже не доходит, всё на уровне кассового ПО и железа ФР.

Проводок нет - нет финансового результата. При чём тут недостача?

Не такой большой оборот у почты чтобы не попробовать пару раз записать всё в бумажном журнале а потом выверить с программой. Я не сомневаюсь что почтальоны умом повыше среднего, поэтому новость скорее всего фейк.

Это сообщение отредактировал samhuawey - 27.04.2021 - 14:56
 
[^]
StockTrader
27.04.2021 - 14:54
1
Статус: Offline


Ярила

Регистрация: 2.01.21
Сообщений: 1308
Цитата (dennsp @ 27.04.2021 - 12:33)
ИТ-технологии развиваются постоянно, в сфере разработки ПО новые технологии появляются чуть ли не каждый день. Контора пользуется ПО, написанным в 1995 году, когда еще интернет был в зачаточном состоянии. Как это возможно? А почту они не на конных повозках возят случайно?

Большие компании очень отсталые в этом плане, у многих банков лет 7 назад еще стоял и активно использовался internet explorer 6.0
 
[^]
StockTrader
27.04.2021 - 14:55
0
Статус: Offline


Ярила

Регистрация: 2.01.21
Сообщений: 1308
Цитата (rmrv @ 27.04.2021 - 12:34)
просто тестирование проводилось на небольших объемах данных, а в реальной жизни вылезли глюки. Хватит даже где-то округление сделать, задав тип числа меньше необходимого, и вместо 1 миллиарда будет 999 999 999.. Как программист говорю

Просто такие компьтерщики, что не знают, что вещественный тип не дает точных результатов.
 
[^]
StockTrader
27.04.2021 - 14:57
0
Статус: Offline


Ярила

Регистрация: 2.01.21
Сообщений: 1308
Цитата (Bush6791 @ 27.04.2021 - 12:46)
Хм... как человек с бухгалтерским образованием и опытом, не совсем понимаю, почему такой баг, так поздно отловили.

Во первых должны были возникнуть "небьющиеся суммы" не только между выручкой и приходом ДС, но и между другими счетами БУ, что как бы должно было сигнализировать о проблеме.

Во вторых - все подобные косяки с некоторым трудом, но вполне себе выявимы в том же Экселе.

Тоже доводилось работать с косячной программой управленческого учета - и в некоторых случаях, только выгрузка и последующие танцы с бубном в Экселе давали возможность получить правильные цифры.

Те объемы данных с которыми они работают в эксель не загонишь
 
[^]
Archimedis
27.04.2021 - 14:57
-1
Статус: Offline


Ярила

Регистрация: 15.03.18
Сообщений: 3896
- Античеловеческий режим убивает своих граждан!
- Так это же в Великобритании!
- А, ну, так ошибки у всех бывают...
 
[^]
Aberrant
27.04.2021 - 14:59
-1
Статус: Offline


На фоксе! Всегда!

Регистрация: 3.10.20
Сообщений: 2723
Цитата (StockTrader @ 27.04.2021 - 14:55)
Цитата (rmrv @ 27.04.2021 - 12:34)
просто тестирование проводилось на небольших объемах данных, а в реальной жизни вылезли глюки. Хватит даже где-то округление сделать, задав тип числа меньше необходимого, и вместо 1 миллиарда будет 999 999 999.. Как программист говорю

Просто такие компьтерщики, что не знают, что вещественный тип не дает точных результатов.

про вещественные типы знают только 1С`совцы,
программисты сейчас чешут репу lol.gif
 
[^]
Понравился пост? Еще больше интересного в Телеграм-канале ЯПлакалъ!
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста, или зарегистрируйтесь, если не зарегистрированы.
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) Просмотры темы: 28623
0 Пользователей:
Страницы: (5) 1 [2] 3 4 ... Последняя » [ ОТВЕТИТЬ ] [ НОВАЯ ТЕМА ]


 
 



Активные темы






Наверх