Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли > КИС Lack & УС Land

УС Лэнд:ЕГАИС – карта решаемых задач ЕГАИС, вопросы, замечания, предложения, доработки : КИС Lack & УС Land

04.02.2023 9:29


Контакты Поиск
03.12.2021 05:25
plvn24
 
Не судьбоносно, но таки задам вопрос:

Цитата:
Дробные количества алкопродукции. Раннее в программе можно было принимать такие ТТН и списывать с дробями со склада. Сейчас добавлены возможность создавать расходную ТТН с дробными количествами, например для возврата нефасованного пива. Везде унифицирована работа с количествами АП. Если «литраж» нулевой – нефасованная алкопродукция, то программа работает и отражает информацию с точностью 10.3, а иначе контроль, отражение, формы ввода только в целых числах.
А как же с ТЗ? В документах трансфера нет возможности проставить дробное количество.
Также в отчете "Гибкий анализ остатков регистров.." округленные значения.
Речь о предпоследнем релизе программы.
Или я как-то криво обновился?
03.12.2021 07:59
AndreyZh
 
Цитата:
plvn24 Не судьбоносно, но таки задам вопрос:

А как же с ТЗ? В документах трансфера нет возможности проставить дробное количество.
Также в отчете "Гибкий анализ остатков регистров.." округленные значения.
Речь о предпоследнем релизе программы.
Или я как-то криво обновился?
По ТЗ… Так оно и есть - учет и операции в ТЗ и обмен со складом делается в целых величинах. Вводить там дроби не считаю разумным, т.к. это отмирающий регистр, да и по сути нужно переделывать очень много, а смысл?

Отчет по остаткам… Резонное замечание, т.к. на складе допускаются дроби - сделаю к завершающему сезон релизу, который выложу в декабре
09.12.2021 16:47
AndreyZh
 
Цитата:
plvn24 Также в отчете "Гибкий анализ остатков регистров.." округленные значения.
Исследовал - в данном отчете все количества даются дробями... Посмотрите внимательно! Однако унифицировал с обычным подходом... Сейчас нефасованная АП отражается дробями во всех форматах, а фасованная целыми величинами

Кроме этого для поиска с целью списания "хвостов" добавил возможности в поиске/группировании:
- искать дробные остатки
- искать только АП с целыми или только дробными остатками


09.12.2021 18:37
plvn24
 
Цитата:
AndreyZh Исследовал - в данном отчете все количества даются дробями... Посмотрите внимательно!
Уже все вернул-списал, пока нет возможности проверить.. Возможно напутал конечно...
02.01.2022 07:03
plvn24
 
С Наступившим!

Вот вчера обнаружил, что разделитель для пива не работает в моих обновленных базах УСЕга (обновлялся с релиза 29/10/21 на релиз 21/12/21)
Конкретно интересовал отчет по остаткам в формате декларации и выгрузки приходов для декларации.
Со значеним "по всем" работает
В отчете "Гибкий анализ остатков регистров" при установленном "по всем", но с фильтром по КВАП:
- строка КВАП "500,520" - в отчете только 520
- строка КВАП "520,500" - в отчете только 500
т.е. берется последнее

Цитата:
В программу внедрен новый расширенный список КВАП, по которому программа определяет, что данная алкопродукция считается «пивом», т.е. не продаётся по чекам, по которой разделяются многие режимы и информация в отчетах. Предположил, что этот список правильный и используется, если ваш список не задан в настройке программы, т.е. вы можете его переопределить по своему усмотрению
В моих настройках для пива прописано "500,510,520,261,262,263"
Я чего-то недопонял возможно, с этими МРЦ 2022 надо/не надо, косяками егаис по остаткам, ключами и прочими "нововведениями"....
02.01.2022 14:04
AndreyZh
 
Цитата:
plvn24 С Наступившим!

Вот вчера обнаружил, что разделитель для пива не работает в моих обновленных базах УСЕга (обновлялся с релиза 29/10/21 на релиз 21/12/21)
Конкретно интересовал отчет по остаткам в формате декларации и выгрузки приходов для декларации.
Со значеним "по всем" работает
В отчете "Гибкий анализ остатков регистров" при установленном "по всем", но с фильтром по КВАП:
- строка КВАП "500,520" - в отчете только 520
- строка КВАП "520,500" - в отчете только 500
т.е. берется последнее

