По теме из базы знаний
- Интеграция сценарного тестирования в процесс разработки
- Разработка и сценарное тестирование с Vanessa-ADD. Концепция, теория и сквозной пример создания сценария
- Разработка и сценарное тестирование с Vanessa-ADD. Практические примеры сценариев. Шаги встроенной библиотеки
- Ценники и этикетки со штрих-кодом для 1С 8.х
- Практические кейсы и примеры создания сценарных тестов с использованием фреймворка Тестирование 3.0
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Можно сделать с лоб, минимальным количеством переделок конфигурации. ПриНачалеРаботыСистемы запросом получить цены на сегодня. Результат запроса выгрузить в таблицу значений. Загрузить ЗначениеИзФайла сохранённую при прошлом ПриНачалеРаботыСистемы таблицу цен. Сохранить ЗначениеВФайл новую таблицу цен, полученную запросом. Сравнить две таблицы значений банальным перебором. Результат показать. При большом количестве номенклатуры работать будет довольно медленно, и не будет показывать цены, изменяемые в течении дня.
ЛУчше будет работать другой вариант.
Создаём справочник, в котором будем хранить изменение цен. С реквизитами ДатаИзменения, ВремяИзменения, Номенклатура, ТипЦен, СтараяЦена, НоваяЦена, Пользователь. Модицифируем форму справочника цены, обработки ФормированиеЦен и ОбновлениеЦенИзДокумента (и всё, что еще в конфигурации найдется, где можно цены поменять), что бы при изменении любой цены факт этого записывался в справочник. ПриНачалеРаботыСистемы или по желаниб пользвателя примитивным запросом выбираем из справочника с даты/времени последнего просмотра изменения цен (сохраняем с помощью СохранитьЗначение при каждом просмотре истории изменения цен) по текущий момент. Результат запроса выводим, например, в отчет. Или тупо показываем на экране таблицу значений.
ЛУчше будет работать другой вариант.
Создаём справочник, в котором будем хранить изменение цен. С реквизитами ДатаИзменения, ВремяИзменения, Номенклатура, ТипЦен, СтараяЦена, НоваяЦена, Пользователь. Модицифируем форму справочника цены, обработки ФормированиеЦен и ОбновлениеЦенИзДокумента (и всё, что еще в конфигурации найдется, где можно цены поменять), что бы при изменении любой цены факт этого записывался в справочник. ПриНачалеРаботыСистемы или по желаниб пользвателя примитивным запросом выбираем из справочника с даты/времени последнего просмотра изменения цен (сохраняем с помощью СохранитьЗначение при каждом просмотре истории изменения цен) по текущий момент. Результат запроса выводим, например, в отчет. Или тупо показываем на экране таблицу значений.
Если что, в ТиС цена - периодический реквизит. Поэтому можно использовать объект Периодический
Примерно так:
КонДата - например ТекущаяДата(). НачДата - тоже какое-то значение задаешь, либо хранишь в константах, либо вычисляешь (ТекущаяДата()-1 например) и т.п.
Где располагать код, в отдельно запускаемом отчете или запускаемом из проц. ПриНачалеРаботыСистемы() - это опять же в зависимости от задачи. Но, допустим, увидит продавец в начале смены, что цены изменились, и что дальше? Бросится срочно ценники менять?
Примерно так:
Процедура Сформировать()
ИсторияЦен=СоздатьОбъект("Периодический");
СпрЦены=СоздатьОбъект("Справочник.Цены");
//задаем проверяемый тип цен. В примере беру из константы
//можно брать из реквизита формы и т.д. в зависимости от задачи
ТипЦен=Константа.РозничныйТипЦен;
//в ТиС задана сортировка по рекв. "ТипЦен"
//поэтому можно использовать ВыбратьЭлементыПоРеквизиту(......)
СпрЦены.ВыбратьЭлементыПоРеквизиту("ТипЦен",ТипЦен,0,0);
Пока СпрЦены.ПолучитьЭлемент()=1 Цикл
ИсторияЦен.ИспользоватьОбъект("Цена",СпрЦены.ТекущийЭлемент());
СтараяЦена=ИсторияЦен.ЗначениеНаДату(НачДата);
НоваяЦена=ИсторияЦен.ЗначениеНаДату(КонДата);
Если СтараяЦена <> НоваяЦена Тогда
//далее нужный способ вывода результатов
//в примере просто в окно сообщений
Сообщить("===========");
Сообщить("Товар "+СпрЦены.Владелец);
Сообщить("Старая цена "+СтараяЦена+"; Новая цена "+НоваяЦена);
КонецЕсли;
КонецЦикла;
КонецПроцедуры ПоказатьКонДата - например ТекущаяДата(). НачДата - тоже какое-то значение задаешь, либо хранишь в константах, либо вычисляешь (ТекущаяДата()-1 например) и т.п.
Где располагать код, в отдельно запускаемом отчете или запускаемом из проц. ПриНачалеРаботыСистемы() - это опять же в зависимости от задачи. Но, допустим, увидит продавец в начале смены, что цены изменились, и что дальше? Бросится срочно ценники менять?
(5) К этому коду желательно еще предусмотреть контроль, что бы цены позавчерашним числом ни кто не поменял. Он выводит не те цены, которые изменились по сравнению со вчерашним утром, а те, которые начали действовать со вчерашнего/сегодняшнего дня. То есть, формально, задача в (1) не решена. :-)
(6) Для удобства пользователя лучше не показывать изменённые цены на экране, а вызвать печать изменённых ценников. Штатной обработке печати ценников, на сколько помнится, можно передать список номенклатуры, ценники которой нужно распечатать.
(6) Для удобства пользователя лучше не показывать изменённые цены на экране, а вызвать печать изменённых ценников. Штатной обработке печати ценников, на сколько помнится, можно передать список номенклатуры, ценники которой нужно распечатать.
(7) Согласен:
1) НачДата д.б. равна ТекущаяДата()-2, иначе вчерашнее изменение цены не будет фиксироваться.
2) Должен быть запрет на изменение цен "задним числом", т.е. вчера нельзя изменить цену на позавчерашний день. Иначе вчера, например, весь день продавали раков по 3 рубля, а в конце дня изменили цену позавчерашним днём на 5 руб., т.е. формально уже вчера товар продавался по неправильной цене. И вообще должен быть какой-то регламент изменения цен, иначе кто-то будет менять цены направо и налево, а крайним будет продавец.
1) НачДата д.б. равна ТекущаяДата()-2, иначе вчерашнее изменение цены не будет фиксироваться.
2) Должен быть запрет на изменение цен "задним числом", т.е. вчера нельзя изменить цену на позавчерашний день. Иначе вчера, например, весь день продавали раков по 3 рубля, а в конце дня изменили цену позавчерашним днём на 5 руб., т.е. формально уже вчера товар продавался по неправильной цене. И вообще должен быть какой-то регламент изменения цен, иначе кто-то будет менять цены направо и налево, а крайним будет продавец.
vcv пишет:
К этому коду желательно еще предусмотреть контроль, что бы цены позавчерашним числом ни кто не поменял. Он выводит не те цены, которые изменились по сравнению со вчерашним утром, а те, которые начали действовать со вчерашнего/сегодняшнего дня. То есть, формально, задача в не решена. :-)
Для удобства пользователя лучше не показывать изменённые цены на экране, а вызвать печать изменённых ценников. Штатной обработке печати ценников, на сколько помнится, можно передать список номенклатуры, ценники которой нужно распечатать.
К этому коду желательно еще предусмотреть контроль, что бы цены позавчерашним числом ни кто не поменял. Он выводит не те цены, которые изменились по сравнению со вчерашним утром, а те, которые начали действовать со вчерашнего/сегодняшнего дня. То есть, формально, задача в не решена. :-)
Для удобства пользователя лучше не показывать изменённые цены на экране, а вызвать печать изменённых ценников. Штатной обработке печати ценников, на сколько помнится, можно передать список номенклатуры, ценники которой нужно распечатать.
Если несложно опиши как сделать то что выше написано (6)
(8) Не подскажу конкретно. Просто нет под рукой типового ТиС, а тот что есть переделан, слишком сильно. Смотри в форме списка номенклатуры процедуру ПечатьЦенника, там всё вполне прозрачно написано, как сформировать таблицу значений и передать её обработке печати ценников.
(9) По хорошему бы всё равно по другому реализовать. Ну поставишь ты ТекущаяДата()-2 что бы с запасом взять не только вчерашние, но и позавчерашние изменения. В результате, если цены меняются часто, пользователи будут перепечатывать цены, которые уже напечатали вчера и позавчера. Лишний расход бумаги. И всё равно остаётся вероятность не напечатать нужные ценники если, например, магазин не работал пару дней. Например, товаровед поставила новые цены с 1 января и ушла на 10 дней в запой, а кассир-продавец числа 3-го открывает магазин и нифига не видит изменения цен.
Для "запрета задним числом" всё равно менять конфу в нескольких местах. Потому что без изменения конфы будет чисто административный запрет, всё равно пользователи когда-нибудь влезут в заднее число, а валить будут всё на программу, потому что она "не показала".
(9) По хорошему бы всё равно по другому реализовать. Ну поставишь ты ТекущаяДата()-2 что бы с запасом взять не только вчерашние, но и позавчерашние изменения. В результате, если цены меняются часто, пользователи будут перепечатывать цены, которые уже напечатали вчера и позавчера. Лишний расход бумаги. И всё равно остаётся вероятность не напечатать нужные ценники если, например, магазин не работал пару дней. Например, товаровед поставила новые цены с 1 января и ушла на 10 дней в запой, а кассир-продавец числа 3-го открывает магазин и нифига не видит изменения цен.
Для "запрета задним числом" всё равно менять конфу в нескольких местах. Потому что без изменения конфы будет чисто административный запрет, всё равно пользователи когда-нибудь влезут в заднее число, а валить будут всё на программу, потому что она "не показала".
(14) В справочнике Цены в типовой ТиС (если мы обсуждаем типовую конечно) есть реквизит Валюта.
Я речь вёл о том, чтобы использовать существующие объекты и стандартный механизм хранения цен. Получилось не без недостатков, в результате у меня, например, сложилось впечатление, что в общем виде задача штатно не решается. Т.е. должны быть некоторые жесткие ограничения, административные и программные, при внесении изменений в цены.
Получается с одной стороны бесконтрольность при внесении новых цен, а с другой проверка начальством продавца, который к изменению цен в базе отношения не имеет.
vcv в (2) предлагает заменить штатное хранение периодических значений цен на нештатное, либо в справочнике, либо во внешнем файле. Может быть такие способы не приводят к ограничениям, т.е. можно например менять цены задним числом и т.п. из (13), контролировать цены, заданные в Валюте лучше, чем это делается штатно. Не спорю, но и утверждать не берусь. Давайте на этот предмет обсудим варианты из (2) или какие-то другие.
Я речь вёл о том, чтобы использовать существующие объекты и стандартный механизм хранения цен. Получилось не без недостатков, в результате у меня, например, сложилось впечатление, что в общем виде задача штатно не решается. Т.е. должны быть некоторые жесткие ограничения, административные и программные, при внесении изменений в цены.
Получается с одной стороны бесконтрольность при внесении новых цен, а с другой проверка начальством продавца, который к изменению цен в базе отношения не имеет.
vcv в (2) предлагает заменить штатное хранение периодических значений цен на нештатное, либо в справочнике, либо во внешнем файле. Может быть такие способы не приводят к ограничениям, т.е. можно например менять цены задним числом и т.п. из (13), контролировать цены, заданные в Валюте лучше, чем это делается штатно. Не спорю, но и утверждать не берусь. Давайте на этот предмет обсудим варианты из (2) или какие-то другие.
(15) Есть штатный метод получения цены, который учитывает всё, что с ценой может происходить: глВернутьЦену. Просто чтения справочника цен недостаточно.
Я в (2) не предлагаю нештатное хранение периодики цен. Предлагается ввести механизм хранения "цены на ценнике". Потому что по условиям в (1) нас интересует определения единственного факта - сегодняшняя цена отличается от цены на ценнике, висящем на товаре. Все костыли "давайте сравним сегодняшнюю и вчерашнюю цену" полностью задачи не решают. Что бы решить полностью, нужно ввести понятие "цены на ценнике". Где/как она будет храниться (справочник цен, отдельный справочник, реквизит номенклатуры, внешний файл...) и когда запоминаться (обработкой "показа изменений цен" или, например, при штатной печати ценника), совершенно не важно. Это уже технические вариации реализации.
Я в (2) не предлагаю нештатное хранение периодики цен. Предлагается ввести механизм хранения "цены на ценнике". Потому что по условиям в (1) нас интересует определения единственного факта - сегодняшняя цена отличается от цены на ценнике, висящем на товаре. Все костыли "давайте сравним сегодняшнюю и вчерашнюю цену" полностью задачи не решают. Что бы решить полностью, нужно ввести понятие "цены на ценнике". Где/как она будет храниться (справочник цен, отдельный справочник, реквизит номенклатуры, внешний файл...) и когда запоминаться (обработкой "показа изменений цен" или, например, при штатной печати ценника), совершенно не важно. Это уже технические вариации реализации.
(11) А что есть "прошлый" и "текущий"? А если сегодня кто-то взял и изменил цену на вчера? А если магазин вчера не работал (выходной, праздник, инвентаризация, проверка, форсмажор)? А если цену на какой-то новый товар уже установили, а наличия еще нет, завоз будет через несколько дней? Я уж молчу о том, что в ТиС есть штатный функцинал расчитываемых цен, учесть который пока ни кто не предложил. И к чему, собственно говоря, был ваш комментарий, если то же самое уже было предложено в (5), притом вместе с куском кода?
Согласен с vcv. глВернутьЦену снимает большую часть вопросов. У меня в рабочей базе механизм отслеживания изменившихся цен, синхронизации с другими базами основан на ней. Единственная проблема - изменение цены "очень задним числом". Но и она решаема административно.
(17)
Так может расскажете об используемом Вами механизме. На какие даты сравниваются цены, т.е. какие даты передаются в качестве параметра в функцию глВернутьЦену ?
(16)
При условии "обратной связи", пожалуй механизм будет работать. Т.е. создается некий справочник с реквизитами НоваяЦена, СтараяЦена, Номенклатура (или справочник подчиненный справочнику Нооменклатура)
При изменении цен меняется реквизит НоваяЦена, после формирования и просмотра продавцом списка измененных цен СтараяЦена становится равной новой цене.
gratis74 пишет:
У меня в рабочей базе механизм отслеживания изменившихся цен, синхронизации с другими базами основан на ней.
У меня в рабочей базе механизм отслеживания изменившихся цен, синхронизации с другими базами основан на ней.
Так может расскажете об используемом Вами механизме. На какие даты сравниваются цены, т.е. какие даты передаются в качестве параметра в функцию глВернутьЦену ?
(16)
vcv пишет:
Предлагается ввести механизм хранения "цены на ценнике".
Предлагается ввести механизм хранения "цены на ценнике".
При условии "обратной связи", пожалуй механизм будет работать. Т.е. создается некий справочник с реквизитами НоваяЦена, СтараяЦена, Номенклатура (или справочник подчиненный справочнику Нооменклатура)
При изменении цен меняется реквизит НоваяЦена, после формирования и просмотра продавцом списка измененных цен СтараяЦена становится равной новой цене.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот