общепит: остатки ЕГАИС после отправки ChequeV4 : ЕГАИС в опте и рознице

Да, отмена общепитных актов списания отменяет только последнюю транзакцию по марке, независимо от того, какую транзакцию по этой марке пытаетесь отменить вы.
Я на 99% уверен, что именно из-за этого архитектурного дефекта БД запретили возвратные чеки v4 - ЕГАИС структурно умеет обрабатывать транзакции только по очереди (пресловутый "блокчейн" в их понимании) и отменить не_крайнюю транзакцию сильно затратно - надо отменить все транзакции до нужной ("запомнив" их при этом), убрать нужную, затем заново просчитать все следующие транзакции. Поэтому, не удивлюсь, если в ближайшее время запретят и отмену актов списания в общепите (на "приготовление")...

если 7 дней не прошло, то можно распровести акт.

Может получилось так, что чек обработался позже акта и поэтому он и отменился первым? Поэтому 100 мл?

нет. При отмене акта списания указывается его идентификатор (WOF-....). Не получится создать запрос на отмену акта списания до его регистрации в ЕГАИС т.к. до этого момента просто неизвестен идентификатор

Лучше подождëм, что ТП ответит. Igor_NP, Вы поделитесь ответом ?

Сама по себе отмена проведенных документов - очень плохая не только технологическая, но и организационная идея. В моей программе любые отмены запрещены чтобы защититься от мошенничества. Если что-то неправильно сделал, нужно провести сторнирующую (обратную) операцию, затем перепровесли основную операцию правильно. Если что-то закупил от поставщика не то, не в том количестве или по неправильной цене, - документ остается в базе данных в таком виде навсегда (принцип моей учетной программы - написанго пером - не вырубишь топором), делается возврат (сторнирование) неверно закупленного товара по не правильной цене и в неправильном количестве, а затем новая закупка уже правильно. В итоге руководитель всегда может подойти и посмотреть - вот товаровед ошибся при закупке, вот сторнировал все ошибочное, вот перезакупил уже правильно. Вся история ошибок и их исправлений хранится в базе. Только так - правильно. Любая возможность отмены - это рассадник мошенничества, когда руководитель проверил, а затем по тихому всё отменяют. Поэтому 1С - опасная программа для хозяина предприятия - там можно так всё наотменять что незаметно для хозяина украсть пол магазина. Вот поэтому все бухгалтера всегда имеют доход больше всех. Хозяин мучается с нехваткой денег в предприятии, а бухгалтер летит на Мальдивы и в Доминикану в отпуск при этом, и хозяин не может ничего понять, как так. А всё - техническая возможность в 1С отменять операции. Эти программисты написали ее не для себя, из рук вон плохо. А я писал свою программу для себя, и сделал всё, чтобы никакое мошенничество в учете было невозможно. И первое что я придумал - невозможность никаких отмен никаким админом. Просто невозможно. Только сторнирование - правильный подход к исправлению ошибок.

Раньше бумажный бухучет был правильным - записали в журнал запись - отменить, замазать корректором, вырезать ножницами, зачеркнуть - невозможно. Только сторнировать. С этой точки зрения Блокчейн мне нравится.

Давайте и из Ворд тогда уберем возможность отменять действия. Чего уж мелочиться. Вы так лихо рассуждаете пока у вас число клиентов исчисляется сотнями. При росте масштаба вы неизбежно столкнетесь с проблемами роста и задумаетесь как их решать. И с вероятностью 99% наступите на горло своей принципиальности. Вам для понимания глубины проблемы всего-то надо найти сеть из 1000 точек продаж с несколькими кассами в каждой, ведущую общий учет.
Например. Ваше решение не корректировать запись, а делать сторно и новую запись сильно усложняет расчет налогов, расчет движений, себестоимости и т.д... Т.е. ваш повышенный контроль боком выходит в смежных областях. И пока ими занимается не ваше ПО - вас все устраивает. А если будет заниматься ваше?

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

А по теме то чего? ReplyRests_v2 у всех кривые остатки выдаëт после списания актами ActWriteOff_v4 с причиной "Приготовление" или только у меня?