Хм... как человек с бухгалтерским образованием и опытом, не совсем понимаю, почему такой баг, так поздно отловили.
Во первых должны были возникнуть "небьющиеся суммы" не только между выручкой и приходом ДС, но и между другими счетами БУ, что как бы должно было сигнализировать о проблеме.
А вот соглашусь. Любая проводка записывается на два счёта дебитом и кредитом. Если даже на одном счету всё будет в порядке, обязательно вылезет в отчёте по второму счёту и баланс попросту не сведётся.
Хм... как человек с бухгалтерским образованием и опытом, не совсем понимаю, почему такой баг, так поздно отловили.
Во первых должны были возникнуть "небьющиеся суммы" не только между выручкой и приходом ДС, но и между другими счетами БУ, что как бы должно было сигнализировать о проблеме.
Во вторых - все подобные косяки с некоторым трудом, но вполне себе выявимы в том же Экселе.
Тоже доводилось работать с косячной программой управленческого учета - и в некоторых случаях, только выгрузка и последующие танцы с бубном в Экселе давали возможность получить правильные цифры.
Ктото издил бабло! А ктото прикрывал!
Почти 10 лет!
Вангую эффективные менеджеры...с пейсами.
Это сообщение отредактировал vlad107 - 27 апр 2021 в 14:35
А в России ломают судьбы даже безо всякого программного обеспечения. Просто, чтобы лишнюю палку для статистики присовокупить.
Размещено через приложение ЯПлакалъ
Я Вас умоляю! Ничего нигде не выплывет. Программа показывает что оператор получил за день 100 евро наличкой - вот будь добр их отдай! Оператор считает кассу - а там 95 евро. Смотрит в экран - там 100 евро. Пожимает плечами и докладывает свои 5 евро. Бухгалтерия даже не увидит всего этого. А если оператор не положит свои 5 евро - к нему будут претензии.
Я обслуживаю сеть аптек с кучей филиалов. Поставили несколько лет назад фискальные регистраторы АТОЛ 55Ф. И у них есть глюк - во время оформления чека он может выдать сначала "Чек аннулирован", а затем сразу нормальный чек. Вот только если чек был безнальный, то аннулируется безнальный чек, а следом выходит чек на эту же сумму, только за нал. И естественно вечером у кассира недостача в кассе на эту сумму. А бухгалтерия этого и не увидит, так как её на счет упадёт правильная сумма и 1С покажет также правильную сумму. Случается редко, но регулярно.
Интересный глюк!
Если можно - чуть глубже копнуть? -я немного не допонял - при оформлении чека продажи по безналу и его последующим глючным аннулированием и пробитием по налу - сама оплата с карты покупателя снимается?
Если снимается - то тогда по идее в одноэске должны не биться выручка по безналу с суммой ДС поступивших на РС в этот день от этой точки - т.е. выручка по программе 100, а на РС пришло 105.
При оформлении безналичной оплаты процедура такая: 1. Кассовое ПО даёт банковскому ПО команду произвести оплату на такую-то сумму. 2. Банковское ПО включает терминал, клиент прикладывает карту. 3. Результат оплаты передается от банковского ПО кассовому ПО чтобы программа знала прошла оплата или нет. 4. Кассовое ПО печатает слип - чек безналичной оплаты. 5. Кассовое ПО дает команду фискальному регистратору оформить безнальный чек. 6. После ответа от фискального регистратора о том что чек оформлен кассовое ПО регистрирует его у себя в базе.
Получается что в описанном выше примере с карты клиента деньги будут списаны и попадут на расчетный счет организации. Ошибка на уровне фискального регистратора, кассовая программа и не знает что в момент оформления чека произошла ошибка. Поэтому кассовое ПО оформит чек как безнальный и в 1С эта продажа отразится именно как безнальная. Поэтому у бухгалтерии всё сойдется. А вот кассир вечером обнаружит недостачу, так как сумма наличных в кассе не будет соответствовать той сумме, который покажет Z-Отчет при закрытии смены.
Этот пример я привел для того чтобы показать какие бывают трудноуловимые глюки. И они не зависят от времени выпуска ПО или страны. К примеру, у того же банковского ПО от Сбербанка есть глюк, в результате которого после успешной оплаты результат операции не передается кассовому ПО. Программа выдает соответствующее предупреждение и по инструкции кассир в этот момент должен совершить определенные действия чтобы проверить - прошла оплата или нет. Но если кассир этого не знал/забыл, то он просит клиента ещё раз провести оплату. В итоге с карты сумма списывается дважды. Приходится потом оформлять отмену операции. Бывает также редко, но регулярно.
БОЛЬШОЕ спасибо за ПОДРОБНЕЙШУЮ консультацию!
Все разложено как у настоящего профессионала по полочкам.
А я уверен что пост офис знал об этом баге в своём ПО. Ведь время от времени они инспектировали ПО. И им указывали об ошибке. Но англичанин есть англичанин. Никогда не признает свою ошибку.
Зато и есть независимый суд, который заставит компанию выплатить миллионные компенсации, вплоть до ликвидации компании
Размещено через приложение ЯПлакалъ
Получается что в описанном выше примере с карты клиента деньги будут списаны и попадут на расчетный счет организации. Ошибка на уровне фискального регистратора, кассовая программа и не знает что в момент оформления чека произошла ошибка.
Чувак ты гонишь. Проводка пойдёт кредит на товары, дебит на кеш. Если в кеше на 10 фунтов больше, к концу дня баланс не сойдётся ровно на те же 10 фунтов и продавца пошлют пересчитывать склады. И если складской учёт ведётся ровно (материальные балансы сходятся), то сразу заподозрят неправильно списанную сумму.
То что ты описываешь - это бардак и отсутствие учёта.
ошибка может быть "накопительная" например из-за неправильного приведения типов в переменных или в БД.
на этапе отчёта сотрудника и сдачи выручки у него всё сходилось. на этапе занесения в базу случался глюк, всё это накапливалось до первой сверки, которая показывала крупную недостачу по какому-то отделению - деньги найти не могли и просто списывали всё на хитрые махинации.
вы себе даже не представляете сколько раз в день исправляется банальщина вроде : в БД задали тип TINYTEXT, а на деле иногда в строку попадает больше 255 символов или сначала считают кол-во символов, а перед записью в БД переводят сущности типа кавычек в ссылки на сущности (в тексте у тебя символ ", а в БД, это уже ") - было 1 символ, а вместо него получилось 6
и дело может быть даже не в том, что программист дурак, а в том, что разные куски кода пишутся разными людьми. одни писал основу бекэнда, а второй занимался БД и записью в БД, не поставив первого в известность, что он решил подстраховаться и "экранировать" все кавычки
Получается что в описанном выше примере с карты клиента деньги будут списаны и попадут на расчетный счет организации. Ошибка на уровне фискального регистратора, кассовая программа и не знает что в момент оформления чека произошла ошибка.
Чувак ты гонишь. Проводка пойдёт кредит на товары, дебит на кеш. Если в кеше на 10 фунтов больше, к концу дня баланс не сойдётся ровно на те же 10 фунтов и продавца пошлют пересчитывать склады. И если складской учёт ведётся ровно (материальные балансы сходятся), то сразу заподозрят неправильно списанную сумму.
То что ты описываешь - это бардак и отсутствие учёта.
Читай внимательней и поймешь о чем речь. До проводок там даже не доходит, всё на уровне кассового ПО и железа ФР.
Ага... Ошиблись они... Только чей-то в свой карман... И когда обнаружили продолжили ошибаться с этой програмулькой дальше в место того что бы её сразу остановить.
ИТ-технологии развиваются постоянно, в сфере разработки ПО новые технологии появляются чуть ли не каждый день. Контора пользуется ПО, написанным в 1995 году, когда еще интернет был в зачаточном состоянии. Как это возможно? А почту они не на конных повозках возят случайно?
Стоимость и трудозатраты перевнедрения ПО в таких компаниях будут стремится куда то в космос. Пока оо работает, какой смысл менять? Чтобы интерфейсы были вебовские и тормозил и побольше? Кроме того, в случае вбиварич данных в ПО вручную современные интерфейсы не выдерживают никакой критики. Время на внесение документа увеличилось в разы...
Размещено через приложение ЯПлакалъ
Получается что в описанном выше примере с карты клиента деньги будут списаны и попадут на расчетный счет организации. Ошибка на уровне фискального регистратора, кассовая программа и не знает что в момент оформления чека произошла ошибка.
Чувак ты гонишь. Проводка пойдёт кредит на товары, дебит на кеш. Если в кеше на 10 фунтов больше, к концу дня баланс не сойдётся ровно на те же 10 фунтов и продавца пошлют пересчитывать склады. И если складской учёт ведётся ровно (материальные балансы сходятся), то сразу заподозрят неправильно списанную сумму.
То что ты описываешь - это бардак и отсутствие учёта.
Читай внимательней и поймешь о чем речь. До проводок там даже не доходит, всё на уровне кассового ПО и железа ФР.
Проводок нет - нет финансового результата. При чём тут недостача?
Не такой большой оборот у почты чтобы не попробовать пару раз записать всё в бумажном журнале а потом выверить с программой. Я не сомневаюсь что почтальоны умом повыше среднего, поэтому новость скорее всего фейк.
Это сообщение отредактировал samhuawey - 27 апр 2021 в 14:56
ИТ-технологии развиваются постоянно, в сфере разработки ПО новые технологии появляются чуть ли не каждый день. Контора пользуется ПО, написанным в 1995 году, когда еще интернет был в зачаточном состоянии. Как это возможно? А почту они не на конных повозках возят случайно?
Большие компании очень отсталые в этом плане, у многих банков лет 7 назад еще стоял и активно использовался internet explorer 6.0
просто тестирование проводилось на небольших объемах данных, а в реальной жизни вылезли глюки. Хватит даже где-то округление сделать, задав тип числа меньше необходимого, и вместо 1 миллиарда будет 999 999 999.. Как программист говорю
Просто такие компьтерщики, что не знают, что вещественный тип не дает точных результатов.
Хм... как человек с бухгалтерским образованием и опытом, не совсем понимаю, почему такой баг, так поздно отловили.
Во первых должны были возникнуть "небьющиеся суммы" не только между выручкой и приходом ДС, но и между другими счетами БУ, что как бы должно было сигнализировать о проблеме.
Во вторых - все подобные косяки с некоторым трудом, но вполне себе выявимы в том же Экселе.
Тоже доводилось работать с косячной программой управленческого учета - и в некоторых случаях, только выгрузка и последующие танцы с бубном в Экселе давали возможность получить правильные цифры.
Те объемы данных с которыми они работают в эксель не загонишь
просто тестирование проводилось на небольших объемах данных, а в реальной жизни вылезли глюки. Хватит даже где-то округление сделать, задав тип числа меньше необходимого, и вместо 1 миллиарда будет 999 999 999.. Как программист говорю
Просто такие компьтерщики, что не знают, что вещественный тип не дает точных результатов.
про вещественные типы знают только 1С`совцы, программисты сейчас чешут репу
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста, или зарегистрируйтесь, если не зарегистрированы.
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
yaplakal.com
samhuawey27 апр 2021 в 14:30