Размышления на тему учета пива в УС... : ЕГАИС в опте и рознице

В общем, я наверное у себя реализую нечто подобное... Сейчас у меня, можно заполнять списание по партиям УС... Что похоже на правду, но может вызвать необеспеченный расход, так, как не связано с остатками ЕГАИС... Надо совместить одно с другим(надо еще придумать как), и будет нормально. Вот только будет обидно, если все сделаю, а эту хрень с учетом НМ АП по АлкоКодам отменят:)))

Имеем список проданных товаров в УС и остатки из Егаис в разрезе алкокодов. Связь товаров в УС и алкокодов многие-ко-многим.

Можно попробовать такой алгоритм.
1. Проходим по списку проданных товаров, обрабатываем каждый из них.
2. Для каждого товара определяем алкокоды по, например, последним 10 приходам (у меня алкокоды сохраняются в приходных накладных, создаваемых на основании приходов по Егаис).
3. По каждому алкокоду товара из полученного списка лезем в остатки, полученные из Егаис, и пытаемся подобрать общее количество, которое было продано по товару. Подобранное количество в разрезе алкокодов сохраняем, чтобы не списать повторно, если один алкокод у разных товаров.
4. Если подобрать полное проданное количество не удалось, вешаем как не привязанную к алкокоду строку в отчете для ручной корректировки. Надеемся, что таких не будет или будет очень мало.
5. Создаем документ списания с торгового зала для Егаис в разрезе алкокодов. Если нужно, корректируем вручную не определенные алкокоды, отправляем...
6. Периодически проводим инвентаризацию и устраняем пересорт.

Хотя тоже не фонтан...

Забил я все-таки на свой партионный учет, который в УС, не вижу в нем смысла - все равно отражать реальные остатки не будет(в программе будет все красиво, а реально на полках все не так), а сложностей куча - чуть что разъедется, и лови "необеспеченный расход".
Сделал списание АК с сортировкой по остатку...
Запрашиваю остатки ЕГАИС, сохраняю в отдельной таблице. После чего, получаю продажи с закрытых кассовых отчетов, собираю их в одну таблицу со сверткой по номенклатуре.
Бегу потом по этой таблице, и для каждой номенклатурной позиции выбираю из таблицы остатков АлкоКоды в отдельную табличку. Потом ее, эту таблицу с АлкоКодами для текущего наименования сортирую по возрастанию количества. Ну, и заполняю строки документа списания, из этой таблички, пока все необходимое(проданное за смену) количество для текущей позиции не будет выбрано.
Решил - ну, раз нет в остатках Р2 признака партий для организации полноценного партионного учета и списания по ФИФО, то пусть списывается сначала те АлкоКоды по конкретной номенклатуре, остаток по которым меньше, а потом следующие, по возрастанию количества... Типа, то, что раньше пришло, продалось в большем объеме(соответственно остаток меньше), а чего больше на остатках, соответственно позже пришло, и пусть еще на остатках "поваляется"
Пока инвентаризация по пиву не сделана, остатки большие, и чего-то не хватить не может в принципе, а если вдруг и не хватит, то будет выдано соответствующее сообщение, текущая позиция спишется до нуля, а сколько "осталось списать" будет в этом сообщении. При желании, можно будет в ручную разобраться, а можно и забить...

PS Это все конечно "за уши притянуто", но и весь учет немаркируемой АП такой, других вариантов я не вижу... Кроме, конечно 100% внутреннего ШтрихКодирования, что тоже считаю неприемлемым.

Это примерно то же, что я писал. Единственный момент опущен - это определение алкокодов для каждой проданной позиции, т.к. соответствие не однозначное.
Еще дополнительно надо похожий алгоритм наладить для результатов инвентаризации. Недостачи (списываемое количество) как расход, излишки как постановка на баланс в Егаис...

Как говорил один разработчик УС, что если ФСРАР будет требовать точно отражать движения пива, ну значит, декларанты будут делать вид, что заносят в ЕГАИС корректную информацию, а ФСРАР будет делать вид, что в это верит.

Чтобы информация была корректная, надо маркировать пиво. Скорее всего, со временем к этому и придут...