В моих настройках для пива прописано "500,510,520,261,262,263"
… и Вас с наступившим Н/Г.
Не доделал в версии 26.11.21... Пока можно обмануть программу давая списки код_2пробела, например:500 ,510, 520 , Доделаю - пришлю

Цитата:
plvn24 Я чего-то недопонял возможно, с этими МРЦ 2022 надо/не надо, косяками егаис по остаткам, ключами и прочими "нововведениями"....
МРЦ пока старые, ну а остальное в процессе
02.01.2022 17:44
AndreyZh
 
Цитата:
AndreyZh Не доделал в версии 26.11.21... Пока можно обмануть программу давая списки код_2пробела, например:500 ,510, 520 , Доделаю - пришлю
Вроде бы исправил недоработки в отчете, а так же в приложенный "левый" релиз добавлена функция: https://olegon.ru/showpost.php?p=378092&postcount=43 Релиз без пароля, для задачи: https://olegon.ru/showthread.php?t=31234 его можно использовать "как есть"... Пусть повисит недельку...


P.S. Сейчас в программе список КВАП, по которым программа относит алкопродукцию к пиву: 500,510,520,530,531,532,533,534,535,536,537,538,261,2611,262,263 и список заменяется данными переменной настройки программы

З.Ы. 11.01.22 Убрал нелегальный релиз програмы
24.01.2022 20:00
AndreyZh
 
В процессе текущей работы по выявлению косяков ЕГАИС снова обнаружилось, что при работе с рабочих станций сети на больших таблицах, означенный только сообщением процессы могут происходить очень долго... Особенно на пуле марок, где их сотни тысяч.

Добавил "бегунки", типа: https://olegon.ru/showthread.php?t=30892 и возможность прерывать процессы на операциях пула:

1. Поиск с текущего места по кнопке F5;
2. Справки по оперативному выявлению рассогласований регистров:





Последовательно в течении несколько дней производил улучшайзинг процесса выявления расхождений регистров:

1. Для "ручной" ревизии сейчас по запросу можно отражать имена товаров полностью... уже нет картинки - и типы марок, по которым имеются расхождения:





2. Через оное место добавил стандартную для отчетов возможность выгрузки в DBF файл, который легко открывается в электронной таблице... Удобнее печатать и вносить инфу:





10.02.2022 15:28
AndreyZh
 
Писец подкрался незаметно...

Переделывая контролы отнесения КВАП к "пиву"... неоднократно в течении 3 месяцев только вчера обратил внимание на новый потенциальный "косяк" программы "УС Лэнд:ЕГАИС": В принципе ей безразличен набор кодов КВАП "пива", а так же упоминаемые в разделе недоработки программы, когда она не может определить, что алкоголь относится к "пиву" - не везде доработал, что нужно код очищать от пробелов при анализе. Например сейчас код в базе "500 " (два пробела в конце), а список КВАП для пива, условно "500,510,520"... и из-за пробелов к конце нет вхождения кода в список.

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

Новая, свежая, исправленная проблема! Длина строки в переменных настройки ограничена 72 символами... и вдруг заметил, что настройка кодов для "пива" - сейчас: "500,510,520,530,531,532,533,534,535,536,537,538,261,2611,2612,2613,2614,262,263" - 80 знаков... Тем более, если добавлять пробелы, то нет возможности корректно задать настройку

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





P.S. А в остальном... для прочих режимов программы... для маркированного алкоголя - КВАП длинной больше 3 знаков есть уже во множестве приходов, например:
Код:
<wb:Position>
					<wb:Product>
						<pref:UnitType>Packed</pref:UnitType>
						<pref:FullName>Вино сортовое ординарное полусладкое красное Киндзмараули торговой марки ГЕНАЦВАЛЕ</pref:FullName>
						<pref:ShortName>Вино сортовое ординарное полусладкое красное Киндзмараули торгов</pref:ShortName>
						<pref:AlcCode>0100606958900000022</pref:AlcCode>
						<pref:Capacity>0.75</pref:Capacity>
						<pref:AlcVolume>8.5</pref:AlcVolume>
						<pref:Producer>
							<oref:FO>
								<oref:ClientRegId>050000047509</oref:ClientRegId>
								<oref:FullName>ООО «Компания Алкогольных Напитков Алаверди»</oref:FullName>
								<oref:ShortName>ООО"Комп.Алк.Нап.Алав"</oref:ShortName>
								<oref:address>
									<oref:Country>268</oref:Country>
									<oref:description>1519, cело Чумлаки, Гурджаанский район, Грузия</oref:description>
								</oref:address>
							</oref:FO>
						</pref:Producer>
						<pref:ProductVCode>4034</pref:ProductVCode>
					</wb:Product>
					<wb:Quantity>12</wb:Quantity>
					<wb:Price>458.85</wb:Price>
					<wb:EAN13>4860114480046</wb:EAN13>
					<wb:Identity>34</wb:Identity>
					<wb:FARegId>FA-000000048167253</wb:FARegId>
					<wb:InformF2>
						<ce:F2RegId>FB-000004546287860</ce:F2RegId>
						<ce:MarkInfo>
							<ce:boxpos>
								<ce:boxnumber>01006069589013221000327895</ce:boxnumber>
								<ce:amclist>
									<ce:amc>192401370857771220001JSS2QCKFRFYN3C4ED42VLJK2444EUUIDA32HIKQDPV4O5JJI76B3FAEHS5GT6VMU3BG4BQ3CVMPVKUTYC77I4E2LLEKYFPGUARTR5SWKWFQCOQ4POKN5IFWNWQGCNLBYQ</ce:amc>
….								</ce:amclist>
							</ce:boxpos>
							<ce:boxpos>
								<ce:boxnumber>01006069589013221000327918</ce:boxnumber>
								<ce:amclist>
									<ce:amc>192401370858301220001YHYRNAWBWDZA6MTDT2PIWKAT2Y7N2N6ATJEU5YR3LAN3JT4FXCYM4TDOJVEUK46AAR5FBRP5KAVGJHUTGUVUUHEJW76MQZUZ23PI7BOMNT5TVYA46EZLEYPUQHA74VMKY</ce:amc>
...								<ce:amclist>
							</ce:boxpos>
						</ce:MarkInfo>
					</wb:InformF2>
					<wb:boxInfo>
						<wb:boxtree>
							<ce:boxnum>01006069924320022000011596</ce:boxnum>
							<ce:bl>
								<ce:boxnum>01006069589013221000327895</ce:boxnum>
								<ce:boxnum>01006069589013221000327918</ce:boxnum>
							</ce:bl>
						</wb:boxtree>
					</wb:boxInfo>
				</wb:Position>

Как следствие - программы декларирования уже с 1 квартала 2022 должны уметь корректно работать с расширенным списком КВАП: https://olegon.ru/showpost.php?p=379237&postcount=128, где код может иметь длину от 3 до 5 знаков
05.04.2022 09:23
AndreyZh
 
Новая технология. Изредка возникала проблема из-за того, что программа в своей БД не хранит дату акта на приходную накладную. Возникали вопросы двух типов:

1. Приход в декларации должен попадать в период реального получения алкоголя - период акта... Просто в реале не встречались ситуации, когда дата накладной в одном квартале, а поступление товара в другом;
2. Иногда возникал вопрос с продавцам - когда они подтверждали приход... Дата акта. Конечно данная инфа сохранялась во внешних файлах wba*.xml, но искать там для продавцов была сложной задачей.

Лучше поздно? Добавил ведение, отражение, анализ дат актов на ТТН поставщика.

Два режима ведения.





1. Разово можно провести процедуры автоматического выявления и прописывания инфы по актам в БД. Понятно, что акты должны были подтверждаться в программе. Если было виртуальное подтверждение, то дата акта ставиться равной дате ТТН и его номер "Virtual":
2. Кнопкой Tab можно изменить атрибуты акта в БД, например подправить при переходе даты через квартал.





Так же, при реальном или виртуальном подтверждении ТТН сейчас инфа по акта сохраняется в БД. При просмотре списка ТТН, при наличии по ней актов информация дополнительно отражается в шапке списка:





При анализе, поиске информации программа дополнительно запрашивает ограничители на период актов на ТТН:

Часовой пояс GMT +3, время: 09:29.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.